Introducing Project Management Life Cycles

,

To plan your journey you need a project landscape that is simple and intuitive and will remain valid despite the volatility of the business environment. It will be your unchanging roadmap for further analysis and action. For several years now, project management professionals have proclaimed, “One size does not fit all.” If it did, the life of a project manager would be boring and this book would be less than 100 pages in length. Unfortunately (or fortunately for those with an adventuresome spirit) being an effective project manager is exhilarating and demanding of all your creative energies. A “one size fits all” mentality doesn't work and probably never worked. I am of course talking about how the characteristics of the project should inform the project manager as to the tools, templates, and processes that should be used on a given project. To help you build a decision making model for choosing a project management model, I will first define a very general project landscape and then a strategy for drilling down in that landscape to a specific project management life cycle (PMLC) model, and then I will discuss the tools, templates, and processes and their adaptation to the specific characteristics of the project. You need to understand at the outset that there are no silver bullets. Project management is not a matter of following a recipe. Rather it is the ability to create and use recipes. I want you to be a chef not just a cook. A cook only has the ability to follow the recipes of others. A chef, on the other hand, has the ability to create recipes. You are going to have to work hard to reach a point where you can create recipes.

Goal and Solution Clarity

I like simple and intuitive models, so I have built my project landscape around two variables: goal and solution. These two variables can each take on two values: clear and complete or not clear and complete. Those two values for each variable generate the four-quadrant matrix shown in Figure 2-1.

Figure 2-1: The four quadrants of the project landscape

Traditional Project Management (TPM) defines Quadrant 1; Agile Project Management (APM) defines Quadrant 2; Extreme Project Management (xPM) defines Quadrant 3; and Emertxe Project Management (MPx) defines Quadrant 4. I don't know where the dividing line is between clear and not clear, but that is not important to this landscape. These values are conceptual not quantifiable. A given project can exhibit various degrees of clarity. The message in this landscape is that the transition from quadrant to quadrant is continuous and fluid.

As an example, say that the project goal is to cure the common cold. Is this goal statement clear and complete? Not really. The word cure is the culprit. Cure could mean any one of the following:

• Prior to birth, the fetus is injected with a DNA-altering drug that prevents the person from ever getting a cold.
• As part of everyone's diet, they take a daily dose of the juice from a tree that grows only in certain altitudes in the Himalayas. This juice acts as a barrier and prevents the onset of the common cold.
• Once a person has contracted a cold, they take a massive dose of tea made from a rare tree root found only in central China, and the cold will be cured within 12 hours.

So what does cure really mean? As another example, consider this paraphrasing of a statement made by President John F. Kennedy in his 1961 State of the Union Address: By the end of the decade, we will have put a man on the moon and returned him safely to earth. Is there any doubt in your mind that this goal statement is clear and complete? When the project is finished, will there be any doubt in your mind that this goal has or has not been achieved?

Every project that ever existed or will exist falls into one of these four quadrants at any point in time. This landscape is not affected by change of any kind. It is a landscape that will remain in place regardless. The quadrant in which the project lies will be an initial guide to choosing a best-fit PMLC model and adapting its tools, templates, and processes to the specific project. As the project work commences and the goal and solution become clearer, the project's quadrant can change, and perhaps the PMLC will then change as well; however, the project is always in one quadrant. The decision to change the PMLC for a project already underway may be a big change and needs to be seriously considered. Costs, benefits, advantages, and disadvantages are associated with a mid-project change of PMLC. Part II will aid you in making this decision.

Beyond clarity and completeness of the goal and solution, you have several other factors to consider in choosing the best-fit PMLC and perhaps modifying it to better accommodate these other factors. By way of example, one of those factors is the extent to which the client has committed to be meaningfully involved. If the best-fit PMLC model requires client involvement that is heavy and meaningful, as many Quadrant 2 and 3 projects do, and you don't expect to have that involvement, you may have to fall back to an approach that doesn't require as much client involvement. Alternatively you may want to put a program in place to encourage the desired client involvement. This is a common situation, and you will learn strategies for effectively dealing with it in Part II.

I have practiced project management since 1963, which pre-dates the Project Management Institute (PMI) by a few years. Across the 45+ years, I have seen project management mature from a simple approach based mostly on Gantt Charts to a multi-disciplined array of tools, templates, and processes tailored to fit all types of situations. Project management is no longer just another tool in the toolkit of an engineer. It is now a way of life as many businesses have morphed themselves into some form of project-based organization. Although there will continue to be applications for which the old ways are still appropriate, there is a whole new set of applications for which the old ways are totally inappropriate. The paradigm must shift and is shifting. Take agile project management, for example, which formally came on the scene in 2001.² It represented a marked formal departure from the then-current practices. Any company that hasn't embraced that shift is sure to risk losing project management as a strategic asset. “Change or die” was never a truer statement than it is today. From that humble introduction in 2001 has emerged an entire portfolio of project management approaches. These are mentioned later in this section and covered in detail in Part II.

