Chapter 12

Comparing Linear, Incremental, Iterative, Adaptive, and Extreme PMLC Models

Don't fall victim to forcing round projects into square project holes. You are only courting failure. If your project isn't well-served by your methodology, find, use and adapt a methodology that does fit the project.

—Robert K. Wysocki, PhD, President, EII Publications, LLC

This chapter brings together the details of 12 specific PMLC models to equip the sponsor, project manager, and project team with the information they will need to make an informed decision as to which PMLC model is the best fit to their project situation. I have had personal experiences with all 12 of these models or led consulting and training engagements with clients who have. There are other models such as Microsoft Solutions Framework, PRINCE2, ITIL, Crystal, Rolling Wave, Chunking, and many others. I could have included these and perhaps others as well. It was not my intention to produce a tome on specific PMLC models. The result would probably double the size of the book. Such a book would now need to come on wheels. My publisher would balk at that likelihood. The 12 models are organized around the five project management categories:

• Linear
• Incremental
• Iterative
• Adaptive
• Extreme

So your strategy for choosing a specific PMLC model is to first build a high-level RBS and based on its clarity and completeness:

This chapter contains the information you will need to make the best decisions for project setup that prepare your team for success.

Linear PMLC Model

The Linear PMLC model is the simplest and most intuitive of the five major model types that populate the project management landscape. This model assumes nearly perfect information about the project goal and solution as can reasonably be expected. This may have come from multiple experiences with similar projects or the fact that the project is just a simple well-defined effort. Deviations such as scope change requests can cause major upheavals in this planning-driven model. Figure 12-1 provides a high-level view of the Linear PMLC model.

Figure 12-1 The Linear PMLC model

The first thing to note about this model is that each phase must be complete before the next phase can begin. After a phase is complete, there is no returning at some later point to revise work completed in any earlier phase. There are no feedback loops. The Linear PMLC model is definitely not a learning model, which has been the major criticism of it. The contemporary business world is one of constant change. The world isn't going to stand still just because you are managing a project. So projects that are not impacted by outside factors are the ones that are likely to succeed using a Linear PMLC model. Infrastructure projects number among those that can generally use a Linear PMLC model with good results. Installing a network in a field office is an example of an infrastructure project. Construction projects are excellent candidates for a Linear PMLC model. Projects that are repeated annually or more frequently can also do well with a Linear PMLC model.

Characteristics

To be used effectively, the Linear PMLC model works best with projects that have the following:

• Complete and clearly defined goal, solution, requirements, functions, and features
• Few expected scope change requests
• Routine and repetitive activities
• Use of established templates

Complete and Clearly Defined Goal, Solution, Requirements, Functions, and Features

You first have to have a clear understanding of what the project is trying to accomplish. That originally led to a statement of the project goal, which you and your client developed together. With the goal firmly established, you and the client were able to define exactly what had to be done to achieve the goal. The statement of what had to be done was detailed through a requirements gathering process that listed and documented the functions and features that spelled out the details of what had to be done. If you and the client were convinced of the completeness of the requirements document, then a Linear PMLC model was chosen for the project.

At the risk of being repetitive, I want to stress that the decision that requirements details were complete is a very subjective decision. You will never really know that requirements details were complete. On the other hand, you would probably know that some of the details were not complete or clear.

Few Expected Scope Change Requests

You are not likely to encounter a project that turns out to be totally free of any scope change requests. We live and work in a dynamic environment that is always changing. I have never encountered a change-free project in more than 45 years of managing projects. It would be presumptuous of you and your client to expect that your project will be safe from any changes. If you have any doubt, add a management reserve task to the end of the project schedule and explain to the client how it will be used. If you successfully manage the project according to the initial plan and there are no scope change requests that impact the schedule, the project will end on its originally planned date. If not, you will have a contingency to handle the changes. If you feel there will be numerous changes, but you meet all other conditions for using a Linear PMLC model, you should probably choose some other model. An Iterative PMLC model would be my most likely choice.

Routine and Repetitive Activities

Even though projects are unique, they can still be repeated. Their uniqueness comes from external factors acting on the project, your client, your team, and your organization. If you manage projects that are routine and repetitive, here are some suggestions to make life a bit easier for you and to increase the effectiveness of your management of those projects.

Build and Use a Library of Templates

This is perhaps the most valuable artifact you will generate from repetitive projects. I have helped my clients build and use templates that range from complete WBSs to parts of WBSs; from candidate risk events lists to detailed risk mitigation plans for a specific risk event, acceptance test criteria lists, vendor solicitation strategies, Request for Information (RFI), Request for Proposals (RFP) and Request for Quote (RFQ) outlines, project notebook outlines, curriculum design, meeting agendas, and the list goes on. If you have a WBS template, it is highly likely that the template also contains duration, resource requirements, project network diagrams, and the schedule to the WBS template. That gives you a start on a big chunk of the project plan. It requires some editing for the specifics of the project plan, but at least you have a start. And you have a start for which there is previous experience.

Building a template library requires very little extra effort. You can start by simply saving in retrievable form any of the documents just mentioned that are produced as part of normal project activities. For some future project, retrieve the document and modify it for use on the current project. Add the modified document to your template library. In time you will build a variety of examples of that type of document. These become your templates. I have found with my clients that a template library has saved them time and reduces mistakes. They are also great training aids. Your Project Management Office (PMO) may already maintain a template library. If it doesn't, suggest that it start one.

But there is a caution here that you need to be aware of. Too many project managers look for silver bullet solutions, and templates can be misused. The degree of fit of a template to a project or partial project must be examined carefully. Expect to modify the template rather than use it off the shelf.

Keep a History of Risks, Your Mitigation Plans, and the Results

Risk history, like task duration history, can be a very simple file. The indexing variables might be any or all of the following:

• Risk category
• Risk type
• Risk description
• Mitigation plan
• Actual risk event that occurred
• Result
• Resource person

The team member who is responsible for the risk log will also have the responsibility of maintaining the risk history file. The risk log provides all of the information you need to populate your risk history file. Your PMO might support a risk history service. If it doesn't, ask it to do so.

Use of Established Templates

If used properly, the template library can really cut down on planning time, significantly increase the quality of your project management experience, and decrease the risk of project failure. There are several benefits to using templates, including the following:

• Increases standard practices
• Provides learning modules for new project managers
• Establishes an archive of project artifacts
• Provides input for process and practice improvement programs

Increases Standard Practices

If the templates are seen as valuable, they can become the foundation on which practices are formed. Learning by way of example is supported. As the templates are used, the adopters will find ways to improve them and ultimately improve the processes they support.

Provides Learning Modules for New Project Managers

Templates can be integrated into the classroom and online curriculum as learning aids for training project managers. Because you are using actual templates from the projects in your organization, they will be of maximum benefit to those attending training. They will have immediate application on the job.

Establishes an Archive of Project Artifacts

Artifacts from actual projects provide help to project managers across all Process Groups. Project managers need a simple and intuitive way to access information from past projects to find what will be helpful to them in managing their current projects. The collection of artifacts will grow quickly. That will require a good indexing and retrieval system. One of my clients has established an intake function for submissions to the archives. No one can just add stuff. All proposed submissions must go through the intake function and be screened for acceptability and indexing before they are added.

Provides Input for Process and Practice Improvement Programs

Templates are looking glasses into the Process Groups. They reflect how clients, project managers, and project teams have applied the PMLC models. Some will have done so correctly, others not. So, one of the responsibilities of the person in charge of the archive intake function is to screen contributions for compliance.

Strengths

The strengths of the Linear PMLC model are as follows:

• The entire project is scheduled at the beginning of the project.
• Resource requirements are known from the start.
• Linear PMLC models do not require the most skilled team members.
• Team members do not have to be co-located.

The Entire Project Is Scheduled at the Beginning of the Project

For those who don't like surprises, this is the ticket. The plan is complete. The project manager and every team member know what has to be done, who will do it, and when it must be complete. There are no surprises—well, you hope not too many, and not too serious ones at that.

Resource Requirements Are Known from the Start

Not only do you know what type of resource is needed but you also know when, for how long, and what that resource is required to do. For people resources you even know the name of the person who will be assigned to the project. That allows you to complete the project budget. You will know what everything will cost and when you need to encumber the funds.

Human resource management and planning can benefit from the Linear PMLC model. Because you know from the existing project plans what skills are needed, by when, and in what numbers, you can compare this against your inventory of skills and when they will be available. The gaps will give you information training and development needs. You have an opportunity to take corrective steps to remove those skill gaps through training or otherwise plan for contracting out your needs.

Linear PMLC Models Do Not Require the Most Skilled Team Members

This is the real strength of the Linear PMLC model. Because the project plan is detailed and work packages have been written for some tasks, a person of intermediate skill can do the work with minimal or no supervision. This is a real plus.

Team Members Do Not Have to Be Co-Located

Again, because the project plan is complete, the person responsible for the task can proceed with the work wherever he or she happens to be located. Some added documentation may be required. Outsourcing and the use of offshore developers are also possible alternatives.

There are strategies that you might employ when the development team is located across several time zones. For example, I have done development in the United States and passed the code to Europe and Asia for testing. The following morning, the developers in the United States had tested code at their disposal. So while having a team distributed across several time zones has its management problems, there are also some advantages to this sort of scheduling.

Weaknesses

The weaknesses of the Linear PMLC model are as follows:

• Does not accommodate change very well
• Costs too much
• Takes too long before any deliverables are produced
• Requires complete and detailed plans
• Must follow a rigid sequence of processes
• Is not focused on client value

Does Not Accommodate Change Very Well

The problem is that nearly any scope change request that is approved will create problems with the schedule. The time of the team members who have to process the request and write the Project Impact Statement is time that has to be added to the schedule. That probably results in a delayed completion of the project. That is the lesser of the two problems. The more serious problem is the adjustment to the schedules of every task that was scheduled to occur after the scope change was added to the project schedule. Literally every team member's schedule will be affected. If those schedule changes are too severe, the request might be delayed until much later in the project. I'm sure you can see the potential for adding significant management time just to accommodate the change request.

Costs Too Much

The client won't see any of the deliverables until the 11th hour in the project schedule—when the acceptance test criteria are being checked for requirements satisfaction. Usually there will be problems with acceptance. More work will have to be done, but there is no money available for that work. By that time, most of the money will have been spent.

Takes Too Long Before Any Deliverables Are Produced

As I just stated, the client doesn't see any of the deliverables until very late in the project. That leaves no time for change even if the money is available. The project deadline is rapidly approaching, and the team members are scheduled to move on to other project work. This is not a problem in simple projects but all of those have already been done. In more complex projects, any additional work that has to be done to gain client acceptance will take time that has not been planned for and will come at the end of the project. The team members' attention is already turned to their next assignment.

Requires Complete and Detailed Plans

Although this may sound strange, a complete plan may be a waste of time. Before you cast your first stone, let me explain. In my early years as a project manager, I fell into the trap of always requiring complete plans. Unfortunately I don't recall even one of those plans being executed without changes being made. Every change request that is approved requires a revision in the project plan from the point where the change is inserted to the end of the project.

Must Follow a Rigid Sequence of Processes

You chose to use the Linear PMLC model, so you have to play by the rules. And the rules say no going back. Remember, you chose this model because you didn't expect to have to go back.

Is Not Focused on Client Value

The Linear PMLC model is driven by the need to get the project done on time, within the budget, and according to client specifications. Nowhere does it say that you have to deliver business value. If it should happen that the delivery according to client specification is the cause of business value, then you are okay. Unfortunately I have had many clients tell me that they got what they asked for, but it didn't do what they expected. Go back to the discussion of wants versus needs in Chapter 4, and you'll find an explanation for this.

When to Use a Linear PMLC Model

Projects that have been repeated several times are excellent candidates for a Linear PMLC model. Supposedly you built a library of templates for those repetitive projects. You will have encountered and put plans in place for every identifiable risk. There will be few, if any, surprises. Simple projects of short duration that fall entirely within a single department and use no resources outside of that department are also good candidates for the Linear PMLC model. Construction and installation projects are particularly amenable to Linear PMLC models.

Specific Linear PMLC Models

There are two Linear PMLC models that we will discuss: Standard Waterfall and Rapid Development Waterfall.

Standard Waterfall Model

The usual rendition of the Standard Waterfall model is shown in Figure 12-2. In practice it is a model that never looks back. Once a phase is complete the process moves to the next phase. Earlier versions allowed for feedback loops, but that has been lost to history. The Standard Waterfall model has been around for more than 50 years and is discussed in any good book on systems development life cycles. While it was originally meant for software development projects it has applications in non-software development projects as well.

Figure 12-2 The Standard Waterfall model

Rapid Development Waterfall Model

The Rapid Development Waterfall model is more recent and is frequently used to get product to market faster by grouping development into parallel and nearly independent “swim lanes”. Grouping for effective and speedy development is challenging. It requires swim lanes that are as independent of one another as is possible. The linearity of the process is still maintained with these parallel swim lanes. Figure 12-3 depicts those parallel swim lanes. There are several things to consider in creating such a development schedule. The first is risk. By squeezing the work into a shorter time frame the incidence of errors and staff scheduling conflicts increases. The amount of work has not decreased it just must be completed in a shorter time frame. Allocating the work to concurrent swim lanes shortens the project duration but increases the risk of completing the project. By cramming more work into a shorter timebox there is less time for mistakes and less time to recover from those mistakes. Having parallel swim lanes in the project schedule raises the possibility of further aggravating any potential resource scheduling conflicts that were present in the initial schedule. The last parallel swim lane that is complete determines the completion date of the development project. It is clear that the risk from a Rapid Development Waterfall model is greater than that of the Standard Waterfall model.

