Effective Project Management Traditional, Adaptive, Extreme phần 8 pdf

Develop Conditions of Satisfaction Prioritize Functional Requirements & Develop Mid-Level WBS Write Project Overview Statement Prioritize Scope Triangle Develop Next Cycle Build Plan CYC

As you will see, this introspection with client and project team fully engaged

is a very thorough process If properly done, it is unlikely that anything icant will be missed Figure 17.1 is a graphical display of the Client Checkpointphase

signif-Figure 17.1 Client Checkpoint phase.

Develop Conditions of Satisfaction

Prioritize Functional Requirements

&

Develop Mid-Level WBS

Write Project Overview Statement

Prioritize Scope Triangle

Develop Next Cycle Build Plan

CYCLE PLAN VERSION SCOPE

Schedule Cycle Build

Build Cycle Functionality

Monitor/Adjust Cycle Build

Conduct Quality Review with Client

Review the Version Results

Inputs to the Client Checkpoint

The following lists the inputs to the Client Checkpoint phase:

■■ Planned versus actual functionality added

■■ Scope Bank

Planned versus Actual Functionality Added

For the cycle just completed, the cycle plan called for a specific list of ality to be added to the deliverables No changes were made during the cycle,

function-so it is possible that not all the planned functionality actually made it into thedeliverables There are several reasons for that, which we will not discuss; theyare obvious (schedule slippages that could not be recovered, a discovery thatrendered the functionality unnecessary) Any functionality not completed inthe just completed cycle will be prioritized along with this cycle’s functional-ity and any adjustments made in the cycle plan going forward

Scope Bank

First discussed in Chapter 16, the Scope Bank is the cumulative depository of all

the ideas and proposed changes that were generated during all previous cyclesand have not yet been acted upon Some of them were incorporated in previous cycles and are no longer in the Scope Bank, and some were not incor-porated and are still in the Scope Bank In any case, the current contents are all

of the items not previously acted upon There may be cases where any ideassuggested earlier that had not been incorporated may now be viable That isthe reason the Scope Bank is cumulative

NOTE

The only time anything is deleted from the Scope Bank is when it is incorporated into the solution.

Questions to Be Answered during Client Checkpoint

The following is a list of the questions to be answered during the Client point phase:

Check-■■ What was planned?

■■ What was done?

Client Checkpoint 319

■■ Is the version scope still valid?

■■ Is the team working as expected?

■■ What was learned?

What Was Planned?

The answer to this question is nothing more than a list of the objectives andfunctionality that were planned to be completed during the previous cycle

What Was Done?

This answer is nothing more than a checkoff of the objectives and ity completed There are often comments accompanying the checkoff becausesome items may not have been completed as planned Subfunctions may havebeen left undone, and there may be good reasons for it In such cases, the ScopeBank should reflect the situation

functional-Again, the only questions to be answered here are these: Did the cycle meet itsobjectives? Did the cycle meet its planned functional specifications? If no,where are the variances? The answers will provide input into planning for theobjectives of the next cycle and the functionality to be built in the next cycle.Remember, we already specified objectives and functionality for the next cycle

in the Version Scope phase So we have the original scope and potentialrevised scope to consider as we consider what the next cycle will contain

NOTE

TPM defines a formal change management process that can be invoked at any time

in the project In APF the change process is imbedded in the client checkpoint The only changes that are accommodated in APF occur between cycles No changes to scope are incorporated within an ongoing cycle.

Is the Version Scope Still Valid?

Armed with the information discussed in the previous two sections, we nowcan ask a very basic question: “Is the version scope still valid?” If yes, we are

on the right track If not, we need to revise accordingly Revisions to versionscope can be significant In some cases revisions may be so significant that thecorrect business decision is to kill the current project, go back to the drawingboard, and start over again You can see that the cost of killing an APF projectwill always be less than the cost of killing a TPM project The reason is thatTPM spends money and time on functionality that may not remain in the solu-tion APF, on the other hand, almost guarantees that all functionality that is

built will remain in the application Further to the point, TPM projects areoften killed, if at all, very late in the game when all the money is spent APFprojects are killed at a point where it becomes obvious that the solution willnot be acceptable That will generally happen while there is still money andtime left in the budget.