Why do we need yet another way of managing projects? Don't we have enough options already? Yes, there certainly are plenty of options, but projects still fail at an unacceptably high rate. In the past, the efforts of project managers have not been too fruitful. There are lots of reasons for that failure. I believe that part of the reason is because we haven't yet completely defined, at a practical and effective level, how to adjust our management approaches to embrace the types of projects that we are being asked to manage in today's business environment. Too many project managers are trying in vain to put squfare pegs in round holes because all they have are squfare pegs. We need to approach project management as the art and science that it truly is. That means basing it on irrefutable principles and concepts and building on those to produce a scientifically defined discipline. This chapter and Part II are my attempt to do just that.

To me the answer to our project management difficulties is obvious. Project managers must open their minds to the basic principles on which project management is based so as to accommodate change, avoid wasted dollars, avoid wasted time, and protect market positions. For as long as I can remember, I have been preaching that one size does not fit all. The characteristics of the project must be the basis on which project management approaches are defined. This concept has to be embedded in your approach to project management. Your thinking must embrace a project management approach that begins by choosing the best-fit PMLC model based on the characteristics of the project at hand. The RBS is the artifact that will allow you to do that. Then you can choose how that model should be adapted to effectively manage the project.

Traditional practices require client requirements to be clearly and completely defined before any planning can take place. Most contemporary thinkers on the topic would suggest that it is impossible to completely and clearly document requirements at the beginning of any project. Whether you agree or not, that condition is likely to exist in most contemporary projects, and there are many reasons for that. In the chapters of Part II you will consider these situations as well as the inevitable scope change requests and their impact on project management processes. In doing that, you will learn alternative project management approaches to handle these difficult situations while maintaining a client focus throughout the entire project life cycle.

As presented in the introduction to this book, the old ways of project management were defined and matured in the world of engineer and construction professionals. These professionals provided what they thought was a complete and accurate description of what the client wanted. It was assumed that the project team clearly understood the solution they were to provide and that they could clearly plan for its delivery. Unfortunately that was not the case, and the result was a project failure rate exceeding 70 percent. Adjustments were implemented in an attempt to appease the client, but it was too late. The project had failed. That describes the world of the project manager until the mid-1950s, when the computer became a viable commercial resource. Using computers to run businesses was now a reality, and position titles such as programmer, programmer analyst, systems analyst, and primitive types of database architects started emerging. The business world and the project world had changed, and we would never look back.

In the face of that change, the old ways still weren't showing any signs of change. To engineers, every project management problem looked like a nail, and they had the hammer. It seemed to be working, or at least no one was complaining or knew how to complain when it wasn't.

Fast forward to the 1970s. Buried beneath the mysticism that surrounded the computer was another problem that would soon surface — that is, the inability of the businessperson to tell the difference between wants and needs. The confusion arose from the glamour surrounding the computer. It was touted as the silver bullet: All users needed to do was push a button and the rest would be automatic. The conduct of business was going to become simple. The wants got in the way of seeing the real needs.

Here we are more than 40 years later, and that problem still persists. If you remember anything from this discussion, remember that what the client wants is probably not what the client needs. Wants are associated with a solution envisioned by the client, whereas needs are associated with an underlying and unstated problem. If the project manager blindly accepts what the client says they want and proceeds with the project on that basis, that project manager is in for a rude awakening. Often in the process of building the solution, the client will begin to see that what they need is not the same as what they requested, which leads to rolling deadlines, scope creep, and an endless trail of changes and reworks.

The market is different today than it was 30 years ago. The PC is less than 30 years old, and look at the impact it has had. Technology has been the prime mover to those market differences. Leveraging technology to get to market as fast as possible must now be the strategy. Leveraging technology to get the most innovative product or service to market before the competition gets there must also be the strategy. Project management is the only enabler of those strategies. It must provide approaches that support high change, speed, and increasing complexity. The old ways had to strain to keep up with the realities of projects such as these. It's no wonder that 70+ percent of projects fail. That has to stop. Project managers need approaches that are built around the expectation of change — ones that embrace learning and discovery throughout all of the project life cycle. These approaches must have built-in processes to integrate the changes that result from this learning and discovery.

A project management life cycle (PMLC) is a sequence of processes that includes:

• scoping
• planning
• launching
• monitoring and controlling
• closing

the projects to which it applies. A valid PMLC always starts with a scoping process and ends with a closing process. All five of the processes must each be done at least once and may be repeated any number of times in some logical order. These process groups are defined in Chapter 3. The logical ordering of these processes is a function of the characteristics of the project. This book defines five different PMLC models. Each is constructed to meet the specific needs of a project type to which it is aligned.

In previous editions of this book, I introduced a way to organize and manage complex projects in the face of uncertainty. To that end I defined the following five models across the four quadrants:

• TPM — Linear and Incremental models
• APM — Iterative and Adaptive models
• xPM — Extreme model
• MPx — Extreme model

These five models form a continuum that ranges from certainty about the solution (both the goal and solution are clearly defined) to some uncertainty about the solution (the goal is clearly defined, but the solution is not clearly defined) to major uncertainty about the solution (neither the goal nor solution are clearly defined).

