Anticipate the Unanticipated

The key to quality project planning is planning for the worst, and the worst of the worst is the unexpected. How can one anticipate the unanticipated?

Software engineering as a discipline has existed for maybe 20 or 30 years. Even electrical engineering is a young 130 years old. By comparison, man has been making war for over 12,000 years, and the science of military planning has a rich history that we can learn from. War, being little more than organized chaos, mandates planning for the unexpected.

Battlefield Reserves

Military planning anticipates the unanticipated using reserves. When a division (approximately 10,000 soldiers organized into three ground brigades) enters the battlefield, it will normally advance with two brigades, and hold one brigade in the rear, just a couple of hours behind the main action, as a tactical reserve. The reserve brigade is available to exploit an unexpected vulnerability in the enemy's line, or to support a forward brigade if it meets unexpected resistance. Similarly, when a brigade is exhausted from battle, the reserve brigade can move forward and take up the offensive.

On a larger scale, an army corps may engage the enemy with three or four forward divisions, and hold one division in the rear as a strategic reserve, ready to move when a forward division needs support. Moving a division of 10,000 men is no easy task, and it may take days to bring the reserve division fully into the battle. As a result, strategic reserve is no substitute for well planned tactical reserve at the division level.

This same approach can be employed effectively in software engineering projects.

Tactical Reserve

In an engineering project, tactical reserve takes the form of staffing reserve, feature reserve, and schedule reserve.

Staffing reserve is when in the planning phase you load your engineers below 100%. I generally figure an engineer will spend 20% of his time doing non-development activities: attending meetings, doing overhead tasks, sick time and vacation (note that 12 paid holidays and three weeks of vacation is already 10% lost time). Even so, I try to load my engineers at 70%: 20% for overhead plus an extra 10% in reserve. There is additional staffing reserve -- the other 128 hours a week that the engineer is not normally scheduled to work (OK, all 128 hours are not available, but for short periods of crisis, an engineer who normally works 40 hours a week can easily provide an addition 50% to 100%).

At the start of a project, developers may find they can spend 80% or more of their time on planned tasks, and so they get ahead of schedule. Then a problem arises, and the project leader needs to pull one engineer off his tasks to address the problem. Because the engineer was already on the project, there is very little ramp-up time, and the engineer is able to make good progress on the problem very quickly, while making little progress on his planned tasks. But since he was already slightly ahead of schedule, the overall impact is minimal, and if necessary, a little overtime might get the entire project back on schedule.

    [I know several engineers that normally put in 60 to 80 hours a week. Some people like them on their team because they give more than 100%. I don't, because when I need everyone to give an extra 50%, they have nothing in reserve.]
Feature reserve comes from triaging features at the start of a project. I like to categorize features as must-have, nice-to-have and non-features. I try to be up-front that my project will deliver all of the must-have features, and may deliver some of the nice-to-have features. Planning would support the implementation of all nice-to-have features. But when problems arise (and they will), and we run out of staffing reserve, I can start to drop nice-to-have features to protect the schedule. If things go fairly smoothly, we may deliver a product with lots of nice-to-have features; if things go very badly, we might have a bare-bones product, but we will have a product.

Schedule reserve is the project's ability to slip schedule without slipping the release date. That might sound contradictory, but it isn't. As an example, consider a new software feature going into Solaris to support new hardware which will be available in June. The base plan may be to release the feature in a Solaris Update release due out in June. But the testing and release process for a Solaris Update is on the order of three months, so the software would need to be complete by March. On the other hand, the feature could be released as a patch to Solaris; patches cost more to release, but only take a few weeks to test and release, and can be further expedited (at additional cost) to release in a matter of days. The base plan would be to complete the software by March and release with a Solaris Update, but the schedule reserve allows completion to slip until May, or even June, and still release on time (albeit, with added cost).

    [Note: I have no idea when the next Solaris Update release is coming out. The June date is only used as an example.]

Strategic Reserve

Strategic reserve is normally factored into the strategic planning. At a business unit level, the project portfolio may include must-have and nice-to-have projects; and the project schedules may include schedule reserve (for example, we want to release a new feature a year before company XYZ, but it's OK if that lead slips to six months).

When one project runs into problems, management can take people from a different project (one with lower priority, or one with more schedule reserve) and apply them to the problem area. Of course, moving a person from one project to another does require a ramp-up time; the person moving may spend days reading project requirements and design documents, and figuring out where they fit into the project.

Due to the cost of moving strategic reserves, it is imperative that every project have some degree of tactical reserve.

I've seen both sides of strategic reserves in motion. I've been on projects where things go so wrong that more staff is needed, sometimes causing another project to implode. I've also been on projects where management reassigned one or more key engineers to another project. That can be an emotionally frustrating position, but one has to keep in mind that these dicisions are being made at a strategic level, and management must do what is best for the business, even if it means dismantling your project.


An engineer leading his first project once said he wished he could be more like me and not worry so much. That's humorous, because I'm the biggest worrywart around. But I channel my anxiety-induced energy into planning, and in a solid plan I find comfort. I mostly worry about the unexpected, so once I plan for the unexpected, I know I have nothing to worry about.

Recommended reading:
  • Clancy, Tom and Franks Jr., General Fred, Into the Storm, New York, 1987.
  • Keegan, John, A History of Warfare, New York, 1983.

Copyright 2007, Robert J. Hueston. All rights reserved

Post a Comment:
Comments are closed for this entry.

Bob Hueston


« July 2016