Iterative Project Management Life Cycle

,

On the certainty/uncertainty line, the models are aligned from Linear to Incremental to Iterative to Adaptive to Extreme. Both the Iterative and Adaptive models have been proposed to address the difficulty many project managers face when they try to clearly decompose requirements and are unable to do so. In some cases that difficulty arises from the client not having a clear picture of their needs and in other cases from the solution not being known. In either case, some type of APM approach is called for.

Definition of the Iterative PMLC Model

An Iterative PMLC model consists of a number of process groups that are repeated sequentially within an iteration with a feedback loop after each iteration is completed. At the discretion of the client, the last process group in an iteration may release a partial solution.

Iterative approaches are used when you have an initial version of the solution, but it is known to fall short in terms of features and perhaps functions. The iterative cycles are designed to select and integrate the missing pieces of the solution. Think of the Iterative PMLC model as a variant of production prototyping. The intermediate solutions are production ready, but they might not be released by the client to the end user until the final version is ready. The intermediate versions give the client something to work with as they attempt to learn and discover additional needed features. The client would choose to release a partial solution to the end user in an attempt to get input from them on further solution detail.

Figure 11-1 is the process group–level view of the Iterative PMLC model.

Figure 11-1: Iterative PMLC model

The Iterative PMLC model requires a solution that identifies the requirements at the function level but might be missing some of the details at the feature level. In other words, the functions are known and will be built into the solution through a number of iterations, but the details (the features) are not completely known at the beginning of the project. The missing features will come to light as the client works with the most current solution in a prototyping sense. The Iterative PMLC model is a learn-by-doing model. The use of intermediate solutions is the pathway to discovering the intimate details of the complete solution.

The Iterative PMLC model embraces several types of iteration. Iteration can be on requirements, functionality, features, design, development, solutions, and other components of the solution. An iteration consists of the Planning, Launching, Monitoring and Controlling, and Closing Process Groups. Closing an iteration is not the same as closing the project.

The Iterative PMLC model kicks in when one of the following occurs:

• Most but not all of the solution is clearly known.
• You might otherwise have chosen the Incremental PMLC model but have a strong suspicion that there will be more than a minimum number of scope change requests.
• You might otherwise have chosen the Adaptive PMLC model but are concerned about lack of client involvement.

Most of the Solution Is Clearly Known

Some of the details of the solution are missing. The alternatives to how those details (that is, features) might be added to the solution are probably known up to a point. All that remains is to give the client a look at how those features might be deployed in the solution and get their approval on which alternative to deploy or their recommendations for further change. This is the simplest of the Iterative situations you will encounter. Production prototype approaches are the usual choice. The Prototyping PMLC model is discussed later in this chapter. As far as the project team knows, all of the functions and sub-functions have been identified and integrated into the current solution. As features are added, there could be changes in how the functions and sub-functions are deployed in the solution, and hence, further changes are recommended. This is the nature of an Iterative approach. It continues in this vein until the client says you are done or until time and/or money is exhausted. The Prototyping PMLC model is ideal for such situations.

Likely to Be Multiple Scope Change Requests

This may just be a hunch, or this client's reputation is one of having made many changes in past projects. It's better to be safe than sorry. The off-the-shelf Incremental PMLC model does not leave room in the project schedule for receiving and processing scope change requests. Rather than risking the consequences, choose an Iterative PMLC model that does leave room in the project schedule for client and end-user feedback or the accommodation of scope change requests.

Concern about Lack of Client Involvement

Coming from the Adaptive PMLC model side of the project landscape, if you have chosen to use an Iterative PMLC model, there are some risks you need to know about. You will have some degree of meaningful client involvement but not to the degree that you feel you will need it. Rather than depending on meaningful client involvement, you will have to guess at what the complete solution will be. The more involved the client is, the less you will be dependent on guessing. You might be good at guessing or just lucky, but you will still be guessing. The more knowledge your team has of the client systems and processes, the better off you will be.

If there is more than one client group, such as different departments all having to utilize the same solution, you are going to have to deal with complications. The first one is coming to closure on the final solution. This is so difficult that you should plan for considerable opposition. A single solution is possible, but it has to accommodate different requirements for each client group. You may have even come to closure on a requirement, but not on its representation in the solution. Those differences might begin with different user views and extend to different features and even different functions. The solution design is going to be more complex but still achievable.