In Figure 2-2, certainty is measured with respect to requirements and solution. The less certain you are that you have clearly defined requirements and a solution to match, the more you should choose an approach at the high uncertainty end of the continuum. Once you understand the nature of the project to be undertaken, you can confidently choose the model that offers the best chance of a successful completion.

Figure 2-2 shows how the five PMLC models are distributed across the four quadrants that were defined in Chapter 1. Note that there is some overlap. It would seem that as the project solution and its requirements becomes less clear, the best-fit PMLC could be chosen from among Linear, Incremental, Iterative, Adaptive, or Extreme. That, in fact, is the case. The decision as to which of these five PMLCs is best for the project is based on factors that include solution clarity. For projects that are near the boundaries of TPM and APM, you will always have a judgment call to make as to which PMLC model is the best-fit model. In Part II the ramifications of that subjective decision are described.

Figure 2-2: PMLC approaches

Traditional Project Management Approaches

How could it be any better than to clearly know the goal and the solution? This is the simplest of all possible project situations, but it is also the least likely to occur in today's fast-paced, continuously changing business world. Testimonial data that I have gathered from all over the world suggests that about 20 percent of all projects legitimately fall in the TPM quadrant. Projects that fall into the TPM quadrant are familiar to the organization. Many infrastructure projects will fall in the TPM quadrant. Perhaps they are similar to projects that have been done several times before. There are no surprises. The client has clearly specified the goal, and the project team has defined how they will reach that goal. Little change is expected. There are different approaches that are in use for such projects, and you will learn how to choose from among them the approach that best fits your project. Such projects also put the team on familiar technology grounds. The hardware, software, and telecommunications environments are familiar to the team. They have used them repeatedly and have developed a skilled and competent developer bench to handle such projects.

The limiting factor in the TPM plan-driven approaches is that they are change-intolerant. They are focused on delivering according to time and budget constraints, and rely more on compliance to plan than on delivering business value. The plan is sacred, and conformance to it is the hallmark of the successful project team.

Because of the times we live in, the frequency of projects legitimately delivered via the TPM quadrant is diminishing rapidly. The simple projects have all been done. The projects that remain in the TPM quadrant are those which have been done many times before and well-established templates are probably in place. As TPM approaches are becoming less frequent, they are giving way to a whole new collection of approaches that are more client-focused and deliver business value rather than strict adherence to a schedule and budget.

In addition to a clearly defined goal and solution, projects that correctly fall into the TPM quadrant have several identifying characteristics as briefly identified in the following sections.

Low Complexity

Other than the fact that a low-complexity project really is simple, this characteristic will often be attributable to the fact that the project rings of familiarity. It may be a straightforward application of established business rules and therefore take advantage of existing designs and coding. Because these projects have been done many times, they will often depend on a relatively complete set of templates for their execution. To the developer, it may look like a cut-and-paste exercise. In such cases, integration and testing will be the most challenging phases of the project.

There will be situations where the project is complex but still well defined. These are rare.

Few Scope Change Requests

This is where TPM approaches get into trouble. The assumption is that the RBS and WBS are relatively complete, and there will be few, if any, scope change requests. Every scope change request requires that the following actions be taken:

• Someone needs to decide if the request warrants an analysis by a project team member.
• The project manager must assign the request to the appropriate team member.
• The assigned team member conducts the analysis and writes the Project Impact Statement.
• The project manager informs the client of the recommendations.
• The project manager and client must make a decision as to whether the change will be approved and if so how it will be accomplished.
• If the scope change request is approved, the project scope, cost, schedule, resource requirements, and client acceptance criteria are updated.

All of this takes time away from the team member's schedule commitments. Too many scope change requests and you see the effect they will have on the project schedule. Furthermore, much of the time spent planning the project before the request was made becomes non-value-added time.

So the answer to too-frequent scope change requests is some form of management monitoring and control. Those management controls can be built into every TPM, APM, xPM, and MPx approach but are different for each type of project.

Well-Understood Technology Infrastructure

A well-understood technology infrastructure is stable and will have been the foundation for many projects in the past. That means the accompanying skills and competencies to work with the technology infrastructure are well grounded in the development teams. If the technology is new or not well understood by the project team, there are alternative strategies for approaching the project. These strategies are discussed throughout Part II.

Low Risk

The requirement for TPM projects is that their environment is known and predictable. There are no surprises. All that could happen to put the project at risk has occurred in the past, and there are well-tested and well-used mitigation strategies that can be used. Experience has rooted out all of the mistakes that could be made. The client is confident that they have done a great job identifying requirements, functions, and features, and they are not likely to change. The project manager has anticipated and prepared for likely events (not including acts of nature and other unavoidable occurrences). There will be few unanticipated risks in TPM projects. That doesn't mean you can skip the risk management process in these projects. That will never be the case, regardless of the quadrant the project occupies. However, the intensity, analysis, monitoring, and mitigation strategies will be different in each quadrant.

Experienced and Skilled Project Teams

