Frustrated by a cheap crystal ball? Nostradamus not returning your calls? Rethinking how you commit to project deliverables may bring the relief you seek.
We expect the TV weather crew to accurately predict only 7 days ahead, but they rarely pull it off. So why do your stakeholders expect you to be able to commit to a date and price tag for a project that may run a year or longer? Like the weather, your project is subject to hundreds of influences, both small and large, that are often beyond your control and can significantly change the outcome.
When your project completes, you’ll be asked, “Were you on-time, on-scope, and on-budget?” regardless of how long ago the project began. During the course of your project you achieved many milestones—did you get “credit” for meeting those, or is your worth as a project manager being evaluated solely on your ability to predict the future of a long-running project?
There are multiple techniques for setting achievable baselines using best practices from the PMBOK and PRINCE2 concepts such as schedule padding, contingency budgets, and rebaselining. These are the basics, but there are more advanced techniques, such as tolerances and phase-based planning, that can be applied. Beyond these, it is worth exploring the planning philosophy from Agile Software Development and how it can improve the impressions that project stakeholders have of project success.
Agile planning is based around short-duration tasks that deliver value to the business. These ideas can be applied to planning on any type of project and can lead to different ways of measuring successful outcomes that extend beyond the notion of binary “success/fail” measures for cost, schedule, and scope at project closure.
The Basics – Baselines, Overestimation, Padding, and Slack
Project stakeholders look to their project manager for one thing and one thing only—on-time and on-budget delivery of their project. Early in the project they are expecting a commitment that the entire project will be delivered by a certain date for a fixed cost.
The project manager and project team are expected to develop a plan that includes the schedule, budget, and resourcing needs that will meet the requested scope. No matter how “draft” that plan is, once it is communicated to the stakeholders, they will see it as a commitment. This is the essence of baselining—defining a plan, communicating it, and gaining commitment from the project team and stakeholder. The baseline can be as formal as a signed contract or as informal as a hallway conversation. At some point, the project stakeholders will expect a commitment to an uncertain future and they will hold the project manager to it.
A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fourth edition (Project Management Institute [PMI}, 2008) describes the development of project commitments in building the Project Management Plan. PRINCE2 prescribes formalizing the baseline in the form of a Project Initiation Document (PID). The PID records the original project scope as well as the cost, schedule, and quality commitments. Having these commitments documented and approved by the project stakeholders is the foundation for controlling a project; for just as the stakeholders will hold the project manager to the cost, schedule, and quality estimates, the project manager can now hold the stakeholders to the scope estimate. Without an agreed baseline, the project manager has no hope of managing expectations or of believably measuring success at project end.
Baselining is thus the first and most basic tool that the project manager will use to control a project. Developing the detailed plan behind this baseline is a crucial activity for the PM. The quality of the plan is impacted by assumptions and risks, both known and unknown. There is a suite of tools that the project manager can use to account for uncertainty in the plan. Some of these tools are built into the plan itself, while others are companions to the plan and are used after the baseline is set.
Rebaselining is a companion tool that allows a project manager to manage expectations if things have gone off plan. When it is clear that a project will not meet one of the baselined commitments, the project is typically considered “red” to the original plan. Once the project manager has fully explained what has gone wrong and has identified impacts to the project, the first question typically asked by stakeholders is “well, what can you deliver?” Analysis should be done to replan the project with the project team. The updated plan should be presented to the stakeholders to regain their support and commitment to go forward. (In an extreme case, the project manager may even suggest that the project be stopped, but that is another topic).
Rebaselining is a powerful tool for managing expectations and should not be used recklessly, because doing so can damage credibility. However, when a rebaseline is warranted, the project manager should not shy away from it. The project manager should do everything possible to ensure that the new plan is achievable and then work to win back the confidence of the team and stakeholders.
Suggested Read: How can project manager improve on time management?
Overestimation is the most common way of dealing with uncertainty in the planning process. There are unwritten rules of thumb such as “build your plan and then double it.” Although often said in jest, such crude techniques are often all that an inexperienced project manager has in the tool belt. The most sinister part of overestimating is that it can occur at all phases of the plan’s construction and communication process. The project members will overestimate their work when communicating it to the project manager, the project manager will assemble the combined inputs and in turn overestimate them before communicating them to the stakeholders, and sometimes the stakeholders will throw in a bit more “fudge factor” before they talk to their superiors. By the time these plans are presented, they bear little resemblance to reality and a fairly typical response of stakeholders is “That sounds good, but cut the time in half.” We’ve all been there! Note that overestimating can occur not only in the construction of the project’s schedule but also when building the budget. Again, the adage “take your budget and double it” is a common and unfortunate occurrence.
Padding and slack are somewhat more sophisticated techniques in project planning. Padding is a close cousin of overestimating but is used more judiciously. The project manager will add time to those tasks with a high degree of uncertainty around them. Such tasks could be ones beyond that are beyond the project manager’s control, perhaps the ordering and delivery of equipment. Another place that padding gets added is with tasks that are new or groundbreaking, or for which there are no historical examples to base the plan on, such as research and development effort. The degree of padding added to a task can be varied based on the degree of uncertainty around it. Using this method, the project manager can build a much more realistic plan, putting zero padding on well-known tasks, light padding on some potentially tricky tasks, and heavy padding on the big unknowns.
Building slack into a plan is similar to padding; however, slack is typically more visible in the plan. The project manager may add in time after a troublesome task such as “2 weeks for bug fix” or “1 month for inspection and approval.” These sorts of tasks inflate the project plan with activities that seem reasonable but are often just “freebies” that allow prior tasks to run late without pushing the entire project off schedule. Some project managers will even openly list slack in the schedule and explain the reason for it—to accommodate the unknown.
The concept of padding is easily extensible to budgets as well, adding extra dollars to the estimates for items with unknown or variable costs. The concept of “slack” doesn’t extend as neatly to budgets and may often be confused with contingency, which is not at all the same thing.
Also Read: Agile innovation and the project manager
Moving Beyond the Basics – Contingency and Tolerance
Two of the more advanced planning techniques are often confused with one another. Contingency and tolerance are both ways of addressing uncertainty in a project plan, but they are actually quite different tools. Each is a method for giving the project manager more control over the project without requiring rebaselines or other project stakeholder intervention. In a way, each defines the amount of authority that the stakeholders are giving the project manager to make decisions about the project. These decisions can impact the baseline commitments but the stakeholders will still accept the outcomes as though they were perfectly to plan.
Contingency is most typically thought of in terms of budget and is sometimes incorrectly thought of as budget slack. During the initial planning of a project, the project manager may ask the stakeholders for a contingency budget. This pool of money is not there to cover for mistakes in budgeting planned items, but rather is there for dealing with the unplanned things that may come up in a project (threats and opportunities). An example will go a long way to explaining the difference:
Susan is the project manager for the development of a new pain medication at a pharmaceutical company. Her team has budgeted US$1,000 for research and development and US$100 for the government approval process, for a total project cost of US$1,100. In addition, Susan has asked for a US$300 contingency budget for the project.
During the course of the project, the team discovers that the new pain medication can be combined with an existing allergy drug and the net effect lowers blood pressure (a business and project opportunity). The project manager uses the contingency budget to pick up the additional R&D for the new combo drug and put it through the government approval process along with the new pain medication. Susan expends the entire original budget plus contingency for a total cost of US$1,400. This is an appropriate use of the contingency budget.
On another drug development project, William has copied Susan’s successful formula for budgeting. During the R&D process, nothing surprising is uncovered but the new drug is still successfully readied for the approval process. However, during approval there are problems and much rework is required. The total R&D expenditure is US$1,100 and the rework in approvals costs a total of US$200. In this case, the total project cost is US$1,300. William believes he can use his contingency budget and still finish “green” to his original baseline, but he is wrong. The contingency budget is to be used to address the unknown, not to cover for imperfect planning. William’s project closes US$200 over budget.
The use of contingency to address the unknown rather than for covering a missed budget is a subtle but important difference. The astute project manager will ask for a contingency budget, outlining the conditions for its use, to allow him or her to take advantage of opportunities or address problems without having to go to the project stakeholders for approval. The project manager should be a responsible steward of this money, always communicating the financial picture and returning unneeded contingency funds as early as possible so that the organization can use the funds in other ways. The project manager should never dip into the contingency to cover for mistakes in the budgeting process or imperfect estimates of costs. There is a different tool to address that problem.
Note that the concept of contingency can be extended to scheduling as well. A request for contingency reserve is often an output of Estimating Activity Duration.
Tolerance, like contingency, affords the project manager greater control over project outcomes without having to resort to rebaselines and project stakeholder intervention. Tolerances can be applied to any commitment in a baselined plan, although the easiest to understand are schedule and budget tolerance. The idea is simple: the project manager communicates a commitment but with an acceptable envelope of deviation. This envelope allows the project manager some “wiggle room” to account for uncertainty in the plan. This is a more mature approach than the overestimation and padding techniques.
In the budget example above, William could have requested a 20% budget tolerance on his US$1,100 budget to account for the uncertainty and difficulties in something as complex as developing a new drug. This tolerance would have let him complete the project anywhere in the window of uS$880 to US$1320 and still be considered “on budget.”
Tolerance can be applied to most any project commitment. It is often expressed as a plus/minus from the commitment (particularly with budget), but any expression of acceptable deviation will work. Schedule can be quantified as “complete in 4 months, plus or minus one week;” scope can be stated “with at least five of these six features;” and even quality can be expressed with a tolerance such as “with no more than three severity – two bugs.”
Project stakeholders do not typically offer tolerances to the project manager. It is up to the project manager to request tolerances on the project plan commitments as appropriate. There are two major factors to consider when proposing tolerances: what is fixed, and what is uncertain.
The project manager must recognize the most critical constraint in the eyes of the project stakeholders. Some projects are time-bound, others budget-, scope-, or even quality-bound. Recognizing the fixed constraint guides the project manager to define tolerances for the other constraints (ref). For example, on a project with a fixed end date, the project manager should consider tolerance for budget and probably scope—these give the project manager latitude to meet the date.
The other major consideration is the amount of uncertainty and risk in the project. During planning, if costs are unpredictable, then a budget tolerance would be important. Schedule contingency may be useful on a long-running project as things change over the project’s lifespan. Beyond the uncertainty in the plan, the project manager must also consider the risks to the project as a whole. If there is a transportation strike looming, for instance, the project manager may want to ask for schedule (and perhaps budget) tolerance to allow for alternative means of getting materials. If the project takes place near the corporation’s fiscal year end, then the project manager may want schedule tolerance to allow for delays when resources are redirected to focus on year-end close activities. All of the risks and uncertainties should be considered when proposing project tolerances.
Tolerance is a powerful tool for managing the uncontrollable aspects of a project. It gives the project manager the ability to meet expectations without having to hit an exacting target.