Is the Team Working as Expected?

Real teamwork is a critical success factor in APF A lot of worker ment is threaded throughout APF If you count the frequency of the use of the

empower-word I as compared to the use of the empower-word we, you will have a pretty good

metric for measuring team strength The formula would be as follows:

Team Strength = number of We’s/(number of I’s plus number of We’s)

You would like to see this number hovering around 1 The APF team needs towork in an open and honest environment for this to happen That means thatevery team member must be forthright in stating the actual status of their proj-ect work To do otherwise would be to violate the trust that must exist amongteam members The project manager must ensure that the working environ-ment on the project is such that team members are not afraid to raise theirhand, say they are having trouble, and ask for help To do otherwise would be

to let the teammates down

What Was Learned?

This question is perhaps the most important one of all Here is where theprocess will be reviewed to provide more value to the client The new ideasthat are generated here could not have come about through the TPM approach.This point in the process is where APF (and xPM, in all fairness) really shine.Both APF and xPM take their value from learning by doing

Adjusting Functionality for the Next Cycle Plan

Once the answers have been given to the preceding questions, it is time for theclient and the project team to look forward to the next cycle The inputs to thenext cycle planning activity are as follows:

■■ Any functionality completed during the previous cycle

■■ Any functionality planned but not completed in the previous cycle

■■ The functionality planned for this cycle

■■ The functionality planned for all the cycles beyond the next one

Client Checkpoint 321

■■ All learning and discovery that took place in all previous cycles (ScopeBank)

■■ Any items still remaining on the Issues Log

■■ Any changes that took place in the business environment during the previous cycles

From these inputs, you generate the following outputs from the Client point phase:

Check-■■ Updated functionality list

■■ Reprioritized functionality list

■■ Next cycle length

Updated Functionality List

We started this whole process with the Conditions of Satisfaction, and it is tothe COS that we now return The only question to be answered here is this: Arethe COS still valid? If yes, continue on If not, revise accordingly These revisions are the planned functionality for the next cycle

The client and the team should spend most of a day in frank and honest versation, considering all of these factors and then agreeing on the functional-ity that will be planned for the next cycle Do not underestimate the value thatcan come from the sharing of learning and discovery That will be your mostimportant information because it really helps both parties understand whatthis solution is really all about and what should be offered as a final solution.This part of the process is no trivial task

con-Reprioritized Functionality List

The process that was used in the first cycle to prioritize functionality can berepeated here The criterion that was used to determine the priority may be thesame or different Again, take advantage of all the learning and discovery fromthe previous cycles

Next Cycle Length

The initial estimates of functionality duration for those functions planned forthe next cycle may require a change in cycle length Remember to be true to theoverall timebox for the version That cannot be adjusted

See Chapter 14 for a more detailed discussion on prioritizing functionality and ing with cycle length and timebox constraints in APF.

work-Putting It All Together

In this chapter we have tried to give you an understanding of how importantthe Client Checkpoint phase is to the success of an APF project As we havealready discussed, APF embraces change, and it is through change that we canconverge on a solution that delivers maximum business value for the time andmoney invested All of the change that occurs in APF occurs in the ClientCheckpoint phase There is no separate change management process as there

is in the traditional approach Make the Client Checkpoint phase the high spot

of your APF experience and you won’t go wrong The Client Checkpoint phase

is the last phase in a loop that returns back to the Cycle Plan phase The loopcycle plan–cycle build–client checkpoint repeats itself for as many cycles ashave been planned within the version timebox

In the next chapter, we look at closing the version project with the post-versionreview

Discussion Questions

1 A member of your team is a systems analyst from the old school and justcannot adjust to APF Her problem is that the client has decision-makingauthority over the direction that your software development project istaking and the client is, shall we say, technically challenged How wouldyou handle this dilemma?

2 You are the project manager over one of your company’s first APF projects You are having trouble getting the client’s involvement Whatwould you do?

Client Checkpoint 323

Installing Custom Controls 325

Just as the traditionalist conducts a post-implementation audit at the end of the

