Planning for Reality

Craig Letavec, PMP, PgMP, MSP Waynesville, Ohio, USA

It's amazing how often software projects 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 trials of managing the very fluid environment of software development are many.

The pace of development will naturally vary throughout the life of the project. Sometimes you are ahead of schedule, sometimes behind. Often project managers seek to control these fluxuations through strict, detailed 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 managers 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 lifecycle of the project. Try introducing “buffer time” or “reality time” into your schedule at each phase of your software development lifecycle (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 four days of buffer 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. “Non-productive” time is the first thing managers will want to eliminate when they review your schedule. 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 technique works best when you are not already buffering each of your task durations by routinely adding additional time to each activity to deal with the unknown.

Try it. It works!