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 CHAPTER 267 F or those businesses that have only recently realized the pain of not having a project management process in place and are struggling to adapt traditional practices to nontraditional projects, we say, “Stop wasting your time!” We’re not advocating the overthrow of the project management world, but rather asking you to stop and think about what has been happening. It’s time to pay attention to the signals coming from the changing business environment and discover how to survive the fast-paced, constantly changing, high-quality demands of the new business model. NOTE Adaptive Project Framework (APF) incorporates selected tools and processes from tradi- 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. 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 16 432210 Ch13.qxd 7/2/03 9:33 AM Page 267 The project survival strategy that we explore in this groundbreaking part of the 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 use the word management. APF represents a shift in thinking about projects and how they should be run. For one thing, it eliminates all of the non-value-added work 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 just- in-time. Sounds like an oxymoron, doesn’t it? It is a new mind-set—one that thrives on change rather than one that avoids change. APF is not a one-size-fits-all approach; it continuously adapts to the unique character of the specific business situation as it learns more about that business situation. Based on the principle that form follows function, this strategy adapts some of the tools and processes from TPM (discussed in Part I of this book) and extreme project management ( discussed in Chapter 19) to its own special needs. It is a framework based on the principle that you learn by doing and 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 is grounded in a set of immutable core values. It ensures maximum business value 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 meaningfully and fully engages the client as the primary decision maker, APF creates a shared 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 max- 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 by adjusting scope at each iteration. It does this by making the client the cen- tral figure in deciding what constitutes that maximum business value. At the completion 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. This constant adjustment means that an APF project’s course is constantly corrected to ensure the delivery of maximum business value. In other words, change is embraced, not avoided. Planning takes on a whole new meaning in APF. Initial planning is done at a high 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. Chapter 13 268 16 432210 Ch13.qxd 7/2/03 9:33 AM Page 268 It begins with a mid-level component or function-based WBS and ends with a micro-level activity and task-based WBS. We like to think of it as just-in-time planning. The underlying strategy to APF planning is not to speculate on the future, because such speculation is a waste of time and energy. A key phrase to keep 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 only what you know to be factual. So, planning is done in segments where each chunk represents work that will require only a few weeks to complete. The five phases that define APF are as follows: ■■ Version Scope ■■ Cycle Plan ■■ Cycle Build ■■ Client Checkpoint ■■ Post-Version Review They are briefly described in the next section. An Overview of the APF The stage is now set to take our first look at APF. Figure 13.1 is a graphic por- trayal of how APF is structured. First, note that APF is an iterative process. We iterate within a cycle and between cycles. Every iteration presents the team and the client with a learning and discovery opportunity. APF is crafted to take advantage of these opportunities. As you continue to study each phase, you will come to realize that is its real strength. Version Scope APF begins with a stated business problem or opportunity. This beginning is the same as TPM. A request has been made to develop a solution to the stated problem or opportunity, and that request has all the earmarks of a project. At this point, we are not at all sure what kind of project this might be or how we might approach it from a methodology perspective. A Conditions of Satisfac- tion (COS) conversation takes place between the requestor and the provider to define more clearly exactly what is needed and what will be done to meet that need. 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 State- ment (POS), is written. Introduction to the Adaptive Project Framework 269 16 432210 Ch13.qxd 7/2/03 9:33 AM Page 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 Chapter 13 270 16 432210 Ch13.qxd 7/2/03 9:33 AM Page 270 CROSS-REFERENCE We discuss the POS in great detail in Part I, particularly in Chapter 3. See that discus- sion for more information. Recall that a POS basically summarizes the Conditions of Satisfaction. It is a brief (usually one page, maybe an attachment) document that contains the following: ■■ 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 be obtained) ■■ General comments on risks, assumptions, and obstacles to success The second deliverable from this phase is a prioritized list of the functionality that has been requested and agreed to in the COS. Both parties recognize that this list may change, but at this point in the project, the list reflects the best information available. CROSS-REFERENCE There are several ways to establish that priority, and we discuss them in Chapter 14. The COS is fully described in Chapter 3. The third deliverable from this phase is the mid-level Work Breakdown Struc- ture (WBS). For our purposes, a mid-level WBS is one that shows the goal at level 0, major functions at level 1, and subfunctions at level 2. Generally, such a WBS would have a two- or three-level decomposition. The number of levels is not important. What is important is to have at least one level of decomposition for each functional requirement. At this point any more WBS detail is not con- sidered useful. The reason for that will become clear in the Cycle Plan phase. The traditionalist would have a problem with this because the entire founda- tion of traditional project planning and scheduling is based on having a com- plete WBS. We contend that the time spent creating a complete WBS at this stage is largely a waste of time. Again, we remind you, why plan for the future when you don’t know what it is? In our case, the piece that is missing is that we are not exactly sure how we are going to deliver the functionality. We do know what functionality has to be delivered, and we are using that information to generate the mid-level WBS but not the complete WBS. The complete WBS will eventually be generated when we know enough to generate it. That will hap- pen within repeated iterations of Cycle Plan–Cycle Build–Client Checkpoint Introduction to the Adaptive Project Framework 271 16 432210 Ch13.qxd 7/2/03 9:33 AM Page 271 phases. We will generate it when we need it and not before, and when we do generate it, we will know that it is correct and not a guess. The fourth deliverable from this phase is a prioritization of the variables that define the scope triangle (time, cost, resources, scope, and quality). This prior- itization will be used later as an aid to decision making and problem solving during 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 are needed to take advantage of the business opportunity or solve the business problem. (Again, for a complete discussion of the POS see Chapter 3.) Some high-level planning is done very quickly to prioritize the functionality into a number of time-boxed cycles for development. Typical cycle length is 2 to 6 weeks. This cycle length is documented and agreed to by both parties—along with the expectation that it will change as project work commences. The Cycle Plan phase will be repeated a number of times before this project is complete. The first Cycle Plan phase has as input the POS, the prioritized scope 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 low- tech operation. While you could certainly use project management software tools, we have found that a whiteboard, Post-It notes, and marking pens are just 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 may sound 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 be several small teams (a typical small team will be one architect and two or three software engineers), each working in parallel but independently on a separate piece of functionality. Each of these small teams will plan the cycle build 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. Chapter 13 272 16 432210 Ch13.qxd 7/2/03 9:33 AM Page 272 3. Establish the dependencies among these tasks. 4. Partition the tasks into meaningful groups and assign teams to each group. 5. Each team develops a micro-level schedule with resource allocations for the completion of their tasks within the cycle timebox and budget constraints. There is no critical path to calculate and manage. Traditionalists would have a problem with this. Their approach is based on managing the critical path. We could certainly calculate one here and maintain it, but we believe that is overkill. The cycle is so short that too much planning and analysis leads to paralysis. We don’t need to clutter the cycle with non-value-added work. The entire 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 can post their plans, work schedules, Scope Bank, Issues Log, and so on, and have their daily 15-minute updates, weekly status meetings with the client, and problem-solving sessions here. Cycle Build Detailed planning for producing the functionality assigned to this cycle is con- ducted. The cycle work begins and is monitored throughout the cycle, and adjustments are made as necessary. The cycle ends when its time has expired. Any functionality not completed during this cycle is reconsidered as part of the functionality in the next cycle. The first activity in the Cycle Build phase is to finish the cycle build schedule and 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 at the completion of every day. Any variances are caught early, and corrective action plans put in place. Nothing escapes the attention of the project manager for more than one working day. A Scope Bank is created to record all change requests and ideas for functional improvements. An Issues Log records all problems and tracks the status of their resolution. CROSS-REFERENCE The Issues Log is discussed in detail in Chapter 16. Client Checkpoint The client and the project team jointly perform a quality review of the func- tionality produced in the just competed cycle. It is compared against the over- all goal of maximum business value, and adjustments are made to the Introduction to the Adaptive Project Framework 273 16 432210 Ch13.qxd 7/2/03 9:33 AM Page 273 high-level plan and next cycle work as appropriate. The sequence Cycle Plan–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 every Cycle 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 to delivering certain functionality will be suggested, and the client will learn through his or her continuous involvement with the team. All of this must be considered along with the functionality that had originally been assigned to the next cycle. The result is a revised prioritization of functionality for the next cycle. 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 in the final solution. We don’t dismiss this as being an easy exercise. It definitely isn’t. Most of the difficulty stems from either the client or the project team not approaching reprioritization with an open mind. People tend to get wedded to their earlier ideas and are hard-pressed to give them up in favor of others. To be successful with 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 continu- 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 taken place to date and with the collaborative support of the project team. They understand 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 in the project even to the level of operating as a co-project manager. Their pres- ence will be a constant reminder to the team of the business aspects and value of what they are doing and what changes should be made to protect that busi- ness value. This client involvement is a very important point to remember. It ensures that what is eventually built will meet client needs. 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 project was undertaken in the first place. Think of these outcomes as success criteria. Chapter 13 274 16 432210 Ch13.qxd 7/2/03 9:33 AM Page 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 the project impacting market share. It won’t happen next Tuesday. It may happen several 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 marks the end of the project. Some functionality that was planned to be completed may not have been completed. The main focus of the post-version review is to check how you did with respect to the success criteria, to document what you learned that will be useful in the next version, and to begin thinking about the functionality for the next version. What the client and the project team believe to be the best mix of functionality has been built into the solution. The project is done. The deliverables are installed, and the solution is in production status. At this stage, three questions need 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 the project in the first place. If it was achieved, chalk that one up on the success side of the ledger. If it wasn’t, determine why not. Can something further be done 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 send good money after bad money. There is also a lesson here for all of us. If projects are limited in scope and they fail and there is no way to rescue them, we have reduced the dollars lost to failed projects. The alternative of undertaking larger projects is that we risk losing more money. If there is a way of finding out early that a project isn’t going 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 and save 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 16 432210 Ch13.qxd 7/2/03 9:33 AM Page 275 The APF Core Values APF is more than just a framework. It represents a way of thinking about clients and how best to serve them. This way of thinking is embodied in the six core values described in the sections that follow. These core values are immutable. They must be practiced in every APF project. No exceptions. In time the APF teams will be recognized for the visible practice of their core values. We have had occasion to work with teams that periodically reward team 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 opera- tive part of truly being client-focused. This value is the most important of the core values. The needs of the client must always come first, as long as they are within 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 obvious through our actions with one another and through our interactions with our clients. Don’t think that we are advocating passive acceptance of whatever the client might request. Client-focused also means that we have their best interests at heart. In a spirit of openness, we are obligated to challenge ideas, wishes, and wants 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 reasons and to always act with integrity. Client-Driven One of the guiding principles of our business has always been to engage the client in every way that we could. We want them not only to be meaningfully involved but to also have the sense that they are determining the direction that the project is taking. At the extreme, this value would mean having the client take on the role and responsibilities of the project manager. Such an extreme will not happen very often, but there are occasions when this will occur. An effective arrangement is to have co-project managers—one from the client and one from your organization. In this arrangement, both individuals share equally in the success and failure of the project. There is a clear and established co-ownership. Practice tells us that this is a key to successful implementation. We say that this is a key factor to successful projects. Chapter 13 276 16 432210 Ch13.qxd 7/2/03 9:33 AM Page 276 [...]... Force Ranking of 10 Pieces of Functionality FUNCTIONALITY # A B C D E F RANK SUM FORCED RANK 1 2 5 3 2 1 6 19 2 2 4 3 2 7 9 10 35 6 3 7 4 9 8 6 3 37 7 4 1 8 5 1 2 2 19 3 5 3 6 8 4 7 5 33 5 6 8 9 10 9 10 8 54 9 7 5 1 1 3 3 4 17 1 8 6 2 4 5 4 1 22 4 9 10 10 7 10 8 9 54 10 10 9 7 6 6 5 7 40 8 290 Chapter 14 The individual rankings from each of the six members for specific functions (or subfunctions) are... management colleagues You have noticed a number of projects where the client has requested and gotten approval for several changes throughout the project These have cost significant money and time, the loss of e-business market share, and the subsequent loss of revenues As Director of the Project Support Office, you have come to realize that APF is the approach that should have been taken on this project. .. forward with mid-level project planning Identifying the Business Problem or Opportunity A well-defined need and a clear solution pathway planned to meet that need define a project that the traditionalist would die for A rather vague idea of a want coupled with a vague idea of how it will be satisfied define a project that the agilest (an agilest is one who aligns their project management approach with... new way of thinking about an important class of projects It is our hope that you find it a valuable addition to your arsenal Discussion Questions 1 Under your leadership, your organization has spent considerable effort to adopt a traditional approach to project management It has reached maturity level three, that is, there are fully documented project management processes and templates and everyone... will do it for the entire project using a complete version of the WBS As noted in the previous chapter, the project manager using APF (APFist) works only on the part of the WBS that corresponds to the work that will be done in the cycle coming up Anything beyond that would be conjecture on the part of the APFist The second difference is that the traditionalist will use project management software, while... difference is that the traditionalist will use project management software, while the APFist will use a whiteboard, Post-It notes, and marking pens The APFist could use project management software, but it is not necessary In fact, using project management software to do cycle planning is like killing mosquitoes with sledgehammers Remember that cycle length is typically around two to six weeks, and that is... this property, and so the term task is a precise term in our project management vocabulary CROSS-REFERENCE discussed in Chapter 4 See that chapter for more The completion criteria are fully details Micromanaging an APF Project Remember that every activity that you define in the low-level WBS must be managed That opens up the possibility of micromanagement We want to make sure that the final decomposition... Facilities Project work takes place in locations Planning rooms, conference rooms, presentation rooms, and auditoriums are but a few examples of facilities that projects require The exact specifications as well as the precise time at which they are needed are some of the variables that must be taken into account The project plan can provide the detail required The facility specification will also drive the project. ..Introduction to the Adaptive Project Framework 277 Incremental Results Early and Often In the spirit of prototyping, we want to deliver a working application to the client as early as possible This early delivery is especially valuable when... what this project intends 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 major segment of the problem or opportunity We say this because all too often we define projects that are far too large in scope That opens us to scope creep and changes in the environment that render the global solution ineffective or . deliverables. The result is to change the project going forward in the next cycle. Introduction to the Adaptive Project Framework 277 16 432210 Ch13.qxd 7/ 2/03 9:33 AM Page 277 Don’t Speculate on the Future APF. 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 16 432210 Ch13.qxd 7/ 2/03 9:33 AM Page 275 The APF. Adaptive Project Framework (APF). This is definitely not your father’s project management. It’s new. We don’t even use the word management. APF represents a shift in thinking about projects