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.
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.
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.
To be used effectively the Incremental PMLC model requires the following:
The strengths of the Incremental PMLC model are as follows:
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.
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.
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.
You must tell the client you have added management reserve and make sure they understand how this can impact the project schedule.
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.
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.
The weaknesses of the Incremental PMLC model are as follows:
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.
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.
This is the same as with the Linear PMLC model.
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.
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:
Alternative A
Increment #1: F3
Increment #2: F3.1, F3.1.1
Increment #3: F3.2, F3.1.1.1, F3.1.1.2
Alternative B
Increment #1: F3, F3.1
Increment #2: F3.2, F3.1.1
Increment #3: F3.1.1.1, F3.1.1.2
Alternative C
Increment #1: F3, F3.1, F3.2
Increment #2: F3.1.1 F3.1.1.1
Increment #3: F3.1.1.2
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.
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.
The added time arises from the following:
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.
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.
Resist the temptation to use the increments to solve a problem. That is not the purpose. You must have a clearly defined goal as well as a clearly defined solution to use these approaches. If the solution is not clearly defined, Iterative and Adaptive approaches will serve you better.
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:
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:
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.
3.138.174.122