project, so also does the APFist conduct a post-version review at the end of thecurrent version (see Figure 18.1) There are a number of similarities between apost-implementation audit and a post-version review, but there are differ-ences, too The traditionalist is looking for final closure on the project, whilethe APFist is looking for ways to further increase the business value of thesolution In other words, the APFist is never looking for final closure; instead,

he or she is always looking for more business value The version just pleted is just another step toward increasing business value In that sense, APF

com-is quite like the production prototype because it conscom-ists of a never-endingcycle of repeated solution improvements The only ending that is ever encoun-tered is to retire the solution altogether

18

Chapter Learning Objectives

After reading this chapter, you will be able to:

◆ Explain the significance of the post-version review

◆ Describe the deliverables from a post-version review

◆ Conduct a post-version review

◆ Extract lessons learned from the version project

Figure 18.1 Post-Version Review phase.

Let’s look at the series of actions that take place in the APF post-versionreview

Checking Explicit Business Outcomes

The project was justified on the basis of explicit business value as defined byspecific business outcomes The Post-Version Review phase is the time tocheck to see if the project has achieved these outcomes Oftentimes, however,these outcomes cannot be measured until weeks, months, or even quartershave passed since the version was put into production status and the successcriteria can be measured This part of the review is no different than in the

Develop Conditions of Satisfaction

Prioritize Functional Requirements

&

Develop Mid-Level WBS

Write Project Overview Statement

Prioritize Scope Triangle

Develop Next Cycle Build Plan

CYCLE PLAN VERSION SCOPE

Schedule Cycle Build

Build Cycle Functionality

Monitor/Adjust Cycle Build

Conduct Quality Review with Client

Review the Version Results

Lessons Learned to Improve APF

traditional approach The project has finished, and the team will be disbandedfor reassignment to other projects Waiting on the validation of a business out-come is related to the business reason for doing the project and in no wayaffects the team Depending on that business outcome, another project focused

on the same application may be commissioned and a new team assembled to

be a next version This information is the major input to the Version Scopephase for the next version The analysis of this information will be the majorpart of the business validation of that next version

Assessing APF for Improvements

So far, the lessons learned have focused on the solution (that is, the product) ofthe just completed version The other type of lessons learned focuses on theprocess that was followed to create the solution and asks such questions as

“How well did APF work?” and “How well did the client and the team followAPF?” In answering these questions, the client and the team offer suggestionsfor improvement of the process and the practice of the process As you can see,APF has a built-in continuous quality improvement process

Putting It All Together

Clearly, the post-version review is focused on the business value of what wasjust completed and on the business value of any future versions that might fol-low, which is as it should be A guiding principle of APF is to deliver maxi-mum business value We have shown how this applies to a critique of thesolution just delivered and to a preparation for any version that might follow

In the next chapter, the final chapter in Part II, we consider some variationsthat might be encountered and how APF can be adapted to fit

Post-Version Review 327

3 What situations might you envision in which APF would be a betterchoice than TPM for the Jack Neift Trucking Company (see the case study

in the Introduction)? Be specific

Installing Custom Controls 329

Variations to APF

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.

—Estill I Green, VP, Bell Telephone Laboratories

An eXtreme project is a complex, self-correcting venture

in search of a desired result.

—Doug DeCarlo

C H A P T E R

329

As its name states, APF is adaptive We have seen that in several ways:

■■ Specifying the number of cycles

■■ Determining cycle length

■■ Changing functionality priorities at each client checkpoint

■■ Building in changes (add new, modify existing, or delete) in functionality

at each client checkpoint

19

Chapter Learning Objectives

After reading this chapter, you will be able to:

◆ Use APF for proof of concept

◆ Adapt APF to revise the version plan

◆ Identify an extreme project

◆ Describe the four phases of the extreme project management approach

◆ Understand how extreme project management clarifies the goal and verges to a solution

con-We have also seen how APF not only anticipates these adaptations but alsoexpects them However, APF is far more adaptable than even the situations inthe preceding list indicate There are three other adaptations that we want you

to be aware of, and these are the topic of this short chapter The first two arebrief topics and demonstrate how APF can be used as a proof-of-concept tooland in revising the version plan These are discussed first Then we draw acomparison between APF and extreme project management (xPM) The twoare closely related approaches to managing projects when the solution is notknown (APF) and when neither the solution nor the goal is known (xPM)

