Guidelines: Project Plan

Project Plan

A time-sequence set of activities and task, assigned to resources, containing task dependencies, for the project.

Topics

• Determining the length of an iteration
• Determining the number of iterations

Determining the length of each iteration

We have defined an iteration as a rather complete mini-project, going through all major workflows and resulting in most cases in an executable, yet incomplete, system: a release. Although the cycle [edit, compile, test, debug] sounds like an iteration, this is not what we have called iteration here. The daily or weekly builds incrementally integrating and testing more and more elements of the system may sound like an iteration, but they are not what we call iteration here.

An iteration starts with planning and requirements, and ends with a release, internal or external.

How quickly you can iterate depends mostly on the size of the development organization.

For example:

• Five people can do some planning on a Monday morning, have lunch together every day to monitor progress, reallocate tasks, start doing some build Thursday, and complete the iteration by Friday evening.
• But this will be very hard to achieve with 20 people. It will take more time to distribute the work, synchronize between subgroups, integrate, etc. An iteration may take rather 3 or 4 weeks.
• With 40 people, it already takes a week for the "nervous influx to go from the brain to the extremities". You have intermediate levels of management, the common understanding of the objective will require more formal documentation, more ceremony. Three month is a more likely reasonable iteration length.

Other factors come into play: the degree of familiarity of the organization with the iterative approach, including having a stable and mature organization, the level of automation the team is using to manage code (e.g., distributed CM), distribute information (e.g., internal web), automate testing, etc.

Be aware also that there is some fixed overhead in an iteration, in planning, synchronizing, analyzing the results, etc.

So, on one hand, convinced by the tremendous benefits of the iterative approach, you might be tempted to iterate furiously, the human limits of your organization are going to slow your fervor.

Some empirical data::

• Iterations of more than 6 months probably need to have intermediate milestones built in to keep the project on track.  Consider reducing the scope of the iteration to reduce its length and ensure a clear focus.
• Iterations of more than 12 months create their own risk, as the iteration spans the annual funding cycle.  A project which has not produced anything visible in the past 12 months is at risk of losing its funding.
• Iterations of less than 1 month need to be scoped carefully.  Typically, short iterations are more suitable for the Construction phase, where the degree of new functionality to be included and the the degree of novelty are low.  Short iterations may do little or no formal analysis or design, and may simply be incrementally improving well-understood functionality.
• Iterations need not all be the same length: their length will vary according to their objectives.  Typically, elaboration iterations will be longer than construction iterations.  Within a phase, iterations are generally the same length (it makes planning easier).

Once you have an idea of the number of iterations in your coarse-grained plan, you need to define the contents of each iteration. It is even a good idea to find a name or title to qualify the product you have at the end of each iteration, to help people get a better focus.

Example Iterations for a Private Telephone Switch

• Iteration 1: local call.
• Iteration 2: add external calls and subscriber management.
• Iteration 3: add voice mail and conference calls.

Determining the Number of Iterations

A very simple project may have only one iteration per phase:

• One iteration in the inception phase, producing perhaps a proof-of-concept prototype, or user-interface mock-up, or no iteration at all, in the case for example of an evolution cycle.
• One iteration in the elaboration phase to produce an architectural prototype.
• One iteration in the construction phase to build the product (up to a "beta" release).
• One iteration in transition to finish the product (full product release).

For a more substantial project, in its initial development cycle the norm would be:

• One iteration in the inception phase (some prototype).
• Two iterations in the elaboration phase; one for an architectural prototype, and one for the architectural baseline.
• Two iterations in the construction phase to allow some maturing.
• One iteration in the transition phase to go from initial operational capability to full product release.

For a large project, with lots on unknowns, new technologies etc.

So over a development cycle, we have:

• Low: 3 iteration [0,1,1,1]
• Typical: 6 [1, 2, 2, 1]
• High: 9 [1, 3, 3, 2]

In general, plan to have six, plus or minus three iterations

Many variations are possible depending on risks, size, complexity:

• If the product is intended for some totally new domain, you may need to add some iterations in the inception phase to consolidate the concepts, show various mock-ups to a cross-section of customers or end users, or build a solid response to a request for proposal.
• If a new architecture must be developed, or there is a large amount of use-case modeling, or there are very challenging risks, you should plan to have two or three iterations in the elaboration phase.
• If the product is large and complex, and developed over a long period, you should plan to have three or more iterations in the construction phase.
• You should plan to have several iterations in the transition phase if, because you must minimize the time to market, you must deliver the product with a reduced set of functionality, or if you feel you may need a lot of small adaptations to the end-user base after a period of use.