Figure 12-3 The Rapid Development Waterfall model

The Rapid Development Waterfall model occurs frequently in product development projects. Figure 12-3 is a graphical description of that variation. The purpose of this variation is to finish the project as quickly as possible so as to get the deliverables implemented sooner. Usually this is done in response to pressures from marketing for early entry of new or revised products.

In the Rapid Development Waterfall model, the sequencing is followed through multiple swim lanes, with each swim lane defining a linear path. The Rapid Development Waterfall model has an integration process that the Standard Waterfall model does not. The deliverables from each swim lane and the accompanying testing must be integrated in order to produce the final deliverables. This adds time to the schedule that is not present in the Standard Waterfall model.

The decision to use this variation must be made during execution of the Planning Phase. Note that planning is done once in the Standard Waterfall model. The planning goal is to partition the functions and features into independent swim lanes so that the dependencies within each swim lane are high (maximum cohesion) and the dependencies between swim lanes are minimal or nonexistent (minimal coupling). This allows each swim lane to proceed independently of all other swim lanes. That minimizes the additional management time brought about by the parallel dependent swim lanes. If a cross–swim lane dependency exists and something goes wrong in one swim lane, it can adversely impact other swim lanes that are dependent upon it.

One of the major obstacles to minimal cohesion is resource contention across the dependent swim lanes. Using team members across swim lanes is another area where caution is needed. If one swim lane is delayed, it can delay the availability of a team member to begin work in another swim lane. Don't expect to avoid this resource contention problem altogether in the Rapid Development Waterfall model. It won't happen. You just have to be aware of the risks and do what you can to minimize the impact.

Incremental PMLC Model

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, solutions that are 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 12-4 is a graphical description of the Incremental PMLC model that shows the dependent increments. The increments follow sequentially, not concurrently.

Figure 12-4 The Incremental PMLC model

Note that the sequence formed by the Launching, Monitoring and Controlling, and Closing steps 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 step.

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 step 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 business 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 Business 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 to execute 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 12-5.

Figure 12-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 to Execute Than the Linear PMLC Model

There are several reasons for this added time. It arises from the following:

• Delays between increments
• The need for handoff documentation between increments
• More scope change requests
• Supporting interim solutions (for example, training and documentation)
• 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 Model

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. In many cases there will be a marketing advantage that accrues to the early entrants. The added risks are often much higher than if a Linear PMLC model had been chosen.

Incremental PMLC Models

Incremental PMLC models are really just a variant of Linear PMLC models but deserve separate discussion. Just as the Linear PMLC models require clearly defined and documented goal and solution so also do the Incremental PMLC models. Whereas Linear PMLC models build and release deliverables all at one time, Incremental PMLC models build and release deliverables in stages over time. For marketing and early sales reasons these models are often chosen. For example, an Incremental PMLC model is often used to release a product in stages to test market acceptance and other variables. The downside of Incremental PMLC models is that the client is tempted to introduce scope change requests between increments. That's okay, but the original project timebox will have to allow time for those scope change requests to come forward from the client, be evaluated, and be acted upon. Management Reserve (see Chapter 6) is a time contingency added as a task to the end of the project schedule to accommodate the time needed to process and incorporate changes. That is an often overlooked detail in Incremental PMLC models. Also having downtime for the development team between increments is a temptation for their resource managers to temporarily reassign those team members elsewhere. There is always the promise that they will return to the team when the next increment is ready to start but that rarely happens. As a form of insurance to protect against the loss of a team member handoff documentation is usually prepared. That adds work not found in the Linear PMLC models.

Staged Delivery Waterfall Model

When considering using an Incremental PMLC model you need to give some thought to the added risk. Figure 12-6 is an example of a Staged Delivery Waterfall model.

Figure 12-6 Staged Delivery Waterfall model

The Staged Delivery Waterfall model suffers the same risks as any other Incremental PMLC model. A constraint of the model is the content of each increment. The deliverables from Increment “N” must have all predecessor deliverables built in the previous “N-1” Increments. This is likely to compromise, or delay, increments having business value sufficient to warrant release to the end user or the market. At best the process is cumulative. That is, not every increment will contain sufficient business value but the last several increments since the last release might offer sufficient business value to be released.

Incremental PMLC models encourage scope change but should not be used to further identify missing parts of the solution or improve an existing solution. That is a job for APF, which is discussed later in this chapter.

Feature-Driven Development Model

Feature-Driven Development (FDD) is not a client-facing model. Instead it delivers partial solutions in parallel, technically cohesive increments referred to as feature sets. FDD first appeared in Java Modeling in Color with UML by Peter Coad, Eric Lefebvre, and Jeff DeLuca (Prentice Hall PTR, 1999). A more comprehensive treatment of FDD can be found in A Practical Guide to Feature-Driven Development by Stephen R. Palmer and John M. Felsing (Prentice Hall PTR, 2002).

The high-level process view of the FDD model is shown in Figure 12-7. Note that planning is done only once, so the solution must be known in order to use FDD effectively. A model of the solution is developed and used to create the functional WBS. The functional WBS contains a very detailed list of features. The features list is grouped into similar features and prioritized for development. FDD iterates on the design and building of the groups of features.

Figure 12-7 FDD model

Much like the Rapid Development Waterfall model, the FDD model prioritizes parts of the solution. But this time it is features-driven. Just as in the Rapid Development Waterfall model, you have multiple design/build swim lanes running sequentially in the FDD model. It differs from the Rapid Development Waterfall model in that the releases consist of groups of features that have a technical relationship to one another rather than a functional relationship to one another. Several feature sets might have to be completed before the client is satisfied that the cumulative features list has enough business value to be released. FDD models might use concurrent swim lanes, sequential phases, or some combination of the two.

To successfully implement either the Rapid Development Waterfall model or the FDD model, you have to begin during the construction of your project network diagram. Your objective is to define a sequence of swim lanes where each swim lane contains the functions and features of part of the solution. In total, all swim lanes contain functions and features that combine to provide a complete solution. These swim lanes must have the following properties:

• The functions and features of a swim lane can be built independently of the functions and features of any other swim lane.
• There are no resource dependencies across swim lanes.
• There are no schedule dependencies across swim lanes.
• The total duration of each swim lane must be nearly equal.

If these properties cannot be satisfied, then at least the interactions between swim lanes must be minimized. Although this variation might seem to be very attractive given today's rush to market, some problems will arise.

There are several things to consider in creating such an aggressive schedule. By squeezing the work into a shorter time frame, you must remember that the amount of work has not decreased—it just must be completed in less time. The last parallel swim lane that is complete determines the completion date of the development project. The results of schedule compression are as follows:

• Increased management time to handle intra– and inter–swim lane issues
• Increased likelihood of resource contention
• Potential for overlooking cross–swim lane dependencies
• Less time to recover from a mistake

All of these results contribute to an increased risk of project failure. So if there is pressure to use either the Rapid Development Waterfall model or the FDD model instead of the Linear PMLC model, assess the complexity and potential risk implications. You might also want to assess the skills and competencies of the project team members and the likelihood that they can adapt to such an aggressive schedule.

Iterative PMLC Model

For Traditional Project Management (TPM) projects, change is the exception. It is costly and upses already planned and committed schedules. For Agile Project Management (APM) projects, change is the norm. It is needed to discover missing pieces of the solution. This difference is significant and results in completely different approaches to managing such projects. While the TPM project will use some form of Linear or Incremental PMLC model as discussed previously, the APM project will use some form of Iterative or Adaptive PMLC model as discussed in the following sections. TPM projects are plan-driven. APM projects use just-in-time planning. So when the solution is not clearly and completely defined you will have to approach the project as some type of agile project and use the appropriate Agile PMLC model. Agile projects come in two flavors:

• Most of the solution is known—Those projects whose goal is clearly defined and documented and whose solution is complete up to the point of specifying the final rendering of one or more features. These projects are what I would call minimalist agile projects. These projects should use an Iterative PMLC model as illustrated in Figure 12-8, but could also use an Adaptive PMLC model as described and illustrated later in this chapter.

Figure 12-8 Iterative PMLC model

• Most of the solution is unknown—Those projects whose goal is clearly defined and documented but whose solution features and functions are not clearly defined and documented. In other words, much of the solution has not been identified. These projects are what I would call maximalist agile projects. These projects should use an Adaptive PMLC model as described and illustrated later in this chapter.

Evolutionary Development Waterfall and Rational Unified Process (RUP) are minimalist agile approaches as defined in this book. Scrum and APF are maximalist approaches. In practice I have seen project managers force fit maximalist adaptive projects into minimalist approaches. While they may have some success with that approach, it would be better to use a maximalist agile approach which is designed for such projects.

Whereas Iterative PMLC models work well in situations where only minor parts of the solution (typically features) have not been defined in the solution, Iterative PMLC models are minimalist agile approaches. The Iterative PMLC models are most effective where we still know all of the functions but some of the features are not known as definitively as the client would like.

Characteristics

Iterative PMLC models are used for projects whose solutions are just vague enough to not use Incremental PMLC models although some project managers will do so out of necessity or lack of any practical experience using Iterative PMLC models. The relevant characteristics are:

• Complete and clearly defined goal
• Minor parts of the solution not yet defined
• Incomplete requirements
• Some scope change requests are expected
• Solution is known but not to the needed depth
• Often uses iconic or simulated prototypes to discover the complete solution

Complete and Clearly Defined Goal

This is the same as the Linear PMLC models.

Minor Parts of the Solution Not Yet Defined

The Iterative and Adaptive PMLC models can be ordered from those whose solution is almost totally known to those whose solution is almost totally unknown. This ordering is important because the best-fit choice will usually be the one that demands the least creativity and that means a choice nearer the beginning of the ordering.

Incomplete Requirements

Requirements can be elicited at the highest level with little difficulty and will often be used as project objective statements. The RBS is a different matter however. Building a complete RBS is usually not possible at the beginning of a complex project. That is commonly held by the project management thought leaders. A complete RBS would require an in-depth understanding of the solution and, by definition, that is not a characteristic of a complex project. Detailed requirements will be discovered using the specific Iterative or Adaptive PMLC model chosen for the project.

Some Scope Change Requests Are Expected

The solution is almost complete and only minor scope changes will be needed to complete the solution. These will be discovered during project execution and necessitate scope changes in order to be implemented.

The Solution Is Known, but Not to the Needed 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 Iterative PMLC models share a number of strengths:

• Based on just-in-time planning
• Accommodates change very well
• Is focused on generating business value
• Client reviews partial solutions for improvement
• Can process scope changes between iterations
• Adaptable to changing business conditions

Based on Just-in-Time Planning

All Traditional PMLC models are plan-driven models. That means a complete plan is required to get the project started. That plan will probably change, but it is still needed to get things going. A just-in-time planning approach eliminates all revisions due to scope changes, as would be present for any plan-driven approach. Iterative PMLC models develop plans only for those activities that are certain to be part of the solution and not for activities in the future that might be part of the solution. The elimination of non-value-added work is a hallmark of any process that purports to be “lean.”

Accommodates Change Very Well

Since change is a necessary part of any Agile or Extreme PMLC, an efficient scope change process is needed. That process will usually collect scope change requests that arise during an iteration and group them for analysis and decision during a client checkpoint when the iteration is complete. Again, that eliminates much of the non-value-added work associated with processing scope change requests. Only one schedule revision is needed for the group of approved scope changes rather than one schedule revision for each approved individual scope change request.

Is Focused on Generating Business Value

Focusing on meeting time, cost and requirements is not what many project thought leaders recommend. Meeting these constraints has nothing to do with delivering business value expected by the sponsor or client which results in their dissatisfaction. Agile and Extreme PMLC models are based on achieving the business value that justified commissioning the project in the first place. Business value is an integral part of the POS (see Chapter 4).

Client Reviews Partial Solutions for Improvement

There is no substitute for 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:

• Risks losing team members between iterations
• Subject to losing priority between iterations
• Resource requirements unclear at project launch
• Requires a more actively involved client than TPM projects
• Requires co-located teams
• Implementation of intermediate solutions can be problematic
• Final solution cannot be defined at the start of the project

Risk Losing Team Members Between Iterations

If there is a lag between a just completed iteration and the beginning of the next iteration, there is a danger that a team member may be lost. Can you envision this situation: “While Harry is waiting for the next iteration to start, could I borrow him for one week?” Somehow that week gets extended and for all intent and purposes Harry is lost.

Subject to Losing Priority Between Iterations

An iteration has just been completed and its deliverables successfully installed. This can put the next iteration in harm's way as other competing projects may be given a higher priority. Your project is postponed and the resources reassigned to the competing project.

Resource Requirements Unclear at Project Launch

Since the solution is not completely known it is reasonable to expect that the resources requirements to discover and develop the missing pieces are not known either. How might availabilities compromise the planning going forward?

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. A more actively involved client may help overcome some of the problems that arise when the team is not co-located.

Difficult to Implement Intermediate Solutions

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.

When to Use an Iterative PMLC Model

Iterative PMLC models are learning and discovery models. That is a significant departure from Linear PMLC models and is a great strength of Iterative PMLC models. So whenever there is any doubt about the clarity or completeness of the solution and its requirements the safe ground is to move to an Iterative PMLC model. Do not try to adapt a Linear PMLC model to a project that clearly requires the benefits to be gained from an Iterative PMLC model. Through iteration, these models allow for the review of partial solutions and the creation of the next steps of the plan going forward. Resources are committed when it makes sense and in the most efficient manner possible.

Specific Iterative PMLC Models

Based on my experiences and client practices I have chosen six Iterative PMLC models:

• Prototyping
• Evolutionary Development Waterfall
• Rational Unified Process (RUP)
• Dynamic Systems Development Model (DSDM)
• Adaptive Software Development (ASD)
• Scrum

