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

It ranges from the traditional approach to APFand then to extreme project management.. NOTE Adaptive Project Framework APF incorporates selected tools and processes from tional project m

Penetration into the Middle Third of the Buffer

Penetration into the middle third of the buffer does call for some action on thepart of the CCPM project manager In this case, the correct action is to investi-gate the cause of the slippage and put a get-well plan in place The earlier inthe sequence this occurs, the more serious the problem

Penetration into the Final Third of the Buffer

Penetration into the final third of the buffer is serious regardless of when in thesequence it occurs Obviously, if it is in the first third of the duration of the sequence, it is very serious If it occurs late in the final third, there may belittle that can be done In any case, action is called for

Figure 12.7 is a matrix that can be used to determine schedule slippage ity and need for action as a function of buffer penetration and distance into thetask sequence

sever-Figure 12.7 Buffer penetration and action decisions.

Second Third

Buffer Penetration

Task Sequence Penetration

NO ACTION

Task sequence will be ahead

of schedule

Monitor the situation for any further penetration

First Third

First Third

Final Third

NO ACTION

Serious problem; implement the solution

A very serious problem exists; aggressive action

is needed

Define the problem and formulate a solution

Serious problem;

immediate action required

NO ACTION

Second Third

Final Third

To grasp the significance of the penetration matrix, let’s first consider the onal from the top left cell to the bottom right cell in Figure 12.7 The cells on thediagonal reflect situations where task sequence penetration is about equal tobuffer penetration The statistician would say that is what we should expect onthe average However, the further we move into task sequence penetration(moving down the diagonal), the more we should be paying attention to theteam’s performance on the work being done on the tasks in the sequence Thenearer we are to the ending tasks in the sequence, the less likely it is that wecan formulate and execute a get-well plan should things go poorly For exam-ple, if we are in the second third of the task sequence, it might be a good idea

diag-to take a look at the problem situation and formulate an action plan in theevent things deteriorate The problem is not serious, but it does deserve ourattention In the final third of the task sequence, all we can do is closely moni-tor and take action at the slightest aberration in the task sequence schedule.Below the diagonal we’ve been discussing is a great place to be We could even

be experiencing a situation where the task sequence will finish ahead of ule and the time saved can be passed to the successor task sequence Above thediagonal are situations we are more used to If we are in the first third of thetask sequence and have penetrated into the second third of the buffer, we have

sched-a serious problem thsched-at needs immedisched-ate investigsched-ation sched-and solution tation There may be some systemic flaw in the project plan, and early inter-vention is needed If the schedule should continue to slip and we findourselves having penetrated into the final third of the buffer, we are in realtrouble, as the matrix suggests We could be looking at a significant slippagethat may impact the project buffer as well

implemen-Track Record of Critical Chain Project Management

It was not until the 1997 publication of Eliyahu M Goldratt’s book Critical Chain (North River Press Publishing Corp.) that people began to see the con-

nections between TOC and project management CCPM has only a five-yearhistory to draw upon for its successes Leach cites a few of them in his book

Critical Chain Project Management They are briefly summarized in the

follow-ing list:

Honeywell Defense Avionics Systems. Using critical chain concepts, ateam at Honeywell was able to reduce a 13-month project to 6 months.And they did finish it in 6 months

Lucent Technologies. A project that was scheduled using CCPM was tohave taken one year Many said it couldn’t possibly be done in one year Itwas, with buffer to spare

Harris. Harris undertook to build a new manufacturing facility using theCCPM approach The industry standard for such facilities was that it took

46 months to get the plant up and running to 90 percent capacity Harrisbuilt it and brought it up to 90 percent capacity in 13 months

Israeli aircraft industry. A particular type of aircraft maintenance requiresthree months on the average Using CCPM techniques the maintenanceteam reduced the average to two weeks

Better online solutions. A software package was originally planned to bereleased to the public in August 1997 The TOC schedule cut it down toMay 1, 1997 The actual delivery date was early April 1997

These stories do not in any way validate CCPM as better than TPM It is tooearly to tell that, but it is a fact that there have been many successes using it.You be the judge You decide if CCPM wins out over TPM or if it is just anotherrepackaging of PMBOK We have simply presented another way of managingresources and leave it up to the project team to decide which approach makesmore sense, given the situation

Putting It All Together

We have given you enough of an overview of CCPM to be able to use it in yourprojects The overview is brief and applied to a simple project Those of youwho are more serious about its application will need to dig deeper into it

