Building a Project Plan

To build a project plan you will need an initial estimate of the overall size of the project (see Figure 12.3). We will visit the estimation part in the section Estimating later in the chapter. Once you have an initial guess at the overall size, there are well-known recipes (such as the COCOMO model) to estimate the right level of staffing.

Figure 12.3. Typical Resource Profile for a Development Cycle. The resources used within each phase vary greatly from project to project. This graph provides you with a starting point for a discussion around resource needs (from Kruchten 2000a and Royce 1998).

Most projects will not function efficiently if staffed with a constant number of people. There is usually a staffing profile that increases from Inception to Construction, plateaus for a while, and then drops a bit toward the end of Transition.

As with many other aspects in the RUP approach, consider this profile only as an example. It must be adjusted to suit your own experience and your own context. For example:

• With many unknown factors and risks, and the added element of new people or tools and technologies, the Elaboration phase may last longer.

• For evolution cycles, Inception and Elaboration may be shortened .

Once you have planted the dates of the major milestones on the calendar, the next questions to address are how many iterations and how long. Opinion varies greatly among iterative development practitioners . First, remember to not confuse a build, like a weekly build, with an iteration. Many avid fans of iterative development think of an iteration as lasting around two to five weeks. This may be fine for most small- to medium- sized projects, but not for large and very large projects where hundreds of people, often distributed over several sites, may have to be coordinated.

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

For example:

• 5 people, 1 week. A team of five people can do some planning on a Monday morning, have lunch together every day to monitor progress, reallocate tasks , start doing a build on Thursday, and complete the iteration by Friday evening. The iteration takes 1 week.

• 20 people, 3 to 4 weeks. The 1-week scenario will be very hard to achieve with 20 people. It will take more time to distribute the work, synchronize between subgroups, integrate, and so on. An iteration could instead take 3 to 4 weeks.

• 40 people, 8 weeks. With 40 people, it already takes a week for all the "synapses" to fire from the "brain" to the "extremities" of the development organization. You have intermediate levels of management; the common understanding of the objective will require more formal documentation, more ceremony. Eight weeks is a more realistic 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, and the level of automation the team is using to manage code (for example, distributed CM), distribute information (for example, internal Web), automate testing, and so on.

• Rational products are all produced through synchronized releases with 700 people/team members involved, and iterations that are 5 to 8 weeks long.

• Craig Larman from Valtech reports projects having 10 iterations or more in a little more than a year.

Be aware also that there is some fixed overhead attached to an iteration: in planning, synchronizing, analyzing the results, and so on.

So, while 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.

• 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 degree of novelty are low. Short iterations may include little or no formal analysis or design, and may simply be incrementally improving on an existing and well- understood functionality.

• Iterations of more than 3 months probably need 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 in multiyear projects create additional business risks because the iteration spans the annual funding cycle. A project that has not produced anything visible in 12 months is at risk of losing its funding. You would not reap much benefit from iterative development. Rethink your strategy.

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). But having a good, regular tempo for a project with many iterations provides an environment that favors balanced iteration lifecycles.

Determining the Number of Iterations

Related to the length of an iteration is the delicate issue of the number of iterations.

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

• Inception: 1 iteration, perhaps to produce a proof-of-concept prototype or user -interface mock-up or no iteration at all, for example, in an evolution cycle.

• Elaboration: 1 iteration to produce an architectural prototype.

• Construction: 1 iteration to build the product (to a beta release).

• Transition: 1 iteration to finish the product (full product release).

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

• Inception: 1 iteration, possibly producing a prototype.

• Elaboration: 2 iterations, one to develop an initial architectural prototype and one to finalize the architectural baseline.

• Construction: 2 iterations, one to expose a partial system and one to mature it for beta testing.

• Transition: 1 iteration, to go from beta to full product release.

For a large project, with many unknown factors, new technologies, and the like , there may be a case for additional iterations:

• Inception: An additional iteration to allow for more prototyping (so 2 iterations in all).

• Elaboration: An additional iteration to allow different technologies to be explored, or to phase in the introduction of architectural solutions, bringing this phase to 3 iterations.