Scoping Phase of an Iterative PMLC Model

The Scoping Phase of the Iterative PMLC model takes on a bit more complexity than the Scoping Phase of the Linear or Incremental PMLC models, and it requires decisions that are not part of Linear or Incremental PMLC models. The key input for your decision to use an Iterative PMLC model is the requirements definition expressed by the Requirements Breakdown Structure (RBS). You and the client will review and discuss the RBS, paying particular attention to how complete you both think it is. Except in the simplest of situations, neither you nor the client can ever know for certain that the RBS is complete. This will always be a subjective decision. My advice is to err on the side of deciding that an RBS is less complete rather than more complete. That is, choosing an Iterative PMLC model rather than a Linear PMLC model or choosing an Adaptive PMLC model rather than an Iterative PMLC model is the safer ground.

Planning Phase of an Iterative PMLC Model

Planning is done at two levels in the Iterative PMLC model. The initial Planning Phase develops a high-level plan without much detail. The reason is that the full detail is not known at the initial stage. The functionality is known, and its design and development can be planned across any number of iterations. There are two ways to structure the high-level plan in the Iterative PMLC model.

The Complete Plan for Building the Known Solution

The first iteration in this plan may be of long duration in order to accommodate building a production version of the entire but incomplete known solution. If you feel that this iteration will be too long, then you might consider using a tool to model the solution instead. You will use that model throughout the entire project and create the production version of the complete solution at the end of the project.

To create this plan, use the Planning Process Group as defined in Chapter 3 and remember that you do not have a complete solution.

The Partial Plan for the High-Priority Functions

For this approach, you will begin the partial plan by prioritizing the functions and features in the initial RBS. The rule for prioritization will most likely be business value so that the deliverables from an iteration can be released to the end user, if the client so chooses. Alternatively, the prioritization might be based on risk or complexity: high-risk functions at the top of the list or high-complexity functions at the top of the list. By developing these functions early in the project, you ensure the successful completion of the project. In some cases, all the known functions and features will be developed in the first few iterations. Later iterations then drill down to possible areas for further identification and development of features. This is probably the most efficient of all the development alternatives you might consider. Yet another strategy would be to develop the high-risk parts of the system first. That removes one of the major variables that could adversely affect the project if left to a later iteration. A final rule may be to satisfy as many users as possible with your choice of functions or features.

Within each iteration, you might have concurrent swim lanes — each developing a different piece of functionality or expanding on its features. The determining factor is the resource pool from which you are drawing your team members. If you need to compress the development time frame, you can structure the project much like you would in the Linear PMLC model when you move from the Linear PMLC model to the Rapid Linear PMLC model or the FDD Linear PMLC model by adding concurrent swim lanes, each developing a different part of the solution.

Iterations are designed to help the client choose additional features or feature detail by having them and the end user spend some time working with the current partial solution. An iteration will present the user with alternatives from which to choose what will be added to the solution in preparation for the next iteration. Presumably those newfound features or feature detail are then prioritized and added to the next version of the solution. This game plan suggests that iterations be kept to two or less weeks. I have managed projects where the new prototyped solution was produced overnight.

Launching Phase of an Iterative PMLC Model

There is a significant difference between the project team for a Traditional Project Management (TPM) project and the project team for an APM project. Table 11-1 summarizes those differences.

Table 11-1: Differences Between a TPM Project Team and an APM Project Team

The team profile for an Iterative PMLC model can be somewhat relaxed, whereas the profile for the Adaptive PMLC model should be adhered to as closely as possible.

In addition to the team differences that you have to consider, there is one major difference in the way scope change is dealt with. In TPM projects, there must be a formal scope change management process. That is not the case in an APM project. There is no need for a formal scope change management process in an APM project, because all of the learning and discovery that takes place during an iteration in an APM project is saved (in a Scope Bank, for example) and reviewed between iterations. The items in the Scope Bank are prioritized for integration into the solution in a later iteration.

Monitoring and Controlling Phase of an Iterative PMLC Model

