Effective Project Management Traditional, Adaptive, Extreme phần 7 pptx

Figure 13.1 The Adaptive Project Framework.Develop Conditions of Satisfaction Prioritize Functional Requirements & Develop Mid-Level WBS Write Project Overview Statement Prioritize Scope

Installing Custom Controls 267

Introduction to the Adaptive Project Framework

It is a mistake to look too far ahead Only one link of the chain of destiny can be handled at a time.

—Winston Churchill

There is no data on the future.

—Laurel Cutler, Vice Chairman, FCB/Leber Katz Partners

C H A P T E R

267

For those businesses that have only recently realized the pain of not having a

project management process in place and are struggling to adapt traditionalpractices to nontraditional projects, we say, “Stop wasting your time!” We’renot advocating the overthrow of the project management world, but ratherasking you to stop and think about what has been happening It’s time to payattention to the signals coming from the changing business environment anddiscover how to survive the fast-paced, constantly changing, high-qualitydemands of the new business model

NOTE

Adaptive Project Framework (APF) incorporates selected tools and processes from tional project management (TPM) Those tools and processes are not repeated here This part of the book assumes that the reader is familiar with the TPM approach A quick review of Part I is suggested for those who do not have a working knowledge of TPM.

tradi-13

Chapter Learning Objectives

After reading this chapter, you will be able to:

◆ Give a general explanation of APF

◆ Understand the purpose of each of the five phases of APF

◆ Apply the APF core values

◆ Describe the types of projects that are appropriate for APF

The project survival strategy that we explore in this groundbreaking part ofthe book is what we are calling Adaptive Project Framework (APF) This is definitely not your father’s project management It’s new We don’t even usethe word management APF represents a shift in thinking about projects andhow they should be run For one thing, it eliminates all of the non-value-addedwork time that is wasted on planning activities that are never performed Why

plan the future when you don’t know what it is? In APF, planning is done in-time Sounds like an oxymoron, doesn’t it? It is a new mind-set—one that

just-thrives on change rather than one that avoids change

APF is not a one-size-fits-all approach; it continuously adapts to the uniquecharacter of the specific business situation as it learns more about that businesssituation Based on the principle that form follows function, this strategyadapts some of the tools and processes from TPM (discussed in Part I of thisbook) and extreme project management ( discussed in Chapter 19) to its ownspecial needs It is a framework based on the principle that you learn by doingand one that guarantees, “If you build it, they will come.”

APF seeks to get it right every time It is client-focused and client-driven and isgrounded in a set of immutable core values It ensures maximum businessvalue for the time and dollars expended and has squeezed out all of the non-value-added work that it possibly could As a framework that meaningfullyand fully engages the client as the primary decision maker, APF creates ashared partnership with shared responsibility between requestor and provider.APF is a framework that works, 100 percent of the time No exceptions!

Do we have your attention?

Defining APF

APF is an iterative and adaptive five-phase approach designed to deliver imum business value to clients within the limits of their time and cost con-straints The fundamental concept underlying APF is that scope is variable,and within specified time and cost constraints, APF maximizes business value

max-by adjusting scope at each iteration It does this max-by making the client the tral figure in deciding what constitutes that maximum business value At thecompletion of an iteration, the client has an opportunity to change the direc-tion of the project based on what was learned from all previous iterations Thisconstant adjustment means that an APF project’s course is constantly corrected

cen-to ensure the delivery of maximum business value In other words, change isembraced, not avoided

Planning takes on a whole new meaning in APF Initial planning is done at ahigh level and is component or functionally based TPM planning is activity-and task-based In APF, planning at the micro level is done within each iteration

C h a p t e r 1 3 268

It begins with a mid-level component or function-based WBS and ends with amicro-level activity and task-based WBS We like to think of it as just-in-timeplanning The underlying strategy to APF planning is not to speculate on thefuture, because such speculation is a waste of time and energy A key phrase tokeep in mind when applying APF is “when in doubt, leave it out,” meaning that

we only include in our detailed planning those activities that clearly will be part

of the final solution—that is, at each iteration, include in your detailed plan onlywhat you know to be factual So, planning is done in segments where eachchunk represents work that will require only a few weeks to complete

The five phases that define APF are as follows:

An Overview of the APF

The stage is now set to take our first look at APF Figure 13.1 is a graphic trayal of how APF is structured First, note that APF is an iterative process Weiterate within a cycle and between cycles Every iteration presents the teamand the client with a learning and discovery opportunity APF is crafted to takeadvantage of these opportunities As you continue to study each phase, youwill come to realize that is its real strength