They are listed here in the order I have found useful as the solution completeness decreases. At some point the solution becomes so vague that Iterative PMLC models give way to the more robust Adaptive PMLC models.

Prototyping 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 prototypes and simulated prototypes. These are often employed when the client doesn't have a good idea of what they need or cannot explain what they need. Iconic and simulated prototypes will often be used as conversation starters. 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 12-9, 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 12-9 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 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.

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.

Evolutionary Development Waterfall Model

Iterative models are minimalist agile approaches. The Iterative PMLC Models are most effective where we still know all of the functions but some of the features are not known as definitively as the client would like. A good example of this model is the Evolutionary Development Waterfall model.

In this approach the project begins much like Standard Waterfall model. The known parts of the solution are developed based on current requirements. Through the Evolutionary Development Waterfall model (Figure 12-10) iterations on the further details of the solution will be undertaken. As the features and functions needed to deliver the requirements are developed, the requirements may well change but few additions or deletions to the original requirements are expected. The WBS for the current version is created along with duration, cost, and resource requirements. This model closely resembles the production prototype approach that has been quite popular for many years.

Figure 12-10 Evolutionary Development Waterfall model

Unlike the traditional models it should be obvious that the meaningful involvement of the client is critical to the success of agile models. The client works with a version of the solution and provides feedback to the project team for further enhancements and changes to features and functions. This process continues as version after version is put in place. At some point in time the client is satisfied that all requirements have been met. Also note that this model always presents the client with a production ready version of the solution.

In the Evolutionary Development Waterfall model the learning and discovering experience is obvious from Figure 12-10. With each iteration more and more of the depth of the solution is revealed. That follows from the client and developers having an opportunity to play with the then solution. For simple and obvious enhancements this approach works just fine.

There is one variation worth mentioning here. There may be cases where iteration on solution design might precede iteration on version. While these tend to be the early efforts for an adaptive model, they can be used here with good effect. Iteration on design helps the client move up the learning curve of understanding the solution concept. Armed with that understanding, the client is better prepared to participate in iterations on the version. Design iteration is done quickly. If you have the right design tools, in my experience design iteration can be done in a matter of days not weeks or months.

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. 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.

For more details see Chapters 17–23 in my book Effective Software Project Management (John Wiley & Sons, 2006). The Evolutionary Development Waterfall Model works fine for those situations where only a small part of the solution has not been clearly defined. How to represent a feature in the solution, for example, would be a case where a small part of the solution is not clear. The development team merely presents the client with renditions of the alternatives, asks for a decision as to which alternative is preferred, and then implements it in the solution. But when the missing parts of the solution are more significant, like how to make a particular decision, then a more powerful approach is needed. This more powerful approach would be some form of Adaptive PMLC Model.

Rational Unified Process (RUP)

The Rational Unified Process (RUP) (Figure 12-11) is a completely documented software engineering process for building a solution in an iterative fashion. One might argue that RUP belongs in the maximalist approach category. I have chosen to put it here. There is an extensive library of books and Internet resources available. 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).

Figure 12-11 Rational Unified Process model

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 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. That means that RUP can have a long payback period. The library must be sufficiently populated in order to be useful from an ROI perspective. Four to five completed projects may be enough to begin to see some payback.

RUP ranges widely over the project landscape. When complexity and uncertainty are low but the solution is not fully defined RUP is a heavy process. It requires considerable documentation especially for code reuse.

Note that each iteration begins with a requirements gathering session. The presumption is that the previous iteration will have clarified future directions for the project to take and those would be fleshed out in the next requirements gathering exercise. The direction that a RUP Project takes tends to be reactive to the requirements gathering activity. APF, on the other hand, is a proactive model that seeks out missing solution parts through probative swim lanes. APF does not depend totally on discovery of the solution which is passive but also depends on proactive initiatives which are activities designed to learn about the solution. It is this property that sets APF apart from all other Agile PMLC models.

RUP consists of four concepts—Inception, Elaboration, Construction, and Transition—which run concurrently through all iterations.

Inception

Through a series of requirements gathering sessions in each iteration an understanding of the scope of the development effort is agreed to and a cumulative solution as to how the scope will be developed can begin. Whatever parts of the solution have not been implemented it is expected that the requirements gathering sessions at the start of an iteration will uncover those missing parts.

Elaboration

Whereas Inception focuses on what is to be done, Elaboration focuses on how it will be done. This is a technical design activity with the appropriate technical specification and plan as deliverables. RUP is an architecture-centric process, so these technical specifications must technically integrate with the deliverables from all previous iterations. RUP is not a client-centric process as is APF. In the APF world these first two RUP concepts are the equivalent to the Version Scoping Phase and Cycle Planning Phase.

Construction

This is the build phase of a RUP iteration. It is equivalent to the Cycle Build Phase of an APF Project.

Transition

The then solution may be released into production if the client is satisfied that such a release has business value and can be supported by the organization. This is the same as the release decision in an APF Project.

Dynamic Systems Development Method (DSDM)

Dynamic Systems Development Method (DSDM) is what the Standard Waterfall model would look like in a zero gravity world. Feedback loops are the defining features that separate DSDM from the Standard Waterfall model. DSDM advocates would claim that a DSDM approach will deliver results quicker with higher quality and less cost than any TPM PMLC model. DSDM is an adaptive model. The feedback loops help guide the client and the project team to a complete solution. The business case is included as a feedback loop so that even the fundamental basis and justification of the project can be revisited. DSDM claims to be the only publicly available framework that covers the entire systems life cycle from end to end.

The list below contains the 9 key principles of DSDM. Note that these principles are quite similar to those we have previous identified as good practices.

Most Agile PMLC models can subscribe to the same principles. With minor variation these principles are common to the APF PMLC model, too, and will be further commented on in the context of APF in a section later in the chapter.

Figure 12-12 highlights the DSDM method.

Figure 12-12 Dynamic Systems Development method

The distinguishing feature of the DSDM is the incremental release and implementation of a production system at the end of each cycle. Note that iterations around Design and Build and Functional Model iterations all follow with an implementation phase. DSDM delivers business value to the client as part of its overall process design. Other approaches may do the same as a variation, but DSDM does it as part of the design of the approach itself.

Pre-Project

This phase includes some type of project overview, charter, or high-level business case designed to support the decision that the project should be undertaken. Once the decision to approve the project is made, the project is funded and the feasibility study can begin.

Feasibility Study

A decision must be made as to whether or not to use DSDM on this project. The typical feasibility study is done, but with the addition of the question about the appropriateness of DSDM. As part of answering that question, consideration is given to the support of DSDM that can be expected from the organization and the capabilities of the available project team members. The DSDM feasibility study is not an exhaustive treatise but is quite high level. Two weeks at most should be allocated to the feasibility study phase. Remember you only want a decision to use DSDM or not.

Business Study

The client team in collaboration with the developer team will do a high-level investigation of the business processes affected by the project and identify information needs. The investigation is best conducted in a workshop environment with the appropriate SMEs involved. High-level process and data flow diagrams are often produced. Requirements are documented. System architecture is defined, but with the proviso that it will probably change as the project progresses. Finally, a high-level plan is developed. It will identify expected prototyping (if any) during functional model iteration and design and build iteration phases.

Functional Model Iteration

In this phase the functional model and information requirements are refined through repeated cycles of the following tasks:

• Identify what you are going to do in this next cycle
• Decide how you are going to do it
• Do it
• Check that you did it right

Systems Design and Build Iteration

These iterations will select prioritized requirements and design and build them. Production prototypes are commonly developed as well. A partial solution is delivered at each iteration and the complete solution as a deliverable from this phase.

Implementation

This is the handoff from development to production. All of the typical implementation activities take place in this phase. Those activities include installation, training, documentation, operations support, and user support.

Post-Project

A post-implementation audit will follow after a suitable period of use has passed. Revisions and other system changes are accepted and built into the system through new releases.

Adaptive Software Development (ASD)

Adaptive Software Development (ASD) is fully described in a book by James A. Highsmith III titled Adaptive Software Development: A Collaborating Approach to Managing Complex Systems (Dorsett House, 2000). ASD has three phases: Speculate, Collaborate, and Learn. These three overlapping phases are shown in Figure 12-13.

Figure 12-13 Adaptive Software Development model

Speculate

The Speculate Phase is nothing more than a guess at what the final goal and solution might look like. It may be correct or it may be far from the mark. It really doesn't make much difference in the final analysis because the self-correcting nature of ASD will eventually lead the team to the right solution. “Get it right the last time” is all that matters.

Collaborate

A Speculate Phase has been completed and it is time to take stock of where the team and client are with respect to a final solution. The client team and the development team must collaborate on their journey to discover the solution. What great “ahas” did the entire project team discover? What direction should the project take in the next and succeeding iterations?

Learn

What was learned from the just completed phase and how might that redirect the team for the next phase?

The ASD Life Cycle Model

Figure 12-13 also shows the detailed phases of ASD.

Project Initiation

The objective of the project initiation phase is to clearly establish project expectations among the sponsor, the client, the core project team, and any other project stakeholders. This would be a good place to discuss, agree upon, and approve the POS. For a project of some size (more than 6 months) it might be a good idea to hold a kick-off meeting, which might last 2–3 days. During that time requirements can be gathered and documented and the POS written. As part of project initiation, a brief statement of objectives for each iteration is prepared. These are expected to change as the solution detail develops, but at least the sponsor, client, and development team have a sense of direction for their efforts.

Adaptive Cycle Plan

Other deliverables from the kick-off meeting might include the project timebox, the optimal number of cycles and the timebox for each, and objective statements for the coming cycle. Every cycle begins with a plan for what will be done in the coming cycle. These plans are high level. Functionality is assigned to sub-teams and the details are left to them to establish. This is at odds with TPM, which requires organized management oversight against a detailed plan. ASD is light when it comes to management processes.

Concurrent Component Engineering

Several concurrent swim lanes are established for each functionality component. Each subteam is responsible for some part of the functionality planned for the present cycle.

Quality Review

This is the time for the client to review what has been completed to date and revise accordingly. New functionality may emerge; functionality is reprioritized for consideration in later cycles.

Final QA and Release

At some point the client will declare the requirements met and there will be a final acceptance test procedure and release of the product.

Scrum

Scrum is not an acronym; it is a term taken from rugby. Scrum involves the team as a unit moving the ball down field in what would appear to be an ad hoc or even chaotic manner. Of all the iterative approaches, Scrum would seem to define a chaotic development environment. The Scrum software development team is self-directed, operates in successive one-month iterations, holds daily team meetings, continuously offers the client demos of the current solution, and adapts its development plan at the end of each iteration. For a complete discussion on Scrum and software development refer to Agile Software Development with Scrum by Ken Schwaber and Mike Beedle (Prentice Hall, 2001).

Of all the development models discussed in this book, Scrum is clearly a customer-driven approach. It is the customer who defines and prioritizes the functions and features which the team prioritizes into phases and builds a phase at a time. The process allows the customer to change functions and features as more of the solution depth is uncovered through the previous iterations. Depending on the working definition you are using from Scrum, Scrum may be a strict application of the iterative class as defined herein or it may border on the adaptive class discussed later.

The Scrum process flow is shown in Figure 12-14.

Figure 12-14 The Scrum process flow

Idea Is Proposed

The original idea for the system may be vague. It may be expressed in the form of business terms. A function level description can be developed as part of the scoping phase but not to the depth of detail that the client requires. It is not likely to be expressed in system terms.

Develop and Prioritize List of Functionality

The Product Owner is responsible for developing this list, which is called the Product Backlog. It will help the team understand more detail about the idea and help them form some ideas about how to approach the project.

Sprint Planning Meeting

This is an 8-hour meeting with two distinct 4-hour parts. In the first part the Product Owner presents the prioritized Product Backlog to the development team. This is the opportunity for the team to ask questions to clarify each piece of functionality. In this first part of the meeting the team commits to the Product Owner the functionality it will deliver in the first 30-day Sprint. The team then spends the remaining 4 hours developing the high-level plan as to how it will accomplish the Sprint. The work to be done is captured in the Sprint Backlog. The Sprint Backlog is the current list of functionality that is not yet completed for the current Sprint.

Sprint Backlog

This is the running current Sprint list of undone functionality for this 30-day Sprint.

Demo Sprint Functionality

At the end of the Sprint the team demos the solution to the client; functionality is added or changed; and the Product Backlog is updated and reprioritized for the next Sprint. This entire process continues until the Product Backlog is empty or the client is otherwise satisfied that the current Sprint version is the final solution.

Adaptive PMLC Model

Adaptive refers to maintaining constant vigil on the total environment in which the project is conducted and managed. Any change in that environment triggers an impact study to decide on the best way to continue the project. That includes the choice of best-fit PMLC model. At present there is only one PMLC model with these characteristics designed into the model—Adaptive Project Framework (APF). It is discussed in detail in this section.

Adaptive PMLC models are most appropriate for situations where sizable parts of the solution have not yet been identified. Figure 12-15 illustrates the Adaptive PMLC model. In the most complex situations incompleteness could even extend to requirements. APF, a model that I developed in 1994 in collaboration with two separate client engagements, is the first example of an Adaptive PMLC model. APF can be used for software development projects as well but it has a much wider range of applications. Even though it is a member of the APM category APF was first designed for use on non-software development projects. APF was initially defined for a process design project and a product design project.

Figure 12-15 Adaptive PMLC model

Characteristics

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

• Iterative structure
• Just-in-time planning
• Critical mission projects
• Thrives on change through learning and discovery
• Continuously reviewed and adapted to changing conditions

Iterative Structure