In the Iterative PMLC model, the Monitoring and Controlling Phase begins to change. Because of the speculative nature of the iterative strategy, much of the heavy documentation and status reporting gives way to more informal reporting. Much of that formalism becomes non-value-added work and begins to burden the team with tasks that do not bring them any closer to the final solution. You want to be careful to not overload the architects and developers with those types of tasks. Let them remain relatively free to pursue the creative parts of the project. During the between-iteration reviews, you should review the status and progress of solution definition and make any needed adjustments.

Closing Phase of an Iterative PMLC Model

The Closing Phase for the Iterative PMLC model is similar to the Closing Phase for the TPM PMLC model in that there are client-specified criteria that must be met in order for the iteration or cycle deliverables to be considered complete. Those criteria were specified during iteration planning. Each iteration has closing criteria, but only regarding the iteration deliverables for that cycle. The only difference is that the project might end (all of the time and or money has been used), and there might still be features not integrated into the solution. These are noted in the final report and are to be considered whenever the next version of the solution will be commissioned.

Lessons learned take on an additional dimension. What did the team and the client learn about doing projects following the Iterative PMLC model? How can the approach be improved for the next iteration or project?

Characteristics

The characteristics of an effective Iterative PMLC model are as follows:

• The solution is known, but not to the expected depth (that is, features are not complete).
• It often uses iconic or simulated prototypes to discover the complete solution.

The Solution is Known, but Not to the Expected Depth

In simpler applications of the Iterative PMLC model, features may not be clearly defined. Should you do it this way or that way? These alternatives are presented to the client for deciding on which way is best by their criteria. They might choose to engage the end user in that decision. In more complex cases an iteration might explore and try to uncover possible alternatives.

Often Uses Iconic or Simulated Prototypes to Discover the Complete Solution

In more complex cases that require solution discovery a modeling approach would be the quick and efficient approach. Such situations often use an Adaptive PMLC model instead of an Iterative PMLC model. The decision as to which PMLC model is best is almost always subjective and dependent on factors other than solution clarity.

Strengths

The strengths of the Iterative PMLC model are as follows:

• The client can review the current partial solution for suggested improvements.
• Scope changes can be processed between iterations.
• You can adapt it to changing business conditions.

Client Reviews Current Partial Solution for Improvement

There is no substitute to experiencing and using a partial solution for the client. Narratives, process flow diagrams, and fancy graphics are nice, but they don't do the job for many clients and end users. They need to see and try out your suggested solution. This continual review by the client tends to keep the solution aligned with business needs.

Can Process Scope Changes Between Iterations

Although the simple Iterative models can receive and process scope change requests between iterations, you should try to stay in control by presenting the client with alternatives and ideas at each iteration. There will be cases where the client sees improvements in the solution that you didn't see. That will result in their proposing scope changes you will have to deal with. Process those requests between iterations, and if approved, integrate the changes into a future iteration.

Adaptable to Changing Business Conditions

I've already mentioned the fact that the world isn't standing still because you are managing a project. Except for projects that are internal and are unaffected by external factors, you have to be ready to accommodate the need for changes outside of your immediate control. If you choose a change-intolerant model such as the TPM models, you place the project at risk if the need for change arises.

Weaknesses

The weaknesses of the Iterative PMLC model are as follows:

• It requires a more actively involved client than Linear and Incremental PMLC models require.
• It requires co-located teams.
• The implementation of intermediate solutions can be problematic.
• The final solution cannot be defined at the start of the project.

Requires a More Actively Involved Client Than TPM Projects

The higher the likelihood of change the more you need active client involvement to make good business decisions regarding that change. Along with that involvement is the need for client ownership of the project. If you don't have both the involvement and ownership, the project is in harm's way. Clients who are only casually involved often get off plan with requests for wants rather than validated needs. The focus must continually be on real business value.

Requires Co-Located Teams

Having co-located teams is usually not possible, and this places a high-change project at great risk. I have managed high-change projects when the team was globally distributed, but they required much more management overhead than otherwise would have been the case. In high-change projects, real-time communications is a project management necessity. So if co-location is not possible, you had better spend a lot of time developing your communications management plan, especially the internal team and client communications components.

Difficult to Implement Intermediate Solutions

I commented on this at the beginning of this chapter. What is the capacity of your organization to absorb change, and what is your capacity for supporting intermediate solutions? Quarterly implementation of partial solutions is about as frequent as most organizations can accommodate. You have to keep the provision of support requirements in mind as well.

