Improve your crystal ball--using agile concepts in project planning
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.
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.
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.
Planning Complex Projects Demystified
For large or long-running projects, it is useful to take a phase-or stage-based approach to planning. A project can be decomposed into multiple components, each of which can be planned independently. Each subcomponent can have its own target dates, budget, and deliverables.
In traditional “waterfall-style” planning, the decomposition is often aligned to a development phase: requirements gathering, design, build, test, and delivery. At the conclusion of each phase, a phase-gate review occurs where the results of that phase are presented to the stakeholders and the project is evaluated. This is an opportunity to assess and adjust the project. At each gate, the stakeholders will either give authorization for the project to precede or give guidance that the project should be terminated.
A project may also be decomposed into time boxes, planning only the work that can be completed in a given period. This type of planning is particularly common when the budget is managed on fixed time boundaries (e.g., quarterly, semi-annually, yearly) and the project is budget constrained. The project manager may plan how much scope can be completed (and at what level of quality) given how much money is available to be spent in the given budget period.
A third approach to breaking down a large project is by product or deliverable. This works well when each deliverable is being handled by a different group. Imagine the construction of a home where there are distinct blocks of work for laying the foundation, framing the building, enclosing the structure, finishing the interior, and landscaping. For the purposes of planning the project, each of these could be an individual phase with its own timeline, budget, and deliverables.
Decomposing a project into different phases—whether they are aligned by process, time, or deliverable—makes it easier to plan a large and complex effort. It is exactly this type of planning that may benefit from the concepts in Agile software development.
Predicting the Future Versus Managing Expectations
Project managers often feel that they are asked to predict the future, to know what is unknowable, and to be more or less infallible. They may spend considerable time and effort trying to produce the perfect plan and then to pad it in all the right ways so that it is achievable. The tools outlined above may be thought of as ways to instill some certainty and control around an unknown future, but I submit that this is incorrect. These tools are in fact about communication. They provide a mechanism for communicating commitments to project teams and stakeholders. They give the project manager a language with which to express the uncertainty and difficulty in delivering a project.
The successful project is the one where both business needs and stakeholder expectations are met. These tools give the project manager a way to set and to manage those expectations. At the end of a project, be it 2 weeks or 2 years, the project manager is evaluated on how well their project delivery matched commitments. This can be a fairly binary “success/fail” measurement. If the project manager delivers 3 months late on a 2-year-long project, it may be considered a failure by stakeholders because “you didn't meet the schedule,” or it could be considered a glowing success when a valuable project is delivered to the company. It's all a matter of the project stakeholders' perspective.
Imagine, then, the 2-year-long project that is delivered 3 months late. During the lifespan of that project, there would have been numerous successes—milestones met, products and processes created, work completed. Why, then, should the success of the project and the project manager be measured only at the end?
The Lessons of Agile
In software development, there is family of “iterative development” methodologies, including Agile, RAD, Lean, Extreme Programming, and others, all designed to adapt quickly to a changing business environment. They measure progress on the rapid and frequent delivery of working software. Many excellent resources exist that explain these techniques in depth; discussion of these is beyond the scope of this paper.
At their core, Agile methodologies are interactive in nature, breaking down complex tasks into small, time-bound activities called “cycles.” These blocks of work are then prioritized based on the customer's needs. The cycle begins with the development team and customer working closely together to define requirements for the top priority item, after which coding and testing commence. Most importantly, at the end of each cycle, a usable component is delivered to the customer for acceptance—thus, each cycle is an opportunity to provide value to the customer.
Because the Agile methodology is iterative in nature, each cycle builds on the lessons of the ones that came before it. This is true for both the development team, which can adjust programming approach, and the customer (business team), who can adapt to changing business conditions.
A key tenet of Agile is that the development team and customer collaborate closely on each cycle. The business team has the opportunity to refine or outright change their priorities or requirements entering the cycle. This approach recognizes that the business is also trying to plan for an unknowable future and allows the development team to adapt to the changing priorities and needs of the business.
In a development effort using a 2-week cycle time and running for 1 year, it is not unreasonable to expect that the development team could complete 20 cycles and thus have 20 opportunities to deliver value to the customer—each time aligned with the customer wants most. It is easy to see how this is an attractive approach.
The philosophy is codified in The Agile Manifesto (Beck et al., 2001):
We are uncovering better ways of developing software by doing it and helping others to do it.
Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Although Agile is focused on software development and is not a generic project management methodology, it provides some excellent lessons about working with a customer. These lessons clearly apply to the concept of managing customer expectations and thereby extend to measuring project success.
Ask Not How Your Phases Define Value, But How Value Defines Your Phases
Consider, then, the Agile project concept above—20 times during a year the development team had an opportunity to understand and then meet the customer's expectations. This means there were 20 measureable events by which one could evaluate project performance against cost, schedule, scope, and quality. The following example may be extreme, but it illustrates a powerful concept: Imagine decomposing a project into manageable pieces, and for each piece applying planning best practices; however, when breaking the project apart, rather than doing it by phase, time, or even deliverable, do it instead by things that provide the customer with something he or she can use, something of value. Further, imagine doing it in such a way that the customer has some level of input on what is worked on next. On such a project it would be appropriate to make commitments (set baselines) for each stage of the project, one by one, and to measure and take credit for the success or failure of each commitment on its own. Planning a 2-year project in this way might enable the project manager to have a dozen different “success/failure” moments, and at the end of the project, the project manager could be evaluated on how many of those commitments were met versus missed.
Using this type of thinking, the construction of a house might be decomposed differently. Instead of breaking the project down into products aligned by functional groups (concrete, framers, finishers, landscapers), it could be decomposed into products that provide value to the end customer. The homeowner would find little value in the framed-up shell, so why choose that as a phase? The customer would find value in usable deliverables such as a fully enclosed (and thus weatherproof) structure, working utilities (plumbing, electricity), finished rooms that are move-in ready, and landscaped property with curb appeal. At each of those points there would be something new the customer could use, even if the project ended at that point.
In addition, the customer may be able to rearrange the order in which some things happen to suit his own needs. For instance, the customer may want to reconsider his choice of bathroom fixtures, so pushing the interior finish work back may allow him time to make those decisions. Imagine that the customer designed the house himself or herself and was submitting photos to an architectural magazine. A looming submission deadline might find him wanting a fully landscaped yard outside the completed structure before having working utilities and finished rooms. Giving the customer some control over the priority of the tasks and input into their design while delivering things of value to him will surely improve customer satisfaction with the final product.
I have been able to successfully apply these concepts on a real-world IT project. We were addressing an audit finding and senior management had committed that the fix would be in place in 6 months. We began in the traditional way, scoping out the problem and gathering customer requirements. We developed a design to meet the needs and then decomposed it into software modules. Working backwards from our fixed date we determined how much time we had to build each module and presented a high-level “waterfall-style” plan to the executives to gain commitment. Once coding began we brought the customers into multiple meetings each week to collaborate on the solution. We would probe, challenge, discuss, and constantly walk through use cases. As our understanding deepened, we began to identify places where the new tool would strengthen existing processes and replace legacy tools. I gathered these use cases and began refactoring the project plan to be about solving the use cases rather than delivering software components.
I laid out a plan showing month by month which of the old processes and tools we would provide solutions for. We went back to the stakeholders and proposed throwing out the original plan. In the new “replan” we showed them how month by month we would deliver value to the company, improving the existing processes and tools one-by-one along the way. Rather than spend 6 months coding and deliver a monolithic solution at the end of the project, we found a way to gradually improve things, addressing the audit finding little by little over the 6-month time frame. After the first 3 months, the internal audit team stated that the finding had moved from a high-to medium-risk item because of the improvements already delivered. This delighted our sponsors, one of whom went on to say, “This is the first time I've seen a project replan that brought the project in early!” In fact, we did not bring the project in early; what we did was bring some of the value in early.
I began reporting status where each milestone was a release of a “new feature deployed and legacy process retired.” I tracked a separate commit date for each “release” and counted it as a commitment made or missed. By having pieces of our software and processes in the hands of the customer early, we'd learned how to make them better as we went, a project quality benefit that wasn't our prime driver but was a pleasant side effect. Over the next 3 months we completed the remaining components and spent time improving the interfaces that we'd built early on. The net result was highly satisfied customers and stakeholders. In the end, I reported seven legacy processes and tools retired or improved, only one of which missed the committed date. The project was seen as a great success and in my performance evaluation I was able to report that I met customer expectations six out of seven times (86%), which was a much more precise and meaningful metric for 6 months of work than a single “project on schedule” measure at the end. Running multiple large projects this way over the course of the year would enable me to show my value as a project manager, meeting customer expectations far more often than not, even if I were to be on a troubled project that missed its final due date.
Planning a project in this way—breaking the project into phases that deliver value, committing to (baselining) one phase at a time, and adjusting the sequencing of phases to meet business needs—provides an opportunity to gather metrics each time value is delivered, multiple times during the project. This in turn influences how project progress is communicated to stakeholders and ultimately how the success or failure of the project is measured.
At the end of a 2-year-long project the conversation could be:
“The project was able to deliver value to the customer and met expectations 11 out of 12 times, delivering late just once.” (92% on time, 100% on scope, 100% on budget)
Or it could instead be:
“After 2 years, this project was 3 months late but met its full scope and budget commitments” (0% on time, 100% on scope and on budget)
Which project would you rather be remembered for?
Beck, K., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., et al. (2001, February 13). The Agile manifesto. Retrieved September 2, 2009, from http://agilemanifesto.org/
Office of Government Commerce. (2009). Managing Successful Projects with PRINCE2 (PRINCE2™) (5th ed.). London: The Stationery Office
Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK® Guide)— Fourth edition. Newtown Square, PA: Author.
Siegelaub, J. M. (October, 2007). Six (yes, six) constraints: A new model for project control. PMI Global Congress 2007—North America, Atlanta, Georgia, USA.
© 2009, Brian Herman
Originally published as a part of 2009 PMI Global Congress Proceedings – Orlando, Florida, USA