por-Version Scope

APF begins with a stated business problem or opportunity This beginning isthe same as TPM A request has been made to develop a solution to the statedproblem or opportunity, and that request has all the earmarks of a project Atthis point, we are not at all sure what kind of project this might be or how wemight approach it from a methodology perspective A Conditions of Satisfac-tion (COS) conversation takes place between the requestor and the provider todefine more clearly exactly what is needed and what will be done to meet thatneed The result of that conversation is a decision as to which project manage-ment approach will be followed: traditional (covered in Part I), extreme (covered in Chapter 19), or APF We have decided that APF is the approach to

be taken, so a project scoping document, specifically, a Project Overview ment (POS), is written

State-Introduction to the Adaptive Project Framework 269

Figure 13.1 The Adaptive Project Framework.

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

CYCLE BUILD

CLIENT CHECKPOINT

POST-VERSION REVIEW

C h a p t e r 1 3 270

We discuss the POS in great detail in Part I, particularly in Chapter 3 See that sion for more information.

discus-Recall that a POS basically summarizes the Conditions of Satisfaction It is

a brief (usually one page, maybe an attachment) document that contains thefollowing:

■■ A statement of the problem or opportunity (reason for doing the project)

■■ A goal statement (what will generally be done)

■■ A statement of the objectives (general statements of how it might be done)

■■ The quantifiable business outcomes (what business value will beobtained)

■■ General comments on risks, assumptions, and obstacles to successThe second deliverable from this phase is a prioritized list of the functionalitythat has been requested and agreed to in the COS Both parties recognize thatthis list may change, but at this point in the project, the list reflects the bestinformation available

Struc-Introduction to the Adaptive Project Framework 271

phases We will generate it when we need it and not before, and when we dogenerate it, we will know that it is correct and not a guess.

The fourth deliverable from this phase is a prioritization of the variables thatdefine the scope triangle (time, cost, resources, scope, and quality) This prior-itization will be used later as an aid to decision making and problem solvingduring the Cycle Build phase

Cycle Plan

The Project Overview Statement has been written and is presented along with

a prioritized list of functionality that the client and the provider believe areneeded to take advantage of the business opportunity or solve the businessproblem (Again, for a complete discussion of the POS see Chapter 3.) Somehigh-level planning is done very quickly to prioritize the functionality into anumber of time-boxed cycles for development Typical cycle length is 2 to 6weeks This cycle length is documented and agreed to by both parties—alongwith the expectation that it will change as project work commences

The Cycle Plan phase will be repeated a number of times before this project iscomplete The first Cycle Plan phase has as input the POS, the prioritizedscope triangle, the functionality that will be built in this cycle, and the mid-level WBS Subsequent Cycle Plan phases will also have a Scope Bank as input

CROSS-REFERENCE

The Scope Bank is introduced in Chapter 16.

Contrary to what you might think, the creation of the cycle build plan is a tech operation While you could certainly use project management softwaretools, we have found that a whiteboard, Post-It notes, and marking pens arejust as effective It does keep the maintenance of a project file down consider-ably and allows the team to focus on value-added work This advice maysound heretical to those of you who are software aficionados, so let us explain.Cycle length generally falls within a 2- to 6-week timeframe There will likely

low-be several small teams (a typical small team will low-be one architect and two orthree software engineers), each working in parallel but independently on aseparate piece of functionality Each of these small teams will plan the cyclebuild in this phase and then conduct the cycle build in the next phase Based

on this description, a minimal planning effort is all that makes sense

The cycle planning effort might go something like this:

1 Extract from the WBS those activities that define the functionality that will

be built in this cycle

2 Decompose the extracted WBS down to the task level

C h a p t e r 1 3 272

3 Establish the dependencies among these tasks.

4 Partition the tasks into meaningful groups and assign teams to eachgroup

5 Each team develops a micro-level schedule with resource allocationsfor the completion of their tasks within the cycle timebox and budgetconstraints

There is no critical path to calculate and manage Traditionalists would have aproblem with this Their approach is based on managing the critical path Wecould certainly calculate one here and maintain it, but we believe that isoverkill The cycle is so short that too much planning and analysis leads toparalysis We don’t need to clutter the cycle with non-value-added work Theentire effort can be whiteboard-, Post-It note-, and marker pen-based A dedi-cated war room would be helpful (12' by 12' should work fine) The team canpost their plans, work schedules, Scope Bank, Issues Log, and so on, and havetheir daily 15-minute updates, weekly status meetings with the client, andproblem-solving sessions here

Cycle Build

