Incremental Project Management Life Cycle

The Incremental PMLC model is the second type of TPM approach and was originally posed as a way to get products and services to market sooner but with what has been labeled “crippled solutions.” That is a solution that is not fully functional. It is designed to enable your client to gain a foothold in a new market or enhance their leverage in an existing market.

Figure 10-4 is a graphical description of the Incremental PMLC model that shows the dependent increments. The increments follow sequentially, not concurrently.

Figure 10-4: The Incremental PMLC model

Note that the sequence formed by the Launching, Monitoring and Controlling, and Closing Process Groups is repeated n times. Each repetition integrates another part of the solution until the nth repetition, when the final part of the solution is integrated and the project moves to the Closing Process Group.

Definition

An Incremental PMLC model consists of a number of dependent increments that are completed in a prescribed sequence. Each increment includes a Launching, Monitoring and Controlling, and Closing Process Group for the functions and features in that increment only. Each increment integrates additional parts of the solution until the final increment, where the remaining parts of the solution are integrated.

Characteristics

To be used effectively the Incremental PMLC model requires the following:

• The same characteristics as the Linear PMLC model
• A need to release deliverables against a more aggressive schedule

Strengths

The strengths of the Incremental PMLC model are as follows:

• Produces business value early in the project
• Enables you to better schedule scarce resources
• Can accommodate minor scope change requests between increments
• Offers a product improvement opportunity
• More focused on client value than the Linear PMLC model

Produces Business Value Early in the Project

Releasing a partial product or service early in the project creates market presence and value earlier than in the Linear PMLC model, hence, an earlier return on investment. From a marketing standpoint, early entry has its advantages, and the Incremental PMLC model supports that entry.

Organizational velocity is something you need to think about as you plan these increments. By velocity, I mean the ability of the organization to implement and absorb change. For example, if the increments are two weeks long, you are fooling yourself if you think the organization can absorb changes every two weeks. You have to support these increments, too. I see some real problems with short increments. On the other hand, increments that are too long may adversely affect your success in the market. Most of my clients plan for quarterly or semi-annual releases. Annual releases are typically version releases that take care of bugs and major product upgrades, not partial product releases.

Enables You to Better Schedule Scarce Resources

Increments are defined around function and feature dependencies, but they can also be defined around the availability of scarce resources. When a scarce resource is available only during certain windows of time, using the Linear PMLC model may create resource contention problems in that the scarce resource is needed when the scarce resource is not available. If instead, you use the Incremental PMLC model in planning the project, you could assign functions and features to an increment that will be scheduled during the available time of the scarce resource. The remainder of the increments and their schedules can be planned around the increment that is using the scarce resource. If there are several scarce resources, the same strategy can be used.

Can Accommodate Minor Scope Change Requests Between Increments

When you release a partial product or service to the end user, you had better expect that those end users will find reasons for change. Something can always be done better. While changes are not supported in the TPM category, you should expect changes when using the Incremental PMLC model. Don't ignore the likelihood of these change requests; instead, plan for them by adding a management reserve task to every increment.

Offers a Product Improvement Opportunity

Releasing functions and features to the end user or client in increments gives room for feedback and possible improvements in later increments. A word of caution is needed here. Your hope is that the time between increments is very short. The longer the time between increments, the more likely you will lose team members to short-term assignments that turn out to be longer term than planned. If the time between increments is short, the end user or client will not have much opportunity for testing and feedback. You've given the end user or client an opportunity to try something out and make suggestions for change, so you had better be prepared to respond.

More Focused on Client Value Than the Linear PMLC Model

Just by giving your client the opportunity to work with a partial solution and provide feedback on improvements, you are already more client-facing than if you are using the Linear PMLC model.

Weaknesses

The weaknesses of the Incremental PMLC model are as follows:

• The team may not remain intact between increments.
• This model requires handoff documentation between increments.
• The model must follow a defined set of processes.
• You must define increments based on function and feature dependencies rather than business value.
• You must have more client involvement than Linear PMLC models.
• An Incremental PMLC model takes longer than the Linear PMLC model.
• Partitioning the functions may be problematic.

The Team May Not Remain Intact Between Increments

This may be the most serious risk created in an Incremental PMLC model that is not a serious issue in the Linear PMLC model. The longer the time between successive increments, the more likely you will lose one or more team members. If they are not busy doing some work on your project, what do you think they will be doing? Another project manager will see that your team members are not busy and request “a little bit of their time” to work on his or her project. My experience has been that this “little bit of time” always gets stretched out, and you will either lose those team members or have your project delayed waiting for them to return.

