Think about it for a minute – what have you done in the last six months to improve your cost management?
Review the projects you’ve completed in the last year. How many of those projects came in over budget?
Consider John, a savvy project manager, who was asked to manage a project to replace a dated network system. The project sponsor told him that he had $100,000 for the project. When John asked the project sponsor how the $100,000 was estimated, but he never got a clear answer.
As John started the project, he checked the historical records of similar projects as well as some other companies. His early estimate — an analogous estimate — was $125,000 with a range of accuracy between -25 percent to +50 percent. John shared the estimate with the sponsor and said that he would provide a more detailed estimate after completing a work breakdown structure (WBS) with the project team.
The team used the WBS to complete a bottom-up estimate, estimating each project activity and rolling the individual estimates up to higher levels and ultimately to a project total. John reported the revised estimate of $120,000 with a range of accuracy of -5 percent to +10 percent. The sponsor increased the budget to $110,000.
John worked with the sponsor and the team to find ways to further decrease cost. What could be excluded? How could the team get discounts when purchasing the equipment, software, and wiring?
Cost management is rarely a straight shot. We zigzag, don’t we? We give and we take, and we attempt to find ways to deal with the budget constraints we face each day. (If you have a spouse and children, you probably already understand these principles, huh?) Let’s look at some ways to improve your cost management.
The Problems with Crashing, Fast Tracking, and other Schedule Compression Techniques
How do project managers unintentionally create schedule risks? As a result, perhaps you feel a cloud of uncertainty about your schedule.
Image courtesy of Adobe Stock.
Many times, it starts with pressure from a sponsor to deliver the goods early. For sure, project managers have a responsibility to work with their sponsors to understand the requirements and to complete the projects within the sponsor-imposed deadlines. Rather than wasting our time complaining about the deadlines, how can we work with our sponsors and team members to find solutions to schedule issues?
As we work to develop and compress our schedules, let’s be aware of the common causes of risk. We will be in a better position to manage the risk and deliver our projects on schedule.
5 Causes of Schedule Risk
Crashing the schedule. It’s always been funny to me that the Project Management Body of Knowledge uses the word “crashing” as a schedule compression technique. The term makes me think of an uninvited guest crashing a party, but with schedule management, the individuals are actually invited to the party. Project managers use crashing to shorten the schedule for the least incremental cost by adding resources, typically to the critical path. It can be a great technique — just be aware — crashing may increase your risk. Too many cooks in the kitchen spoil the broth.
Fast tracking. Here’s a technique to shorten the schedule by performing activities in parallel for at least a portion of their duration. For example, we might start work on a software design while the team is working on the requirements. Consequently, this technique may increase your risk and requires good communication and coordination; otherwise, it may be anything but fast.
Assigning the wrong resources. You ask a manager for a resource for your project. In return, you get the person who is least busy, not the skilled resource you need. Rather, Susan, an experienced project manager describes specific skills needed and uses her influencing skills to persuade the manager, greatly improving her chance for securing the queen resource. What’s a project manager to do when resources are preassigned?
Making sequence mistakes. John, an inexperienced project manager, failed to work with his team to sequence the project activities properly, resulting in issues which were discovered after the schedule was approved. As a result, John has learned to engage his team members when identifying and sequencing future project activities.
Failure to baseline your schedules. The project manager and team did a great job in breaking down the project, identifying activities, and creating the project schedule. However, the project manager failed to get approval for the schedule. What happened? Yes, the schedule changed. The team did not have a baseline for comparison resulting in significant uncertainty about the health of the project. Like building a house without a plumb line, who knows if the walls are straight?
Question: What other ways have you seen project managers unintentionally create schedule risks?
What tips do you have for breaking down your project into deliverables and activities?
I asked this question on LinkedIn: What tips do you have for breaking down your project into deliverables and activities? Bill Duncan responded with the following tips (which I thought were great):
Recognize that “work packages” are only the lowest level of the WBS from the buyer’s perspective in a contracting environment.
Recognize that any deliverable can be described as an activity (by adding a verb) and any activity can be described as a deliverable (by removing a verb). Don’t worry about the distinction until you have the decomposition done.
Decomposition happens phase-by-phase. You can’t develop a complete WBS for a non-trivial project at the start.
When you are confident that you can estimate cost and duration, you have enough detail.
Every lower level must be both necessary and sufficient for the item above it.
Steven Pressfield said, “A great trick that I learned having worked as a screenwriter for many years, the way screenwriters work, is they break the project down into three-act structure: Act 1, Act 2, Act 3. I think that is a great way to break down any project, whether it’s a new business or anything at all.”
Image courtesy of Adobe Stock
Whether we are creating a Pixar movie, a building, a highway, or a service center, wise project managers break down their projects into pieces. As we do, we create a structure for the project that helps stakeholders understand the project.
Some people struggle with the challenges of creating large, complex systems, highways, and companies. How can we do this? The answer: one bite at a time. Breaking projects into pieces makes the impossible possible. In addition, the break down creates the vision.
Some project managers struggle to identify scope risks. Why?
Image courtesy of Adobe Stock
First, individuals may lack a concrete understanding of scope; scope seems to be a nebulous concept. WHAT exactly is scope?
Second, individuals may not know HOW to identify scope risks.
Either way, the failure to identify (and manage) scope risks can be costly. It’s like an overdrawn bank account. There are all kinds of penalties and fees if you know what I mean.
What are Scope Risks?
Risks are uncertain events or conditions, that if they occur, will have a positive or negative effect on the project objectives. What are some examples of scope-related risks?
Individuals may add features to the product that were not approved.
The project team may not identify all the deliverables, requiring changes later.
Scope changes may not be processed through the change control process.
Requirements may not be properly analyzed and understood.
Requirements may change and affect the deliverables.
Requirements may not be properly prioritized.
The design may be simplified resulting in less effort and cost.
Traceability structure may not be developed resulting in requirements not being managed through the design, development, and testing processes.
The project team may fail to identify all the activities required to create the deliverables.
Keep in mind that scope is the sum of the products, services, and results to be delivered through the project. Product scope includes the features and functions of the products, services, and results. Project scope is the work required to create the deliverables.
Why is scope management so difficult? What enemies cause us scope issues?
Let’s first consider the essence of scope management: “to ensure that the project includes all the work required, and only the work required, to complete the project successfully,” according to the Project Management Body of Knowledge (PMBOK). Let’s take a look at each part of this statement.
Enemy #1 – Not Including All the Work
Some project managers have a bad habit – they create their project plans with little input from the stakeholders. What’s the result? The project manager may miss key deliverables. They do not have ALL the work required in their project plan.
In his book — Just Enough Requirements Management — Alan Davis shares, “Various studies suggest that errors introduced during requirements activities account for 40 to 50 percent of all defects found in a software product.”
Photo courtesy of Adobe Stock
What are Project Requirements?
Project managers talk about this topic a lot. Stakeholders hear the term “requirements” but interpret the meaning in different ways. Before we can manage anything, it’s critical that we have a working definition.
Requirement: something that is needed or that must be done. –Merriam-Webster Dictionary
The Project Management Body of Knowledge defines requirement as “a condition or capability that is required to be present in a product, service, or result to satisfy a contract or other formally imposed specification.”
Karl Wiegers — author of Software Requirements — shared this definition: “Requirements are a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute.”
5 Questions for Developing a Scope Management Plan
How can you develop a scope management plan quickly that provides value to the project? It’s not as complicated as it may seem.
Photo courtesy of Adobe Stock
Some project managers check the Project Management Body of Knowledge (PMBOK) for advice, which I think is a great place to start. However, project managers may make the following mistakes: Individuals may see the PMBOK as a prescription and include every element for every project. On the other hand, some people see all the “required steps” and throw their hands up, deciding to do nothing.
I am a simple guy that likes simple ways of doing things. I use the PMBOK as a guide, but I determine which parts make sense for each of my projects.
Here are some questions I answer when developing a scope management plan:
Although this video focuses on community projects, the questions presented in the video apply to for any type project. I recommend that you develop a project charter prior to developing your project plan. Here’s a checklist to help you with your project plan.
Have you left anything out of your project plan? Check out this project plan checklist to help you identify the baselines and plans that will be most helpful to each of your projects.
I like to keep my project plans as simple as possible. For many project plans, I will only have three or four of the items in this checklist. But I like to make sure that I’ve not skipped something that was needed.
As I define my baselines and plans, I strive for clarity, brevity, and simplicity. My aim is the create a project plan that is easy to understand and that helps me and the project team achieve the project objectives.
Image courtesy of Adobe Stock (edited in Canva)
Project Plan Checklist
Project Scope Statement – describe product(s), project work, major deliverables, assumptions, and constraints
Work Breakdown Structure – create a hierarchical decomposition or outline of the scope of work to achieve the project objectives and to create the deliverables
Work Breakdown Structure Dictionary – provide the detailed information about the deliverables, activities, cost estimates, and scheduling information for each item in the WBS
Schedule Baseline – approved version of the schedule
Cost Baseline – approved version of the project budget