Detailed planning for producing the functionality assigned to this cycle is ducted The cycle work begins and is monitored throughout the cycle, andadjustments are made as necessary The cycle ends when its time has expired.Any functionality not completed during this cycle is reconsidered as part ofthe functionality in the next cycle

con-The first activity in the Cycle Build phase is to finish the cycle build scheduleand resource allocation With everything in place and understood by the team,work begins Every team member has a daily task list and posts task status atthe completion of every day Any variances are caught early, and correctiveaction plans put in place Nothing escapes the attention of the project managerfor more than one working day A Scope Bank is created to record all changerequests and ideas for functional improvements An Issues Log records allproblems and tracks the status of their resolution

func-Introduction to the Adaptive Project Framework 273

high-level plan and next cycle work as appropriate The sequence CyclePlan–Cycle Build–Client Checkpoint is repeated until the time and cost bud-gets for this version have been expended.

The Client Checkpoint phase is a critical review that takes place after everyCycle Build phase is completed During the cycle build, both the client and the project team will benefit from several discovery and learning episodes.Variations to the version functionality will surface; alternative approaches todelivering certain functionality will be suggested, and the client will learnthrough his or her continuous involvement with the team All of this must beconsidered along with the functionality that had originally been assigned tothe next cycle The result is a revised prioritization of functionality for the nextcycle The most important thing to remember is not to speculate on the future

In the next cycle, prioritize only the functionality that you are certain will be inthe final solution

We don’t dismiss this as being an easy exercise It definitely isn’t Most of thedifficulty stems from either the client or the project team not approachingreprioritization with an open mind People tend to get wedded to their earlierideas and are hard-pressed to give them up in favor of others To be successfulwith APF, both the team and the client must have an open mind and not dis-play pride of authorship on any previous functionality that was discussed

TIP

Change is a critical success factor in APF.

One of the greatest benefits from this approach is the meaningful and ous involvement of the clients They are the decision makers in all going-forward activities They are doing it with full knowledge of what has takenplace to date and with the collaborative support of the project team Theyunderstand how business value can be achieved by changes in functionality,and they are in a position to take action APF encourages the clients to engage

continu-in the project even to the level of operatcontinu-ing as a co-project manager Their ence will be a constant reminder to the team of the business aspects and value

pres-of what they are doing and what changes should be made to protect that ness value This client involvement is a very important point to remember Itensures that what is eventually built will meet client needs

busi-Post-Version Review

During the Version Scope phase, we developed measurable business outcomes

in discussions with the client These became the rationale for why the projectwas undertaken in the first place Think of these outcomes as success criteria

C h a p t e r 1 3 274

That is, the undertaking will have been considered a success if, and only if,these outcomes are achieved In many cases, these outcomes cannot be mea-sured for some time after the project has been completed Take the case of theproject impacting market share It won’t happen next Tuesday It may happenseveral quarters later, but the timeframe is part of the success criteria state-ment as well.

The budget and time allotted to this version have been spent, and that marksthe end of the project Some functionality that was planned to be completedmay not have been completed The main focus of the post-version review is tocheck how you did with respect to the success criteria, to document what youlearned that will be useful in the next version, and to begin thinking about thefunctionality for the next version

What the client and the project team believe to be the best mix of functionalityhas been built into the solution The project is done The deliverables areinstalled, and the solution is in production status At this stage, three questionsneed to be answered:

1 Was the expected business outcome realized?

2 What was learned that can be used to improve the solution?

3 What was learned that can be used to improve the effectiveness of APF?The business outcome was the factor used to validate the reason for doing theproject in the first place If it was achieved, chalk that one up on the successside of the ledger If it wasn’t, determine why not Can something further bedone to achieve the outcome? If so, that will be input to the functional specifi-cations for the next version If not, kill the project right now No need to sendgood money after bad money

There is also a lesson here for all of us If projects are limited in scope and theyfail and there is no way to rescue them, we have reduced the dollars lost tofailed projects The alternative of undertaking larger projects is that we risklosing more money If there is a way of finding out early that a project isn’tgoing to deliver as promised, cut your loses The same logic works from cycle

to cycle If we can learn early that a version will not work, kill the version andsave the time and cost of the latter cycles

NOTE

TPM would find out a project wasn’t working only after all the money was spent, and then a great deal of trouble might be involved in killing the project The traditional thought goes, “After all, there is so much money tied up in this project, we can’t just kill it Let’s try to save it.” How costly and unnecessary.

Introduction to the Adaptive Project Framework 275

The APF Core Values