Final Solution Cannot Be Defined at the Start of the Project

The final solution is variable. The less you know about the solution at the beginning, the more unexpected it may be at the end. You might have started out thinking you were going to solve the entire problem, but you ended up solving only a part of it because the time or budget ran out. Or maybe parts of the problem turn out to be intractable, and you just have to live with the best you can do.

Types of Iterative PMLC Models

Several software development models map quite well into an Iterative PMLC model. Models that are Iterative by my definition are Prototyping and RUP. Scrum and DSDM are viewed by some as Iterative and by others as Adaptive. For my purposes, I have chosen to classify Scrum and DSDM as Adaptive. Also in the Adaptive category are Adaptive Software Development (ASD) and Adaptive Project Framework (APF). All of these models work across the Agile landscape — some better than others, depending on a number of other factors.

Prototyping PMLC Model

Prototyping has been around since the days of the pharaohs. Engineers and the construction industry use prototypes on most projects. Early prototypes were physical models built to scale. Other prototypes include iconic models and simulated models. The kind of prototype that is used in the Iterative PMLC model is called a production prototype. A production prototype is a working version of the known solution. It evolves as the project team learns more about the solution from using the current prototyped solution. The deployment of intermediate solutions is the decision of the client.

It should be obvious that the meaningful involvement of the client is critical to the success of APM approaches. The client works with a version of the solution and provides feedback to the project team as they envision further enhancements and changes to improve the solution. This process continues as version after version is put in place. The Prototyping PMLC model doesn't really have a rule that says you are finished and can move to the Closing Phase. At some point in time, the client will have spent enough money or time or is satisfied that all requirements have been met and the solution is as good as it is going to get. The project then moves to the Closing Phase. Also note that this model always presents the client with a production-ready version of the system. Succeeding versions merely add to the features and functions.

Iterative PMLC models are definitely in the learn-and-discover category. In the Prototyping Iterative PMLC model shown in Figure 11-2, the learning and discovering experience is obvious. With each iteration, more and more of the depth of the solution is revealed and implemented. That follows from the client and developers having an opportunity to experiment with the current solution and collaborate on further enhancements.

Figure 11-2: Prototyping model

The discovery of additional features is a process that fully engages the client in meaningful exchanges with the developers. Both client and developers work with the prototypes — sometimes independently and sometimes in collaboration. Collaboration usually follows periods where they work independently. The collaboration would be done in an effort to decide how to go forward with new or redefined features in the next and subsequent iterations.

The Prototyping Iterative PMLC model reaches some distance into Quadrant 2 because it can embrace learning and discovery even under conditions when not much of the solution is known. At some point on the uncertainty axis, it will make more sense to use an Iterative approach called Rational Unified Process (RUP), and then use an Adaptive PMLC model at the outermost point on the uncertainty axis.

As Figure 11-3 shows, the Prototyping model is an example of the Iterative PMLC model.

Figure 11-3: Prototyping model mapped into the Iterative PMLC model

The iteration is defined by the sequence Plan Next Prototype, Develop Prototype, and Deliver Prototype. Get Client Feedback includes the client commenting on the current prototype and the client deciding with the development team how to proceed. The next step could be another iteration or accepting the current prototype as the final solution. If the prototype is a product prototype, the final solution can be implemented. If it is an iconic or simulated solution, then a Linear PMLC model can be used to create the production version. In this case, the RBS can correctly be assumed to be complete.

Rational Unified Process (RUP)

RUP is a completely documented process for building a software system in an iterative fashion. An extensive library of books and Internet resources are available on the topic. A good starting point is the book by Stefan Bergstrom and Lotta Raberg entitled Adopting the Rational Unified Process: Success with the RUP (Addison-Wesley, 2004). The bibliography has several other reference texts on RUP.

The essential phases in a RUP approach are as follows:

• Inception
• Elaboration
• Construction
• Transition

Inception

Inception has as its objective the definition and concurrence of all the stakeholders as to the scope of the software development project. The scope is bounded by a number of use cases that define the functions that the software system must perform. Initial systems architecture is developed using these critical use cases. Cost, schedule, and risk are also estimated as a preparation for the Elaboration Phase.

Elaboration