NOTE

You will probably find other reasons to adapt APF Feel free to do that APF is not a rigid structure to be followed without question For us, the bottom line has always been to do what is right for the client If that flies in the face of some established process or procedure, you need to take a serious look at the process or procedure

It may not be serving your needs.

Proof-of-Concept Cycle

There will be situations where the business case has not been sufficiently made

to get approval to build the first version In much the same way we have usedprototyping to help with client definition of functionality, we can use the sameconcept in the first cycle by making the first cycle of APF a proof-of-conceptcycle That proof of concept could entail any of the following:

■■ The creation of a prototype

to strike quickly while the iron is hot

Revising the Version Plan

There will be situations where the initial version scope misses the mark Youwill see evidence of this via a significant number of discoveries and lessonslearned coming in the first few cycles These discoveries and lessons can create

a big disconnect between the original direction of the project and the correctedone that is now indicated In other words, continuing on the course suggested

by the current version scope is a waste of time and money Remember that youbuilt a mid-level WBS and are making your cycle plans around that WBS Toomany changes brought on by learning and discovery may render much of theWBS out of sync The need to revise the version plan is clearly a subjectivedecision We would err on the side of revision rather than sticking with a planthat may be heading in the wrong direction The APFist is hard-pressed to doanything that may be a waste of the client’s time or money The APFist wouldconclude that the plan is off course and should be abandoned immediately.The correct action is to revise (or even replace) the current version plan andbasically start over

NOTE

At this early point in the project, do not be afraid to kill the plan In almost every case we can think of, you will be making the correct decision.

Extreme Project Management

The third variation that we will discuss is extreme project management xPMand APF both originated at about the same time, so it is difficult to say which

is a variation of the other from a chronological point of view In any case, xPMhandles the situation where the goal is not clearly defined and therefore thesolution cannot be defined either On the continuum of project managementapproaches, the traditional approach occupies the structured end, where there

is the most clarity with respect to both the goal and the solution xPM is at theunstructured end, where there is the least clarity with respect to the goal andthe solution APF occupies the middle ground

This section defines the extreme project and gives a high-level overview of thefour phases that constitute the xPM approach As such, it is a good startingpoint for the executive or manager who simply needs to become familiar withthe xPM approach

Variations to AP F 331

Defining an Extreme Project

The best way to define an extreme project is to consider its characteristics,which are discussed in the following list:

High speed. The types of projects that are suited to xPM are ground ing, innovative, critical to an organization’s future, and otherwise veryimportant to their sponsors That means that the results are wanted ASAP.Fast is good, and you will be around tomorrow to talk about it Slow isbad, and you will be looking for something else to do with the rest of yourlife Time, or faster, to market is a critical success factor in every extremeproject business endeavor

break-High change. The uncertainty about the goal or the solution means that asthe project is underway, learning and discovery, just as in APF projects,will happen It will happen with more regularity and frequency in xPMthan in APF projects The APF changes can be thought of as minor in com-parison The changes in an extreme project may completely reverse thedirection of the project We can envision cases where the changes might be

to cancel the current project and start two or more projects based on thelearning and discovery to date with the now cancelled project For exam-ple, R&D projects are extreme projects, and a discovery in one cycle maycause the team and the client to move in a totally different direction in thenext and later cycles

High uncertainty. Because an extreme project is innovative and oriented, no one really knows what lies ahead The direction chosen by theclient and the project team might be 180 degrees out of phase with whatthey should be doing, but no one knows that Furthermore, the time tocomplete the extreme project is not known The cost to complete anextreme project is not known either There will be a lot of trial and error.There will be a lot of false starts and killed projects

research-These characteristics will strike fear into the hearts of most, if not all, projectmanagers Make no mistake, extreme projects are extremely challenging Theirfailure rate will be high Many will be cancelled before they are completed Forthose that are successful, what they deliver may not at all reflect what theythought they would deliver In other words, the actual goal achieved may bequite different than the goal that was originally envisioned That is the nature

of extreme projects, and that is where we begin our investigation of how xPMapplies to them

Overview of Extreme Project Management