APF is more than just a framework It represents a way of thinking aboutclients and how best to serve them This way of thinking is embodied in the sixcore values described in the sections that follow These core values areimmutable They must be practiced in every APF project No exceptions Intime the APF teams will be recognized for the visible practice of their core values We have had occasion to work with teams that periodically rewardteam members for practicing the APF core values They are that important

Client-Focused

While we were looking for the appropriate name for this core value, the phrase

“walk in the shoes of the client” was always on our minds It still is an tive part of truly being client-focused This value is the most important of thecore values The needs of the client must always come first, as long as they arewithin the bounds of ethical business practices This value can never be com-promised, and it goes beyond simply keeping it in mind It must be obviousthrough our actions with one another and through our interactions with ourclients

opera-Don’t think that we are advocating passive acceptance of whatever the clientmight request Client-focused also means that we have their best interests atheart In a spirit of openness, we are obligated to challenge ideas, wishes, andwants whenever we believe challenge is called for To do otherwise is not part

of being client-focused We want to do the right things for the right reasonsand to always act with integrity

Client-Driven

One of the guiding principles of our business has always been to engage theclient in every way that we could We want them not only to be meaningfullyinvolved but to also have the sense that they are determining the direction thatthe project is taking At the extreme, this value would mean having the clienttake on the role and responsibilities of the project manager Such an extremewill not happen very often, but there are occasions when this will occur Aneffective arrangement is to have co-project managers—one from the client andone from your organization In this arrangement, both individuals shareequally in the success and failure of the project There is a clear and establishedco-ownership Practice tells us that this is a key to successful implementation

We say that this is a key factor to successful projects

C h a p t e r 1 3 276

Incremental Results Early and Often

In the spirit of prototyping, we want to deliver a working application to theclient as early as possible This early delivery is especially valuable when there

is any question that the real needs of the client have not yet surfaced despiteour best efforts The functionality of the first iteration of the application will bevery limited but useful in any case In some cases, the first iteration might be aproof of concept (See Chapter 19 for more on this point.) It should deliverbusiness value even though it is of very limited functionality It gives the client

an early feel for the final deliverables Giving the client an opportunity to workwith something concrete is always better than asking them to react to somevague concept or sketch on a notepad

Continuous Questioning and Introspection

Building a solution iteratively affords the opportunity to be creative It createsthe opportunity to adjust as better and more valuable features or presentationsare discovered As the cycle build proceeds, both the client and the project teamshould always be looking for improvements in the solution or the functionalityoffered Look back at previous cycles, and ask whether what was done was thebest that could have been done All of this learning and discovery will be cap-tured in the Scope Bank and come together in the Client Checkpoint phase Here

is where the client and the project team propose, discuss, and approve changes

A true spirit of openness must exist Neither party should be afraid to offer orchallenge an idea or the real value of some present or future deliverable We’vefrequently told teams that if anyone of their members had an idea and didn’tshare it with the rest of the team, we would consider it dereliction of duty Thesame is true for the client The successful practice of this core value is heavilydependent on the existence of a true team environment

Change Is Progress to a Better Solution

One of our colleagues is often heard saying, “You’re always smarter tomorrowthan you are today.” He is referring to improving estimates over time, but hiscomment applies to APF as well The Version Scope phase begins with therequestor and provider coming to a definition of what is needed and what will

be delivered through the COS experience Despite their best efforts, all the twoparties have done to this point is take the best guess they can as to what will bedone That guess may turn out to be very good, but that is not important What

is important is that by working with the deliverables from the first cycle, bothparties will get a better picture of what should be delivered They will besmarter as a result of their experiences with the early deliverables The result

is to change the project going forward in the next cycle

Introduction to the Adaptive Project Framework 277

Don’t Speculate on the Future

APF strips out all added work Guessing only adds added work back in So, when in doubt, leave it out APF is designed to spendthe client’s money on business value not on non-value-added work

non-value-Putting It All Together

In this introductory chapter, we have set the stage for the rest of Part II Therationale behind the APF has been briefly explored, and we have given you thehigh-level view of what the APF involves This introduction could well meetthe needs of the senior manager who simply wants to understand APF at ahigh level For those at the program or project manager level, you are off to agood start With that understanding in place, we can now proceed to peel backthe layers of our onion—the APF In Chapters 14 through 19, you will discoverand come to understand the most granular of details for each of the five phasesand adaptations of the APF Our intent is that you have a working knowledge

of APF when you are finished

We are truly thankful to have this opportunity to introduce a new way ofthinking about an important class of projects It is our hope that you find it avaluable addition to your arsenal

Discussion Questions