An Adaptive PMLC model is structured around iterations that are designed to find and complete the solution. Each Adaptive PMLC model finds and defines that solution in different ways.

Just-in-Time Planning

For all of the Adaptive PMLC models, planning is confined to the next iteration. There is no speculation on what might be in the solution and then planning for it. That would turn out to be a potential waste of time.

Critical Mission Projects

Because of the complexity and uncertainty associated with an Adaptive project, these projects are high risk. With that high risk comes high business value. They are undertaken because their successful completion is critical to the enterprise.

Thrives on Change Through Learning and Discovery

Learning and discovery sets Adaptive projects apart from Iterative projects. The learning and discovery can come about only with the client being heavily involved in the project. There is an increasing dependence on that involvement as you move across the Adaptive landscape.

Continuously Reviewed and Adapted to Changing Conditions

This is essential if the chosen PMLC model is to maintain alignment to the changing needs of the project and its dynamic environment. The underlying assumption for effective complex project management is captured in the following note.

In other words there are no fail-safe recipes for project management success. That is the domain of the cooks. But you need to be a chef if you hope to succeed in the complex project world!

Strengths

The strengths of the Adaptive PMLC model are as follows:

• Continuously realigns the project management process to accommodate changing conditions
• Does not waste time on non-value-added work
• Avoids all management issues processing scope change requests
• Does not waste time planning uncertainty
• Provides maximum business value within the given time and cost constraints

Continuously Realigns the Project Management Process to Accommodate Changing Conditions

At the time of this writing, APF is the only Adaptive PMLC model that does this. The less that is known about the solution, the more likely the choice of PMLC models may not be the best fit. So as the solution unfolds through iteration, project execution may benefit from minor adjustments to a complete change of PMLC model. This is no small decision as is discussed in the closing section of this chapter.

Does Not Waste Time on Non-Value-Added Work

This is one of the basic principles of lean project management. It is an essential strength of all Adaptive PMLC models.

Avoids All Management Issues Processing Scope Change Requests

In the Adaptive PMLC models, there is no formal scope change management process. What otherwise would have been a scope change request in a Linear or an Incremental PMLC model is simply a note to the Scope Bank in the Adaptive PMLC models. That item is considered and prioritized along with other functionality and features yet to be integrated into the solution. Best of all, it does not take time away from the team's work. It is imbedded in the planning time spent between cycles.

Does Not Waste Time Planning Uncertainty

No one can know the future, so why waste time guessing what it might be and then planning for it? I have encountered many project managers who have a project that clearly fits an APM model, but they force-fit it to a TPM model. If that has been your practice in the past, stop it right now. You will save yourself many heartaches and project failures. Spend your time planning the certainty part of the project, and leave the uncertainty to the future (you will discover it in good time).

Provides Maximum Business Value within the Given Time and Cost Constraints

At the completion of each cycle, the entire project team will consider what is still missing from the solution and how it might be discovered and integrated. Those missing pieces should be prioritized based on business value and their discovery should be investigated. So, every cycle ends with a more complete solution than the previous cycle, and the new solution has maximum business value at that point in time. If the project should be canceled for any reason, the client will walk away with the best that could have been done for the effort, time, and money expended. That is not the case with any project that uses a Linear PMLC model and most projects that use an Incremental PMLC model.

Weaknesses of the Adaptive PMLC Model

The weaknesses of the Adaptive PMLC model are as follows:

• Must have meaningful client involvement
• Cannot identify exactly what will be delivered at the end of the project

Must Have Meaningful Client Involvement

You know that the Iterative PMLC models benefit from client input. That is a passive type of input. You show the client something, they give it thumbs-up or -down, and you go on to the next iteration. In an Adaptive PMLC model, that involvement changes from passive to active. The entire project team collaborates on the current solution. The responsibility for suggesting the next version of the solution is shared equally among the client members and the developer members of the project team. Clients must be fully engaged and must accept responsibility for the project along with the development team. Client involvement increases across the Agile PMLC models.

Cannot Identify Exactly What Will Be Delivered at the End of the Project

The Linear and Incremental thinkers have a real problem with not knowing what will be delivered. In the early days of Agile projects, I vividly remember prospective clients saying, “You mean I am going to give you $500,000 and six months, and you can't tell me what I am going to get?”

“That's right,” I said, “but you are going to get the most business value that you and I can deliver for that money and time. You came to me with an unsolved problem that had to be solved, and we are going to do our best to solve it with the money and time you are willing to invest.”

When to Use an Adaptive PMLC Model

The less you know about the solution the more likely it is that an Adaptive PMLC model will be needed. While the Iterative PMLC models appear to be the same as the Adaptive PMLC model (compare Figure 12-8 to Figure 12-15), looks are very deceiving. At this time APF is the only Adaptive PMLC model that satisfies the conditions of this category.

Adaptive Project Framework

APF presents an entirely different way of managing critical mission projects with poorly defined solutions. The major distinction is that APF is an active model for searching out solutions whereas all other Agile PMLC models are basically passive. For them solution discovery emerges rather than being designed into actual initiatives. APF searches out the missing parts of the solution using probative swim lanes that run concurrently with integrative swim lanes. The probative swim lanes can be of several types. Probative swim lanes are unique to APF. These are discussed later in this section.

APF is relatively new. It was first introduced in 2001. It is an industrial-strength model designed especially for managing complex projects. APF has two parts: Project setup followed by project execution. The major focus of project setup is requirements elicitation and the choice and adaptation of the best-fit PMLC model. Project execution is a five-phase approach designed to discover and deploy a solution that delivers maximum business value to the sponsor and client. Figure 12-16 (given later in this chapter) provides the details of these two parts. Before that is presented, some preparatory discussion is needed. I want to plant some early ideas and concepts so that you will see and understand the relevance of later discussion. As I develop the concepts and practices of APF, I would ask that you keep an open mind. Don't saddle yourself with old practices and worn out tenets. APF can open a whole new world of possibilities for you.

APF is robust. Simply put, it is an umbrella that encompasses all known PMLC models as special cases. By following the framework, you can choose the best-fit PMLC and adapt it to specific project characteristics and the internal and external environment.

APF is dynamic. As projects are executed they change. The project environment also changes. These changes call into question the need to revisit the best-fit PMLC model. What made sense at the outset may no longer be the best business decision.

The APF Project Team

The APF project team comprises a client team and a development team. For some APF projects the client team may be a single individual with decision-making authority. For larger APF projects the client team may have several members in order to cover the business processes or functions involved. Client team membership may change over the life of the project. The client team should have a single member in charge with decision-making authority. This person will serve as co-project manager for the entire project. The development team comprises the technical professionals who are responsible for producing the deliverables. Development team membership will most likely change over the life of the project although there is usually a core development team that stays with the entire project. The development team will have a single individual in charge with decision making authority. This person serves as co-project manager along with the client team manager.

These co-managers share equally in the success or failure of the project and both must have decision-making authority with respect to this project. Your APF project would be seriously handicapped if the client co-manager had to get approval from their management all through the project. This project manager model is unique to APF and is a critical success factor for such projects. The most important characteristic of this management model is that both parties are equally vested and responsible for the project. I have used this structure for over 20 years and it works! In my experience many of the implementation challenges do not arise in this joint-ownership model.

The APF project team can be a very special team. In the complex project landscape its members are senior level professionals who can work without supervision. The project they are undertaking is complex and filled with a great deal of uncertainty and so they must be creative people as well if they are to find an acceptable solution. Creative people are generally very independent and therefore not good team players. This will present management challenges to the co-project managers. Along with their creativity comes the need to be independent and unfettered by organizational constraints and rigid processes.

I'll refer to development team or client team when that specificity is required. When I use the term project team I am referring to the single team formed by the client team and the development team.

APF Roots

APF had its beginnings in two client engagements that were running concurrently and by coincidence had much in common. The first engagement was with a retailer who wanted to install kiosks in their stores. The kiosks would give the latest information on product specials, give store location information for their products, and provide other customer services. The second was a software development company that designed and built Internet and intranet applications for their clients. Their business model was defined using a fixed bid, and they were losing money in the complex project landscape. They needed a new business model.

Even though these two projects were quite different they did have one characteristic in common. Both knew the final goal but neither one knew the solution in detail. The question for both projects was this: How do you proceed with managing such projects when neither a complete Requirements Breakdown Structure (RBS) nor a complete Work Breakdown Structure (WBS) could be established as the basis for the project plan? Both organizations followed more or less the traditional linear approach to project management. Both could see that that approach wasn't going to do the job. But what would do the job? Something different was needed. That was the impetus for the development of APF concurrent with the projects themselves. Both projects completed successfully and APF became a reality. Since then APF has been used successfully in a number of different organizations. I am aware of its use in developing new financial products for a large insurance company, designing and building computer-based commercials and short subjects, new product R & D for a consumer products company, drug research, and others.

I still consider APF a work in process and will expand and embellish it through my own consulting engagements as well as the experiences shared by others. All of my learning and discovery about APF has found its way into the literature in my book Adaptive Project Framework: Managing Complexity in the Face of Uncertainty (Addison-Wesley, 2010). In a sense the development of APF is an APF project!

Scope Is Variable

In the complex project world where solutions are often not known at the outset of the project, sponsors will make an investment (usually money, but other resources as well, such as human or facilities) and a deadline for deliverables. Solutions are defined in terms of high-level requirements and the business value that is expected. Requirements specify “the what” of the project not the “how.” The how may be discovered through project iterations. Some requirements and their accompanying business value may be achieved, some only partially and some not at all. So within the time and budget constraints, the project manager in collaboration with their client works to deliver the maximum business value. What they finally deliver is unknown, and that means scope is variable.

This is a reality of the complex project landscape and requires a change of mind-set for sponsors and other senior managers. Knee jerk reactions take the form of “You want me to give you $5M and 6 months and you can't tell me what I am going to get?” The best answer takes the form of “With the collaboration of the client we are going to deliver the maximum business value we can for the time and resources you are willing to invest.”

APF Just-in-Time Planning

Because scope is variable, APF project planning takes on a whole new meaning. The basic concept underlying an APF project is not to plan the future. The future is unknown—leave it that way. Part of the solution lives in the future and is waiting to be discovered. As it is discovered, it will be integrated into the solution. APF planning does not forecast the future and then plan for it. APF is not a passive model. It does try to discover the future through what I will call “probative initiatives” but more on that later. Trying to forecast the future is a waste of time and simply adds to the non-value-added work already present in the project. Initial planning is done at a high level and is functionally based. TPM planning is activity and task-based. In APF, planning at the micro-level is done within each cycle. It begins with a mid-level component or function-based RBS and ends with a micro-level activity and task-based WBS. I like to think of it as just-in-time planning. A key phrase to keep in mind when applying APF is “when in doubt, leave it out!” meaning that you include within each cycle only the detailed planning of those activities that clearly will be part of the final solution—that is, in each cycle include in your detailed plan only what you know to be factual. So, planning is done in just-in-time segments where a cycle includes work that will require only a few weeks to complete. A cycle is so short that it typically will not meet the duration requirements to be called a project. So while a cycle will use many of the tools, templates, and processes of a more traditional approach, it is a unique artifact of an APF project.

Change Is Expected

Unlike in the Linear and Incremental PMLC models where you treat scope as fixed and hope to avoid change, the Agile and Extreme PMLC models require change in order for the project to be successful. In these two model types change is what leads to the discovery and learning of missing features and functions (Adaptive PMLC models) or clearer focus on the goal (Extreme PMLC models). Two useful metrics to track from cycle to cycle are the number of additions to the Scope Bank at each cycle and the number of additions that result in further defining the solution at each cycle. These metrics are discussed later in this section.

Change in a complex project is encouraged through frequent release of product or process in order to solicit input for further change. Without that input a complex project is likely to fail. The meaningful involvement and collaboration of the client team is critical to that change process.

The APF Project Contract

This is perhaps the most difficult part of an APF project to justify to managers whose mind-set is in the TPM world. Simply put an APF contract says that with meaningful client involvement the contract will deliver the most business value within the limits of client-specified time and cost constraints. Or stated another way, the client doesn't know exactly what will be delivered at the end of the project but only that it will be the most business value possible and that they will have played a critical role in that determination. For the time and money invested the client will get as much of the solution as they possibly can with the knowledge they and the development team has of the situation. What this all boils down to is the need for trust and openness between the client team and the development team as well as between the co-project managers.

Remember that the APF project must be done. You can't wait until somebody figures out what the requirements are. That will never happen. You must proceed with the project based on incomplete information. Your expectation is that the approach you have chosen will bring the missing functions and features into focus and the project can deliver acceptable business value.

An APF Project Is Mission Critical

Given the preceding it is unlikely that an APF project is anything but critical to the enterprise. The situation is this:

• No complete solution is known
• The risk of finding a complete solution is high
• The success of the project is critical
• None of the familiar Linear and Incremental PMLC models will work
• APF is the only model that offers any hope of finding an acceptable solution or partial solution

So while APF may not be the silver bullet you are hoping to find, it is your only alternative. An APF approach will deliver as much business value as is possible. Through a collaborative effort of the client team and the development team, the best solution humanly possible will emerge. It may not be the perfect solution, but it is the best that could be done. The expectation is that with actual experience using the solution, a second and succeeding versions can be justified.

The Role of the Client and the Project Manager in an APF Project

In the absence of meaningful client involvement it would be foolish to use an APF approach. In fact, without meaningful client involvement, it would be risky to undertake any project regardless of the model being used. Every PMLC requires some level of client involvement. For an APF project, however, there is much more to say about the role of the client co-manager and the role of the development co-project manager. It is best to think of the two as sharing the responsibilities of the project manager—they become co-project managers but with distinct responsibilities.