By its very nature, xPM is unstructured xPM (see Figure 19.1) and APF areboth variations of the same theme The theme is that learning and discoverymoves the project forward The idea is an adaptation of the Flexible ProjectModel introduced in 2000 by Doug DeCarlo in his eXtreme Project Manage-ment Workshop Recall that the difference between xPM and APF is that APFrequires a clearly defined goal, whereas xPM does not As Figure 19.1 illus-

trates, xPM consists of four phases that we are calling INitiate, SPeculate,

I ncubate, and REview (INSPIRE).

xPM is an iterative approach just as APF is an iterative approach xPM iterates

in an unspecified number of short cycles (1- to 4-week cycle lengths are typical) in search of the solution (in other words, the goal) It may find anacceptable solution, or it may be cancelled before any solution is reached It isdistinguished from APF in that the goal is unknown, or at most, someone has

a vague, but unspecified, notion of what the goal consists Such a client mightsay: “I’ll know it when I see it.” That isn’t a new revelation to the experiencedproject manager; they have heard that many times before Nevertheless, it istheir job to find the solution (with the client’s help, of course)

Figure 19.1 Extreme project management

APF is further distinguished from xPM in that xPM requires the client to bemore involved within and between cycles, whereas APF requires clientinvolvement between cycles Drug research provides a good example of theextreme project Suppose, for example, that the goal is to find a natural foodadditive that will eliminate the common cold This is a wide-open project.Constraining the project to a fixed budget or fixed time line makes no sensewhatsoever More than likely the project team will begin by choosing someinvestigative direction or directions and hope that intermediate findings andresults will do two things:

■■ That the just finished cycle will point to a more informed and productivedirection for the next and future cycles In other words, xPM includeslearning and discovery experiences just as APF does

■■ Most important of all, that the funding agent will see this learning anddiscovery as potentially rewarding and will decide to continue the fund-ing support

There is no constrained scope triangle in xPM as there is in TPM and APF projects Recall that those TPM and APF projects have time and funding constraints that were meaningful “Put a man on the moon and return himsafely by the end of the decade” is pretty specific It has a built-in stoppingrule When the money or the time runs out, the project is over xPM does havestopping rules, but they are very different There are two stopping rules

in xPM:

■■ The first one says that the project is over when the solution is found Success!

■■ The second one says the project is over when the sponsor is not willing tocontinue the funding The sponsor might withdraw the funding becausethe project is not making any meaningful progress It is not converging on

an acceptable solution In other words, the project is killed Failure!

The next sections take a high-level look at the four phases of xPM

INitiate

The INitiate phase is a mixture of selling the idea, establishing the businessvalue of the project, brainstorming possible approaches, forming the team,and getting everyone on board and excited about what they are about toundertake It is definitely a time for team building and creating a strong work-ing relationship with the client

Someone has an idea for a product or service and is proposing that a project becommissioned 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 demon-strate that there is business value in the undertaking The Project OverviewStatement (POS), which we used in both TPM and APF, is the documentation

we are recommending to sell the idea There are some differences in the xPMversion of the POS

Defining the Project Goal

Unlike the goal of an APF project, the goal of an extreme project is not muchmore than a vision of some future state “I’ll know it when I see it” is about theonly statement of the project goal that could be made, given the vague nature

of the project goal as envisioned at this point in time It has all the tics of an adventure where the destination is only vaguely defined You have

characteris-to understand that the goal of an extreme project unfolds along the journey It

is not something that you can plan to achieve; it is only something that youand the client discover along the way That process of discovery is exciting Itwill call upon all of the creative juices that the team and the client can muster.Contrast this to the project goal in an APF project In APF, the goal is known;it’s the solution that evolves as the project unfolds In general, the client is themore directive in xPM, while the team is more directive in APF

At this early stage, any definition of the project goal should be that vision ofthe future It would be good at this point to discuss how the user or customer

of the deliverables will use the product or service Don’t be too restrictive,either Keep your options open—or keep your powder dry, as one of mycolleagues would say Forming a vision of the end state is as much a brain-storming exercise as it is anything else Don’t close out any ideas that mayprove useful later on

xPM 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 Project Overview Statement

is a critical document in both the TPM and APF approaches, and so it is again