1 Under your leadership, your organization has spent considerable effort toadopt a traditional approach to project management It has reached maturitylevel three, that is, there are fully documented project management

processes and templates and everyone is following them PMBOK is the ognized standard You have earned a good reputation among your manage-ment colleagues You have noticed a number of projects where the client hasrequested and gotten approval for several changes throughout the project.These have cost significant money and time, the loss of e-business marketshare, and the subsequent loss of revenues As Director of the Project Sup-port Office, you have come to realize that APF is the approach that shouldhave been taken on this project You are convinced that by using APF thesetypes of projects could have been completed earlier, at less cost, and with amuch better end results What strategy would you suggest to introduce andinstitutionalize APF in your company? What obstacles do you foresee?

rec-2 You are a senior project manager in your company You have 15 years’ rience with them and a solid reputation for delivering successful projects.What might you, acting on your own, do to get your organization to appre-ciate the value of APF? What obstacles might prevent you from going for-ward with your plan? How do you feel about stepping outside the box?

expe-C h a p t e r 1 3 278

Installing Custom Controls 279

Version Scope

Prediction is very difficult, especially about the future.

—Neils Bohr

Define the problem before you pursue a solution.

—John Williams, CEO, Spence Corp.

C H A P T E R

14

279

The Version Scope phase is the beginning of APF (see Figure 14.1) It is a formal

set of activities that take place very soon after a request has been made Thereare two major parts to version scope:

A defining part. The defining part can effectively be completed by two ties: a requestor and a provider These may each be single individuals orsmall groups that represent the two parties In either case, the critical factor

par-is that they not only represent their constituency but they speak for theirconstituency and can make decisions for their constituency

Chapter Learning Objectives

After reading this chapter, you will be able to:

◆ Describe the components of the Version Scope phase

◆ Conduct a Conditions of Satisfaction process

◆ Write a Project Overview Statement for an APF project

◆ Develop a mid-level WBS

◆ Prioritize version functionality using one of three methods

◆ Prioritize the scope triangle using success sliders

◆ Determine the number of cycles and the cycle timeboxes

◆ Assign functionality to cycles

A planning part. The planning part is not unlike the early stages of theTPM planning session It should be attended by the stakeholders and coreproject team The difference here is that the version plan is not a detailedplan It does not provide a detailed definition of the work to be done or of

a schedule to be followed Those details are part of the cycle plans

Figure 14.1 Version Scope 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

C h a p t e r 1 4 280

Defining the Version Scope

You have probably guessed by now that more than one version of the solution

is expected And you are correct However, we are only concerned with thisversion and will not reference any future versions of the solution Informationwill be gathered during this version that will inform management about anyfurther enhancements they might want to consider in future versions Thesefuture versions are not unlike the normal releases we see in products, services,and systems

While there are similarities between TPM and APF, one major difference has to

do with scope Scope creep is the bane of the traditionalist They put up with itbecause they have no choice They know it will happen, and they just have tomake the best of it In APF there is no such thing as scope creep What occurs

is change brought about by discovery and learning by the team and by theclient This change is expected, and APF is designed to handle it with ease ateach client checkpoint

So let’s get into the details of the defining part of the Version Scope phase

Developing the Conditions of Satisfaction

The Conditions of Satisfaction (COS) are determined by a one-on-one, time, face-to-face dialogue between the requestor and the provider Emails willnever be a substitute for face-to-face dialogue The problem with emailrequests and replies is that we are never really sure what the other individual

real-is saying because we don’t have the opportunity for immediate feedback or tosee nonverbal reactions to the dialogue With emails we assume we under-stand, but we have no way of verifying that we understand correctly

To further press our point, here is an example from our early days of training ITprofessionals in project management We would ask each student to write

down his or her definition of implementation They could do it by making a list

of what was in and not in implementation Would you be surprised to knowthat there wasn’t much agreement from one list to another? IT professionals canhardly say a sentence without using the word implementation, and they don’treally know what they are talking about With this simple example, it is clearthat the message sent is surely not the message received How serious a com-munications problem might there be between a requestor (a businessperson)and the provider (a technical person)? Such communications problems can be

Version Scope 281

pretty serious They could result in the project team having one idea of what theclient needed and the client having yet another understanding of what the team

is going to deliver It is so important that both the client and the team have acommon understanding of what is needed and what is being delivered that topass up the COS exercise could be fatal The COS, which is introduced in Chap-ter 3 and is briefly revisited here, solves the problem once and for all

NOTE

The requestor and provider may be individuals or small groups, but they must be representative of the requestor group and the provider group and be empowered to make commitments and decisions for the groups they represent.