There will inevitably be some delay between the end of one stage and the beginning of the next. That delay can be dangerous because there will be a temptation to assign team members to other short-term tasks while waiting to start the next stage. The short term can extend to a longer term and compromise the next stage.

This Model Requires Handoff Documentation Between Increments

You have to assume that the team who will work on the next increment may not be the same as the team who worked on the just-completed or previously completed increments. You should also assume that you may not have face-to-face or real-time communications with those who might be assigned to future increments. Nevertheless, the new team must pick up where the old team left off.

That means the team working on the current increment must create documentation for the team that will work on the next increment. This adds time to the increment duration and hence adds time to the project completion. Fortunately, not every increment will require this additional non-value-added work.

The Model Must Follow a Defined Set of Processes

This is the same as with the Linear PMLC model.

You Must Define Increments Based on Function and Feature Dependencies Rather Than Business Value

The constraining factor in choosing the functions and features to go into an increment are the dependencies between functions and features. In most cases, the features that belong to a function should be in all increments that include this function. That would make for a more efficient use of development resources. A good start would be to build a network diagram of the functions. That will be your guide to allocating functions to increments. A simple example is shown in Figure 10-5.

Figure 10-5: Allocating functions to increments

Suppose the client would like to have three releases of the product or service. One way to approach the partitioning would be to look at the longest dependency path and allocate that path to the three increments. The longest dependency path is the one that begins with F3. Here are some possible alternatives for allocating that longest path:

How would you choose the best allocation? The criteria might be resource availability, increment duration, increment risk, and/or business value. The same criteria would apply if you were trying to choose from among two or more complete allocations.

You Must Have More Client Involvement Than Linear PMLC Models

The first and primary difference in client involvement between the Linear and Incremental PMLC models is increment planning. In the Linear PMLC model, there is only one increment, and the point is moot. In the Incremental PMLC model, the client will be concerned about increment duration and business value. The development team will be concerned about compliance to the dependency relationships between increments, risk, and resource availability. It is possible that client needs will conflict with development team needs and some negotiation will have to take place.

An Incremental PMLC Model Takes Longer Than the Linear PMLC Model

The added time arises from the following:

• Delays between increments
• The need for handoff documentation between increments
• More scope change requests
• Supporting interim solutions
• The loss of team members between increments
• Integration of the latest increment deliverables

Partitioning the Functions May Be Problematic

As stated previously, you will have occasions where some negotiation will have to take place, and the results of that negotiation may require compromises by both parties. Here is where the allocation of the features may help. Developing the feature list for a particular function could be allocated to several increments, beginning with the increment where the function is developed. There will be several options to consider, and balancing the increments by allocating the feature list may present some acceptable compromises.

When to Use an Incremental PMLC

The only justification for using an Incremental PMLC model is to get a partial product, service, or process into the end user's hands faster than any alternative model. The added risks are often much higher than if a Linear PMLC model had been chosen.

Adapting and Integrating the Tools, Templates, and Processes for Maximum Effectiveness in Incremental PMLCs

To successfully implement the Incremental PMLC model, you have to begin during construction of the project network diagram (just as you do for the Rapid PMLC model). Your objective is to define a set of increments so that each increment contains only the functions and features that depend on functions and features released through previous increments. When the last increment is complete, the solution is complete. These increments must have the following properties:

• The functions and features of an increment can be built independently of the functions and features that are still not integrated into the solution.
• The functions and features in any increment must provide a meaningful addition to the business value when integrated into the current solution.
• The organization can absorb the frequent changes to the solution.
• The total duration of each increment should be nearly equal.

Although this variation may seem to be very attractive given today's rush to market, some problems will arise.

The risk of failure is increased. There are several things to consider in creating such an incremental schedule. The amount of work has not decreased — it just must be completed in a shorter time frame. The last increment that is complete determines the completion date of the development project. The results of an incremental schedule are as follows:

• An increase of management time to handle between-increment issues
• An increase in the total amount of work as compared to the Linear PMLC model
• Encouraging between-increment scope change requests
• An increased likelihood of losing resources between increments
• The possibility of project delays between increments
• Potential for overlooking increment dependencies
• Handoff documentation requirements between increments

All of these results contribute to an increased risk of project failure. So if there is pressure to use the Incremental PMLC model rather than the Linear PMLC model, assess the complexity and potential risk implications. You might also want to assess the skills and competencies of potential replacement team members in anticipation of losing your original team members between increments.