in xPM projects However, because the goal was known in both TPM and APFprojects but is not known in xPM projects, there will be some differences in thePOS These differences are best illustrated by way of example Figure 19.2 isthe POS for the project to find a cure for the common cold

Variations to AP F 335

Figure 19.2 POS for the project to find a cure for the common cold.

The following bulleted list looks at each of the elements of this xPM POS toillustrate the differences between this sort of POS and that used in a TPM orAPF approach

Problem or opportunity statement. Nothing unusual here This is a verysimple statement of a problem that has plagued health care providers andmoms since the dawn of civilization

Goal statement. This particular project is taking a calculated (or maybe wilda**) guess that they can establish a preventative barrier to the occurrence of

PROJECT OVERVIEW STATEMENT

Project Name Common Cold Prevention Project

Project No.

02 - 01

Project Manager Carrie deCure

Prepared By Earnest Effort

Date 2-14-2003

Date 2-16-2003 Approved By

Hy Podermick

Problem/Opportunity There does not exist a preventative for the common cold.

Goal Find a way to prevent the occurrence of the common cold.

Objectives

1 Find a food additive that will prevent the occurrence of the common cold.

Success Criteria The solution must be effective for persons of any age.

The solution must not introduce any harmful side effects.

Assumptions, Risks, Obstacles The common cold can be prevented.

The solution will have harmful side effects.

The solution must be affordable.

The solution must be acceptable to the FDA.

The solution must be easily obtained.

The solution must create a profitable business oppurtunity.

3 Define a program of diet and excercise that will prevent the occurrence of the common cold.

2 Alter the immune system to prevent the occurrence of the common cold.

the common cold Unlike the goal statements in TPM and APF projects,there is no timeframe specified That would make no sense for such aresearch project.

Objective statements. These objective statements identify broad directionsthat the research effort will take Notice that the format does not fit theS.M.A.R.T characteristics defined in Chapter 3 In most cases, these objec-tive statements will provide some early guidance on the directions the teamintends to pursue Unlike TPM and APF projects, these objective statementsare not a necessary and sufficient set of objectives Their successful comple-tion does not assure goal attainment In fact, some of them may be dis-carded based on learning and discovery in early cycles Think of them asguideposts only They set an initial direction for the project Because thegoal is not clearly defined, you can’t expect the objective statements to playthe role that they do in TPM and APF projects

Success criteria. The goal statement might do just as well as any successcriteria, and so this part of the POS could be left blank In this case we haveset bounds around the characteristics of an acceptable cure

Assumptions, risks, and obstacles. There is no difference between xPM,TPM, and APF when it comes to this section The statements given in theexample lean heavily toward assumptions Having to make such assump-tions happens to be the nature of this project

Establishing a Project Timebox and Cost

Contrary to an APF project, an extreme project is not constrained by a fixedtimeframe or cost limit It is best to think of the xPM time and cost parameters

as something to give the project team guidance on what the client expectationsare It is much like having the client say: “I would like to see some resultswithin X months, and I am willing to invest as much as $Y to have youdeliver.” The reality is that at each REview phase, the decision to continue orabort is made That decision isn’t necessarily tied to the time and cost parame-ters given earlier by the client In fact, if there is exceptional progress toward asolution, the client may relax either or both of the time and cost parameters.Put another way, if the progress to date is promising, more time and/or moneymay be put at the team’s disposal

Establishing the Number of Cycles and Cycle Length

In the beginning, short cycles are advisable In the early cycles, new ideas aretested, and many will be rejected; proof of concept may be part of the first fewcycles The team should not be committing to complex activities and tasksearly on As the team gains a better sense of direction, cycle length may beincreased Specifying cycle length and the number of cycles up front merely

Variations to AP F 337

sets expectations as to when and how frequently the REview phase will takeplace At each occurrence of a REview phase, cycle length and perhaps thenumber of cycles remaining may be changed to suit the situation In anexploratory project, it would be a mistake to bind the team and the client tocycles that do not relate to the realities of the project Remember that flexibility

is the key to a successful xPM project

Trade-Offs in the Scope Triangle

Despite the fact that xPM is unstructured, it is important that the priorities ofthe variables in the scope triangle be set As project work commences andproblems arise, which variable or variables are the client and the team willing