Past projects can be good training grounds for project teams. Team members will have had opportunities to learn or to enhance their skills and competencies through project assignments. These skills and competencies are a critical success factor in all projects. As the characteristics of the deliverables change, so does the profile of the team that can be most effective in developing the deliverables. TPM project teams can include less experienced team members and project managers. They can be geographically dispersed and still be effective.

Plan-driven TPM Projects

Because all of the information that could be known about the project is known and considered stable, the appropriate PMLC model would be the one that gets to the end as quickly as possible. Based on the requirements, desired functionality, and specific features, a complete project plan can be developed. It specifies all of the work that is needed to meet the requirements, the scheduling of that work, and the staff resources needed to deliver the planned work. TPM projects are clearly plan-driven projects. Their success is measured by compliance and delivery to that plan.

Knowing this, you can use a TPM approach to managing such projects. For example, you can build a complete Work Breakdown Structure (WBS) and from that estimate duration, estimate resource requirements, construct the project schedule, and write the project proposal. This is a nice neat package and seemingly quite straightforward and simple. Oh, that the life of a project manager were that simple. But it isn't, and that's where the real challenge comes in. You'll see that later as I show how to adjust this quadrant for more complex project situations discussed in Chapters 11 and 12.

Testimonial data that I have gathered from more than 10,000 project managers worldwide suggests that not more than 20 percent of all projects require some form of TPM approach. The two models discussed in the subsections that follow are special cases of the TPM approach.

Linear Project Management Life Cycle Model

I start with the simplest TPM approach — the Linear PMLC model — as a foundation for the variations presented in this section. Figure 2-3 illustrates a Linear model approach to project management.

Figure 2-3: Linear PMLC model

Note that the five process groups are each executed once in the order shown in the figure. There is no looping back to repeat a process group based on learning from a later process group. This is a major weakness of all Linear PMLC models in that knowledge gained from one process group, such as Launching, cannot be used to revise and improve the deliverables from a previously completed process group, such as Scoping. There is no going back to improve deliverables. For example, suppose the project involves the development of a software application. The Monitoring and Controlling Phase includes a systems development life cycle, which might simply consist of Design, Build, Test, and Implement. That, too, is done without going back to an earlier part of the systems development life cycle, so an improved solution discovered during Build cannot be reflected in a revised and improved Design. There is no going back.

So you might argue that going back and improving the solution is in the best interest of the client. It probably is, but if that is the possibility you are willing to accept, why not make the decision at the beginning of the project and choose a PMLC model that includes repeating process groups? And you have several to choose from.

A scope change request from the client upsets the balance in the Linear PMLC model schedule and perhaps the resource schedule as well. One or more of the team members must analyze the request and issue a Project Impact Statement. (The Project Impact Statement is discussed in Chapter 6.) This takes one or more team members away from their scheduled project work, potentially putting the project behind schedule.

You can always choose to use a Linear PMLC, but if a better choice was another PMLC, you are in for a rough ride.

Incremental Project Management Life Cycle Model

On the surface, the only difference between the Linear and Incremental approaches is that the deliverables in the Incremental approach are released according to a schedule. That is, a partial solution is initially released, and then at some later point in time, additional parts of the solution are added to the initial release to form a more complete solution. Subsequent releases add to the solution until the final increment releases the complete solution. The decision to use an Incremental PMLC model over the Linear PMLC model is a market-driven decision. In both models, the complete solution is known at the outset. Getting a partial solution into the market is viewed as a way to get an early entry position and therefore create some leverage for generating increased market share. I'll have more to say about the advantages and disadvantages of this model in Chapter 10.

All of this incremental release happens in a linear fashion, as shown in Figure 2-4, so that in the end, the solution is the same as if a Linear PMLC model had been followed. Ideally, the project ends with the same deliverables and at approximately the same time. There is some additional management overhead associated with the Incremental PMLC model, so those projects will finish later than the Linear PMLC model.

The sequences of Launch Increment through Next Increment decision boxes are strung out in series over time.

Figure 2-4: Incremental PMLC model

A more in-depth investigation would show that significant differences exist between the Incremental PMLC model and the Linear PMLC model. The following two are worth mentioning:

• The first difference has to do with scope change requests. In the Linear PMLC model, these are not expected or encouraged. As a hedge against the time they require, management reserve is often added to the end of the schedule. (See Chapter 5 for a discussion of management reserve.) Because of the structure of the Incremental PMLC model change is actually encouraged. It happens in a subtle and unsuspecting way. The initial release of a partial solution gives the client and the end user an opportunity to experiment with the partial solution in a production scenario and find areas that could be improved. That encourages change requests. A smart project manager will build schedule contingencies into the plan in the event of these scope change requests. There is more detail on this in Chapter 10.
• The second difference is related to how the full solution is decomposed into partial solutions whose development would then be planned in a sequential fashion and released in that same order. The release schedule needs to be consistent with the dependencies that exist between each partial solution. To be clear, what if a particular release depended upon the features and functions scheduled for development in a later release? There goes the integrity of the release schedule. Extensive re-planning often follows, significantly changing the release schedule.