In an APF project the manager of the development team assumes more of an advisory role. They keep the client team pointed in feasible directions and further advise the client on the best choice from among a number of feasible alternatives. The client, however, makes the final decision among the set of alternatives. For some traditional project managers this role will be difficult to accept. Rather than being in charge they are going to have to share responsibility for leadership and decision making. For some clients, too, this role will be difficult to accept. Rather than deferring to the project manager they are going to have to be meaningfully involved and make decisions. Project success or failure is shared between the client team manager and the development team manager.

From the client side the role is different than the project manager would be accustomed to. The first difference is that the traditional project manager has to quickly get used to the fact that they are no longer in charge of the project—at least not by themselves. They now share that responsibility with the client. There is no finger pointing except at themselves. Different isn't it? This client side accountability is one of the strengths of APF. Both project manager and client have a vested interest in the success of the project. What otherwise might have been an obstacle to implementation success fades into oblivion.

The second difference is that the client has to be willing to step forward and clearly and openly state their opinions. Their relationship with the project manager and the team must be open. They must feel like an equal with the team. They can no longer hide behind the excuse that this is a technology project and they don't understand technology. This is a business project and they have as much say and as much authority as does anyone else on the project team. A great synergy can be created between two parties with totally different perspectives on the same project. Find a way to leverage that power to the advantage of your organization.

APF Is Not a Recipe to be Blindly Followed

I am not in the recipe business. You won't find endless lists of things to do in an APF project. That would be a waste of time and the APFist doesn't waste time. As you read and study the pages that follow, expect to learn how you, an APF co-project manager, need to start thinking about what you are doing and how you are working together with your co-manager. If something either of you are doing doesn't make sense, it probably doesn't and should be changed or not done at all. As an APF co-project manager you will know how to recognize these situations and invoke the proper change. For some traditional project managers this continues to be a difficult adjustment. They would rather not have to think about what to do but merely follow a recipe. I want you to start thinking about creating a recipe from the ingredients you have at your disposal. That way you will be able to take charge of the project rather than being victimized by it.

If you need a recipe to manage your project, APF is not for you. The effective APF co-project manager is a senior level manager who not only has command over an extensive collection of tools, templates, and processes but more importantly knows when to use them, how to use them and how to adapt them—this type of co-project manager is the chef I talked about earlier!

Why Do We Need APF?

APF offers a unique approach to a category of projects that other approaches and models do not. APF was designed for non-software development projects and has been used successfully on process and product design and improvement projects and a variety of R & D projects as well. These are critical mission projects whose solutions are not completely known and can only be known by doing the project. These are projects for which TPM approaches will not work. They are projects that must be done and some way of doing them effectively must be devised. You have no choice! That need gave rise to APF. APF is not the only agile project management methodology. But APF is unique in that it was designed for any type of project not just software development projects as all of the other agile methodologies are restricted to. The use of co-project managers and probative swim lanes are two of the unique artifacts of an APF effort and set APF apart from all other Agile PMLC models.

Benefits of APF vs. Other Approaches

APF brings a lot of business value to the table as compared to other approaches as is discussed in the following sections.

APF Projects Always Finish Sooner Than TPM Projects

If it were possible to do the same project twice—once using a TPM Linear PMLC model and once using APF—the APF project would finish sooner every time. The reason for this is obvious. Because APF squeezes out all non-value-added work (Yes, it is a lean framework!), it has less to do than those projects that follow more traditional approaches. The time spent planning is a good example. Linear and Incremental PMLC models plan the entire project, and then when change comes along and is approved, the plan has to be redone from the point of the change to the end of the project. That is repeated several times throughout the project. That means much of the original planning work turns out to be non-value-added work. The more change that is approved the more non-value-added work there will have been. APF has none of this excess baggage and is therefore guaranteed to finish sooner than traditional approaches.

APF Projects Are Less Expensive Than TPM Projects

Non-value-added work costs money. There is at least a labor cost for the time spent planning activities and tasks that are never done due to frequent scope changes. This wastes money in the end.

APF Projects Have a Better Business Termination Policy Than TPM Projects

Most distressed or failing TPM projects are terminated too late because by the time it is discovered that the project isn't producing the desired results and should be terminated the available budget and time are nearly expended. That happens because the first deliverables come very late in the project life cycle. Most of the money and time have already been spent. Not so with APF. APF delivers early and often. If anything is going awry, it will be discovered earlier than in a TPM project. The APF project will terminate before any additional time or money will be spent needlessly. That doesn't mean the project won't be done. It means that the project won't be done in the way it was originally planned. Some other approach using APF is needed, and the time and money saved by this early termination will be invested in the search for a solution in a different direction.

The APF Project Produces Higher Quality Deliverables Than the TPM Project

The elevated level of client involvement in an APF project means that the client will have a look at intermediate deliverables early in the project and have an opportunity to adjust them. The quality of the final product will therefore exceed that of a TPM project.

TPM projects all suffer from the effects of scope change. The initial design will be compromised due to the changes. The more frequent the changes the more the design is compromised. The final TPM solution, if there even is a final solution, will be a patchwork solution.

The APF Project Delivers Maximum Business Value for the Time and Cost Invested

The continual adjustment and redirection of an APF project means that everything that is delivered is needed and is of the quality expected by the client. The client in collaboration with you decides what goes into the solution at every iteration. Poor or less than expected deliverables will not survive the APF project life cycle. If an APF project is terminated, at least you will have a partial solution with some business value.

Core Values of APF

As you can see, APF is more than just a framework. It represents a way of thinking about clients and how best to serve them. The client is the center of attention in an APF project. They control the direction of the project and determine where business value can be created or increased. The APF project continues at the client's discretion and with their approval. This way of thinking is embodied in the six core values described here. These core values are immutable. They must be practiced in every APF project. No exceptions. In time the APF teams will be recognized for the visible practice of their core values. I have had occasion to work with teams that periodically reward team members for practicing the APF core values above and beyond the call of duty. The core values are that important.

Client-Focused

While I was looking for the appropriate name for this core value, the phrase “walk in the shoes of the client” was always on my mind. It still is an operative part of truly being client-focused. This value is the most important of the core values. The needs of the client must always come first, as long as they are within the bounds of ethical business practices. This value can never be compromised, and it goes beyond simply keeping it in mind. It must be obvious through your actions with your fellow development team members and through your interactions with all of the members of the client team.

A client-focused attitude will be a radical behavioral change to those few project managers who are clinging to old practices. I have some clients who provide templates for their clients to use to submit a description of what they want and of what business value it will be. I've seen questions such as: What other systems will the requested system impact? How they expect the client to answer that question is beyond me. Some can, but I suspect most cannot. Others will make the process a little less painful by assisting the client with filling out the document. Better, but not the best. That approach still assumes that the client can in fact state what they want (or to be more precise what they need). Few clients will be able to do that because of the complexity and uncertainty that pervades today's projects. The simple projects have all been done many times. Best would be to engage the client in discussions about their needs and from that forge a strategy for going forward.

Don't think that I am advocating passive acceptance of whatever the client might request. To do so would border on dereliction of duty. Client-focused means going way beyond doing what they have asked of you. It also means that you are protecting their best interests. In a spirit of openness, you are obligated to challenge ideas, wishes, and wants whenever you believe such challenge is called for. Your goal is to maximize business value to the client even if you have to push back on their requests. You have to own the solution just as much as the client has to own the solution. To do otherwise is not part of being client-focused. You want to do the right things for the right reasons and to always act with honesty and integrity.

Client-Driven

One of the guiding principles of my business has always been to engage the client in every way that I could. I want them not only to be meaningfully involved but to also have the sense that they are determining the direction that the project is taking. At the extreme, this value would mean having the client take on the role and responsibilities of the project manager. I've been in such situations only a few times in the last 20 years of consulting and practicing project management. It is an awesome experience! It does require a complete change of mind-set from one that is directive to one that is supportive. Such an extreme will not happen very often, but there are occasions when this will occur. As middle ground an effective arrangement I insist on with my clients is to have co-project managers—one from the client side and one from my organization. I have insisted on this for my entire career in project management. In this arrangement, both individuals share equally in the success or failure of the project. There is a clear and established co-ownership. My own practice with my clients tells me that this is a key to successful implementation. The client will have a vested interest in the success of the project and will do whatever is necessary to assure success. Their reputation and credibility is on the line just as mine is on the line. I say that this is a key critical success factor for a successful APF Project.

For many clients in organizations early in their history of APF adoption there is a learning curve that you will have to pay attention to. The first APF project you undertake with a client should be prefaced with a workshop to help them not only understand what APF is and why APF is being used but more importantly how they can be a good client in an APF project. For the second and later projects with this client you can expect more from them. Eventually you may even move them to the position of being the project manager with you acting as advisor, coach, and mentor. Being the product owner in a Scrum project would be the final step in the growth and development of the client as a contributing member of an agile project team.

Incremental Results Early and Often

In the spirit of prototyping, in an APF project you want to deliver a working solution to the client as early and often as possible. This early delivery is especially valuable when there is any question that the real needs of the client have not yet surfaced despite your best efforts. The functionality of the first cycles of the project may be very limited but useful in any case. In some cases, the first iteration might be a proof of concept. It should deliver business value even though it is of very limited functionality. It gives the client an early feel for the final deliverables. Giving the client an opportunity to work with something concrete is always better than asking them to react to some vague concept or sketch on the back of a napkin or buried in a lengthy functional specification.

Early and often helps get the client meaningfully engaged and keeps them engaged throughout the project. It creates an ownership on the part of the client. This is critically important to the success of the project. Without the client's meaningful participation an APF project is doomed to failure. They must understand this, and you must facilitate it. If you can't get that involvement, use some other approach. APF is not the way to go.

Continuous Questioning and Introspection

This core value speaks to an openness and honesty that must exist between the client team and the development team. Both parties must be committed to making the best business decisions possible. That can only happen with honest and open dialog. Personalities have to be put aside if this environment is to be realized.

Building a solution iteratively affords the opportunity to be creative. It creates the opportunity to adjust as better and more valuable features or functions are discovered. As the cycle build proceeds, both the client team and the development team should always be looking for improvements in the solution or the functionality and features being offered. Look back at previous cycles and ask whether what was done was the best that could have been done. All of this learning and discovery will be captured in the Scope Bank (See Chapter 6) and come together in the Client Checkpoint Phase (discussed in the “APF Project Execution” section later in this chapter). Here is where the client and your project team propose, discuss, and approve further solution development efforts.

A true spirit of openness must exist. Neither party should be afraid to offer or challenge an idea or the real value of some present or future deliverable. I've frequently told teams that if anyone of their members had an idea and didn't share it with the rest of the team I would consider that dereliction of duty. Some think that coveting knowledge is a source of power. In the APF project that is the kiss of death! The same is true for the client. The successful practice of this core value is heavily dependent on the existence of a true team environment.

Change Is Progress to a Better Solution

One of my colleagues, is often heard saying, “You're always smarter tomorrow than you are today.” He is referring to improving task duration estimates over time, but his comment applies to APF as well. The Version Scope Phase begins with the requestor and provider coming to a definition of what is needed and what will be delivered through the Conditions of Satisfaction (COS) experience (see Chapter 4). Despite their best efforts, all the two parties have done to this point is take the best guess they can as to what will be done. That guess may turn out to be a very good guess or only a partial guess, but that is not important. What is important is that by working with the deliverables from the earlier cycles both parties will get a better picture of what can still be delivered. They will be smarter as a result of their experiences with the deliverables from the earlier cycles. The result is to improve the solution going forward into the future cycles.

While change is needed to reach the best solution, too much change sends a very different message. One of the metrics I advise my clients to use is to track the frequency of change requests over time. The expectation is that the solution is converging on the final solution. This is evidenced first by an increasing number of change requests from cycle to cycle and then a decreasing number of change requests later in the project. If this is not happening, there is a likelihood that the project is not converging on an acceptable solution but rather is diverging.

Don't Speculate on the Future

There will always be the temptation to envision the future. I have seen that thinking invade client team and development teams but not for good reasons. It is often seen as inevitable and invades the WBS and other aspects of project management. An APF team must resist that temptation. APF strips out all non-value-added work. Guessing the future only adds non-value-added work back in. So, when in doubt, leave it out. APF is designed to spend the sponsor's time and money on producing business value rather than on non-value-added work.

If you find yourself building the RBS or the WBS and you or the client is guessing at what should be included, you are probably using the wrong approach. The high-level RBS is the best input for deciding on the best-fit PMLC model.

An Overview of the APF Life Cycle

The stage is now set for our first look at APF. Figure 12-16 is a graphic portrayal of the Project Setup and Project Execution parts of APF. First, note that APF, like all Agile PMLC models, is an iterative process. You iterate within a cycle and between cycles. Every cycle presents the development team and the client team with a learning and discovery opportunity. APF is crafted to take advantage of these opportunities. As you continue to study each phase, you will come to realize that defining the cycle content for learning and discovery is its real strength. It sets APF apart from all the other PMLC models.

Figure 12-16 APF life cycle

APF Project Setup

Project Setup is unique to APF. It is based on the assumption that the uniqueness of the project drives the uniqueness of the project management model. As shown in Figure 12-16 it consists of the following:

• Conduct Conditions of Satisfaction (See Chapter 4.)
• Elicit requirements (See Chapter 4.)
• Assess completeness of requirements (See Chapter 4.)
• Classify project in the landscape (See Chapters 1 and 2.)
• Determine the best-fit PMLC model (See this chapter.)
• Assess project characteristics (See Chapter 1.)
• Choose and modify specific PMLC approach

The defining factors here will be:

• The conditions needed to support the chosen PMLC model are not present—Training, training, and more training will usually resolve this obstacle. If the client is the problem, I have conducted training in parallel with Project Execution and workshops aligned to every phase. If the team is the problem, the short-term solution is probably to outsource those areas where the needed skills and competencies are lacking.
• The internal environment does not support the needs of the chosen PMLC model—This can be a showstopper for a complex project. The sponsor, client, and other senior managers need to be aware of the potential risks and your recommendation for mitigating these risks.
• The external environment is volatile—Shorter duration projects and shorter duration increments, iterations, and cycles are the best protection against the effects of market changes.

APF Project Execution

Now that the best-fit PMLC has been chosen and adapted to the project characteristics and the internal/external environments, it is time to execute the project. Project Execution is a robust process that includes all PMLC models and any adaptations that have been made as special cases. But that execution is not a static effort. Note the feedback loop from the Checkpoint in Project Execution to the Assess Completeness of Requirements in Project Setup. Included in the Checkpoint is a review of the current solution with respect to current requirements and that can lead to a change in the best-fit PMLC model.

Version Scope

An APF project begins with a stated business problem or opportunity. This beginning is the same as a TPM project. A request has been made to develop a solution to the stated problem or business opportunity. At this point, you are not at all sure what kind of project this might be or how you might approach it from a methodology perspective. A Conditions of Satisfaction (COS) conversation takes place between the requestor and the provider to define more clearly exactly what is needed and what will be done to meet that need. A Requirements Gathering session may be held and an RBS constructed. The RBS is the input to the decision as to which project management category the project belongs in: TPM, APM, xPM, or MPx. Once the category is chosen the project characteristics are used to decide which model is a best fit. For the sake of this section, you discover or suspect that the RBS is not complete, and the missing functions and features suggests an APM approach is to be taken. You have chosen APF, so a project scoping document, specifically, a POS, is written. A POS basically summarizes the COS and RBS, if either is available. The POS is a brief (usually one page, with perhaps an attachment) document that contains the following five sections:

• A statement of the problem or opportunity (reason for doing the project)
• A goal statement (what will generally be done)
• A statement of the objectives (general statements of how it might be done)
• The quantifiable business outcomes (what business value will be obtained)
• General comments on risks, assumptions, and obstacles to success

The second deliverable from this phase is a prioritized list of the functionality that has been requested and agreed to in the COS. The RBS contains this information. Both parties recognize that this list may change, but at this point in the project, the list reflects the best information available; however, it is probably incomplete. There may be additions, deletions, and changes as the project commences.

The third deliverable from this phase is the mid-level WBS. Since the RBS is incomplete, the WBS will also be incomplete. If an RBS exists, it may be used as the starting point for defining the WBS. The RBS will specify what is to be done, and the WBS will further decompose the RBS to define how it will be done. For purposes here, a mid-level WBS is one that shows the goal at level 0, major functions at level 1, and sub-functions at level 2. Generally, such a WBS would have a two- or three-level decomposition. The number of levels is not important. What is important is to have at least one level of decomposition to the work level for as many functions and features that have been identified. At this point any more WBS detail is not considered useful. The reason for that will become clear in the Cycle Plan phase.

The traditionalist would have a problem with this because the entire foundation of traditional project planning and scheduling is based on having a complete WBS. I contend that the time spent trying to create a complete WBS at this stage is largely a waste of time. Again, I remind you, why plan for the future when you don't know what it is? In this case, the piece that is missing is that you are not exactly sure how you are going to deliver the functionality. You do know what functionality has to be delivered, and you are using that information to generate the mid-level WBS but not the complete WBS. The complete WBS will eventually be generated when we know enough to generate it. That will happen within repeated iterations of Cycle Plan–Cycle Build–Client Checkpoint phases. You will generate it when you need it and not before, and when you do generate it, you will know that it is correct and not a guess.

The fourth deliverable from this phase is a prioritization of the variables that define the scope triangle (time, cost, resource availability, scope, and quality). This prioritization will be used later as an aid to decision making and problem solving during the Cycle Build phase.

Cycle Plan

The POS has been written and is presented along with a prioritized list of known functionalities that the client and the project manager believe are needed to take advantage of the business opportunity or solve the business problem. Some high-level planning is done very quickly to prioritize the functionalities into a number of timeboxed cycles for development. Typical cycle length is 2 to 6 weeks. This cycle length is documented and agreed to by both parties—along with the expectation that it will change as project work commences.

The Cycle Plan Phase will be repeated a number of times before this project is complete. The first Cycle Plan Phase has as input the POS, the prioritized scope triangle, the functionality that will be built in this cycle, and the mid-level WBS. Subsequent Cycle Plan Phases will also have a Scope Bank as input.

So far we have been discussing specific cycle contents that relate to adding detail to the evolving solution. There is another aspect of the cycle contents that is equally important. Think of a cycle as containing two major swim lanes. These are streams of build activities that occur in parallel. One swim lane is devoted to adding more detail to the evolving solution. These are called integrative swim lanes. The other swim lane is devoted to discovering aspects of the solution heretofore unknown. These are what I call probative swim lanes. There may be several occurrences of each type of swim lane in a single Cycle Build Phase. They might be the search for an answer to a question like: I wonder if this is the way to solve that part of the problem? Or, I wonder if this would work?

In the probative swim lanes you are calling on the problem-solving and creative skills of the client team and development team. In the integrative swim lanes you are calling on the implementation and process skills of the client team and the development team. Different skill sets are needed for each type of swim lane. The challenge is to build a team that has both sets of skills.

I don't dismiss this as being an easy exercise. It definitely isn't. Most of the difficulty stems from either the client team or the development team not approaching reprioritization with an open mind. People tend to get wedded to their earlier ideas and are hard-pressed to give them up in favor of others. To be successful with APF both the development team and the client team must have an open mind and not display pride of authorship on any previous functionality that was discussed.

One of the greatest benefits from this approach is the meaningful and continuous involvement of the client. They are the decision makers in all activities going forward. They are doing it with full knowledge of what has taken place to date and with the collaborative support of the development team. They understand how business value can be achieved by changes in functionality, and they are in a position to take action. Their presence will be a constant reminder to the development team of the business aspects and value of what they are doing and what changes should be made to protect that business value. This client involvement is a very important point to remember. It ensures that what is eventually built will meet client needs.

Cycle Build

Contrary to what you might think, the creation of the cycle build plan is a low-tech operation. While you could certainly use project management software tools, I have found that a whiteboard, sticky notes, and marking pens are just as effective. It does keep the maintenance of a project file down considerably and allows the team to focus on value-added work. This advice may sound heretical to those of you who are project management software aficionados, so let me explain. Cycle length generally falls within a 2- to 6-week time frame. There will likely be several small teams (a typical small team will be one designer and one or two developers), each working in parallel but independently on a separate piece of functionality. Each of these small teams will plan the cycle build in this phase and then conduct the cycle build in the next phase. Based on this description, a minimal planning effort is all that makes sense.

The cycle planning effort might go something like this:

There is no critical path to calculate and manage. The longest duration swim lane is the critical path. Pay attention to it! The cycle is so short that too much planning and analysis leads to paralysis and, worst of all, non-value-added work. Take the low-tech approach it will work just fine here. You don't need to clutter the cycle with non-value-added work. The entire effort can be whiteboard-, sticky note-, and marker pen-based. A dedicated war room would be helpful (about 300 square feet of floor space should be adequate). The team can post their plans, work schedules, Scope Bank, Issues Log, and so on, and have their daily 15-minute updates, weekly status meetings with the client, and problem-solving sessions here.

Detailed planning for producing the functionality assigned to this cycle is conducted. The cycle work begins and is monitored throughout the cycle, and adjustments are made as necessary. The cycle ends when its time has expired. Any functionality not completed during this cycle is reconsidered and reprioritized for later consideration. The Cycle Build timebox is never changed once the Cycle Build Phase begins.

The first activity in the Cycle Build Phase is to finish the cycle build schedule and resource allocation. With everything in place and understood by the team, work begins. Every team member has a daily task list and posts task statuses at the completion of every day. Any variances are caught early, and corrective action plans put in place. Nothing escapes the attention of the co-project managers for more than one working day. A Scope Bank is created to record all change requests and ideas for functional improvements. An Issues Log records all problems and tracks the status of their resolution.

Client Checkpoint

Without a doubt this is the most important phase of APF. In this phase the client team and the development team come together and assess what has been accomplished, what has been discovered and learned from the just completed cycle, and what should be done in the cycle to come. The client team and the development team jointly perform a quality review of the features and functionality produced in the just completed cycle. It is compared against the requirements and its part in the solution and the overall goal of maximum business value. Adjustments are made to the high-level plan and next cycle work as appropriate. The sequence Cycle Plan–Cycle Build–Client Checkpoint is repeated until the time and cost budgets for this version have been expended, or the project should be terminated because it is not converging on an acceptable solution, or an acceptable solution has been reached for this version and no further work is needed.

The Client Checkpoint Phase is a critical review that takes place after every Cycle Build Phase is completed. During the Cycle Build Phase, both the client team and the development team will benefit from several discovery and learning episodes. Variations to the version functionality will surface; alternative approaches to delivering certain functionality will be suggested, and both teams will learn through their continuous involvement with the other team. There is a definite synergy that will develop between the two teams. All of this must be considered along with the functionality that had originally been assigned to the next cycle. The result is a revised prioritization of functionality for the next cycle. The most important thing to remember is not to speculate on the future. For the next cycle, prioritize only the functionality that you are certain will be in the final solution. That newly prioritized list will be input to deciding on the integrative swim lanes for the coming cycle. The learning and discovery from the just completed Cycle Build Phase will be input to deciding on the probative swim lanes for the coming cycle. The available resources and the resource requirements of the prioritized integrative and probative swim lanes will dictate the contents of the coming cycle.

Version Close

During the Version Scope Phase, you developed measurable business outcomes in discussions with the client. These became the rationale for why the project was undertaken in the first place. Think of these outcomes as success criteria. That is, the undertaking will have been considered a success if, and only if, these outcomes are achieved. In many cases, these outcomes cannot be measured for some time after the project has been completed. Take the case of the project impacting market share. It won't happen next Tuesday. It may happen several quarters later, but the time frame is part of the success criteria statement as well.

When the budget and time allotted to this version have been spent, that marks the end of the project. Some functionality that was planned to be completed may not have been completed. It will be archived in the Scope Bank for consideration in the next version. The main focus of the Post-Version Review is to check how you did with respect to the success criteria, to document what you learned that will be useful in the next version, and to begin thinking about the functionality for the next version.

What the client team and the development team believe to be the best mix of functionality has been built into the solution. The project is done. The deliverables are installed, and the solution is in production status. At this stage, three questions need to be answered:

The business outcome was the factor used to validate the reason for doing the project in the first place. If it was achieved, chalk that one up on the success side of the ledger. If it wasn't, determine why not. Can something further be done to achieve the outcome? If so, that will be input to the functional specifications for the next version. If not, kill the project right now. No need to send good money after bad money.

There is also a lesson here for everyone. If projects are limited in scope and they fail and there is no way to rescue them, you have reduced the dollars lost to failed projects. The alternative to undertaking larger projects is that you risk losing more money. If there is a way of finding out early that a project isn't going to deliver as promised, cut your losses. The same logic works from cycle to cycle. If you can learn early that a version will not work, kill the version and save the time and cost of the later cycles. TPM would find out a project wasn't working only after all the money was spent, and then a great deal of trouble might be involved in killing the project. The traditional thought goes, “After all, there is so much money tied up in this project, we can't just kill it. Let's try to save it.” How costly and unnecessary.

Extreme PMLC Model

While Agile PMLC models apply to projects whose solutions are not completely known, Extreme PMLC models apply to projects whose goals and solutions are not completely known. Oftentimes the goal of an Extreme project is nothing more than a desired end state. It might be achievable, but it may not be achievable as currently stated. Since there is no known solution at the outset, the achievability of the goal is not known. In an Agile project the solution converges through learning and discovery during iterations. In an Extreme project both the goal and the solution converge to a final goal and solution. That may or may not achieve the desired end state or expected business value. Obviously an Extreme project is much higher risk than an Agile project. Figure 12-17 illustrates the Extreme PMLC model.

Figure 12-17 Extreme PMLC model

Characteristics

The best way to define an Extreme project is to consider its characteristics, which are discussed in the following sections. These characteristics will strike fear into the hearts of most, if not all, project managers. Make no mistake, Extreme projects are extremely challenging. Many will be canceled before they are completed. For those that are run to completion, what they deliver may not at all reflect what you thought they would deliver. And then there is the question of the business value delivered. You may have found a $10,000 solution to a $1,000 problem. In other words, the actual goal achieved may be quite different from the goal that was originally envisioned. That is the nature of Extreme projects, and that is where I begin the investigation of how xPM applies to them.

High Speed

The types of projects that are suited to xPM are groundbreaking, innovative, critical to an organization's future, and otherwise very important to their sponsors. That means that the results are wanted ASAP. Fast is good, and if your project can keep up this pace, you will be around tomorrow to talk about it. Slow is bad, and if that's the pace of your project, you will be looking for something else to do with the rest of your life. Getting to market faster is a critical success factor in every Extreme project business endeavor.

High Change

The uncertainty about the goal or the solution means that as the project is under way, learning and discovery will occur, just as in APF projects. However, this happens with more regularity and frequency in xPM than in APF projects. The APF changes can be thought of as minor in comparison. The changes in an Extreme project may completely reverse the direction of the project. In some cases, the changes might mean canceling the current project and starting two or more projects based on the prior learning and discovery. For example, R & D projects are Extreme projects, and a discovery in one cycle through the five phases may cause the team and the client to move in a totally different direction in the next and later cycles.