to compromise? As is discussed in Chapter 1, the five variables in a project are

be the first to be compromised But what if you knew that a competitor wasworking on the same project? Would time still be the first variable to compro-mise? Probably not Cost might take its place because time to market is now acritical success factor

Scope is an interesting variable in extreme projects Consider the common coldcure example again Hypothetically, what if you knew that the competitionwas also looking for a cure for the common cold and that being first to marketwould be very important In an earlier cycle, the team discovered not a cure forthe cold but a food additive that arrests the cold at whatever stage of develop-ment it happens to be In other words, the cold will not get worse than it was

at the time the additive was taken The early discovery also holds greatpromise to morph into the cure that you are looking for, but you need time toexplore it You feel that getting the early result to market now may give you astrategic barrier to entry, give the competition reason to pause, and buy yousome time to continue toward the original goal And so, scope is reduced in thecurrent project and the project brought to a successful completion A new proj-ect is commissioned to continue on the path discovered in the earlier project

This phase defines the beginning of a new cycle and will always start with abrainstorming session The input will either be a blank slate or output from theprevious SPeculate-Incubate-REview cycle In any case, the project team,client, and final user of the product or service should participate in the brain-storming session The objective of this session is to explore ideas and identifyalternative directions for the next Incubate phase Because an extreme projecthas a strong exploratory nature about it, no idea should be neglected Severaldirections may eventually be pursued in parallel in the next cycle Cyclelength, deliverables, and other planning artifacts are defined in the SPeculatephase as well

The word speculate conjures up deep thinking, carrying out due diligence on

several alternatives, the choosing of one or more of those alternatives, andthen simply taking your chances You should hear yourself saying, “I wonder

if this would work?” That is what the SPeculate phase of xPM is all about

Defining How the Project Will Be Done

The initial sense of direction for the team to take in the first cycle of an extremeproject can vary considerably A good approach is to use the POS objectivestatements as a guide The POS can continuously be updated to reflect the cur-rent view of the project, and its objective statements can serve as a guide towhat will be done In later cycles, the team and the client will have the benefit

of learning and discovery from the prior cycles For the sake of discussion, let’streat those two situations separately In this section of the chapter, assume youare planning the first cycle In some of the following sections, you will look atthe SPeculate phase for the second and subsequent cycles

Conditions of Satisfaction

We discussed the Conditions of Satisfaction in detail in Chapter 3 and will notrepeat that discussion here While the COS is a tool that produces a requireddeliverable in TPM and APF, its use in xPM is optional COS loses its value asthe goal becomes more and more elusive If the client has only a vague ideaabout the goal, no amount of discussion around needs and deliverables willclarify the situation for either party, and the other planning artifacts described

in the text that follows may be more useful in the initial SPeculate phase

If you choose to use the COS in your xPM project, think of it as more of a storming process The project team and the client can investigate ideas enroute to putting a list of what will be done in this cycle

brain-Variations to AP F 339

Scenarios, Stories, and Use Cases

The technical perfectionist would probably define these terms as differentfrom one another, but for our purposes, they are synonymous All three can bedefined as descriptions of how a person might use the application Because theapplication may be feature-rich, there can be, and usually will be, several suchdescriptions If done correctly, these descriptions will be exhaustive of how theapplication can be used These descriptions can then be prioritized andassigned to the appropriate development cycles There is no practical limit tothe number of such situations that are documented In the case of technologyprojects, like Web site development, the client may be more comfortable tellingyou how they envision someone using the deliverable and what they can do atthe Web site than they would be in trying to help you write a functional spec-ification The advantage in using scenarios, stories, and use cases is that theview you are building is from the user side, not from the technology side

Prioritizing Requirements

The collection of scenarios, stories, and use cases provides insight into therequirements that the deliverable should meet For the client, it is far easier toprioritize the collection than it is to prioritize the requirements Prioritization

is the next step in the SPeculate phase There are several ways to produce a prioritized list of the items in the collection Chapter 14 discussed three suchmethods: forced ranking; must-haves, should-haves, nice-to-haves; and the Q-Sort Refer to Chapter 14 for the details on those methods

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