Agile Project Management Approaches

What about cases where what is needed is clearly defined but how to produce it isn't at all that obvious? These types of projects occupy a space in the landscape somewhere between traditional and extreme projects. Many managers have observed that the vast majority of their projects are a closer fit with APM approaches than either TPM or xPM approaches. Clearly TPM won't work when the solution is not known. For TPM to work, you need a detailed plan. But if you don't know how you will get what is needed, how can you generate a detailed plan? What about the extreme approach? I'm guessing that the “agilists” would argue that any one of the extreme approaches would do just fine. I agree that you could use an extreme approach and probably do quite well. Unfortunately, you would be ignoring the fact that you know what is needed. It's a given. Why not use an approach that incorporates the fact that you know what's needed?

Projects that correctly use an APM approach have several defining characteristics as briefly identified in the sections that follow.

A Critical Problem without a Known Solution

These are projects that must be done. You have no choice. Because there is no known solution, a TPM approach, which requires a complete RBS and WBS, will not work. Despite the realities, it amuses me how many project managers try to use a hammer when a screwdriver is needed (maybe some of them only have hammers). The only approaches that make sense are those that enable you to discover an acceptable solution by doing the project. These projects fly in the face of all of the traditional practices of project management. Executives are uncomfortable with this situation because all of the valid approaches have variable scope. Resources are being requested without knowing what final product will be delivered. Some of the functions and features of the solution may be known, but there is not enough business value in the known partial solution for it to be implemented.

A Previously Untapped Business Opportunity

In these types of projects, the company is losing out on a business opportunity and must find a way to take advantage of it through a new or revamped product or service offering. The question is what is that business opportunity and how can you take advantage of it? Here very little of the solution is known.

APM Projects Are Critical to the Organization

You should have guessed by now that an APM project can be very high risk. If previous attempts to solve the problem have failed, it means the problem is complex and there may not be an acceptable solution to the problem. The organization will just have to live with that reality and make the best of it. Projects to find that elusive solution might work better if they are focused on parts of the problem or if approached as process-improvement projects. See Chapter 15 for a discussion of how to design and implement a continuous process and practice improvement program.

Meaningful Client Involvement Is Essential

The solution will be discovered only if the client and the development team meaningfully collaborate in an open and honest environment. For the client this means fully participating with the project team and a willingness to learn how to be a client in an agile world. For the development team this means a willingness to learn about the client's business and how to communicate in their language. For the project manager this means preparing both the client team and the development team to work together in an open and collaborative environment. It also means that the project manager will have to share responsibility and leadership with a client manager.

My project governance model is a co-project manager model. I share project management with the client representative. This could be the client manager or a senior business analyst assigned to the business unit. I have found that this fosters ownership on the part of the client and that is important to implementation success.

APM Projects Use Small Co-located Teams

If the project requires a team of more than 30 professionals, you probably should partition the project into several smaller projects with more limited scopes. As a rule, APM approaches do not scale well. To manage a 30+ project team, partition it into smaller teams, with each of these teams being responsible for part of the scope. Set up a temporary program office to manage and coordinate the work of the smaller project teams.

Two model types fall into the APM quadrant. The first is the Iterative PMLC model. It is appropriate to use with projects for which some of the features are missing or not clearly defined. When the solution is less clearly specified — functions as well as features are missing or not clearly defined — then the best-fit choice favors using the other model type: the Adaptive PMLC model.

There are various Iterative and Adaptive approaches to managing APM projects that can be used when the goal is clearly defined but how to reach the goal — the solution — is not. Imagine a continuum of projects that range from situations where almost all of the solution is clearly and completely defined to situations where very little of the solution is clearly and completely defined. This is the range of projects that occupy the APM quadrant. As you give some thought to where your projects fall in this quadrant, consider the possibility that many, if not most, of your projects are really APM projects. If that is the case, shouldn't you also be considering using an approach to managing these projects that accommodates the goal and solution characteristics of the project rather than trying to force-fit some other approach that was designed for projects with much different characteristics?

I contend that the Adaptive and Iterative class of APM projects is continuously growing. I make it a practice at all “rubber chicken” dinner presentations to ask about the frequency with which the attendees encounter APM projects. With very small variances in their responses, they say that at least 70 percent of all their projects are APM projects, 20 percent are TPM projects, and the remaining 10 percent is split between xPM and MPx projects. Unfortunately, many project managers try to apply TPM approaches (maybe because that is all they have in their project management arsenal) to APM projects and meet with very little success. The results have ranged from mediocre success to outright failure. APM projects present a different set of challenges and need a different approach. TPM approaches simply will not work with APM projects. For years I have advocated that the approach to the project must be driven by the characteristics of the project. To reverse the order is to court disaster. I find it puzzling that we define a project as a unique experience that has never happened before and will never happen again under the same set of circumstances, but we make no assertion that the appropriate project management approach for these unique projects will also be unique. I would say that the project management approach is unique up to a point. Its uniqueness is constrained to using a set of validated and certified tools, templates, and processes. To not establish such a boundary on how you can manage a project would be chaotic. Plus the organization could never be a learning organization when it comes to project management processes and practices.