High Uncertainty

Because an Extreme project is innovative and research-oriented, no one really knows what lies ahead. The direction chosen by the client and the project team might be 180 degrees out of phase with what they should be doing, but no one knows that at the beginning of the project. Furthermore, the time to complete the Extreme project is not known. The cost to complete an Extreme project is not known either. In short, there will be a lot of trial and error and a lot of false starts and killed projects.

Strengths

The strengths of the Extreme PMLC model are as follows:

• Keeps options open as late as possible
• Offers an early look at a number of partial solutions

Keeps Options Open as Late as Possible

You don't want to miss any chances of finding a solution amidst all of the options you are investigating. Any idea that generates a probative swim lane must be pursued until there is no possibility that it can contribute to the solution. In planning an Extreme project, the project team will brainstorm possible solutions or solution components and prioritize the options. Starting at the top of the list, the team will launch Probative Swim Lanes in a further search. To eliminate a possible solution at this point means it will be replaced by an option of lesser priority. You don't want to do that unless you are absolutely sure the possible solution is, in fact, not feasible.

Offers an Early Look at a Number of Partial Solutions

All of the options that were prioritized are being considered. One of them might spark an idea for several others not on the priority list. Remember that you are on a search for a solution that up until now has been elusive. If the solution were that simple, it would have already been discovered.

Weaknesses

The weaknesses of the Extreme PMLC model are as follows:

• May be looking for solutions in all the wrong places
• No guarantee that any acceptable business value will result from the project deliverables

May Be Looking for Solutions in All the Wrong Places

The early phases are critical. If you can legitimately eliminate all of the prioritized options, then you should kill the project and start over in another direction.

No Guarantee That Any Acceptable Business Value Will Result from the Project Deliverables

Even if you find a solution and clarify the goal that the solution satisfies, the project may still fail. The solution may satisfy a goal that doesn't have sufficient business value, or the solution may be too costly for the goal it satisfies.

Specific Extreme PMLC Models

There are only two models that I am aware of. I offer my own model called INSPIRE. The other model is one developed by my colleague Doug DeCarlo in eXtreme Project Management: Using Leadership, Principles, and Tools to Deliver Value in the Face of Volatility (Jossey-Bass, 2004).

INSPIRE Extreme PMLC Model

By its very nature, an xPM project is unstructured (see Figure 12-18). xPM and Agile Project Management (APM) projects are both variations of the same theme: the learning and discovery of the solution during successive iteration, cycles, or phases moves the project forward. The INSPIRE Extreme PMLC model is an idea that I adapted from the Flexible Project model introduced in 2000 by Doug DeCarlo in his eXtreme Project Management Workshop. As Figure 12-18 illustrates, INSPIRE consists of four stages, which I am calling INitiate, SPeculate, Incubate, and REview (hence, the acronym INSPIRE).

Figure 12-18 The INSPIRE Extreme PMLC model

INSPIRE is an iterative approach, just as all of the Adaptive PMLC models are iterative. INSPIRE iterates in an unspecified number of short phases (one- to four-week phases are typical) in search of the solution to some goal. It may find an acceptable solution, or it may be canceled before any solution is reached. It is distinguished from APM models in that the goal is unknown, or at best, someone has a vague, but unspecified, notion of what the goal consists of. Such a client might say, “I'll know it when I see it.” That isn't a new revelation to the experienced project manager—they have heard that many times before. Nevertheless, it is the project manager's job to find the solution (with the client's help, of course).

APM models are further distinguished from INSPIRE in that INSPIRE requires the client to be more involved within and between phases, whereas the APM models require client involvement between cycles. Drug research provides a good example of the Extreme project. Suppose, for example, that the goal is to find a cure for the common cold. This is a wide-open project. Constraining the project to a fixed budget or fixed time line makes no sense whatsoever. More than likely, the project team will begin by choosing some investigative direction or directions and hope that intermediate findings and results will accomplish the following two things:

• The just-finished phase will point to a more informed and productive direction for the next and future phases. In other words, INSPIRE includes learning and discovery experiences just as the Agile models do.
• Most important of all, the funding agent will see this learning and discovery as potentially rewarding and decide to continue the funding support.

There is no constrained scope triangle in INSPIRE as there is in Traditional Project Management (TPM) and APM projects. Recall that TPM and APM projects have time and funding constraints that are meaningful. “Put a man on the moon and return him safely by the end of the decade” is pretty specific. It has a built-in stopping rule. When the money or the time runs out, the project is over. INSPIRE also has stopping rules, but they are very different. The two INSPIRE stopping rules are as follows:

• The first rule says that the project is over when a solution is found. If the solution supports a goal that has sufficient business value, the project is deemed a success, and the solution is implemented. If the solution does not support a goal that has sufficient business value, the project is deemed a failure, and it's back to the drawing board for another try (perhaps).
• The second rule says the project is over when the sponsor is not willing to continue the funding. The sponsor might withdraw the funding because the project is not making any meaningful progress. It is not converging on an acceptable solution and goal. In other words, the project is killed. Failure!

The next sections take a high-level look at the four components of INSPIRE.

INitiate

INitiate is a mixture of selling the idea, establishing the business value of the project, brainstorming possible approaches, forming the team, and getting everyone on board and excited about what they are about to undertake. It is definitely a time for team building and creating a strong working relationship with the client.

At this point, someone has an idea for a product or service and is proposing that a project be commissioned to investigate and produce it. Before any project will be launched, management must be convinced that it is an idea worth pursuing. The burden of proof is on the requestor. He or she must document and demonstrate that there is business value in undertaking the proposed project. The Project Overview Statement (POS), which you used in both TPM and APM projects, is the documentation I recommend to sell the idea. There are some differences, however, in the INSPIRE version of the POS.

Defining the Project Goal

Unlike the goal of an Agile project, the goal of an Extreme project is not much more than a vision of some future state. “I'll know it when I see it” is about the only statement of the project goal that could be made, given the vague nature of the goal as envisioned at this point in time. It has all the characteristics of an adventure in which the destination is only vaguely defined. You have to understand that the goal of an Extreme project unfolds along the course of the project life cycle. It is not something that you can plan to achieve—instead, it is something that you and the client discover along the way. That process of discovery is exciting. It will call upon all of the creative juices that the development team and the client team can muster. Contrast this to the project goal in an Agile project. In an Agile project, the goal is known—it's the solution that evolves as the project unfolds. In general, the client is more directive in an INSPIRE project, whereas the team is more directive in an Agile project.

At this early stage, any definition of the project goal should be a vision of the future. It would be good at this point to discuss how the user or client of the deliverables will use the product or service. Don't be too restrictive. Keep your options open (or “keep your powder dry,” as one of my colleagues would say). Forming a vision of the end state is as much a brainstorming exercise as it is anything else. Don't close out any ideas that may prove useful later.

INSPIRE Project Overview Statement

An example will help ground some of these new ideas. Suppose the project is to find a cure for the common cold. As discussed in earlier chapters of this book, the POS is a critical document in both the TPM and APM approaches. It is also critical in xPM projects. However, because the goal is known in both TPM and APM projects but is not known in xPM projects, there will be some differences in the POS. These differences are best illustrated by way of example. Figure 12-19 is the POS for the project to find a cure for the common cold.

Figure 12-19 POS for the project to find a cure for the common cold

The following brief descriptions of the INSPIRE POS elements will help you understand the differences between this type of POS and the one that's used in TPM or APM projects.

Problem or Opportunity Statement

There's nothing unusual here. This is a very simple statement of a problem that has plagued healthcare providers and moms since the dawn of civilization.

Goal Statement

This particular project is taking a calculated (or maybe wild a**) guess that they can establish a preventative barrier to the occurrence of the common cold. Unlike the goal statements in TPM and APM projects, no time frame is specified. That would make no sense for such a research project.

Objective Statements

These objective statements identify broad directions that the research effort will take. Notice that the format does not fit the S.M.A.R.T. characteristics defined in Chapter 4. In most cases, these objective statements will provide some early guidance on the directions the team intends to pursue. Unlike TPM and APM projects, these objective statements are not a necessary and sufficient set of objectives. Their successful completion does not ensure goal attainment. In fact, some of them may be discarded based on learning and discovery in early phases. Think of them as guideposts only. They set an initial direction for the project. Because the goal is not clearly defined, you can't expect the objective statements to play the role that they do in TPM and APM projects.

Success Criteria

The goal statement might do just as well as any success criteria, so this part of the POS could be left blank. In this case, you have set bounds around the characteristics of an acceptable cure. Success criteria are a quantitative measure of goal attainment, and you don't know what the final goal will be in an xPM project.

Assumptions, Risks, and Obstacles

There is no difference between xPM, TPM, and APM projects when it comes to this section. The statements given in the example lean heavily toward assumptions. Having to make such assumptions happens to be the nature of this project. I have already discussed how risk increases as your project moves along the continuum from certainty to uncertainty. Some of that risk will be reflected in this section of the POS.

Establishing a Project Timebox and Cost

Contrary to an APM project, an INSPIRE project is not constrained by a fixed time frame or cost limit. It is best to think of the time and cost parameters as providing the project team with guidance about the client's expectations. It is much like having the client say, “I would like to see some results within N months, and I am willing to invest as much as $X to have you deliver.” In reality, at each REview, the decision to continue or terminate is made. That decision isn't necessarily tied to the time and cost parameters given earlier by the client. In fact, if exceptional progress toward a solution is made, then the client may relax either or both of the time and cost parameters. In other words, if the progress to date is promising, more time and/or money may be placed at the team's disposal.

Establishing the Number of Phases and Phase Length

In the beginning, very short phases are advisable. I recall an xPM project in which the first few phases were very exploratory. With the collaboration of the client, we were searching for a feasible direction. For this project, the first few phases were one to three days in length. In the early phases, new ideas are tested, and many will be rejected. Proof of concept may be part of the first few phases. The team should not be committing to complex activities and tasks early on. As the team gains a better sense of direction, phase length may be increased. Specifying phase length and the number of phases up front merely sets expectations as to when and how frequently REview will take place. At each occurrence of a REview, phase length and perhaps the number of phases remaining may be changed to suit the situation. In an exploratory project, it would be a mistake to bind the team and the client to phases that do not relate to the realities of the project. Remember that flexibility is the key to a successful INSPIRE project. Cycle and iteration length in an APM project are more stable than phase length is in an xPM project.

Trade-Offs in the Scope Triangle

Despite the fact that INSPIRE is unstructured, it is important to set the priorities of the variables in the scope triangle. As project work commences and problems arise, which variable or variables are the client and the team willing to compromise? As discussed in Chapter 1, the variables in any project are as follows:

• Scope
• Quality
• Cost
• Time
• Resource availability
• Risk

In Chapter 1, you saw the scope triangle ranking matrix repeated here for convenience (Figure 12-20).

Figure 12-20 Prioritized scope triangle variables

It shows which of these variables is least likely to be compromised. Which would you choose to compromise first if the situation warranted it? The answer should depend on the type of project. For example, if the project involves conducting research to find a cure for the common cold, quality is the least likely to be compromised, and time might be the first to be compromised. But what if you knew that a competitor was working on the same project? Would time still be the first variable to compromise? Probably not. Cost might take its place, because time to market is now a critical success factor.

Scope is an interesting variable in Extreme projects. Consider the example of finding the cure for the common cold again. Hypothetically, what if you knew that the competition was also looking for a cure for the common cold, and that being first to market would be very important? In an earlier phase, the team discovered not a cure for the cold but a food additive that arrests the cold at its current stage of development. In other words, the cold will not get worse than it was at the time the additive was taken. The early discovery also holds great promise to morph into the cure that you are looking for, but you need time to explore it. You feel that getting the early result to market now may give you a strategic barrier to entry, give the competition reason to pause, and buy you some time to continue toward the original goal. Therefore, the scope is reduced in the current project, and it is brought to a successful completion. A new project is commissioned to continue on the path discovered in the earlier project.

SPeculate

This component defines the beginning of a new phase and will always start with a brainstorming session. The input will be either a blank slate or output from the previous INitiate → SPeculate → Incubate → REview cycle. In any case, the project team, client, and final user of the product or service should participate in the brainstorming session. The objective of this session is to explore ideas and identify alternative directions for the next Incubate phase. Because an INSPIRE project has a strong exploratory nature about it, no idea should be neglected. Several directions may eventually be pursued in parallel in the next phase. Phase length, deliverables, and other planning artifacts are defined in the SPeculate stage as well.

The word speculate conjures up deep thinking, carrying out due diligence on several alternatives, choosing one or more of those alternatives, and then simply taking your chances. You should hear yourself saying, “I wonder if this would work?” That is what the SPeculate stage of INSPIRE is all about.

Defining How the Project Will Be Done

The initial sense of direction for the team to take in the first phase of an INSPIRE project can vary considerably. A good approach is to use the POS objective statements as a guide. The POS can continuously be updated to reflect the current view of the project, and its objective statements can serve as a guide to what will be done. In later phases, the team and the client will have the benefit of learning and discovery from the prior phases. For the sake of discussion, I want to treat these two situations separately. In this section of the chapter, assume you are planning the first phase.

Conditions of Satisfaction

The COS was described in detail in Chapter 4 and will not be repeated here. Although the COS is a tool that produces a required deliverable in TPM and the APM, its use in xPM is optional. The COS loses its value as the goal becomes more and more elusive. If the client has only a vague idea about the goal, no amount of discussion about needs and deliverables will clarify the situation for either party, and the other planning artifacts described in the text that follows may be more useful in the initial SPeculate stage.