Elaboration is the engineering phase of a RUP project. It is here that the details of the problem and its solution are formed and the architecture is finalized. That permits more refined estimates of time, cost, and risk. Prototypes are often built as an aid to the design considerations, more detailed functionality, and features.

Construction

In the Construction Phase, the current design is turned into a working system. If this is phase has been repeated, then the most recent designs are integrated into the current solution and a more enhanced solution is turned over to the client.

Transition

Transition turns over a solution that the client and end user can put into production. It need not be a complete solution, but it does need to have sufficient business value to be released to the end user by the client. Later minor enhancements will be made to integrate features defined but not integrated.

All four of these phases are embedded within each of the stages shown in Figure 11-4. The stages are not explicitly shown in the figure, however.

Figure 11-4: Rational Unified Process

RUP is probably the most well known of the Iterative software development processes. It adapts quite well to a process approach that is documentation-heavy or to one that is documentation-light. The foundation of RUP lies in the library of reusable code, requirements, designs, and so on. That library will have been built from previous project experiences, which means that RUP can have a long payback period. The library must be sufficiently populated to be useful from a Return On Investment (ROI) perspective. Four to five completed projects might be enough to begin to see some payback.

RUP can be used over the APM quadrant of the project landscape. When complexity and uncertainty are low but the solution is not fully defined, RUP is viewed as a heavy process. It requires considerable documentation, especially for code reuse. On the other hand, an organization that has considerable RUP experiences to draw upon can deploy a lighter RUP version across many projects.

As Figure 11-5 shows, RUP is an example of the Iterative PMLC model.

Figure 11-5: RUP mapped into the Iterative PMLC model

Note that a RUP iteration begins with gathering requirements and ends with implementation of the resulting solution. You can almost interpret a RUP iteration as defining a complete Linear PMLC model. A RUP iteration is commonly defined around one or more related use cases, so that dictates the process to be followed for gathering requirements.

When to Use an Iterative PMLC Model

In addition to what I have already discussed about the use of Iterative PMLC models, there is one application that I want to present. I have used Iterative PMLC models for just about every continuous process-improvement project I have ever managed. It is clearly the best-fit choice for the following reasons:

• Intuitive to the client
• Easily engages the client
• Immediate feedback on the effect of solution change
• Tolerant of assessing and evaluating the impact of alternatives
• No fixed deadline for completion

Intuitive to the Client

The client is kept in the safety of their own work environment, where they can see the solution unfold and have an opportunity to practice with it and to offer their acceptance of it. The solution evolves rapidly from iteration to iteration. The differences between the alternatives that you present can be compared with respect to how they work and are represented in the solution. The client becomes an active decision maker in the process, and that is what you want to happen.

Easily Engages the Client

In my experiences with the Prototyping Iterative PMLC model, I have seen the client get very actively involved, and even excited, about seeing their solution evolve. As long as you are using a production prototype, you are safe working within the constraints of client excitement. When you are using iconic or simulated prototypes, the situation is very different. The time between iterations is often very short because you are not building a production version, and the client tends to minimize the effort required to go from an iconic or simulated solution to the real solution. They are disappointed when you tell them it will be six months before they will see and be able to deploy the production version.

Immediate Feedback on the Effect of Solution Change

On a recent project, I decided to use a simulated prototype approach to brainstorm possible solutions and was able to create a successive version of the solution in a matter of hours, and even minutes in some cases, not days or weeks. The simulated solution looked just like the production solution, but there was no logic generating screen after screen. It looked real to the client. I could feel the electricity in the air as the client really got into the process. Ideas were flowing freely, and the developers were able to respond quickly.

Tolerant of Assessing and Evaluating the Impact of Alternatives

In my experience with prototypes, I have gotten the most benefit out of using them on process-improvement projects. In this context, the time between iterations is long enough to implement a process change and let it operate long enough to measure the impact of the change on process performance. Process improvement projects are usually continuous improvement projects. There are target performance metrics that you would like to see in an improved process and you continue with iterations until the performance is reached or determined to be at its best.

No Fixed Deadline for Completion

The stopping rule for a prototyping project is usually qualitative, not quantitative. The solution either meets or does not meet client requirements, or the money runs out. The number of iterations is variable. Iteration timeboxes are usually not specified. But short duration timeboxes are good.