Extreme Project Management Life Cycle

,

The Extreme PMLC model is the most complex of the five major models in the project management landscape. Figure 12-1 is a graphical representation of the Extreme PMLC model. The first thing to note about the model is that the phases repeat all Process Groups in a linear fashion. (I call these phases in this model to distinguish them from increments, iterations, and cycles used in the models discussed earlier in the book.) If the decision is made to go to the next phase, that phase begins with the scoping of the changed direction for the project. The reason for this is that the just-completed phase may suggest that the solution can be found by taking the project in an entirely different direction than originally planned. By repeating the Scoping Phase, you may find that the goal may change due to the new direction the project will take.

Figure 12-1: Extreme PMLC model

Definition

Extreme PMLC models consist of a sequence of repeated phases with each phase based on a very limited understanding of the goal and solution. Each phase learns from the preceding ones and redirects the next phase in an attempt to converge on an acceptable goal and solution. At the discretion of the client, a phase may release a partial solution. A phase consists of the five Process Groups, each performed once in the sequence Scoping Planning Launching Monitoring and Controlling Closing. In effect, a phase is a complete project life cycle much as it is in the Incremental PMLC model, but with an option to release a partial solution at the completion of each phase.

The following section gives a high-level overview of the four components that constitute the INSPIRE Extreme PMLC model. As such, it is a good starting point for the executive or manager who simply needs to become familiar with the xPM approach.

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

INSPIRE Extreme PMLC Model

By its very nature, an xPM project is unstructured (see Figure 12-2). 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-2 illustrates, INSPIRE consists of four stages, which I am calling INitiate, SPeculate, Incubate, and REview (hence the acronym INSPIRE). The Launching Phase occurs between SPeculate and Incubate, where the normal activities described in Chapter 2 are conducted. Similarly, the Closing Phase occurs between Incubate and Review, and the same activities described in Chapter 2 are conducted.

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

Figure 12-2: The INSPIRE Extreme PMLC model

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-3 is the 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.

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

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 five variables in any project are as follows:

• Scope
• Quality
• Cost
• Time
• Resource availability

In Chapter 11, you saw the scope triangle ranking matrix (see Table 11-4). It showed 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 Conditions of Satisfaction (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.

Scenarios, Stories, and Use Cases

The technical perfectionist would probably define these terms as different from one another, but for the purposes this discussion, they are the same. All three can be defined as descriptions of how an end user might use the application. Because the application may be feature-rich, there usually will be several such descriptions. If done correctly, these descriptions will be comprehensive regarding how the application can be used. The descriptions can then be prioritized and assigned to the appropriate development phases. There is no practical limit to the number of such situations that are documented. In the case of technology projects, such as website development, the client may be more comfortable telling you how they envision someone using the deliverable and what they can do at the website than they would be trying to help you write a functional specification or generate the Requirements Breakdown Structure (RBS). The advantage in using scenarios, stories, and use cases is that the view you are building is from the end user's perspective, not from the technology perspective. That will raise the client's comfort level because they are on familiar ground during the exercise.

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:

• There can be a great number of items in the collection, so approaches like Forced Ranking are not practical. Forced Ranking doesn't scale very well. 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 the chapter 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 cancelled. APF and INSPIRE share this go/no-go decision point at the completion of each phase. APF is less likely to result in a cancellation, because so much more is known about the solution. Conversely, INSPIRE is so exploratory and research-based that cancellations 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.