If you choose to use the COS in your INSPIRE project, think of it as more of a brainstorming process. The project team and the client can investigate ideas en route to generating a list of what will be done in this phase.

Prioritizing Requirements

The collection of scenarios, stories, and use cases provides insight into the requirements that the deliverable should meet. For the client, it is far easier to prioritize the collection than it is to prioritize the requirements. Prioritization is the next step in the SPeculate stage. There are several ways to produce a prioritized list of items in the collection.

Here are other aspects of the prioritization that need to be considered:

• A compromise approach might involve grouping the items based on their relationship to specific functions and then prioritizing between and within the functions. The strategy here would be to assign all of the items related to a specific function to a subteam for their consideration and development. Several subteams could be active in any given phase.
• Depending on how well the goal is understood, it might be wise to plan the initial SPeculate stage so that as many options and alternatives as possible can be investigated. The strategy here is to eliminate those alternatives that show little promise earlier rather than later in the project. That enables more resources to be brought to bear on approaches that have a higher probability of success.
• Where appropriate, prototypes might be considered as part or all of the first-phase deliverables. Here the strategy is to prioritize items in the collection or functions by not spending too much time developing the real deliverable. Familiarizing the client with the prototype may provide sufficient information to enable not only a reduction in the number of items in the collection, but also a prioritization of items or functions that show promise. A good example is a typical business-to-consumer (B2C) application. The prototype will show the various ways that a client can interact with the application. Upon examination, the client adds to this list or deletes from the list as they experience what the client would experience when interacting with the application.

Think of the first phase or two as exploratory in nature. Their purpose is to discover the directions that show promise and focus later phases on them.

Identifying the First-Phase Deliverables

After the prioritization is done, it is time to decide how much of that prioritized list to bite off for the initial phase. Remember that you want shorter phases in the early part of the project, which suggests that you limit the first-phase deliverables to what you can reasonably accomplish in a week or two.

Because your team resources are limited, you have to face the question of depth versus breadth of deliverables. In other words, might it be better to extend the breadth to accommodate more functions by not delving deep into any one function until a later phase? Produce enough detail in each function in this initial phase to get a sense of further direction for the function. You may learn from only a shallow look at a function that it isn't going to be part of the final solution. This shallow look enables you to save labor that would have been spent on a function that will be discarded, and to spend it on more important work.

Go/No-Go Decision

Because the initial phase can be purely exploratory, the sponsor must have an opportunity to judge the soundness of the initial phase plan and decide whether it makes sense to proceed. It is entirely possible that the original idea of the client cannot be delivered with the approach taken in the first phase, and the first phase leads the client to the decision that the idea doesn't make any sense after all. Some other approach needs to be taken, and that approach is not known at this time. The go/no-go decision points will occur at the end of each phase. Decisions to stop a project are more likely to occur in the early phases than in the later phases. You should expect later phases to benefit from earlier results that suggest that the project direction is feasible and should be continued.

Planning for Later Phases

Later phases will have the benefit of output from a REview to inform the planning activities that will take place in the SPeculate stage that follows. Each REview stage will produce a clearer vision and definition of the goal. That clearer vision translates into a redirection of the project, which translates into a new prioritized list of deliverables for the coming Incubate stage. The newly prioritized deliverables list may contain deliverables from previous phases that were not completed, deliverables that have not yet been part of an Incubate stage, and deliverables that are new to the project as a result of the learning and discovery that occurred in the most recently completed Incubate stage. In any case, the revised prioritized deliverables list is taken into consideration as the team plans what it will do in the coming Incubate stage. It is now in the same position as it was in the very first SPeculate stage. What follows then is the assignment of deliverables to subteams, and scheduling the work that will be done and who will do it.

Incubate

Incubate is the INSPIRE version of the Cycle Build Phase in APF. There are several similarities between the two models and some differences as well. Consider the following points:

• Even though the Incubate stage has a prioritized list of deliverables that are to be produced in this phase, INSPIRE still must maintain the spirit of exploration. It is a learning and discovery experience that may result in mid-phase corrections arising from that exploration. This would not happen in an APF project.
• Conversely, an APF project does benefit from learning and discovery as it proceeds with the Cycle Plan, but it does not vary from that plan. The learning and discovery are input to the Client Checkpoint, and that is where plan revisions take place.

These points reflect an important distinction between INSPIRE and APF. Subteams, working in parallel, will execute the plan developed in the previous SPeculate stage. The environment has to be very open and collaborative for SPeculate to be successful. Teams should be sharing ideas and cross-fertilizing discoveries and learning moments with one another. This is not just a time to execute a plan; it is a time for exploration and dynamic interchange. Mid-phase corrections with the collaboration of the client are to be expected as the subteams learn and discover together. New ideas and a redirection or clarification of the goal is likely to come from these learning and discovery experiences as well.

Assigning Resources

The Incubate stage begins with an assignment of team members to each of the deliverables that have been prioritized for this phase. The assignment should take place as a team exercise. That team involvement is important because of the exploratory nature of INSPIRE. Team members need to express their interest in one or more deliverables and share their ideas with their fellow team members. This assignment time can also be an opportunity for team members to recruit others who share their same interests and would like to develop the deliverable with them. The project manager should not pass up the opportunity to create a synergy among team members with similar interests, as well as between subteams that will be working in parallel on different deliverables. Any opportunity to create a collaborative work environment only increases the team's chances of success. You see then the importance of a co-located xPM team. The excitement generated from the spontaneous sharing of ideas can only come from a co-located xPM team.

Establishing a Phase Plan

With the subteams in place and with their assignments made, the subteams can plan how they will produce the deliverables assigned to them. Deciding how a team produces the deliverables is exactly the same as discussed in Chapter 5. In fact, many of the same tools discussed in Chapter 5 can be used to help establish a phase plan here with equal effectiveness. For example, Chapter 5 presents the phase plan as a time-sequenced whiteboard diagram showing a day-by-day schedule of what is going to be done and by whom.

Collaboratively Producing Deliverables

Collaboration goes to the very essence of INSPIRE. Collaboration between subteams must occur. The example given earlier is one such instance. I spoke earlier in the chapter about the exploratory nature of an Extreme project. Because the project is exploratory, no one has a lock on the solution. Even the goal is somewhat elusive. That means the goal and the solution can be attained only through a solid team effort—a collaborative effort. There is a great deal of similarity between INSPIRE projects and brainstorming. One idea may not be of much value when taken individually. However, combine it with one or more other ideas and suddenly there is value. Co-location can make this exchange possible. The quote at the beginning of Chapter 11 from Estill I. Green, former vice president of Bell Telephone Laboratories, is relevant here: “Clearly no group can as an entity create ideas. Only individuals can do this. A group of individuals may, however, stimulate one another in the creation of ideas.”

REview

REview in INSPIRE is very similar to the Client Checkpoint Phase in the APF. All of the learning and discovery from the just-completed Incubate stage are brought together in another brainstorming session. During the REview stage, the project team will share their answers to questions such as the following:

• What did you learn?
• What can you do to enhance goal attainment?
• What new ideas arose and should be pursued?
• What should you do in the next phase?

The most important decision is whether or not the project will continue. This is a client decision. Have the results to date met with their expectations? Is the project moving toward an acceptable solution? These answers will determine whether or not the project continues to the next phase or is canceled. APF and INSPIRE share this go/no-go decision point at the completion of each phase. APF is less likely to result in a cancelation, because so much more is known about the solution. Conversely, INSPIRE is so exploratory and research-based that cancelations are far more likely.

Each phase of an INSPIRE project ends with a review of the just-completed Incubate stage. It is a meeting attended by the client and the project team. The purpose of the REview stage is to reflect on what has just happened and what learning and discovery have taken place. The output is a definition of the next phase's activities.

Applying Learning and Discovery from the Previous Phase

Early in the sequence of phases, the client and the team should expect significant findings and major redirections of further efforts. As the project moves into later phases, the changes should diminish in scope because the project team should be converging on a more clearly defined goal and an acceptable solution to reach it.

Revising the Project Goal

The first order of business is for the client and the project team to revisit the previous goal statement from the prior REview stage. Ask the following questions:

• What has happened in the just-completed Incubate stage?
• What new information do you have?
• What approaches have you eliminated?
• What new discovery suggests a change in goal direction and definition?
• Are you converging on a more clearly defined goal that has business value?

This revision of the project goal is an important step and must not be treated lightly. The client and the team need to reach a consensus about the new goal, and you then need to update the POS with a revised goal statement.

Reprioritizing Requirements

The second order of business is for the client and the project team to revisit deliverables and requirements. The following questions should be asked here:

• How does the new goal statement affect the deliverables list?
• Should some items be removed?
• Should new items be added?
• How is the functionality embedded in the new goal statement affected?

The answers to these questions enable the client and the project team to reprioritize the new requirements. Update the POS to reflect any changes in the objective statements.

Making the Go/No-Go Decision for the Next Phase

Will there be a next INitiate → SPeculate → Incubate → REview phase? Equivalently, the question could be this: Are you converging at an acceptable rate on a clearly defined goal and acceptable solution? The client will consider this question in the face of the money and time already spent. Does it make business sense to continue this project? The updated POS is the input to this decision.

Challenges to Project Setup and Execution

In the complex project world, change is frequent and often affects projects in unanticipated ways. Risk is high, and an attentive risk management plan may be the key to successful projects. Drawing on my experiences I have compiled a list of the four most significant complex project management challenges I can recall and what might be done to prevent and mitigate them.

Sponsors Have a Hard Time Accepting Variable Scope

Without a doubt this has been a continuing challenge as organizations transition to the realities of managing complex projects. Sponsors and C-level executives have a particularly difficult time adjusting to the realities of complex project management. First, these senior managers must understand that to be successful complex projects require a new collaboration between the client team and the development team. That collaboration is an open and honest partnership to creatively learn and discover a solution to a critical and unmet business need. At the outset no one knows what solution will emerge and what business value it will deliver. Risk is high and a successful effort will provide high return. Sponsors and clients must be meaningfully involved as the next challenge discusses.

Achieving and Sustaining Meaningful Client Involvement Through the Phases of the Chosen PMLC Model

This is a critical success factor especially in the complex project space. My consulting model has always stressed meaningful client involvement, and I do that by having a responsible client manager partner with me in the role of a co-manager. We share equally in the successes, failures and decisions. That quickly builds strong co-ownership with the client. Since their name is associated with the management of the project, they will not let the project fail. That co-ownership is the greatest contributor to project success that I know of.

Adapting the Chosen PMLC Model to Changing Conditions

Projects are dynamic. They can change for a variety of reasons including changes in business conditions and priorities as well as other internal and external environmental factors. That translates into a need to continuously review the chosen PMLC model for adaptations and even for reconsideration. For example, at some point in an iteration during a Scrum project the client says, “Aha, now I see what the complete solution will look like.” And the project manager replies, “And I know how we can build that solution.” Does that mean that Scrum should be abandoned in favor of say a Staged Delivery Waterfall model for example? That question is difficult to answer because there are so many moving parts to the project. For example, some of the more obvious implications are:

• Changes to resource requirements
• Schedule changes and resource availabilities
• Cost of abandonment of Scrum and replacement by a Staged Delivery Waterfall model
• Budget implications

These added costs need to be balanced against the benefits which could include:

• Pricing changes to products/services
• Sales and marketing implications to product/service rollout dates
• Cost avoidance implications

APF is the only Adaptive PMLC model that is designed to accommodate PLMC model changes mid-project.

Delivering Business Value in a Complex Project Landscape

Expected incremental business value is the primary metric used to validate, approve and prioritize a project. Figure 12-21 is a conceptual illustration of the likely outcomes.

First, understand that the business value that will be delivered from a project is an estimate provided by the sponsor and client to gain approval to conduct the project. As Figure 12-21 illustrates, that estimate has a variance.

For TPM projects all of the business value is delivered after the project is complete and the variance of the estimate is small compared to APM and xPM projects.

Figure 12-21 TPM, APM, and xPM solution business value

For APM projects the situation is quite different. At each iteration or cycle specific business value will be delivered. The variance of the estimate increases over the project life span. For the example illustrated in Figure 12-21 the delivered business value may fall far short of the business value estimated if the goal is achieved. It is also possible that the delivered business value exceeds what was estimated if the goal is achieved. Clearly the risk of not delivering expected business value is greater for APM projects than for TPM projects, but the rewards can be much greater.

xPM projects are in a world far different than any APM project. In an APM project the goal is clear, and hopefully, as the solution emerges, it will converge on the goal and deliver the expected business value but there is high risk. In an xPM project both the goal and the solution are not fixed. The goal may be an expression of a desired end state with no vision of how or even if that end state can be achieved. That is for the project to learn and discover. As the solution emerges the goal will change as certain aspects of the goal cannot be attained given present technology and understanding of the solution space. Hopefully the goal and its solution will converge and produce business value. That business value may not be acceptable to the sponsor or the client. Again, we are dealing with a very high-risk situation.

Putting It All Together

We have looked in depth into the five types of project management model types: Linear, Incremental, Iterative, Adaptive, and Extreme. The characteristics, strengths, weaknesses, and considerations of when to use specific PMLC models were documented and compared. The result is a relatively complete foundation for classifying a project into one of the four quadrants of the project landscape and then choosing the best-fit PMLC for a given project. This is a rich collection for effective project management.

By way of summary it is instructive to recall Figure 2-8 from Chapter 2. It is reproduced here as Figure 12-22.

Figure 12-22 The five PMLC models

First note the similarities. We know that the purposes and interpretations at each phase are quite different. These occur as part of the feedback loops and the decision processes that follow the closure of an increment, iteration, cycle, or phase. Understanding the similarities and differences gives the project manager a leg up on the effective management of complex projects.

Discussion Questions