Again, we heartily endorse Leach’s book Critical Chain Project Management.

Discussion Questions

1 Assume that your organization is interested in using CCPM along withTPM What criteria would you use to decide which approach makes moresense for a given project? You might try answering this question by con-sidering some of the characteristics of the project that would lead you toone choice over the other

2 You are a senior project manager in your company You have 15 years’experience with them and a solid reputation for delivering successfulprojects What might you, acting on your own, do to get your organiza-tion to appreciate the value of CCPM? What obstacles might prevent youfrom going forward with your plan?

Adaptive Project Framework

Project management is at a major crossroads How we choose to go forward will

either endear us to our clients or give them more reasons to dismiss projectmanagement as irrelevant to their needs Changes that have taken place in thepast few years in the way businesses operate have given us good reason topause and reflect on whether or not our traditional approach to project man-agement still satisfies the needs of organizations We are of the belief that weare not meeting the needs of contemporary organizations and that we must dosomething to correct that deficiency These thoughts have dominated ourthinking for several years now We’ve had this feeling that the business world

is passing us by, and that what we are offering them isn’t up to expectations.It’s time for some out of the box thinking

Part II of this book rose out of that belief and the need to act We call this newapproach Adaptive Project Framework (APF) It reflects our thinking on anapproach to projects that do not fit the traditional project profile Much of APF

is the direct result of working with project managers who are frustrated withtheir foiled attempts to adapt TPM to projects for which it was not designed

We warn you now that what you are going to read about in Part II is different

We ask you to be open-minded as you read these chapters What we have done

is take parts from the traditional approach and parts from the extremeapproach and integrate them in a way that meets the needs of a type of projectthat is not served by either the traditional or the extreme approaches There is

a new taxonomy of projects It ranges from the traditional approach to APFand then to extreme project management As we discussed in the Introduction,projects also follow a taxonomy that maps directly to these approaches

If you would like to reduce the cost of projects to your organization, read thispart of the book We believe it is required reading for Project Office directorsand managers, program managers, project managers, project leaders, teammembers, and those who use the services of any of these professionals Execu-tives will want to read Chapter 13 and learn that there is something that can be

TWO

done to significantly reduce the high percentage of failed projects withoutspending any more money That’s right—without spending any more money.APF does not require any special tools or software or consultant expertise to beimplemented For the traditionalist, APF should be intuitive Everything youneed is in this book In fact, we hypothesize that the APF approach that isintroduced here is actually less costly than the traditional processes now inplace in every organization.

We first introduce Adaptive Project Framework at a 60,000-foot level The firstchapter of this part describes the five-phase APF approach and briefly explainseach phase This chapter is an excellent introduction to APF for senior-levelexecutives, directors, and managers They will come away with a good graspand understanding of why APF is so critically important to our organizations

at this time The following five chapters discuss each of the five phases indetail sufficient for a project team to follow the approach The final chapterdiscusses a few variations of APF and focuses mostly on extreme project management (xPM) xPM is a variation of APF in that the goal is not clearlyspecified in xPM, whereas it is in APF That slight difference leads to a number

of variations in the approach These are discussed in some detail for the practitioner

Part II is a work in process We continue to learn and discover the real powerbehind APF as we discuss it with our colleagues and implement it with ourclients How interesting it is to realize that our project to develop a fully functional version of APF is an APF project

Many strict traditionalist project managers will probably find APF sial At least we hope to get their attention and open their minds to other possibilities There is an entire class of projects that we believe is not beingserved by the traditionalist approach Recent developments in extreme projectmanagement address some of those projects APF addresses projects that fall

controver-in the growcontrover-ing gap between the traditional and agile approaches In our rience, the majority of projects fall into this middle ground

expe-We claim full responsibility for the contents and any reactions that follow Ifnothing else, we hope to get a number of traditionalists excited enough to take

a look at what we are presenting Perhaps they will help us smooth the edges toAPF and make it a viable tool in their project management arsenal If you care

to comment, contact Bob Wysocki at rkw@eiicorp.com or Rudd McGary at rmcgary@hotmail.com We promise you a personal and thoughtful response

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

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

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

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

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

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.

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

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

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

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

CYCLE BUILD

CLIENT CHECKPOINT POST-VERSION REVIEW

DELIVERABLES

Conditions of Satisfaction

Project Overview Statement

Prioritized Scope Triangle

Prioritized Functionality

Mid-Level WBS & Dependencies

Cycle Length & # of Cycles

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

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

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:

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

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