■■ First, there can be a great number of items in the collection; so many, infact, that approaches like forced ranking are not practical Forced rankingdoesn’t scale very well A compromise approach might involve groupingthe items based on their relationship to specific functions and then priori-tizing between and within the functions The strategy here would be toassign all of the items that relate to a specific function to a subteam fortheir consideration and development Several subteams could be active inany given cycle

■■ Second, depending on how well the goal is understood, it might be wise

to plan the initial SPeculate phase so that as many options and tives as possible can be investigated The strategy here is to eliminatethose alternatives that show little promise earlier rather than later in theproject That allows more resources to be brought to bear on approachesthat have a higher probability of success

alterna-■■ Finally, where appropriate, prototypes might be considered as part or all

of the first-cycle deliverables Here the strategy is to prioritize items in thecollection or functions by not spending too much time developing the realdeliverable Getting the client familiar with the prototype may give suffi-cient information to allow not only a reduction in the number of items inthe collection, but also a prioritization of those items or functions thatshow promise A good example is a typical B2C application The proto-type will show the various ways that a customer can interact with theapplication Upon examination, the client will add to that list or deletefrom that list as they experience what the customer would experiencewhen interacting with the application

Think of the first cycle or two as exploratory in nature Their purpose is todiscover the directions that show promise and focus later cycles on them

Identifying the First Cycle Deliverables

Once the prioritization is done, it is time to decide how much of that tized list to bite off for the initial cycle Remembering that you want shortercycles in the early part of the project suggests that you limit the first cycledeliverables to what you can reasonably accomplish in a week or two

priori-NOTE

By taking this approach, you are keeping the client’s interest up That is important APF follows the same strategy Once the client has been fully engaged in the project, later cycles can be lengthened.

Because your team resources are limited, you have to face the question ofdepth versus breadth of deliverables In other words, might it be better toextend the breadth to accommodate more functions by not delving deep intoany one function Produce enough detail in each function in this initial cycle toget a sense of further direction for the function You may learn from only ashallow look at a function that it isn’t going to be part of the final solution Thisshallow look allows you to save labor that would have been spent on a func-tion that will be discarded and to spend it on more important work

Go/No Go Decision

Because the initial cycle can be exploratory, the sponsor must have an nity to judge the soundness of the initial cycle plan and decide whether itmakes sense to proceed It is entirely possible that the original idea of the clientcannot be delivered with the approach taken in the first cycle, and the first cycle

opportu-Variations to AP F 341

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 thistime The go/no go decision points will occur at the end of each cycle Deci-sions to stop a project are more likely to occur in the early cycles than in the latercycles One should expect later cycles to have the benefit of earlier results thatsuggest that the project direction is feasible and should be continued.

Planning for Later Cycles

Later cycles will have the benefit of output from a REview phase to inform theplanning activities that will take place in the SPeculate phase that will follow.Each REview phase will produce a clearer vision and definition of the goal.That clearer vision translates into a redirection of the project and that trans-lates into a new prioritized list of deliverables for the coming Incubate phase.The newly prioritized deliverables list may contain deliverables from previouscycles that were not completed, deliverables that have not yet been part of anIncubate phase, and deliverables that are new to the project as a result of learn-ing and discovery that occurred in the most recently completed Incubatephase In any case, the revised prioritized deliverables list is taken into consideration as the team plans what it will do in the coming Incubate phase

It is now in the same position as it was in the very first SPeculate phase Whatfollows then is the assignment of deliverables to subteams and the scheduling

of the work that will be done and who will do it

Incubate

The Incubate phase is the xPM version of the Cycle Build phase in APF Thereare several similarities between the phases and some differences as well Consider the following points:

■■ Even though the Incubate phase has a prioritized list of deliverables thatare to be produced in this cycle, xPM still must maintain the spirit ofexploration It is a learning and discovery experience that may result inmid-cycle corrections that arise from that exploration

■■ APF, on the other hand, does benefit from learning and discovery as itproceeds with the cycle plan but it does not vary from the plan The learn-ing and discovery are input to the client checkpoint and that is where planrevisions take place

These points are an important distinction between xPM and APF

Subteams, working in parallel, will execute the plan developed in the previousSPeculate phase The environment has to be very open and collaborative forthis phase to be successful Teams should be sharing ideas and cross-fertilizing