Planning for Reality

Planning for Reality

Craig Letavec, PMP, PgMP, MSP Waynesville, Ohio, U.S.
IT’S AMAZING HOW OFTEN SOFTWARE PROJECTS tend to fall into late, over-budget, off-quality situations. Even in highly touted software shops with international certifications and maturity assessments lining the walls, the tri- als of managing the very fluid environment of software development are many.
The pace of development will naturally vary throughout the life of the proj- ect. Sometimes you are ahead of schedule, sometimes behind. Often, project managers seek to control these fluctuations through strict, elaborate project timelines that lay out prescribed task assignments and deadlines. However, they find themselves making multiple revisions to the plan along the way to deal with the dynamic nature of creating software.
While the development and execution of a detailed, keenly estimated project plan is important in the success of any project, many software project manag- ers may find some benefit in adding some “reality time” into their plans.
The critical chain method uses the concept of “buffers” as one means to deal with inherent variance over the life cycle of the project. Try introducing “buf- fer time” or “reality time” into your schedule at each phase of your software development life cycle (design, coding, testing, etc.).
Buffer time allows for a degree of flexibility within a phase without the need to perform major scheduling adjustments. Think of this buffer time as a time contingency reserve for the phase. The process is fairly straightforward. Look at each phase of your project, consider the total duration of the phase based on your best planning, and then add a buffer task at the end of the phase that has a duration of a percentage of the total phase duration, say 10% or so.

           For example, on a 40-day total duration for a design phase, add 4 days of buf- fer time to the end of the phase, for a total phase duration of 44 days. Will the phase actually take 44 days? Perhaps not, but the “unused” time can then be either carried forward or added to future buffers.

As experienced software project managers know, projects may proceed on schedule during the early stages, only to end up dragging on later in the process. Getting ahead of the curve almost always has more advantages than disadvantages.
Expect skepticism the first time you try this approach. “Nonproductive” time is the first thing managers will want to eliminate when they review your sched- ule. Stand your ground. Make the simple point that you are performing basic schedule risk management.
If you have a phase of the project that is riskier than another, add more buffer at that point. You may be able to add less of a risk buffer in other spots on the timeline.
Last, make sure that you are not “double-dipping.” Double-dipping would be adding extra time at the task level and then again at the phase level. The tech- nique works best when you are not already buffering each of your task dura- tions by routinely adding extra time to each activity to deal with the unknown.
Try it. It works!