As the solution moves from those that are clearly specified towards those that are not clearly specified, you move through a number of situations that require different handling. For example, suppose only some minor aspects of the solution are not known, say the background and font color for the login screens. How would you proceed? An approach that includes as much of the solution as is known at the time should work quite well. That approach would allow the client to examine, in the sense of a production prototype, what is in the solution in an attempt to discover what is not in the solution but should be. At the other end of the APM Quadrant, when very little is known about the solution, projects have higher risk than those where a larger part of the solution is known. A solution is needed, and it is important that a solution be found. How would you proceed? What is needed is an approach that is designed to learn and discover most of the solution. Somehow that approach must start with what is known and reach out to what is not known. In Chapter 11, I will share a process that I developed called Adaptive Project Framework (APF). APF is the only APM PMLC model I know of that includes work streams designed specifically to discover rather than implement aspects of the solution. I call these work streams “Probative Swim Lanes.” They are defined and fully discussed in Chapter 11.

There are several approaches to APM projects. These approaches all have one thing in common — you cannot build a complete WBS without guessing. Because guessing is unacceptable in good project planning, you have to choose an approach designed to work in the absence of the complete WBS. All APM approaches are structured so that you will be able to learn and discover the missing parts of the solution. As these missing parts are discovered, they are integrated into the solution. There are two distinct PMLC models for use in APM projects: Iterative PMLC models and Adaptive PMLC models. The choice of which model to use depends somewhat on the initial degree of uncertainty you have about the solution. You'll see this in Chapter 11 as you adjust the APM PMLC models to accommodate more complex situations.

Iterative Project Management Life Cycle Model

As soon as any of the details of a solution are not clearly defined or perhaps are even missing, you should favor some form of Iterative PMLC model. For software development projects, the most popular models are Evolutionary Development Waterfall, Scrum, Rational Unified Process (RUP), and Dynamic Systems Development Method (DSDM). See the bibliography in Appendix C for references to all four models. The Iterative PMLC model is shown in Figure 2-5.

Figure 2-5: Iterative PMLC model

You might notice that this is quite similar to production prototyping. That is, a working solution is delivered from every iteration. The objective is to show the client an intermediate and perhaps incomplete solution and ask them for feedback on changes or additions they would like to see. Those changes are integrated into the prototype, and another incomplete solution is produced. This process repeats itself until either the client is satisfied and has no further changes to recommend or the budget and/or time runs out. The Iterative PMLC model differs from the Incremental PMLC model in that change is expected. In fact, change is a necessary part of this model.

Iterative PMLCs definitely fit the class of projects that provide opportunity to learn and discover. In Figure 2-5, the learning and discovering experience takes place as part of each feedback loop. With each iteration, more and more of the breadth and depth of the solution is produced. That follows from the client having an opportunity to work with the current solution and give feedback to the project team. The assumption is that the client learns and discovers more details about the solution from the current iteration. In the prototyping mode, the development team usually takes client input and presents alternatives in the next version of the prototype. As you can see, there is a strong collaborative environment in APM approaches that is usually not present and not required in TPM approaches.

Adaptive Project Management Life Cycle Model

The next step away from a complete solution is the Adaptive PMLC model. Here the missing pieces of the solution extend to functionality that is missing or not clearly defined. At the extreme end of the APM, part of the landscape would be projects where almost nothing about the solution is known. In other words, the less you know about the solution, the more likely you will choose an Adaptive PMLC model over an Iterative PMLC model. Unfortunately, all of the current Adaptive PMLC models were designed for software development projects. Because not all projects are software development projects, that left a giant gap in the PMLC model continuum. In my consulting practice, this was a serious shortcoming in the agile space and led me to develop the Adaptive Project Framework (APF) for application to any type of project. APF is an APM approach that spans the gap between TPM and xPM approaches for all types of projects. I have successfully used APF on product development, business process design, and process improvement projects. Chapter 11 discusses APF in detail.

Figure 2-6 is a graphic portrayal of how the Adaptive PMLC is structured. At the process group level, it is identical to the Iterative PMLC model. Within each process group, the differences will become obvious. Chapter 11 covers the Adaptive PMLC model in considerable detail.

Figure 2-6: Adaptive PMLC model

Extreme Project Management Approach

The third model type arises in those projects whose solution and goal are not known or not clearly defined. Here you are in the world of pure R & D, new product development, and process improvement projects. These are high-risk, high-change projects. In many cases, they are also high-speed projects. Failure rates are often very high.

When so little is known about the goal and solution, you might be concerned about how to approach such projects. What tools, templates, and processes will work in these cases? Will any of them work? This can be a high-anxiety time for all but the most courageous, risk-taking, flexible, and creative project teams. Very heavy client involvement is essential. When you are venturing into the great unknown, you won't get very far unless an expert is standing at your side.