• Construction: An additional iteration because of the sheer size of the product, also 3 iterations.

• Transition: An additional iteration to allow for operational feedback halfway through.

Therefore, over a development cycle, we have several possible degrees of iteration (see Table 12.1).

In general, plan to have 3 to 10 iterations. Observe, though, that the upper and lower bounds connote unusual circumstances: Most developments will use 6 to 8 iterations.

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

• If the product is intended for a totally new domain, you may need to add some iterations in Inception to consolidate the concepts, show various mock-ups to a cross-section of customers or users, or build a solid response to a request for proposal.

  Table 12.1. Degrees of Iteration in Different Projects. This table can be used as a starting point when deciding how many iterations to have. The number of iterations and iteration length depend on a lot of different factors.

  Project Size (People)	Project Length (Months)	Iteration Length (Weeks)	Number of Iterations Per Phase
  			Inception	Elaboration	Construction	Transition
  3	4	2 “3	1	1	3	1
  10	8	4	1	2	3	2
  80	20	7 “8	2	3	4	2

• If a new architecture must be developed or there is a large amount of use-case modeling to be done, or there are very challenging risks, you should plan to have 2 or 3 iterations in Elaboration.

• If the product is large and complex and to be developed over a long period of time, you should plan to have 3 or more iterations in Construction.

• If you feel you may need a lot of small adaptations to the user base after a period of use, you should plan to have several iterations in Transition.

• A simple evolution cycle or a maintenance cycle can be done with few iterations: none in Inception and Elaboration, 1 in Construction, and 1 in Transition.

• Or an organization that has never done iterative development may choose a modest start with a low number, such as 3 iterations.

Alternatively, you might settle on an iteration length that your organization is comfortable with, and just proceed by fitting as many iterations of that length as you can in each phase. It is obviously easier, but you need to have done this before with your current organization, or with an organization comparable in size and experience, to be certain about iteration duration. Again, there is no "one-size-fits-all" approach. Do not try to optimize too much. Take a first shot at it, and modify it as you learn.

Iteration Length

As a first approximation , obtain the iteration length by dividing the length of the phase by the number of iterations. If the duration obtained is not quite right, according to the rules of thumb given earlier, revisit the process. Now is the time to make some adjustments, either to the length of a phase or to the number of iterations. Then also take into account major holidays, planned vacations , or plant closures to adjust the project plan to a realistic time frame. For example, it is never a good idea to plan a major milestone between Christmas and New Year's Eve (in some countries , at least).

It's not necessary get your plan 100 percent right on day one, because you will revisit this plan several times during the development cycle. Start with something realistic, create a baseline of your project plan, and revisit it as you grow wiser at the end of each iteration.

Iteration Objectives

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 release you have at the end of each iteration, and to help people gain a better focus on the next target.

Example: Names of Iterations for a Private Telephone Switch

Iteration 1: Local station-to-station call

Iteration 2: Add external calls and subscriber management

Iteration 3: Add voice mail and conference calls And so on

Again, do not put too much effort into this. You will revise these several times throughout the cycle. Planning is iterative and adaptive.

Staffing the Project

The next step is to allocate the right level of resources to the project alongside the lifecycle. Figure 12.4 shows a typical staffing profile.

Figure 12.4. Example Resource Profile Across Project Lifecycle Phases. The effort spent on each phase varies greatly from project to project. This graph shows an example staffing profile for a project.

Your actual staffing profile will vary depending on your project.

• For an initial development cycle, a green-field development, it is not a good idea to start with too many people during Inception and Elaboration. Since there is nothing in place, you will struggle just to keep everyone fully employed. Fifty people will not shape the vision document together. Staffing can peak during Construction.

• In an evolution cycle or a maintenance cycle, the staffing profile may be more flat. The same five people may be permanently allocated to it, and the work done looks like Transition, or Construction and Transition.

Models such as COCOMO will help you determine the optimal number of people versus duration of the phase for the various phases, taking into account various parameters (cost drivers).

You will need the right mix of competence to allocate the activities to individual resources; this can be done by tabulating for each team member the RUP roles that he or she is likely to play.