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.
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.
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
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 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.
- 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