What do you do if what is needed is not clearly defined? What if it isn't defined at all? Many have tried to force-fit the traditional approach into these situations, and it flat-out doesn't work. xPM is designed to handle projects whose goal can only be fuzzily defined or really not defined at all. Building a business-to-business (B2B) web site with no further specification is an excellent example. Much like the early stages of an R & D project, building the B2B web site starts out with a guess, or maybe several guesses. As the project commences, the client reflects upon the alternatives chosen and gives some direction to the development team. This process repeats itself. Either the partial solution converges on a satisfactory solution, or it is killed along the way. In most cases, there is no fixed budget or timeline. Obviously, the client wants it completed ASAP for as little as possible. Furthermore, the lack of a clear goal and solution exposes the project to a lot of change. Unfortunately, the nature of this project does not lend itself to fixed time and cost constraints.

Chapter 12 defines the xPM project and provides a detailed view of the phases that constitute the xPM PMLC model.

The xPM Project Is a Research and Development Project

The goal of an R & D project may be little more than a guess at a desired end state. Whether it is achievable and to what specificity are questions to be answered by doing the project. In this type of xPM project, you are trying to establish some future state through some enabling solution. Because you don't know what the final solution will be, you cannot possibly know what the goal will be. The hope is that the goal can be achieved with a solution and that the two together deliver acceptable business value.

The xPM Project Is Very High Risk

Any journey into the great unknown is fraught with risk. In the case of an xPM project, it is the risk of project failure and that is very high. Even if the goal is achieved, the cost of the solution may be prohibitive. The direction chosen to find the solution may be the wrong direction entirely and can only result in failure. If the project management process can detect that early, it will save money and time.

Failure is difficult to define in an xPM project. For example, the project may not solve the original problem, but it may deliver a product that has uses elsewhere. The 3M Post-It Note Project is one such example. Nearly 7 years after the project to develop an adhesive with certain temporary sticking properties failed (that was an xPM project), an engineer discovered an application that resulted in the Post-It Note product (that was an MPx project).

xPM extends to the remotest boundaries of the project landscape. xPM projects are those projects whose goal and solution cannot be clearly defined. For example, R & D projects are xPM projects. What little planning is done is done just in time, and the project proceeds through several phases until it converges on an acceptable goal and solution. Clearly the PMLC for an xPM project requires maximum flexibility for the project team, in contrast to the PMLC for a TPM project, which requires adherence to a defined process. If instead, there isn't any prospect of goal and solution convergence, the client may pull the plug and cancel the project at any time and save the remaining resources for alternative approaches.

If goal clarity is not possible at the beginning of the project, the situation is much like a pure R & D project. Now how would you proceed? In this case, you use an approach that clarifies the goal and contributes to the solution at the same time. The approach must embrace a number of concurrent Probative Swim Lanes. Concurrent Probative Swim Lanes might be the most likely ones that can accomplish goal clarification and the solution set at the same time. Depending on time, budget, and staff resources, these probes might be pursued sequentially or concurrently. Alternatively, the probes might eliminate and narrow the domain of feasible goal/solution pairs. Clearly, xPM projects are an entirely different class of projects and require a different approach to be successful.

The goal is often not much more than a guess at a desired end state with the hope that a solution to achieve it can be found. In most cases, some modified version of the goal statement is achieved. In other words, the goal and the solution converge on something that hopefully has business value. Chapter 12 provides much more detail.

In addition to a goal and solution where neither one are clearly defined, projects that correctly fall into xPM have several identifying characteristics as briefly identified in the sections that follow.

The Extreme Model

The Extreme PMLC model is shown in Figure 2-7. By its very nature, xPM is unstructured. It is designed to handle projects with “fuzzy goals” or goals that cannot be defined because of the exploratory nature of the extreme project. The theme here is that the learning and discovery take place between the client and the development team in each phase, thus moving the project forward. Note that the major difference between APM and xPM PMLC models is the use of the Scope Process Group. In an APM project, scope is done once at the beginning of the project. That flows mostly from the fact that the goal is clearly defined. In the xPM project, scope is adjusted at each phase. That follows from the fact that the goal can change.

Figure 2-7: Extreme PMLC model

