Project Charter: Increments and Estimates

Increments

So far, our mantra has been to approach any application development effort with an eye toward incremental releases. Recall from Chapter 1 that risk is reduced exponentially if we tackle the project in stages. To align our terminology with the Unified Process, we will produce each of these increments by conducting many different iterations through the four phases (Inception, Elaboration, Construction, Transition). This approach will allow the project to focus first on the riskiest requirements. Toward that end, we propose the following release cycles as the staged increments for Remulak Productions:

Increment 1:

1.1 Process Orders

1.2 Maintain Orders

1.3 Maintain Relationships (customer pathways only)

1.4 Architecture Infrastructure

Increment 2:

2.1 Maintain Inventory

2.2 Shipping

2.3 Invoicing

2.4 Maintain Relationships (remaining pathways)

Increment 3:

3.1 Decision Support

3.2 Security

3.3 Audit

3.4 Archiving

Estimates: The Issues

For years, analysts and designers have been told in classroom settings never to provide estimates until all of the requirements are known. With the Unified Process, and any other process that is iterative and incremental, we use the learn-as-you-go approach. Our bases are somewhat covered because we have done a flyby of all of the events, use-cases, and pathways and we have detailed the happy pathways. However, we still don't know all of the supporting detail behind the requirements. Yet the project sponsors need an estimate; without it, they can't decide whether or not to give the go-ahead.

Before I stray into the semantics of estimating using use-cases, let me say a few words about estimates and the project sponsor. When I am consulting or teaching seminars, one question that always comes up is, “Well, this is all fine and good, but what do you do when your sponsor wants all the functionality you've specified for the same price, but in half the time?” My initial answer is that I feel sorry for the project team. At the same time, I usually sketch a little diagram and discuss its merits and meaning (see Figure 4-6).

I contend that all projects must face the reality of the equilateral triangle creed. Once the information technology group has estimated the project and calculated a delivery schedule, the ratios generated form the basis of the equilateral triangle. The edict is: All sides must remain in the same proportion as to the initial ratios. Quality is never negotiable.

This creed implies that if a sponsor wants more functionality, the time and cost factors will increase in proportion to the increase in functionality. Typically, however, the request of the project sponsor yields a picture of these factors that looks like Figure 4-7.

This situation is not feasible. The sponsors want the project done in half the time, but at the same cost and of course the same level of functionality. These types of no-win situations are worth walking away from. What ends up being sacrificed is quality. If the discussion about keeping time, cost, and functionality ratios equal doesn't help the project sponsor see the light, then I usually launch into a lecture pointing out that a building contractor would laugh in our face if we suggested such foolishness. And how about a plastic surgeon practicing his/her craft on an accident victim. What would the response be in that situation? Would we want either one of these professionals to sacrifice quality or to somehow rush the job while still attaining all the original goals?

The solution is to look at the problem and break it down into even more elemental pieces—that is, more increments. As mentioned in the preface and in Chapter 1, we must avoid risk if we are going to build software that meets the needs of a business but can stand the test of time. Working 100-hour workweeks is a perceived temporary solution that has absolutely no long-term benefit.

Estimates: The Process

Varying levels of success have been realized with structured approaches to project estimating. Estimating still is a combination of mystic art, the school of hard knocks, and plain luck. However, some very interesting research has been done at Rational Software by Gustav Karner (which he begain initially while at Objectory AB, which was later purchased by Rational Software). The result is a modification of work originally done by Allan Albrecht on estimating by using function point analysis. Appendix C provides an overview of that estimating technique, as well as how the estimates were reached for Remulak Productions.

Remulak Productions' deliverable will be realized by implementation of three different increments, staged as three different release cycles. This will enable Remulak to manage the risk of the project, as well as ease it into the new millennium without too much new-system shock. The estimates for each increment are as follows:

Increment 1: 670 person-hours

Increment 2: 950 person-hours

Increment 3: 950 person-hours

Figure 4-8 depicts the project with all of the increments in process. This figure does a good job of showing the iterative, incremental approach that we will take for the Remulak Productions application. The middle spiral is flipped to indicate that many increments or deliverables can be active at any one time, each in its own phase.

The UML package diagram can depict the same thing, while hiding much of the detail. Figure 4-9 is a package diagram reflecting the incremental deliverables.

The Inception phase is now complete. The road is laid out for us clearly and concisely. The diagrams produced, together with the project vision, are collectively called the requirements model, and we have reached the Lifecycle Objective milestone in the Unified Process. The next step is to create two project plans: One will be a high-level phase plan, the other a detailed plan for the first iteration in the Elaboration phase, where we will tackle Increment 1 of the Remulak Productions order entry application. The bases for these project plans are drawn from the Unified Process project plan templates that can be found in Appendix A.

The remainder of this book will explore the details of the first increment for Remulak Productions. The remaining two increments are not presented in this book, but they would be developed in the same fashion.

Let's now look at how the project-planning process is laid out in the Unified Process. Figure 4-10 shows how each iteration cuts vertically through all the workflows offered in the Unified Process (Business Modeling, Requirements, and so on). Just remember that as the project moves farther to the right in its lifecycle, the project plan tasks will shift more toward design and construction activities.

Here the timeline shows multiple iterations: one in Inception, two in Elaboration, two in Construction, and one in Transition. For Remulak, because there are three packages or increments of delivery, the proposition is to stretch both the Elaboration and Construction phases into three iterations each. This approach maps nicely to the packages and spreads out the risk. Figure 4-11 shows the phase timeline with the proper number of iterations. So the increment packages shown in Figure 4-9 will map to Iterations 2, 3, and 4 for the Elaboration phase of the application. The same applies for Iterations 5, 6, and 7 in the Construction phase.

There we have the outline of our phase plan and the input necessary to create a detailed project plan for the first Elaboration iteration.