Let’s review how the COS works The COS consists of two conversations Thefirst one is driven by the requestor and the second by the provider Figure 14.2

is a schematic of the process

Let’s look at the two types of conversation:

Requestor-driven conversation. The requestor states and describes therequest using their language The provider makes sure he or she under-stands the request by using questions and eventually feeding back therequest in his or her own language At some point in this conversation, youwant the requestor to be able to say to the provider, “You clearly under-stand what I am asking you to do.” The conversation now shifts to theprovider-driven conversation

Provider-driven conversation. The provider responds by stating and ing what can be done to meet the requestor’s request The requestor asksquestions to frame the answer and eventually describes the response in his

describ-or her own language At some point in this conversation, the provider is able

to say to the requestor, “You clearly understand what I can provide.”

Figure 14.2 Establishing Conditions of Satisfaction.

Negotiate Agreement and Write Project Overview Statement

Clarify Request

Agree on Response

Response Request

C h a p t e r 1 4 282

We should now have agreement and a clear understanding of what is beingasked and what can be done There will be some negotiating to reach agree-ment, and you shouldn’t assume that everything is in sync until finishing theprocess Note that the requestor and provider, through their earlier conversa-tions, have established a common language They each understand the other,which will smooth the negotiating that will take place This understanding isone of the major benefits of COS; a clear communication link is now estab-lished between the two parties This communication link is very importantnow because the project does not have a clear solution It will take the bestefforts of both the project team and the client to fashion a solution that meetsthe expectations of the client.

The COS process is not a one-time event It occurs continuously throughout theproject At each client checkpoint, revisit the COS Because of the learning anddiscovery that has taken place, something will have surely changed that rendersthe previous agreement obsolete This revisiting the COS is your guarantee ofalways staying in alignment with what the client needs It is also the pathway tomove the client from what they want to what they need Remember, APFembraces change, and here is the place where change enjoys the light of day

Writing the Project Overview Statement

The output from the COS contains all of the information needed to write theProject Overview Statement

CROSS-REFERENCE

The POS is introduced and discussed in detail in Chapter 3.

To review, the POS has five parts:

Version Scope 283

Some organizations may require a little analysis to validate the business come of the proposed project We have seen a number of attachments includedwith the POS, such as:

Identifying the Business Problem or Opportunity

A well-defined need and a clear solution pathway planned to meet that needdefine a project that the traditionalist would die for A rather vague idea of awant coupled with a vague idea of how it will be satisfied define a project thatthe agilest (an agilest is one who aligns their project management approachwith xPM, which is discussed in Chapter 19) would die for Everything inbetween belongs to the project manager using APF The problem or opportu-nity that our project is going to respond to must already be recognized by theorganization as a legitimate problem or opportunity If anyone in the organi-zation were asked about it, he or she would surely answer, “You bet it is and

we need to do something about it.” In other words, it is not something thatneeds a defense It stands on its own merits

Defining the Goal of This Version

This goal will be a simple yet definitive statement about what this projectintends to do to address the problem or opportunity It might be a total solution, but to be more realistic, it should be a solution that addresses a majorsegment of the problem or opportunity We say this because all too often wedefine projects that are far too large in scope That opens us to scope creep andchanges in the environment that render the global solution ineffective or irrel-evant By defining the goal of this version to be a reachable target rather than

a lofty or unattainable ambition, we protect the client and the team from scopecreep We are sure that this has a lot to do with the high incidence of projectfailure It may sound too pedestrian to some of you, but we believe that wewill be far more successful in the long run by biting off less than we think wecan chew We are not asking for heroic efforts, just successful ones

C h a p t e r 1 4 284

Writing the Objectives of This Version

By way of analogy, we think of the goal statement as a pie and the objectivestatements as slices of the pie All of the slices that make up the pie are theobjective statements If you would rather have a mathematical interpretation,think of the objectives as necessary and sufficient conditions for the attainment

of the goal In either case, the objective statements give a little more detail onhow the goal will be achieved They are the boundary conditions, if you will

We would expect to see you write six to eight objective statements to clarifyyour goal statement

Defining the Success Criteria

The success criteria (or explicit business outcomes) are quantitative statements

of the results that will be realized from having successfully completed thisproject They are formulated in such a way that they either happened or theydidn’t There will be no debate over attainment of success criteria Statementslike “Gross profit margins will increase from their current average of 11 per-cent per month to an average of at least 14 percent per month by the end of thesecond quarter of production using the new system” are acceptable State-ments like “Increase customer satisfaction” are not We would expect to seetwo or perhaps three success criteria for your project Success criteria generallyfall into three categories:

■■ A metric related to an increase in revenues

■■ A metric related to a reduction or avoidance of cost

■■ A metric related to an improvement or increase in services

Listing the Major Risks

Put yourself in the shoes of the financial analyst who might ask, “I am beingasked to invest $10 million in a new system that is supposed to cut operatingexpenses by 5 percent per month What risks are we exposed to that might pre-vent us from achieving that ROI?” What would you tell the analyst? That iswhat you list in the major risks You might also make senior managers aware

of the fact that certain staff skill shortages are going to be a problem or that thereorganization of sales and marketing will have to be complete or there will beserious consequences during system implementation

Holding a Fixed Version Budget and Timebox

In APF the budget and timebox are fixed The timebox refers to the window of

time within which the project must be completed This timebox includes all

Version Scope 285

cycles, which have their own timeboxes, too We suggest trying to keep a sion timebox to less than six months Any longer and you invite many of theproblems that plague the traditionalist There are no rolling schedules There is

ver-no going back to the well for aver-nother budget increase One of the objectives in

an APF project is to maximize business value under fixed time and cost straints Period This is a very different approach to the project than the tradi-tionalist would take As long as the client is satisfied that the maximumbusiness value has been attained for the time and dollars expended, the proj-ect was successfully completed If the client and the project team pay attention,this result can be achieved every time No exceptions!

con-Unfortunately, the maximum business value they attain may not meet the success criteria, but that is an issue for the client to deal with and should notdetermine the success or failure of the APF approach Whatever didn’t getdone in this version will have to be left for the next version or not at all Hence,

we have another reason for keeping scope to a feasible minimum and the box to less than six months Those restrictions reduce the occasions whereschedules are extended or more dollars are needed Those restrictions thenalso reduce the financial loss to the organization as compared to the traditionalapproach With APF you can kill a bad project much earlier than you can withthe traditional approach, and that accounts for the dollar savings

time-Planning the Version Scope

This planning function will look quite similar to what the traditionalist would

do In APF however, we stop the process earlier than the traditionalist would.The APF version plan extends only to the mid level, whereas the traditionalplan would extend to the low level In APF we plan only to the level that weknow will happen Anything below that level is playing with the future, andthe project manager using APF doesn’t play with the future APF planning isjust-in-time planning

So let’s get into the details of the planning part of the Version Scope phase

Developing the Mid-Level WBS

The input to planning the version is the mid-level WBS The mid-level WBSidentifies the functionality that will be built in this version It is a noun-typedecomposition of the goal statement

C h a p t e r 1 4 286

Refer to Chapter 4 for a refresher on the noun-type decompositions.

The mid-level WBS does not show the tasks have to be done to build that tionality To complete the WBS down to that level at this point in time woulddefine work that might never be done In APF we don’t know enough aboutthe future to spend the time creating the full WBS to that level of detail Overthe course of all of the cycles, we may end up generating the complete WBS,but we don’t know that for sure In APF we will build the WBS detail when weneed it For our purposes here, we simply decompose the WBS to a level where

func-we can reasonably estimate the time and resources needed for each piece offunctionality These are not top-down estimates nor are they bottom-up Wesimply need a reasonable guesstimate

The techniques described in Chapter 4 can be used here to build the mid-levelWBS Typically, the mid-level WBS is detailed down to level 2, but this is notmandatory Level 2 would consist of subfunctions, but they are still noun-typestatements If you find yourself decomposing using verb-type statements, youhave gone too far In the APF mid-level WBS, the lowest level of detail is still adefinition of what needs to be built (functionality) rather than how it is built.This is an important distinction To define how to build something that maynot even be built is a waste of time Again, why plan the future when you don’tknow what it is?

Prioritizing the Version Functionality

Using the mid-level WBS as a starting point, the core team, along with sentatives from the requestor organization, must determine the priorities ofthe subfunctions identified in the mid-level WBS Before you can determinethe priorities of the various functionalities, you need a criterion on which tomake those priority decisions Some possibilities are risk, complexity, dura-tion, business value, or dependencies Let’s take a look at each one and discusssome of the reasons why you might want to use it

repre-Risk

This criterion suggests that high-risk functionality has the highest priority andlow-risk functionality has the lowest priority Why? The strategy goes some-thing like this If we get started on the tough stuff early and we have problems,we’ll have time to make any mid-project corrections If we leave it till later, wemay not have time to solve it before the version timebox expires

Version Scope 287