Similar to APM PMLC models, the Extreme PMLC model is iterative. It iterates in an unspecified number of short phases (1- to 4-week phase lengths are typical) in search of the solution (and the goal). It may find an acceptable solution, or it may be cancelled before any solution is reached. It is distinguished from APM in that the goal is unknown, or, at most, 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 experienced project managers — they have heard this many times before. Nevertheless, it is their job to find the solution (with the client's help, of course).

xPM is further distinguished from APM in that xPM requires the client to be more involved within and between phases. In many xPM projects, the client takes a leadership position instead of the collaborative position they took in APM projects. Drug research provides a good example. Suppose, for example, that the goal is to find a natural food additive that will eliminate the common cold. This is a wide-open project. Constraining the project to a fixed budget or fixed timeline 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, xPM includes learning and discovery experiences just as APM does.
• Most important of all is that the funding agent will see this learning and discovery as potentially rewarding and will decide to continue the funding support.

There is no constraining scope triangle in xPM as there is in TPM and APM projects. Recall that TPM and APM projects have time and funding constraints that were 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. xPM does have stopping rules, but they are very different. An xPM project stops when one of the following occurs:

• The project is over when a solution and the goal it supports are found and they both make business sense. Success!
• 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 or is not converging on an acceptable solution. In other words, the project is killed. Failure! But all is not over. It is common to restart such projects but to search for a solution in a different direction.

Emertxe Project Management Life Cycle Model

The solution is known, but the goal is not. Don't be tempted to dismiss this as the ranting of professional service firms who have the answer to your problem. They are out there, and you probably know who they are. All you have to do is state your problem, and they will come to your rescue armed with their solution! That is not where I am going with this discussion.

MPx projects are a type of R & D project but in reverse. When you think of an R & D project, you think of some desired end state and the project has to figure out if and how that end state might be reached. In so doing, it might be necessary to modify the end state. So for the MPx project, you reverse the R & D situation. You have some type of solution, but you have not yet discovered an application for that solution (unknown goal). You hope to find an application that can be achieved through some modification of the solution. You are successful if the application has business value.

Figure 2-7 works for both the xPM and MPx project.

Note here that each phase is a complete project in its own right. Scoping starts each phase, and the decision to begin another phase ends the current phase. In an MPx project, phase and project are basically identical.

These approaches are for MPx projects whose solution is completely and clearly defined but whose goal is not. This sounds like nonsense, but actually it isn't. (Just trust me for now — I'll return to this approach in Chapter 12.) I find it easiest to think of these projects as a backwards version of an extreme project, hence the name “Emertxe” (pronounced a-mert-see). The solution or a variant of it is used to help converge on a goal that it can support and that hopefully delivers acceptable business value. So rather than looking for a solution as in the xPM project, you are looking for a goal. The PMLCs for both xPM and MPx projects have a lot in common, so they are discussed together in Chapter 12.

You have the solution; now all you need is to find the problem it solves. This is the stuff that academic articles are often made of, but that's okay. It's a type of R & D project but in reverse. Post your solution and hope somebody responds with a problem that fits it. It has happened. Take the 3M Post-It Note saga, for example. The product sat on the shelf for several years before someone stumbled onto an application. The rest is history. Major drug research firms encounter these projects often.

In addition to a goal that is not clearly defined and solution that is clearly defined, projects that correctly fall into the MPx category have several identifying characteristics as briefly identified in the sections that follow.

A New Technology without a Known Application

I'm reminded of the Radio Frequency Identification (RFID) technology for reading coded information embedded in an object as it moved down a conveyor belt and routing the object to a destination based on the encoded information found. When RFID was first announced, several warehouse applications came to mind. One of the largest retailers in the world commissioned a project team to find applications for RFID in their logistics and supply chain management systems. The technology was only about 70 percent accurate at the time, and the team concluded that it would have good business value if only the accuracy could be significantly improved. That has since happened, and RFID is now commonly used in warehousing and distribution operations.

A Solution out Looking for a Problem to Solve

Commercial off-the-shelf application software provides several examples of these situations. For example, say a new human resource management system (HRMS) has just been introduced to the commercial software market by a major software manufacturer. Your project is to evaluate it for possible fit in the new HRMS design that has just been approved by your senior management team. Among all MPx projects, this example is the simplest case. You already know the application area. What you need to find out is the degree of fit and business value. At the other extreme would be to have something whose application is not known. A juice taken from the root of some strange Amazon tree would be an example of a more complex situation. The project is to find an application for the juice that has sufficient business value.

Recap of PMLC Models

The five PMLC models bear a closer look and comparison. If you have been counting, you expected to see six PMLC models. Because the xPM PMLC and MPx PMLC models are identical, there are really only five distinct PMLC models. Figure 2-8 gives you that view.

Figure 2-8: The five PMLC models

There is a very simple and intuitive pattern across the life cycle when viewed at the process group level. A note on terminology before I proceed. In the APM and xPM approaches, I use the terms iteration, cycle, and phase to distinguish between the Iterative, Adaptive, and Extreme model types, respectively. I'll need that later on in the discussion to clarify what I am referring to. To reinforce your understanding of the PMLC models, I want to point out their similarities and differences.

Similarities between the PMLC Models

Their similarities are as follows:

• All five process groups are used in each PMLC model.
• Each PMLC model begins with a Scope Process Group.
• Each PMLC model ends with a Close Process Group.

Differences between the PMLC Models

Their differences are evident when viewed from the degree of solution uncertainty, as follows:

• The models form a natural ordering (Linear, Incremental, Iterative, Adaptive, Extreme) by degree of solution uncertainty.
• The processes that form repetitive groups recognize the effect of increasing uncertainty as you traverse the natural ordering. Those groups move more towards the beginning of the life cycle as uncertainty increases.
• Complete project planning is replaced by just-in-time project planning as the degree of uncertainty increases.
• Risk management becomes more significant as the degree of solution uncertainty increases.
• The need for meaningful client involvement increases as the degree of solution uncertainty increases.