This criterion says that highly complex functionality has the highest priorityand low-complexity functionality has the lowest priority Why? The rationalehere is exactly the same as the risk criterion

Duration

This criterion says that short duration functionality has the highest priorityand long duration functionality has the lowest priority Again, why? If thedriving strategy is to get something to the client ASAP, this criterion does thejob This criterion also keeps the client’s interest at a high level You don’t wantthem to wait three months before you produce some working piece of the solution, and this strategy allows you to get back to them quickly They havesomething to inspect, and you get some input for the next cycle As you movefurther into the cycles, cycle length can increase because by that time you willhave the committed interest of the client and longer cycles will not be a problem for them

Business Value

This criterion states that high business value has the highest priority and lowbusiness value has the lowest priority From a business perspective, this crite-rion makes perfect sense Get the most business value into the solution ASAPand start to reap the benefits

So which criterion do you use? If you guessed that the answer is “it depends,”you are partially right Actually, the best strategy is to defer to the client for theanswer Of course, you as project manager had better provide a detailed analysis of the pluses and minuses of each choice Still, this decision is really abusiness decision, and the client is in the best position to give the answer Inany case, the functionality gets prioritized

C h a p t e r 1 4 288

Prioritization Approaches

Before we leave this topic, we need to spend a few lines on what that zation looks like The choice of how you establish the priority order of the subfunctions is entirely up to the client and the team If you need some sug-gestions about the rule you will use to prioritize, here are three suggestions.They are briefly described in the sections that follow by way of examples

prioriti-Forced Ranking

The first approach to prioritizing is called forced ranking Suppose 10 pieces of

functionality have been requested Number them 1, 2, , 10 so that we canrefer to them later on Let’s also suppose that the client has a panel of six man-agers (A, B, , F), and they are each asked to rank the functionality from mostimportant (1) to least important (10) They can use any criteria they wish, andthey do not have to describe the criteria they used The results of their rankingsare shown in Table 14.1

Table 14.1 Force Ranking of 10 Pieces of Functionality

FUNCTIONALITY # A B C D E F RANK FORCED

The individual rankings from each of the six members for specific functions (orsubfunctions) are added to produce the rank sum for each function (or subfunc-tion) Low values for the rank sum are indicative of functions (or subfunctions)that have been given high priority by the members So for example, Function 7has the lowest rank sum and is therefore the highest-priority function Ties arepossible In fact, the preceding example has two ties (1 and 4, 6 and 9) Ties can

be broken in a number of ways We prefer to use the existing rankings to breakties In this example, taking the tied function with the lowest rank score andmoving it to the next lowest forced rank breaks a tie For example, the lowestrank for Function 1 is 6, and the lowest rank for Function 4 is 8 Therefore, the tie

is broken by giving Function 1 a rank of 2 and Function 4 a rank of 3

Must-Haves, Should-Haves, Nice-to-Haves

The second prioritization approach is a bit less demanding Here you simplycreate three buckets: the must-haves, the should-haves, and the nice-to-haves.Every piece of functionality is assigned to one and only one bucket Be carefulwith this one because there is a temptation to make everything a must-have Toprevent that from happening, you might put a rule in place that every bucketmust have at least 20 percent of the functionality in it Adjust the percentage tosuit your taste

Prioritizing the Scope Triangle

You are probably wondering why we would want to do this or even what itmeans to prioritize the scope triangle First, let’s define the scope triangle, andthen we can talk intelligently about what it means to prioritize it and why wewant to do that Figure 14.4 is the scope triangle that is used in APF It’s thesame one that was introduced in Chapter 1 and is reproduced here for yourconvenience

C h a p t e r 1 4 290

Figure 14.3 An example of the Q-Sort.

Recall that the scope triangle consists of five variables: time, cost, resourceavailability, scope, and quality To understand the triangle, think in terms ofgeometry There is a triangle whose area is defined by scope and quality Thetriangle is bounded by the three sides defined by time, cost, and resourceavailability The sides are exactly long enough to bound the area defined byscope and quality This triangle also represents a system in balance because ofits geometric properties If any one of these variables should change (clientwants the deliverables earlier than originally planned or a scarce resourceleaves the company and will be very difficult to replace), the length of its linewill decrease, and the three sides of the triangle could no longer encompassthe area represented by scope and quality Then one or more of the other vari-ables must somehow change in order to bring this system back into balance

Proposed functionality

High-priority functionality

Low-priority functionality

Medium-priority functionality

Medium-priority functionality

Low-priority functionality

High-priority functionality

High-priority functionality

Highest-priority functionality

Lowest-priority functionality

Low-priority functionality

Version Scope 291