Effective_Project_Management_Traditional,_Agile,_Extreme_by_Robert

Chapter 12 ■ Comparing PMLC Models 407 final solution—that is, in each cycle include in your detailed plan only what you know to be factual. So, planning is done in just-in-time segments where a cycle includes work that will require only a few weeks to complete. A cycle is so short that it typically will not meet the duration requirements to be called a project. So while a cycle will use many of the tools, templates, and processes of a more traditional approach, it is a unique artifact of an APF project. Change Is Expected Unlike in the Linear and Incremental PMLC models where you treat scope as fixed and hope to avoid change, the Agile and Extreme PMLC models require change in order for the project to be successful. In these two model types change is what leads to the discovery and learning of missing features and functions (Adaptive PMLC models) or clearer focus on the goal (Extreme PMLC models). Two useful metrics to track from cycle to cycle are the number of additions to the Scope Bank at each cycle and the number of additions that result in further defining the solu- tion at each cycle. These metrics are discussed later in this section. Change in a complex project is encouraged through frequent release of prod- uct or process in order to solicit input for further change. Without that input a complex project is likely to fail. The meaningful involvement and collaboration of the client team is critical to that change process. The APF Project Contract This is perhaps the most difficult part of an APF project to justify to managers whose mind-set is in the TPM world. Simply put an APF contract says that with meaningful client involvement the contract will deliver the most business value within the limits of client-specified time and cost constraints. Or stated another way, the client doesn’t know exactly what will be delivered at the end of the project but only that it will be the most business value possible and that they will have played a critical role in that determination. For the time and money invested the client will get as much of the solution as they possibly can with the knowledge they and the development team has of the situation. What this all boils down to is the need for trust and openness between the client team and the development team as well as between the co-project managers. Remember that the APF project must be done. You can’t wait until somebody figures out what the requirements are. That will never happen. You must proceed with the project based on incomplete information. Your expectation is that the approach you have chosen will bring the missing functions and features into focus and the project can deliver acceptable business value.

408 Part III ■ Complex Project Management An APF Project Is Mission Critical Given the preceding it is unlikely that an APF project is anything but critical to the enterprise. The situation is this: ■ No complete solution is known ■ The risk of finding a complete solution is high ■ The success of the project is critical ■ None of the familiar Linear and Incremental PMLC models will work ■ APF is the only model that offers any hope of finding an acceptable solu- tion or partial solution So while APF may not be the silver bullet you are hoping to find, it is your only alternative. An APF approach will deliver as much business value as is possible. Through a collaborative effort of the client team and the development team, the best solution humanly possible will emerge. It may not be the perfect solution, but it is the best that could be done. The expectation is that with actual experience using the solution, a second and succeeding versions can be justified. The Role of the Client and the Project Manager in an APF Project In the absence of meaningful client involvement it would be foolish to use an APF approach. In fact, without meaningful client involvement, it would be risky to undertake any project regardless of the model being used. Every PMLC requires some level of client involvement. For an APF project, however, there is much more to say about the role of the client co-manager and the role of the development co-project manager. It is best to think of the two as sharing the responsibilities of the project manager—they become co-project managers but with distinct responsibilities. In an APF project the manager of the development team assumes more of an advisory role. They keep the client team pointed in feasible directions and further advise the client on the best choice from among a number of feasible alternatives. The client, however, makes the final decision among the set of alter- natives. For some traditional project managers this role will be difficult to accept. Rather than being in charge they are going to have to share responsibility for leadership and decision making. For some clients, too, this role will be difficult to accept. Rather than deferring to the project manager they are going to have to be meaningfully involved and make decisions. Project success or failure is shared between the client team manager and the development team manager. From the client side the role is different than the project manager would be accustomed to. The first difference is that the traditional project manager has to quickly get used to the fact that they are no longer in charge of the project—at

Chapter 12 ■ Comparing PMLC Models 409 least not by themselves. They now share that responsibility with the client. There is no finger pointing except at themselves. Different isn’t it? This client side accountability is one of the strengths of APF. Both project manager and client have a vested interest in the success of the project. What otherwise might have been an obstacle to implementation success fades into oblivion. The second difference is that the client has to be willing to step forward and clearly and openly state their opinions. Their relationship with the project man- ager and the team must be open. They must feel like an equal with the team. They can no longer hide behind the excuse that this is a technology project and they don’t understand technology. This is a business project and they have as much say and as much authority as does anyone else on the project team. A great synergy can be created between two parties with totally different perspec- tives on the same project. Find a way to leverage that power to the advantage of your organization. APF Is Not a Recipe to be Blindly Followed I am not in the recipe business. You won’t find endless lists of things to do in an APF project. That would be a waste of time and the APFist doesn’t waste time. As you read and study the pages that follow, expect to learn how you, an APF co-project manager, need to start thinking about what you are doing and how you are working together with your co-manager. If something either of you are doing doesn’t make sense, it probably doesn’t and should be changed or not done at all. As an APF co-project manager you will know how to recognize these situations and invoke the proper change. For some traditional project managers this continues to be a difficult adjustment. They would rather not have to think about what to do but merely follow a recipe. I want you to start thinking about creating a recipe from the ingredients you have at your disposal. That way you will be able to take charge of the project rather than being victimized by it. If you need a recipe to manage your project, APF is not for you. The effective APF co-project manager is a senior level manager who not only has command over an extensive collection of tools, templates, and processes but more impor- tantly knows when to use them, how to use them and how to adapt them—this type of co-project manager is the chef I talked about earlier! Why Do We Need APF? APF offers a unique approach to a category of projects that other approaches and models do not. APF was designed for non-software development projects and has been used successfully on process and product design and improve- ment projects and a variety of R & D projects as well. These are critical mission projects whose solutions are not completely known and can only be known by

410 Part III ■ Complex Project Management doing the project. These are projects for which TPM approaches will not work. They are projects that must be done and some way of doing them effectively must be devised. You have no choice! That need gave rise to APF. APF is not the only agile project management methodology. But APF is unique in that it was designed for any type of project not just software development projects as all of the other agile methodologies are restricted to. The use of co-project managers and probative swim lanes are two of the unique artifacts of an APF effort and set APF apart from all other Agile PMLC models. Benefits of APF versus Other Approaches APF brings a lot of business value to the table as compared to other approaches as is discussed in the following sections. APF Projects Always Finish Sooner Than TPM Projects If it were possible to do the same project twice—once using a TPM Linear PMLC model and once using APF—the APF project would finish sooner every time. The reason for this is obvious. Because APF squeezes out all non-value-added work (Yes, it is a lean framework!), it has less to do than those projects that fol- low more traditional approaches. The time spent planning is a good example. Linear and Incremental PMLC models plan the entire project, and then when change comes along and is approved, the plan has to be redone from the point of the change to the end of the project. That is repeated several times through- out the project. That means much of the original planning work turns out to be non-value-added work. The more change that is approved the more non-value- added work there will have been. APF has none of this excess baggage and is therefore guaranteed to finish sooner than traditional approaches. APF Projects Are Less Expensive Than TPM Projects Non-value-added work costs money. There is at least a labor cost for the time spent planning activities and tasks that are never done due to frequent scope changes. This wastes money in the end. APF Projects Have a Better Business Termination Policy Than TPM Projects Most distressed or failing TPM projects are terminated too late because by the time it is discovered that the project isn’t producing the desired results and should be terminated the available budget and time are nearly expended. That happens because the first deliverables come very late in the project life cycle. Most of the money and time have already been spent. Not so with APF. APF delivers early and often. If anything is going awry, it will be discovered earlier than in a TPM project. The APF project will terminate before any additional time or money will be spent needlessly. That doesn’t mean the project won’t

Chapter 12 ■ Comparing PMLC Models 411 be done. It means that the project won’t be done in the way it was originally planned. Some other approach using APF is needed, and the time and money saved by this early termination will be invested in the search for a solution in a different direction. The APF Project Produces Higher Quality Deliverables Than the TPM Project The elevated level of client involvement in an APF project means that the cli- ent will have a look at intermediate deliverables early in the project and have an opportunity to adjust them. The quality of the final product will therefore exceed that of a TPM project. TPM projects all suffer from the effects of scope change. The initial design will be compromised due to the changes. The more frequent the changes the more the design is compromised. The final TPM solution, if there even is a final solution, will be a patchwork solution. The APF Project Delivers Maximum Business Value for the Time and Cost Invested The continual adjustment and redirection of an APF project means that every- thing that is delivered is needed and is of the quality expected by the client. The client in collaboration with you decides what goes into the solution at every iteration. Poor or less than expected deliverables will not survive the APF project life cycle. If an APF project is terminated, at least you will have a partial solution with some business value. Core Values of APF As you can see, APF is more than just a framework. It represents a way of think- ing about clients and how best to serve them. The client is the center of attention in an APF project. They control the direction of the project and determine where business value can be created or increased. The APF project continues at the client’s discretion and with their approval. This way of thinking is embodied in the six core values described here. 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. I have had occa- sion to work with teams that periodically reward team members for practicing the APF core values above and beyond the call of duty. The core values are that important. Client-Focused While I was looking for the appropriate name for this core value, the phrase “walk in the shoes of the client” was always on my mind. It still is an operative 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

412 Part III ■ Complex Project Management the bounds of ethical business practices. This value can never be compromised, and it goes beyond simply keeping it in mind. It must be obvious through your actions with your fellow development team members and through your interac- tions with all of the members of the client team. A client-focused attitude will be a radical behavioral change to those few project managers who are clinging to old practices. I have some clients who provide templates for their clients to use to submit a description of what they want and of what business value it will be. I’ve seen questions such as: What other systems will the requested system impact? How they expect the client to answer that question is beyond me. Some can, but I suspect most cannot. Others will make the process a little less painful by assisting the client with filling out the document. Better, but not the best. That approach still assumes that the cli- ent can in fact state what they want (or to be more precise what they need). Few clients will be able to do that because of the complexity and uncertainty that pervades today’s projects. The simple projects have all been done many times. Best would be to engage the client in discussions about their needs and from that forge a strategy for going forward. Don’t think that I am advocating passive acceptance of whatever the client might request. To do so would border on dereliction of duty. Client-focused means going way beyond doing what they have asked of you. It also means that you are protecting their best interests. In a spirit of openness, you are obligated to challenge ideas, wishes, and wants whenever you believe such challenge is called for. Your goal is to maximize business value to the client even if you have to push back on their requests. You have to own the solution just as much as the client has to own the solution. To do otherwise is not part of being client- focused. You want to do the right things for the right reasons and to always act with honesty and integrity. Client-Driven One of the guiding principles of my business has always been to engage the client in every way that I could. I 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. I’ve been in such situations only a few times in the last 20 years of consulting and practicing project management. It is an awesome experience! It does require a complete change of mind-set from one that is directive to one that is supportive. Such an extreme will not happen very often, but there are occasions when this will occur. As middle ground an effective arrangement I insist on with my clients is to have co-project manag- ers—one from the client side and one from my organization. I have insisted on this for my entire career in project management. In this arrangement, both individuals share equally in the success or failure of the project. There is a clear

Chapter 12 ■ Comparing PMLC Models 413 and established co-ownership. My own practice with my clients tells me that this is a key to successful implementation. The client will have a vested interest in the success of the project and will do whatever is necessary to assure success. Their reputation and credibility is on the line just as mine is on the line. I say that this is a key critical success factor for a successful APF Project. For many clients in organizations early in their history of APF adoption there is a learning curve that you will have to pay attention to. The first APF project you undertake with a client should be prefaced with a workshop to help them not only understand what APF is and why APF is being used but more impor- tantly how they can be a good client in an APF project. For the second and later projects with this client you can expect more from them. Eventually you may even move them to the position of being the project manager with you acting as advisor, coach, and mentor. Being the product owner in a Scrum project would be the final step in the growth and development of the client as a contributing member of an agile project team. Incremental Results Early and Often In the spirit of prototyping, in an APF project you want to deliver a working solution to the client as early and often as possible. This early delivery is espe- cially valuable when there is any question that the real needs of the client have not yet surfaced despite your best efforts. The functionality of the first cycles of the project may be very limited but useful in any case. In some cases, the first iteration might be a proof of concept. It should deliver business 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 work with something concrete is always better than asking them to react to some vague concept or sketch on the back of a napkin or buried in a lengthy functional specification. Early and often helps get the client meaningfully engaged and keeps them engaged throughout the project. It creates an ownership on the part of the client. This is critically important to the success of the project. Without the cli- ent’s meaningful participation an APF project is doomed to failure. They must understand this, and you must facilitate it. If you can’t get that involvement, use some other approach. APF is not the way to go. Continuous Questioning and Introspection This core value speaks to an openness and honesty that must exist between the client team and the development team. Both parties must be committed to making the best business decisions possible. That can only happen with hon- est and open dialog. Personalities have to be put aside if this environment is to be realized. Building a solution iteratively affords the opportunity to be creative. It creates the opportunity to adjust as better and more valuable features or functions are

414 Part III ■ Complex Project Management discovered. As the cycle build proceeds, both the client team and the develop- ment team should always be looking for improvements in the solution or the functionality and features being offered. Look back at previous cycles and ask whether what was done was the best that could have been done. All of this learning and discovery will be captured in the Scope Bank (See Chapter 6) and come together in the Client Checkpoint Phase (discussed in the “APF Project Execution” section later in this chapter). Here is where the client and your proj- ect team propose, discuss, and approve further solution development efforts. A true spirit of openness must exist. Neither party should be afraid to offer or challenge an idea or the real value of some present or future deliverable. I’ve frequently told teams that if anyone of their members had an idea and didn’t share it with the rest of the team I would consider that dereliction of duty. Some think that coveting knowledge is a source of power. In the APF project that is the kiss of death! The same is true for the client. The successful practice of this core value is heavily dependent on the existence of a true team environment. Change Is Progress to a Better Solution One of my colleagues, is often heard saying, “You’re always smarter tomorrow than you are today.” He is referring to improving task duration estimates over time, but his comment applies to APF as well. The Version Scope Phase begins with the requestor and provider coming to a definition of what is needed and what will be delivered through the Conditions of Satisfaction (COS) experience (see Chapter 4). Despite their best efforts, all the two parties have done to this point is take the best guess they can as to what will be done. That guess may turn out to be a very good guess or only a partial guess, but that is not important. What is important is that by working with the deliverables from the earlier cycles both parties will get a better picture of what can still be delivered. They will be smarter as a result of their experiences with the deliverables from the earlier cycles. The result is to improve the solution going forward into the future cycles. While change is needed to reach the best solution, too much change sends a very different message. One of the metrics I advise my clients to use is to track the frequency of change requests over time. The expectation is that the solution is converging on the final solution. This is evidenced first by an increasing number of change requests from cycle to cycle and then a decreasing number of change requests later in the project. If this is not happening, there is a likelihood that the project is not converging on an acceptable solution but rather is diverging. Don’t Speculate on the Future There will always be the temptation to envision the future. I have seen that thinking invade client team and development teams but not for good reasons. It is often seen as inevitable and invades the WBS and other aspects of project management. An APF team must resist that temptation. APF strips out all non- value-added work. Guessing the future only adds non-value-added work back

Chapter 12 ■ Comparing PMLC Models 415 in. So, when in doubt, leave it out. APF is designed to spend the sponsor’s time and money on producing business value rather than on non-value-added work. N O T E When in doubt, leave it out. If you find yourself building the RBS or the WBS and you or the client is guess- ing at what should be included, you are probably using the wrong approach. The high-level RBS is the best input for deciding on the best-fit PMLC model. An Overview of the APF Life Cycle The stage is now set for our first look at APF. Figure 12-16 is a graphic portrayal of the Project Setup and Project Execution parts of APF. First, note that APF, like all Agile PMLC models, is an iterative process. You iterate within a cycle and between cycles. Every cycle presents the development team and the client team 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 real- ize that defining the cycle content for learning and discovery is its real strength. It sets APF apart from all the other PMLC models. Project Setup Conduct Conditions of Satisfaction Elicit requirements Assess completeness of requirements Classify project in the landscape Determine best-fit PMLC Model Assess project characterisitcs Choose and modify specific PMLC approach Version Scope Project Execution Cycle Plan Cycle Build Checkpoint Version Close Figure 12-16: APF life cycle

416 Part III ■ Complex Project Management APF Project Setup Project Setup is unique to APF. It is based on the assumption that the unique- ness of the project drives the uniqueness of the project management model. As shown in Figure 12-16 it consists of the following: ■ Conduct Conditions of Satisfaction (See Chapter 4.) ■ Elicit requirements (See Chapter 4.) ■ Assess completeness of requirements (See Chapter 4.) ■ Classify project in the landscape (See Chapters 1 and 2.) ■ Determine the best-fit PMLC model (See this chapter.) ■ Assess project characteristics (See Chapter 1.) ■ Choose and modify specific PMLC approach The defining factors here will be: ■ The conditions needed to support the chosen PMLC model are not present—Training, training, and more training will usually resolve this obstacle. If the client is the problem, I have conducted training in parallel with Project Execution and workshops aligned to every phase. If the team is the problem, the short-term solution is probably to outsource those areas where the needed skills and competencies are lacking. ■ The internal environment does not support the needs of the chosen PMLC model—This can be a showstopper for a complex project. The sponsor, client, and other senior managers need to be aware of the potential risks and your recommendation for mitigating these risks. ■ The external environment is volatile—Shorter duration projects and shorter duration increments, iterations, and cycles are the best protection against the effects of market changes. APF Project Execution Now that the best-fit PMLC has been chosen and adapted to the project charac- teristics and the internal/external environments, it is time to execute the project. Project Execution is a robust process that includes all PMLC models and any adaptations that have been made as special cases. But that execution is not a static effort. Note the feedback loop from the Checkpoint in Project Execution to the Assess Completeness of Requirements in Project Setup. Included in the Checkpoint is a review of the current solution with respect to current require- ments and that can lead to a change in the best-fit PMLC model. Version Scope An APF project begins with a stated business problem or opportunity. This beginning is the same as a TPM project. A request has been made to develop a

Chapter 12 ■ Comparing PMLC Models 417 solution to the stated problem or business opportunity. At this point, you are not at all sure what kind of project this might be or how you might approach it from a methodology perspective. A Conditions of Satisfaction (COS) conversa- tion 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. A Requirements Gathering session may be held and an RBS constructed. The RBS is the input to the decision as to which project management category the project belongs in: TPM, APM, xPM, or MPx. Once the category is chosen the project character- istics are used to decide which model is a best fit. For the sake of this section, you discover or suspect that the RBS is not complete, and the missing functions and features suggests an APM approach is to be taken. You have chosen APF, so a project scoping document, specifically, a POS, is written. A POS basically summarizes the COS and RBS, if either is available. The POS is a brief (usually one page, with perhaps an attachment) document that contains the following five sections: ■ 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 functional- ity that has been requested and agreed to in the COS. The RBS contains this information. Both parties recognize that this list may change, but at this point in the project, the list reflects the best information available; however, it is prob- ably incomplete. There may be additions, deletions, and changes as the project commences. The third deliverable from this phase is the mid-level WBS. Since the RBS is incomplete, the WBS will also be incomplete. If an RBS exists, it may be used as the starting point for defining the WBS. The RBS will specify what is to be done, and the WBS will further decompose the RBS to define how it will be done. For purposes here, a mid-level WBS is one that shows the goal at level 0, major functions at level 1, and sub-functions 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 to the work level for as many functions and features that have been identified. At this point any more WBS detail is not considered useful. The reason for that will become clear in the Cycle Plan phase. The traditionalist would have a problem with this because the entire foundation of traditional project planning and scheduling is based on having a complete WBS. I contend that the time spent trying to create a complete WBS at this stage is largely a waste of time. Again, I remind you, why plan for the future when

418 Part III ■ Complex Project Management you don’t know what it is? In this case, the piece that is missing is that you are not exactly sure how you are going to deliver the functionality. You do know what functionality has to be delivered, and you 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 happen within repeated iterations of Cycle Plan–Cycle Build–Client Checkpoint phases. You will generate it when you need it and not before, and when you do generate it, you 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, resource availability, scope, and quality). This prioritization will be used later as an aid to decision making and problem solving during the Cycle Build phase. Cycle Plan The POS has been written and is presented along with a prioritized list of known functionalities that the client and the project manager believe are needed to take advantage of the business opportunity or solve the business problem. Some high-level planning is done very quickly to prioritize the functionalities into a number of timeboxed 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. So far we have been discussing specific cycle contents that relate to adding detail to the evolving solution. There is another aspect of the cycle contents that is equally important. Think of a cycle as containing two major swim lanes. These are streams of build activities that occur in parallel. One swim lane is devoted to adding more detail to the evolving solution. These are called integrative swim lanes. The other swim lane is devoted to discovering aspects of the solution heretofore unknown. These are what I call probative swim lanes. There may be several occurrences of each type of swim lane in a single Cycle Build Phase. They might be the search for an answer to a question like: I wonder if this is the way to solve that part of the problem? Or, I wonder if this would work? In the probative swim lanes you are calling on the problem-solving and cre- ative skills of the client team and development team. In the integrative swim lanes you are calling on the implementation and process skills of the client team and the development team. Different skill sets are needed for each type of swim lane. The challenge is to build a team that has both sets of skills. I don’t dismiss this as being an easy exercise. It definitely isn’t. Most of the dif- ficulty stems from either the client team or the development team not approaching reprioritization with an open mind. People tend to get wedded to their earlier

Chapter 12 ■ Comparing PMLC Models 419 ideas and are hard-pressed to give them up in favor of others. To be successful with APF both the development team and the client team must have an open mind and not display pride of authorship on any previous functionality that was discussed. One of the greatest benefits from this approach is the meaningful and continu- ous involvement of the client. They are the decision makers in all activities going forward. They are doing it with full knowledge of what has taken place to date and with the collaborative support of the development team. They understand how business value can be achieved by changes in functionality, and they are in a position to take action. Their presence will be a constant reminder to the development team of the business aspects and value of what they are doing and what changes should be made to protect that business value. This client involvement is a very important point to remember. It ensures that what is eventually built will meet client needs. Cycle Build 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, I have found that a whiteboard, sticky notes, and marking pens are just as effective. It does keep the maintenance of a project file down considerably and allows the team to focus on value-added work. This advice may sound heretical to those of you who are project management software aficionados, so let me explain. Cycle length generally falls within a 2- to 6-week time frame. There will likely be several small teams (a typical small team will be one designer and one or two developers), 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. Under the guidance and advice of the client team, extract from the WBS those activities that define the features and 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 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. The longest duration swim lane is the critical path. Pay attention to it! The cycle is so short that too much planning and analysis leads to paralysis and, worst of all, non-value-added work.

420 Part III ■ Complex Project Management Take the low-tech approach it will work just fine here. You don’t need to clut- ter the cycle with non-value-added work. The entire effort can be whiteboard-, sticky note-, and marker pen-based. A dedicated war room would be helpful (about 300 square feet of floor space should be adequate). 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. Detailed planning for producing the functionality assigned to this cycle is conducted. 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 and repri- oritized for later consideration. The Cycle Build timebox is never changed once the Cycle Build Phase begins. 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 statuses at the completion of every day. Any variances are caught early, and corrective action plans put in place. Nothing escapes the attention of the co-project man- agers 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. Client Checkpoint Without a doubt this is the most important phase of APF. In this phase the cli- ent team and the development team come together and assess what has been accomplished, what has been discovered and learned from the just completed cycle, and what should be done in the cycle to come. The client team and the development team jointly perform a quality review of the features and functional- ity produced in the just completed cycle. It is compared against the requirements and its part in the solution and the overall goal of maximum business value. Adjustments are made to the high-level plan and next cycle work as appropri- ate. The sequence Cycle Plan–Cycle Build–Client Checkpoint is repeated until the time and cost budgets for this version have been expended, or the project should be terminated because it is not converging on an acceptable solution, or an acceptable solution has been reached for this version and no further work is needed. The Client Checkpoint Phase is a critical review that takes place after every Cycle Build Phase is completed. During the Cycle Build Phase, both the client team and the development team will benefit from several discovery and learn- ing episodes. Variations to the version functionality will surface; alternative approaches to delivering certain functionality will be suggested, and both teams will learn through their continuous involvement with the other team. There is a definite synergy that will develop between the two teams. All of

Chapter 12 ■ Comparing PMLC Models 421 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. For the next cycle, prioritize only the functionality that you are certain will be in the final solution. That newly prioritized list will be input to deciding on the integrative swim lanes for the coming cycle. The learning and discovery from the just completed Cycle Build Phase will be input to deciding on the probative swim lanes for the coming cycle. The available resources and the resource requirements of the prioritized integrative and probative swim lanes will dictate the contents of the coming cycle. Version Close During the Version Scope Phase, you 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. 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 measured 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 time frame is part of the success criteria statement as well. When the budget and time allotted to this version have been spent, that marks the end of the project. Some functionality that was planned to be completed may not have been completed. It will be archived in the Scope Bank for con- sideration in the next version. 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 team and the development team believe to be the best mix of functionality has been built into the solution. The project is done. The deliver- ables 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 everyone. If projects are limited in scope and they fail and there is no way to rescue them, you have reduced the dollars lost

422 Part III ■ Complex Project Management to failed projects. The alternative to undertaking larger projects is that you 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 losses. The same logic works from cycle to cycle. If you can learn early that a version will not work, kill the version and save the time and cost of the later cycles. 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. Extreme PMLC Model While Agile PMLC models apply to projects whose solutions are not completely known, Extreme PMLC models apply to projects whose goals and solutions are not completely known. Oftentimes the goal of an Extreme project is nothing more than a desired end state. It might be achievable, but it may not be achievable as currently stated. Since there is no known solution at the outset, the achievability of the goal is not known. In an Agile project the solution converges through learning and discovery during iterations. In an Extreme project both the goal and the solution converge to a final goal and solution. That may or may not achieve the desired end state or expected business value. Obviously an Extreme project is much higher risk than an Agile project. Figure 12-17 illustrates the Extreme PMLC model. Scope Plan Launch Monitor Close Next Close Phase Phase Phase & Control Phase Phase N Project Y Figure 12-17: Extreme PMLC model Characteristics The best way to define an Extreme project is to consider its characteristics, which are discussed in the following sections. These characteristics will strike fear into the hearts of most, if not all, project managers. Make no mistake, Extreme projects are extremely challenging. Many will be canceled before they are com- pleted. For those that are run to completion, what they deliver may not at all reflect what you thought they would deliver. And then there is the question of the business value delivered. You may have found a $10,000 solution to a $1,000

Chapter 12 ■ Comparing PMLC Models 423 problem. In other words, the actual goal achieved may be quite different from the goal that was originally envisioned. That is the nature of Extreme projects, and that is where I begin the investigation of how xPM applies to them. High Speed The types of projects that are suited to xPM are groundbreaking, innovative, critical to an organization’s future, and otherwise very important to their spon- sors. That means that the results are wanted ASAP. Fast is good, and if your project can keep up this pace, you will be around tomorrow to talk about it. Slow is bad, and if that’s the pace of your project, you will be looking for something else to do with the rest of your life. Getting to market faster is a critical success factor in every Extreme project business endeavor. High Change The uncertainty about the goal or the solution means that as the project is under way, learning and discovery will occur, just as in APF projects. However, this happens with more regularity and frequency in xPM than in APF projects. The APF changes can be thought of as minor in comparison. The changes in an Extreme project may completely reverse the direction of the project. In some cases, the changes might mean canceling the current project and starting two or more projects based on the prior learning and discovery. For example, R & D projects are Extreme projects, and a discovery in one cycle through the five phases may cause the team and the client to move in a totally different direction in the next and later cycles. High Uncertainty Because an Extreme project is innovative and research-oriented, no one really knows what lies ahead. The direction chosen by the client and the project team might be 180 degrees out of phase with what they should be doing, but no one knows that at the beginning of the project. Furthermore, the time to complete the Extreme project is not known. The cost to complete an Extreme project is not known either. In short, there will be a lot of trial and error and a lot of false starts and killed projects. Strengths The strengths of the Extreme PMLC model are as follows: ■ Keeps options open as late as possible ■ Offers an early look at a number of partial solutions

424 Part III ■ Complex Project Management Keeps Options Open as Late as Possible You don’t want to miss any chances of finding a solution amidst all of the options you are investigating. Any idea that generates a probative swim lane must be pursued until there is no possibility that it can contribute to the solution. In planning an Extreme project, the project team will brainstorm possible solutions or solution components and prioritize the options. Starting at the top of the list, the team will launch Probative Swim Lanes in a further search. To eliminate a possible solution at this point means it will be replaced by an option of lesser priority. You don’t want to do that unless you are absolutely sure the possible solution is, in fact, not feasible. Offers an Early Look at a Number of Partial Solutions All of the options that were prioritized are being considered. One of them might spark an idea for several others not on the priority list. Remember that you are on a search for a solution that up until now has been elusive. If the solution were that simple, it would have already been discovered. Weaknesses The weaknesses of the Extreme PMLC model are as follows: ■ May be looking for solutions in all the wrong places ■ No guarantee that any acceptable business value will result from the project deliverables May Be Looking for Solutions in All the Wrong Places The early phases are critical. If you can legitimately eliminate all of the prioritized options, then you should kill the project and start over in another direction. No Guarantee That Any Acceptable Business Value Will Result from the Project Deliverables Even if you find a solution and clarify the goal that the solution satisfies, the project may still fail. The solution may satisfy a goal that doesn’t have sufficient business value, or the solution may be too costly for the goal it satisfies. Specific Extreme PMLC Models There are only two models that I am aware of. I offer my own model called INSPIRE. The other model is one developed by my colleague Doug DeCarlo in

Chapter 12 ■ Comparing PMLC Models 425 eXtreme Project Management: Using Leadership, Principles, and Tools to Deliver Value in the Face of Volatility (Jossey-Bass, 2004). INSPIRE Extreme PMLC Model By its very nature, an xPM project is unstructured (see Figure 12-18). xPM and Agile Project Management (APM) projects are both variations of the same theme: the learning and discovery of the solution during successive iteration, cycles, or phases moves the project forward. The INSPIRE Extreme PMLC model is an idea that I adapted from the Flexible Project model introduced in 2000 by Doug DeCarlo in his eXtreme Project Management Workshop. As Figure 12-18 illustrates, INSPIRE consists of four stages, which I am calling INitiate, SPeculate, Incubate, and REview (hence, the acronym INSPIRE). INitiate SPeculate Incubate REview Scope Plan Launch Monitor Close Next Close Phase Phase Phase & Control Phase Phase N Project Y Figure 12-18: The INSPIRE Extreme PMLC model INSPIRE is an iterative approach, just as all of the Adaptive PMLC models are iterative. INSPIRE iterates in an unspecified number of short phases (one- to four-week phases are typical) in search of the solution to some goal. It may find an acceptable solution, or it may be canceled before any solution is reached. It is distinguished from APM models in that the goal is unknown, or at best, someone has a vague, but unspecified, notion of what the goal consists of. Such a client might say, “I’ll know it when I see it.” That isn’t a new revelation

426 Part III ■ Complex Project Management to the experienced project manager—they have heard that many times before. Nevertheless, it is the project manager’s job to find the solution (with the client’s help, of course). APM models are further distinguished from INSPIRE in that INSPIRE requires the client to be more involved within and between phases, whereas the APM models require client involvement between cycles. Drug research provides a good example of the Extreme project. Suppose, for example, that the goal is to find a cure for the common cold. This is a wide-open project. Constraining the project to a fixed budget or fixed time line makes no sense whatsoever. More than likely, the project team will begin by choosing some investigative direction or directions and hope that intermediate findings and results will accomplish the following two things: ■ The just-finished phase will point to a more informed and productive direction for the next and future phases. In other words, INSPIRE includes learning and discovery experiences just as the Agile models do. ■ Most important of all, the funding agent will see this learning and discov- ery as potentially rewarding and decide to continue the funding support. There is no constrained scope triangle in INSPIRE as there is in Traditional Project Management (TPM) and APM projects. Recall that TPM and APM projects have time and funding constraints that are meaningful. “Put a man on the moon and return him safely by the end of the decade” is pretty specific. It has a built-in stopping rule. When the money or the time runs out, the project is over. INSPIRE also has stopping rules, but they are very different. The two INSPIRE stopping rules are as follows: ■ The first rule says that the project is over when a solution is found. If the solution supports a goal that has sufficient business value, the project is deemed a success, and the solution is implemented. If the solution does not support a goal that has sufficient business value, the project is deemed a failure, and it’s back to the drawing board for another try (perhaps). ■ The second rule says the project is over when the sponsor is not willing to continue the funding. The sponsor might withdraw the funding because the project is not making any meaningful progress. It is not converging on an acceptable solution and goal. In other words, the project is killed. Failure! The next sections take a high-level look at the four components of INSPIRE. INitiate INitiate is a mixture of selling the idea, establishing the business value of the project, brainstorming possible approaches, forming the team, and getting

Chapter 12 ■ Comparing PMLC Models 427 everyone on board and excited about what they are about to undertake. It is definitely a time for team building and creating a strong working relationship with the client. At this point, someone has an idea for a product or service and is proposing that a project be commissioned to investigate and produce it. Before any project will be launched, management must be convinced that it is an idea worth pur- suing. The burden of proof is on the requestor. He or she must document and demonstrate that there is business value in undertaking the proposed project. The Project Overview Statement (POS), which you used in both TPM and APM projects, is the documentation I recommend to sell the idea. There are some differences, however, in the INSPIRE version of the POS. Defining the Project Goal Unlike the goal of an Agile project, the goal of an Extreme project is not much more than a vision of some future state. “I’ll know it when I see it” is about the only statement of the project goal that could be made, given the vague nature of the goal as envisioned at this point in time. It has all the characteristics of an adventure in which the destination is only vaguely defined. You have to understand that the goal of an Extreme project unfolds along the course of the project life cycle. It is not something that you can plan to achieve—instead, it is something that you and the client discover along the way. That process of discovery is exciting. It will call upon all of the creative juices that the develop- ment team and the client team can muster. Contrast this to the project goal in an Agile project. In an Agile project, the goal is known—it’s the solution that evolves as the project unfolds. In general, the client is more directive in an INSPIRE project, whereas the team is more directive in an Agile project. At this early stage, any definition of the project goal should be a vision of the future. It would be good at this point to discuss how the user or client of the deliverables will use the product or service. Don’t be too restrictive. Keep your options open (or “keep your powder dry,” as one of my colleagues would say). Forming a vision of the end state is as much a brainstorming exercise as it is anything else. Don’t close out any ideas that may prove useful later. INSPIRE Project Overview Statement An example will help ground some of these new ideas. Suppose the project is to find a cure for the common cold. As discussed in earlier chapters of this book, the POS is a critical document in both the TPM and APM approaches. It is also critical in xPM projects. However, because the goal is known in both TPM and APM projects but is not known in xPM projects, there will be some differences in the POS. These differences are best illustrated by way of example. Figure 12-19 is the POS for the project to find a cure for the common cold.

428 Part III ■ Complex Project Management PROJECT Project Name Project No. Project Manager OVERVIEW Common Cold 02 - 01 Carrie deCure STATEMENT Prevention Project Problem/Opportunity There does not exist a preventative for the common cold. Goal Find a way to prevent the occurrence of the common cold. Objectives 1. Find a food additive that will prevent the occurrence of the common cold. 2. Alter the immune system to prevent the occurrence of the common cold. 3. Define a program of diet and exercise that will prevent the occurrence of the common cold. Success Criteria The solution must be effective for persons of any age. The solution must not introduce any harmful side effects. The solution must be affordable. The solution must be acceptable to the FDA. The solution must be easily obtained. The solution must create a profitable business opportunity. Assumptions, Risks, Obstacles The common cold can be prevented. The solution will have harmful side effects. Prepared By Date Approved By Date Earnest Effort 2-14-2013 Hy Podermick 2-16-2013 Figure 12-19: POS for the project to find a cure for the common cold The following brief descriptions of the INSPIRE POS elements will help you understand the differences between this type of POS and the one that’s used in TPM or APM projects. Problem or Opportunity Statement There’s nothing unusual here. This is a very simple statement of a problem that has plagued healthcare providers and moms since the dawn of civilization.

Chapter 12 ■ Comparing PMLC Models 429 Goal Statement This particular project is taking a calculated (or maybe wild a**) guess that they can establish a preventative barrier to the occurrence of the common cold. Unlike the goal statements in TPM and APM projects, no time frame is specified. That would make no sense for such a research project. Objective Statements These objective statements identify broad directions that the research effort will take. Notice that the format does not fit the S.M.A.R.T. characteristics defined in Chapter 4. In most cases, these objective statements will provide some early guidance on the directions the team intends to pursue. Unlike TPM and APM projects, these objective statements are not a necessary and sufficient set of objectives. Their successful completion does not ensure goal attainment. In fact, some of them may be discarded based on learning and discovery in early phases. Think of them as guideposts only. They set an initial direction for the project. Because the goal is not clearly defined, you can’t expect the objective statements to play the role that they do in TPM and APM projects. Success Criteria The goal statement might do just as well as any success criteria, so this part of the POS could be left blank. In this case, you have set bounds around the charac- teristics of an acceptable cure. Success criteria are a quantitative measure of goal attainment, and you don’t know what the final goal will be in an xPM project. Assumptions, Risks, and Obstacles There is no difference between xPM, TPM, and APM projects when it comes to this section. The statements given in the example lean heavily toward assump- tions. Having to make such assumptions happens to be the nature of this project. I have already discussed how risk increases as your project moves along the continuum from certainty to uncertainty. Some of that risk will be reflected in this section of the POS. Establishing a Project Timebox and Cost Contrary to an APM project, an INSPIRE project is not constrained by a fixed time frame or cost limit. It is best to think of the time and cost parameters as providing the project team with guidance about the client’s expectations. It is much like having the client say, “I would like to see some results within N months, and I am willing to invest as much as $X to have you deliver.” In reality, at each REview, the decision to continue or terminate is made. That decision isn’t neces- sarily tied to the time and cost parameters given earlier by the client. In fact, if exceptional progress toward a solution is made, then the client may relax either

430 Part III ■ Complex Project Management or both of the time and cost parameters. In other words, if the progress to date is promising, more time and/or money may be placed at the team’s disposal. Establishing the Number of Phases and Phase Length In the beginning, very short phases are advisable. I recall an xPM project in which the first few phases were very exploratory. With the collaboration of the client, we were searching for a feasible direction. For this project, the first few phases were one to three days in length. In the early phases, new ideas are tested, and many will be rejected. Proof of concept may be part of the first few phases. The team should not be committing to complex activities and tasks early on. As the team gains a better sense of direction, phase length may be increased. Specifying phase length and the number of phases up front merely sets expectations as to when and how frequently REview will take place. At each occurrence of a REview, phase length and perhaps the number of phases remaining may be changed to suit the situation. In an exploratory project, it would be a mistake to bind the team and the client to phases that do not relate to the realities of the project. Remember that flexibility is the key to a successful INSPIRE project. Cycle and iteration length in an APM project are more stable than phase length is in an xPM project. Trade-Offs in the Scope Triangle Despite the fact that INSPIRE is unstructured, it is important to set the priorities of the variables in the scope triangle. As project work commences and problems arise, which variable or variables are the client and the team willing to com- promise? As discussed in Chapter 1, the variables in any project are as follows: ■ Scope ■ Quality ■ Cost ■ Time ■ Resource availability ■ Risk In Chapter 1, you saw the scope triangle ranking matrix repeated here for convenience (Figure 12-20). It shows which of these variables is least likely to be compromised. Which would you choose to compromise first if the situation warranted it? The answer should depend on the type of project. For example, if the project involves con- ducting research to find a cure for the common cold, quality is the least likely to be compromised, and time might be the first to be compromised. But what

Chapter 12 ■ Comparing PMLC Models 431 if you knew that a competitor was working on the same project? Would time still be the first variable to compromise? Probably not. Cost might take its place, because time to market is now a critical success factor. Priority Critical (2) (3) (4) Flexible (1) X (5) Variable Scope X X X Quality Time X Cost Resource Availability Figure 12-20: Prioritized scope triangle variables Scope is an interesting variable in Extreme projects. Consider the example of finding the cure for the common cold again. Hypothetically, what if you knew that the competition was also looking for a cure for the common cold, and that being first to market would be very important? In an earlier phase, the team discovered not a cure for the cold but a food additive that arrests the cold at its current stage of development. In other words, the cold will not get worse than it was at the time the additive was taken. The early discovery also holds great promise to morph into the cure that you are looking for, but you need time to explore it. You feel that getting the early result to market now may give you a strategic barrier to entry, give the competition reason to pause, and buy you some time to continue toward the original goal. Therefore, the scope is reduced in the current project, and it is brought to a successful completion. A new proj- ect is commissioned to continue on the path discovered in the earlier project. SPeculate This component defines the beginning of a new phase and will always start with a brainstorming session. The input will be either a blank slate or output from the previous INitiate → SPeculate → Incubate → REview cycle. In any case, the project team, client, and final user of the product or service should participate in the brainstorming session. The objective of this session is to explore ideas and identify alternative directions for the next Incubate phase. Because an INSPIRE project has a strong exploratory nature about it, no idea should be neglected. Several directions may eventually be pursued in parallel in the next phase. Phase length, deliverables, and other planning artifacts are defined in the SPeculate stage as well.

432 Part III ■ Complex Project Management PIZZA DELIVERED QUICKLY PDQ: LOGISTICS SUBSYSTEM The Logistics subsystem is very complex. Although it may not seem obvious at first, the complexity begins with the goal statement. You probably prefer a goal statement that says something about the time from order entry to order fulfillment. Do you want to mini- mize this time? That is certainly what the pizza customer has in mind. Or would you rather minimize the time from when the order was ready to be delivered until the time it is deliv- ered? That is certainly what PDQ has in mind for delivery of a quality order. Your choice for which PMLC model to use is between APF and INSPIRE. Either model will work just fine. The choice might depend on which approach the client is most comfortable with. The word speculate conjures up deep thinking, carrying out due diligence on several alternatives, choosing one or more of those alternatives, and then simply taking your chances. You should hear yourself saying, “I wonder if this would work?” That is what the SPeculate stage of INSPIRE is all about. Defining How the Project Will Be Done The initial sense of direction for the team to take in the first phase of an INSPIRE project can vary considerably. A good approach is to use the POS objective state- ments as a guide. The POS can continuously be updated to reflect the current view of the project, and its objective statements can serve as a guide to what will be done. In later phases, the team and the client will have the benefit of learning and discovery from the prior phases. For the sake of discussion, I want to treat these two situations separately. In this section of the chapter, assume you are planning the first phase. Conditions of Satisfaction The COS was described in detail in Chapter 4 and will not be repeated here. Although the COS is a tool that produces a required deliverable in TPM and the APM, its use in xPM is optional. The COS loses its value as the goal becomes more and more elusive. If the client has only a vague idea about the goal, no amount of discussion about needs and deliverables will clarify the situation for either party, and the other planning artifacts described in the text that follows may be more useful in the initial SPeculate stage. If you choose to use the COS in your INSPIRE project, think of it as more of a brainstorming process. The project team and the client can investigate ideas en route to generating a list of what will be done in this phase. Prioritizing Requirements The collection of scenarios, stories, and use cases provides insight into the requirements that the deliverable should meet. For the client, it is far easier to prioritize the collection than it is to prioritize the requirements. Prioritization

Chapter 12 ■ Comparing PMLC Models 433 is the next step in the SPeculate stage. There are several ways to produce a pri- oritized list of items in the collection. Here are other aspects of the prioritization that need to be considered: ■ A compromise approach might involve grouping the items based on their relationship to specific functions and then prioritizing between and within the functions. The strategy here would be to assign all of the items related to a specific function to a subteam for their consideration and develop- ment. Several subteams could be active in any given phase. ■ Depending on how well the goal is understood, it might be wise to plan the initial SPeculate stage so that as many options and alternatives as pos- sible can be investigated. The strategy here is to eliminate those alterna- tives that show little promise earlier rather than later in the project. That enables more resources to be brought to bear on approaches that have a higher probability of success. ■ Where appropriate, prototypes might be considered as part or all of the first-phase deliverables. Here the strategy is to prioritize items in the collection or functions by not spending too much time developing the real deliverable. Familiarizing the client with the prototype may provide sufficient information to enable not only a reduction in the number of items in the collection, but also a prioritization of items or functions that show promise. A good example is a typical business-to-consumer (B2C) application. The prototype will show the various ways that a client can interact with the application. Upon examination, the client adds to this list or deletes from the list as they experience what the client would experi- ence when interacting with the application. Think of the first phase or two as exploratory in nature. Their purpose is to discover the directions that show promise and focus later phases on them. Identifying the First-Phase Deliverables After the prioritization is done, it is time to decide how much of that prioritized list to bite off for the initial phase. Remember that you want shorter phases in the early part of the project, which suggests that you limit the first-phase deliv- erables to what you can reasonably accomplish in a week or two. N O T E By taking this approach, you are keeping the client’s interest up, which is impor- tant. APM projects follow the same strategy. Once the client has been fully engaged in the project, later phases can be lengthened. Because your team resources are limited, you have to face the question of depth versus breadth of deliverables. In other words, might it be better to extend the breadth to accommodate more functions by not delving deep into any one

434 Part III ■ Complex Project Management function until a later phase? Produce enough detail in each function in this initial phase to get a sense of further direction for the function. You may learn from only a shallow look at a function that it isn’t going to be part of the final solution. This shallow look enables you to save labor that would have been spent on a function that will be discarded, and to spend it on more important work. Go/No-Go Decision Because the initial phase can be purely exploratory, the sponsor must have an opportunity to judge the soundness of the initial phase plan and decide whether it makes sense to proceed. It is entirely possible that the original idea of the cli- ent cannot be delivered with the approach taken in the first phase, and the first phase leads the client to the decision that the idea doesn’t make any sense after all. Some other approach needs to be taken, and that approach is not known at this time. The go/no-go decision points will occur at the end of each phase. Decisions to stop a project are more likely to occur in the early phases than in the later phases. You should expect later phases to benefit from earlier results that suggest that the project direction is feasible and should be continued. Planning for Later Phases Later phases will have the benefit of output from a REview to inform the plan- ning activities that will take place in the SPeculate stage that follows. Each REview stage will produce a clearer vision and definition of the goal. That clearer vision translates into a redirection of the project, which translates into a new prioritized list of deliverables for the coming Incubate stage. The newly prioritized deliverables list may contain deliverables from previous phases that were not completed, deliverables that have not yet been part of an Incubate stage, and deliverables that are new to the project as a result of the learning and discovery that occurred in the most recently completed Incubate stage. In any case, the revised prioritized deliverables list is taken into consideration as the team plans what it will do in the coming Incubate stage. It is now in the same position as it was in the very first SPeculate stage. What follows then is the assignment of deliverables to subteams, and scheduling the work that will be done and who will do it. Incubate Incubate is the INSPIRE version of the Cycle Build Phase in APF. There are several similarities between the two models and some differences as well. Consider the following points: ■ Even though the Incubate stage has a prioritized list of deliverables that are to be produced in this phase, INSPIRE still must maintain the spirit

Chapter 12 ■ Comparing PMLC Models 435 of exploration. It is a learning and discovery experience that may result in mid-phase corrections arising from that exploration. This would not happen in an APF project. ■ Conversely, an APF project does benefit from learning and discovery as it proceeds with the Cycle Plan, but it does not vary from that plan. The learning and discovery are input to the Client Checkpoint, and that is where plan revisions take place. These points reflect an important distinction between INSPIRE and APF. Subteams, working in parallel, will execute the plan developed in the previous SPeculate stage. The environment has to be very open and collaborative for SPeculate to be successful. Teams should be sharing ideas and cross-fertilizing discoveries and learning moments with one another. This is not just a time to execute a plan; it is a time for exploration and dynamic interchange. Mid-phase corrections with the collaboration of the client are to be expected as the subteams learn and discover together. New ideas and a redirection or clarification of the goal is likely to come from these learning and discovery experiences as well. Assigning Resources The Incubate stage begins with an assignment of team members to each of the deliverables that have been prioritized for this phase. The assignment should take place as a team exercise. That team involvement is important because of the exploratory nature of INSPIRE. Team members need to express their inter- est in one or more deliverables and share their ideas with their fellow team members. This assignment time can also be an opportunity for team members to recruit others who share their same interests and would like to develop the deliverable with them. The project manager should not pass up the opportu- nity to create a synergy among team members with similar interests, as well as between subteams that will be working in parallel on different deliverables. Any opportunity to create a collaborative work environment only increases the team’s chances of success. You see then the importance of a co-located xPM team. The excitement generated from the spontaneous sharing of ideas can only come from a co-located xPM team. Establishing a Phase Plan With the subteams in place and with their assignments made, the subteams can plan how they will produce the deliverables assigned to them. Deciding how a team produces the deliverables is exactly the same as discussed in Chapter 5. In fact, many of the same tools discussed in Chapter 5 can be used to help establish a phase plan here with equal effectiveness. For example, Chapter 5 presents the phase plan as a time-sequenced whiteboard diagram showing a day-by-day schedule of what is going to be done and by whom.

436 Part III ■ Complex Project Management N O T E However, never forget the differences of a phase plan in INSPIRE. In INSPIRE, the team has to be ready for changes at any time. Exploration will often bring the team to a point where a change of direction makes sense. When these situations arise, the team needs to collaborate with the client and decide how to go forward. Collaboratively Producing Deliverables Collaboration goes to the very essence of INSPIRE. Collaboration between subteams must occur. The example given earlier is one such instance. I spoke earlier in the chapter about the exploratory nature of an Extreme project. Because the project is exploratory, no one has a lock on the solution. Even the goal is somewhat elusive. That means the goal and the solution can be attained only through a solid team effort—a collaborative effort. There is a great deal of similarity between INSPIRE projects and brainstorming. One idea may not be of much value when taken individually. However, combine it with one or more other ideas and suddenly there is value. Co-location can make this exchange possible. The quote at the beginning of Chapter 11 from Estill I. Green, former vice president of Bell Telephone Laboratories, is relevant here: “Clearly no group can as an entity create ideas. Only individuals can do this. A group of individu- als may, however, stimulate one another in the creation of ideas.” REview REview in INSPIRE is very similar to the Client Checkpoint Phase in the APF. All of the learning and discovery from the just-completed Incubate stage are brought together in another brainstorming session. During the REview stage, the project team will share their answers to questions such as the following: ■ What did you learn? ■ What can you do to enhance goal attainment? ■ What new ideas arose and should be pursued? ■ What should you do in the next phase? The most important decision is whether or not the project will continue. This is a client decision. Have the results to date met with their expectations? Is the project moving toward an acceptable solution? These answers will determine whether or not the project continues to the next phase or is canceled. APF and INSPIRE share this go/no-go decision point at the completion of each phase. APF is less likely to result in a cancelation, because so much more is known about the solution. Conversely, INSPIRE is so exploratory and research-based that cancelations are far more likely. Each phase of an INSPIRE project ends with a review of the just-completed Incubate stage. It is a meeting attended by the client and the project team. The

Chapter 12 ■ Comparing PMLC Models 437 purpose of the REview stage is to reflect on what has just happened and what learning and discovery have taken place. The output is a definition of the next phase’s activities. Applying Learning and Discovery from the Previous Phase Early in the sequence of phases, the client and the team should expect signifi- cant findings and major redirections of further efforts. As the project moves into later phases, the changes should diminish in scope because the project team should be converging on a more clearly defined goal and an acceptable solution to reach it. N O T E This part of the INSPIRE process differs from APF. In APF, the goal has always been clearly defined—it is the solution that becomes clearer with each passing APF cycle. In an INSPIRE phase, both the goal and the solution become clearer. Revising the Project Goal The first order of business is for the client and the project team to revisit the pre- vious goal statement from the prior REview stage. Ask the following questions: ■ What has happened in the just-completed Incubate stage? ■ What new information do you have? ■ What approaches have you eliminated? ■ What new discovery suggests a change in goal direction and definition? ■ Are you converging on a more clearly defined goal that has business value? This revision of the project goal is an important step and must not be treated lightly. The client and the team need to reach a consensus about the new goal, and you then need to update the POS with a revised goal statement. Reprioritizing Requirements The second order of business is for the client and the project team to revisit deliverables and requirements. The following questions should be asked here: ■ How does the new goal statement affect the deliverables list? ■ Should some items be removed? ■ Should new items be added? ■ How is the functionality embedded in the new goal statement affected? The answers to these questions enable the client and the project team to reprioritize the new requirements. Update the POS to reflect any changes in the objective statements.

438 Part III ■ Complex Project Management Making the Go/No-Go Decision for the Next Phase Will there be a next INitiate → SPeculate → Incubate → REview phase? Equivalently, the question could be this: Are you converging at an acceptable rate on a clearly defined goal and acceptable solution? The client will consider this question in the face of the money and time already spent. Does it make business sense to continue this project? The updated POS is the input to this decision. Challenges to Project Setup and Execution In the complex project world, change is frequent and often affects projects in unanticipated ways. Risk is high, and an attentive risk management plan may be the key to successful projects. Drawing on my experiences I have compiled a list of the four most significant complex project management challenges I can recall and what might be done to prevent and mitigate them. Sponsors Have a Hard Time Accepting Variable Scope Without a doubt this has been a continuing challenge as organizations transition to the realities of managing complex projects. Sponsors and C-level executives have a particularly difficult time adjusting to the realities of complex project management. First, these senior managers must understand that to be successful complex projects require a new collaboration between the client team and the development team. That collaboration is an open and honest partnership to cre- atively learn and discover a solution to a critical and unmet business need. At the outset no one knows what solution will emerge and what business value it will deliver. Risk is high and a successful effort will provide high return. Sponsors and clients must be meaningfully involved as the next challenge discusses. Achieving and Sustaining Meaningful Client Involvement Through the Phases of the Chosen PMLC Model This is a critical success factor especially in the complex project space. My consulting model has always stressed meaningful client involvement, and I do that by having a responsible client manager partner with me in the role of a co-manager. We share equally in the successes, failures and decisions. That quickly builds strong co-ownership with the client. Since their name is associ- ated with the management of the project, they will not let the project fail. That co-ownership is the greatest contributor to project success that I know of.

Chapter 12 ■ Comparing PMLC Models 439 Adapting the Chosen PMLC Model to Changing Conditions Projects are dynamic. They can change for a variety of reasons including changes in business conditions and priorities as well as other internal and external envi- ronmental factors. That translates into a need to continuously review the chosen PMLC model for adaptations and even for reconsideration. For example, at some point in an iteration during a Scrum project the client says, “Aha, now I see what the complete solution will look like.” And the project manager replies, “And I know how we can build that solution.” Does that mean that Scrum should be abandoned in favor of say a Staged Delivery Waterfall model for example? That question is difficult to answer because there are so many moving parts to the project. For example, some of the more obvious implications are: ■ Changes to resource requirements ■ Schedule changes and resource availabilities ■ Cost of abandonment of Scrum and replacement by a Staged Delivery Waterfall model ■ Budget implications These added costs need to be balanced against the benefits which could include: ■ Pricing changes to products/services ■ Sales and marketing implications to product/service rollout dates ■ Cost avoidance implications APF is the only Adaptive PMLC model that is designed to accommodate PLMC model changes mid-project. Delivering Business Value in a Complex Project Landscape Expected incremental business value is the primary metric used to validate, approve and prioritize a project. Figure 12-21 is a conceptual illustration of the likely outcomes. First, understand that the business value that will be delivered from a project is an estimate provided by the sponsor and client to gain approval to conduct the project. As Figure 12-21 illustrates, that estimate has a variance. For TPM projects all of the business value is delivered after the project is complete and the variance of the estimate is small compared to APM and xPM projects.

Cumulative Business Value Delivered440 Part III ■ Complex Project Management xPM Goal TPM & APM Goal Project Time TPM Solution Business Value APM Solution Business Value xPM Solution Business Value Figure 12-21: TPM, APM, and xPM solution business value For APM projects the situation is quite different. At each iteration or cycle specific business value will be delivered. The variance of the estimate increases over the project life span. For the example illustrated in Figure 12-21 the deliv- ered business value may fall far short of the business value estimated if the goal is achieved. It is also possible that the delivered business value exceeds what was estimated if the goal is achieved. Clearly the risk of not delivering expected business value is greater for APM projects than for TPM projects, but the rewards can be much greater. xPM projects are in a world far different than any APM project. In an APM project the goal is clear, and hopefully, as the solution emerges, it will converge on the goal and deliver the expected business value but there is high risk. In an xPM project both the goal and the solution are not fixed. The goal may be an expression of a desired end state with no vision of how or even if that end state can be achieved. That is for the project to learn and discover. As the solution emerges the goal will change as certain aspects of the goal cannot be attained given present technology and understanding of the solution space. Hopefully the goal and its solution will converge and produce business value. That business

Chapter 12 ■ Comparing PMLC Models 441 value may not be acceptable to the sponsor or the client. Again, we are dealing with a very high-risk situation. Putting It All Together We have looked in depth into the five types of project management model types: Linear, Incremental, Iterative, Adaptive, and Extreme. The characteristics, strengths, weaknesses, and considerations of when to use specific PMLC models were documented and compared. The result is a relatively complete foundation for classifying a project into one of the four quadrants of the project landscape and then choosing the best-fit PMLC for a given project. This is a rich collection for effective project management. By way of summary it is instructive to recall Figure 2-8 from Chapter 2. It is reproduced here as Figure 12-22. TRADITIONAL Plan Launch Monitor Close Linear Scope & Control Project Incremental Scope Plan Launch Monitor Close Next Close Increment & Control Increment Increment N Project AGILE Plan Increment Iterative Scope Iteration Launch Close Y Iteration Monitor Iteration & Control Next N Close Iteration Iteration Project Y Adaptive Scope Plan Launch Monitor Close Next Close Cycle Cycle & Control Cycle Cycle N Project Cycle Close Y Phase EXTREME Extreme Scope Plan Launch Monitor Next Close Phase Phase Phase & Control Phase N Project Phase Y Figure 12-22: The five PMLC models First note the similarities. We know that the purposes and interpretations at each phase are quite different. These occur as part of the feedback loops and

442 Part III ■ Complex Project Management the decision processes that follow the closure of an increment, iteration, cycle, or phase. Understanding the similarities and differences gives the project manager a leg up on the effective management of complex projects. Discussion Questions 1. How would you go about the task of decomposing the project into mean- ingful business chunks in preparation for an Incremental approach? Speak to the rules you might employ. 2. You have completed the first few increments and released deliverables to the client. They are now coming to you with changes to what has been released. These changes make sense, but will cause your project to go off schedule if integrated into the future increments. What would you do? 3. How would you manage the time between increments in an Incremental PMLC model? There is pressure for longer between-increment delays to allow the client to integrate the increment deliverables, and there is pres- sure for shorter between-increment delays to reduce the risk of losing a team member. How do you balance these conflicting needs? How would you manage the work of your team members between increments—that is, what would you have them do? 4. What is the impact on your risk management plan for using a Rapid Development Waterfall model instead of a Linear PMLC model—that is, what risks are added and what mitigation plans would you put in place? Be specific. 5. Are there any projects in the PDQ Case Study that would benefit from any of the PMLC models studied in this chapter? 6. Clients are always reluctant to get too involved in planning. What might you do to sell them on the idea that their full involvement in APF is needed for this effort to succeed? 7. A member of your team is a systems analyst from the old school and just cannot adjust to APF. Her problem is that the client has decision-making authority over the direction that your software development project is taking and that the client is, shall we say, technically challenged. How would you handle this dilemma? 8. You are the project manager over one of your company’s first APF proj- ects. You are having trouble getting the client’s involvement. What would you do?

Chapter 12 ■ Comparing PMLC Models 443 9. Suppose a project should have used a TPM approach, but you used APF. Comment on what might be different. Would the traditional approach have given you a better outcome? Why or why not? Be specific. 10. Clearly, the Monitoring and Controlling Phase is very dependent upon the people on your team. APF gives team members great discretion in completing their work. If you were managing an APF project, how would you balance your need to know against the need to empower team mem- bers to do their work? Be specific. 11. Compare what happens with a TPM project and an APF project when a team member is taken off the team and no longer available. What are the impacts on each approach? Which approach is least affected by such a change? To do this comparison, you will be considering a full TPM plan versus an APF Cycle Plan. 12. Defend the claim: APF is a lean agile process. Your defense should show how APF possesses all 7 Lean Principles. 13. You are a senior project manager in your company. You have 15 years’ experience with them and a solid reputation for delivering successful projects. What might you, acting on your own, do to get your organization to appreciate the value of APF? What obstacles might prevent you from going forward with your plan? How do you feel about stepping outside the box? 14. In the formation stages of a project, are there any distinct disadvantages to using APF over xPM for an Extreme project? If so, identify them. In considering your answer, think about what is really known versus what may be only speculation and how that might create problems. 15. Is APF or xPM more likely to waste less of the client’s money and the team’s time if the project were killed prior to completion? To answer the ques- tion, you have to consider when the decision to kill the project is made in APF projects versus when it is made in xPM projects and what is known at the time the decision is made. Defend your position with specifics. 16. Compare, contrast and prioritize all 12 specific PMLCs in this chapter against the seven lean principles discussed in Chapter 10. Does anyone stand out as “most lean”?



Part IV Managing the Realities of Projects Complex projects arise from situations not only of complexity but situations where some degree of uncertainty is present. As you learned in Chapter 1, that uncertainty can be the result of a goal, or solution, or both that are not clearly defined. Annual surveys conducted by the Standish Group report on the top 10 reasons for project failure. At or near the top of every list since the surveys began is lack of senior-management support. You might think of that support as pertaining only to individual projects, but it also extends to the infrastructure that is put in place to support projects. A category called User Involvement was added for the first time to the 2007 survey, and it topped the list as the major factor for project success. And finally, Stakeholder Management was added as a 10th Knowledge Area in the PMBOK Guide, 5th edition, and will have major impact as well. Part IV covers the four most relevant topics to effective project management and to the success of even the most complex of projects: ■ Prevention and Intervention Strategies for Distressed Projects—I describe many of my experiences with such situations. You will see that by judi- ciously applying what has already been presented in this book, you will have taken a big step toward preventing projects from becoming distressed. But even at best, some projects are destined for the distressed pile. Maybe that was built in from the start, and no one noticed or could tell. In any case, what do you do when the project has become distressed, and without some significant intervention, will likely fail? ■ Organizing Multiple Team Projects—Three models are presented; each are used in the industry to manage projects where two or more indepen- dent teams are involved and each team has its own project management

446 Part IV ■ Managing the Realities of Projects tools, templates, and processes. The question is how to organize and manage such projects and which of the three structures is best for each situation. ■ Establishing and Maturing a Project Support Office—A Project Support Office (PSO), which is also known as a Project Management Office (PMO), consists of organizational units that are put in place to support project managers and teams. They can offer a bare minimum of support services or up to 50 different support services. While discussing this topic, I define the PSO; describe its mission, objectives, support functions, structure, and placement in the organization; and discuss how to establish a PSO. ■ Establishing and Managing a Continuous Process Improvement Program—Putting a project management methodology in place is the beginning of a long journey that will never end. The care and feeding of that methodology will occupy the enterprise for as long as it does busi- ness. To do that successfully requires the establishment of some type of process improvement program. This topic discusses a four-phase model for establishing such a program. The role and responsibility of the PSO in this process are also discussed.

CHAPTER 13 Prevention and Intervention Strategies for Distressed Projects The best-laid schemes o’ mice an’ men, gang aft a-gley, and leave us naught but grief and pain, for promised joy. —Robert Burns, Scottish national poet CHAPTER LEARNING OBJECTIVES After reading this chapter, you will be able to: ■ Recognize a potentially distressed project ■ Understand why projects become distressed ■ Implement prevention strategies ■ Use the tools, templates, and processes for preventing distressed projects ■ Understand and apply the intervention steps for a distressed project ■ Conduct a Root Cause Analysis for a distressed project ■ Understand the roles and responsibilities of the Project Support Office (PSO) with respect to distressed projects Despite the project team’s best efforts, some projects are destined for prob- lems. Sometimes it’s the team’s fault, and sometimes it’s just the roll of the dice. What is important is to protect the project against the unexpected and to have early warning signs in place to minimize the impact of the coming problems. Having a solid risk management plan is also important. These are the prevention strategies. But the inevitable still happens, and sometimes you are left with a project that is in trouble, one you need to save as best you can. These are the 447

448 Part IV ■ Managing the Realities of Projects intervention strategies. Forming and executing prevention and intervention strate- gies is the focus of this chapter. What Is a Distressed Project? Whenever the performance of a project falls outside nominal values, it is judged to be a project in distress. How it got to that state is a question that needs answer- ing. Most important is knowing how to establish an early warning system and prevent a project from becoming distressed. But understand that even the best efforts will not be 100-percent effective, and a project can still become distressed. The question then becomes: How can it be returned to a state of normalcy—if at all? The following characteristics are symptomatic of a distressed project: The project has exhibited a performance trend that, if continued, will result in its failure. I define two metrics in this chapter that capture the cumulative history of the project with respect to progress against time. Whenever the cumulative history of one or both of those metrics exhibits certain trends, it suggests that the project is out of control, and the reason for the trends needs to be identified and a decision needs to be made as to how to proceed. If left unchecked, the trend will continue, and failure is almost a certainty. A growing schedule slippage is one such trend that, if continued, will lead to failure. For a software development project, an unresolved bug list that continues to grow and/or whose average resolu- tion time increases is a signal that the project may be heading toward a distressed condition. The project’s performance has exceeded one or more metric values and is a high risk for failure. I will define several metrics and trigger values that can be used to track the general health of a project. When any one of these metrics exceeds its trigger value, the project is at high risk for failure. That sets off a series of activities designed to identify the source of the anomaly and the corrective action that needs to be taken. A significant schedule slippage due to a bad estimate, a mistake, and serious vendor delays are three such events that may result in project failure. The project has recently experienced some significant change that may result in failure. Oftentimes these changes are related to personnel or other major organizational shifts. Even though the project performance metrics do not indicate any problem, the environmental change may be sufficient to throw the project off course. A change of sponsor and a loss of critical resources are two such changes that may result in a distressed condition and eventual project failure.

Chapter 13 ■ Prevention and Intervention Strategies for Distressed Projects 449 If any of the preceding situations happen, it should immediately trigger a project intervention process designed to discover the reasons for the distressed condition, fix the condition, and replan the project going forward. That process is discussed in detail later in the chapter. Why Projects Become Distressed or Fail Many studies have been done over the years that attempt to discover the reasons for project failure. The failure rates for information technology (IT projects) are documented to range from 70 percent and higher! That level of performance has persisted for several years with no sign of any meaningful change for the better. The industry hasn’t found an effective strategy for reducing that failure rate. I believe that many of the reasons for this are related to the methodology that is being used. Traditional Project Management (TPM) is the default approach and seems to be outside the mainstream of contemporary project types. Data that I have collected from all corners of the globe suggest that only 20 percent of projects fall into the TPM quadrant, but the approaches to managing the projects remain relatively unchanged. TPM approaches are forced upon such projects for lack of an alternative, which is not much more than a failure waiting to happen. From interviews conducted with my clients and my own consulting experi- ences with them, a number of factors emerge repeatedly as possible reasons why their projects become distressed or fail. The following subsections discuss these reasons. Poor, Inadequate, or No Requirements Documentation As I discussed in several previous chapters, it is impossible to generate complete requirements documentation at the beginning of a project. That is no excuse for doing a sloppy job. Once requirements have been generated following the definition I suggested in Chapter 2, ask yourself what your level of confidence is that you have done the best job possible. You should be reasonably certain that you have identified the necessary and sufficient set of requirements and only their detailed decomposition is suspect. You can employ a number of Agile Project Management (APM) project management life cycle (PMLC) models if requirements documentation is less than satisfactory or if you expect a high rate of change. Inappropriate or Insufficient Sponsorship Some sponsors take their job of sponsorship seriously. Others do not. As project manager, you should keep the project very visible to your sponsor. Sending

450 Part IV ■ Managing the Realities of Projects an e-mail once a week is not sufficient. I would try for face-to-face meetings if there is any doubt about your sponsor’s attentiveness to the project. You will certainly sense inattentiveness when they are sitting across the desk from you. Sending them informal notes of project happenings just to keep them connected is another tool I have used on occasion. You have to keep them excited about the project and how it is going to contribute value to the organization. If there is some way for you to make them look good to their management as a result of this project, doing so would be a smart move on your part. I look for added value opportunities and communicate those face to face with the sponsor. Complexity of Requirements Not Recognized Don’t assume that the project is simple. That thinking leads to a sloppy job of requirements gathering and documentation. You are heading for trouble if you can’t get requirements done correctly, realize what you have or don’t have, and then choose the best-fit PMLC model. Your risk management plan must anticipate the unusual and have the appro- priate mitigation plans in place. As requirements become more complex or less complete and clearly documented, the risk of the project becoming distressed goes up. Unwillingness to Make Tough Decisions How easy it is to get a project approved, and how hard it is to pull the plug on the most distressed of projects. If you want to get the sponsor’s attention, recommend terminating their hopelessly distressed project. But be careful that you don’t hurt your own reputation in the process. You needn’t be defensive, just honest. Some projects have a very powerful sponsor. They may defend the project beyond reason, but few are willing push back or take them on. The president of your company will often be the major culprit here. If you are going to take him or her on, you had better do your homework. A good example of this situ- ation would be my experience with the president of a company where I was the CIO. We had a very complex hardware implementation project underway, and it was in trouble mostly due to vendor delays. I presented two alternatives to the president. He was a tough boss and told me that I didn’t do my homework. There was a third alternative I had not considered. He told me to combine the two alternatives I had proposed into a third and report back. I later learned that this was merely a stalling tactic on his part because he wasn’t comfortable making a decision at that time. There was no feasible third alternative. We later decided to follow the first alternative I had presented.

Chapter 13 ■ Prevention and Intervention Strategies for Distressed Projects 451 Lag Time Between Project Approval and Kick-Off Getting a project approved is one thing. Getting it started is another. If the time between approval and startup is too long and the completion date is firm, project risk goes up. Any date-dependent tasks are compromised by the delay, so avoid using those in your project schedule if possible. You are also at some risk of losing team members due to the delay, especially those who have scarce skills that you need but so do others. No Plan Revision After Significant Cuts in Resources or Time Budget cuts, staff cuts, and shorter deadlines are not unusual. Under those circumstances, many project plans are not changed. Despite your pleas, senior management says something like this: “You’ll figure out how to do it anyway. You always have.” Most project managers are helpless to do anything here except keep quiet. Many do not have the tools to push back with an intelligent business argument. Estimates Done With Little Planning or Thought Far too many project managers don’t take estimation seriously. They throw some numbers at the plan, and if no one objects, the numbers stay. The correct strategy is to get estimates from staff members who have done the tasks before or will be assigned to do the task on this project. Unless they have been a cred- ible source in the past, you will want some validation of the estimates they provide. Getting a second opinion from someone who is not on the project can be a good validation strategy. Overcommitment of Staff Resources This continues to be a major problem. Projects are often approved without assessing staff availability. You may have the skills needed, but the people with those skills are already committed to other projects and cannot work your project into their schedules. Dealing with this situation effectively requires a Human Resources Management System (HRMS) with skills inventories and staff scheduling capability. Inconsistent Client Sign-Off Some clients will fully participate in acceptance procedures and not be forced to sign off until they are completely satisfied that their requirements have been

452 Part IV ■ Managing the Realities of Projects met and expected business value achieved. If they have been meaningfully involved throughout the project, that’s a good sign that they will be meaningful participants in the acceptance procedures, and their signature is testimony that requirements have been met. Not all clients are like this, however. Some might sign off simply to get the project out of the way and get on with their business. Others might not really understand the project and sign off in ignorance rather than risk being exposed. No Credibility in the Baseline Plan If the baseline plan has undergone several revisions and changes at manage- ment’s and the client’s request, there may be serious doubt that it can be achieved. Estimates that are made and then changed to accommodate a tight deadline are sure signs of a weak plan and one that is destined for trouble. What may have been a solid and well-thought-out plan initially has undergone so many changes and patchwork fixes that it is now a jumbled mess and has lost its credibility with the team. Unmanageable Project Scope APM projects expect change and are structured to accommodate it, but there must still be vigilance over scope change. Tracking the frequency and cumula- tive number of additions to the Scope Bank are two metrics you should have in place. Over the cycles of the APM, a healthy project will show convergence. If changes are requested at an increasing rate, that is a sign of a project out of control. TPM projects do not expect scope change requests, so some control over the number and frequency must be in place. Management reserve is an effective tool and should be included in every TPM project plan. Managing Distressed Projects In general, there are two types of strategies for dealing with distressed projects. Every project that becomes distressed was once not in distress, and there are prevention strategies to minimize the likelihood of projects becoming distressed. Despite your diligence, the prevention strategies might not work due to prevailing conditions beyond your control, and your project will still become distressed. If this happens, there are intervention strategies that you can use. This section describes both strategy types. Prevention Management Strategies Prevention strategies are proactive practices and processes that you can employ to significantly reduce the number of projects that become distressed. For the

Chapter 13 ■ Prevention and Intervention Strategies for Distressed Projects 453 typical company situation, you may be able to enhance some of the processes covered previously in this book to decrease the likelihood of a project becoming distressed. These enhancements are briefly discussed in the next subsection. Again, it is not possible to eliminate all projects from falling into the distressed category, but you can significantly reduce their numbers. In establishing your prevention strategies, you have to take your efforts to the next level. Considering the high failure rate of projects, I suggest that you take some of the actions described in this section with every project. If for some reason you find these efforts burdensome to do on every project, you might consider them as part of your risk management plan and be more selective in how you apply them. Using Tools, Templates, and Processes to Prevent Distressed Projects Although there is no guarantee that prevention strategies will actually prevent a project from becoming distressed, they are your best protection against such an outcome. In this section, I discuss some specific prevention strategies you might use to reduce the likelihood of a project becoming distressed. You learned about the following six processes earlier in this book, which are also irreplaceable tools for formulating prevention strategies: ■ Requirements gathering ■ Work Breakdown Structure (WBS) construction ■ Dynamic risk management process ■ Scope change management process ■ Milestone trend charts ■ Earned value analysis These processes are briefly discussed in the following subsections with a focus on prevention strategies. Requirements Gathering Knowing that complete requirements documentation is difficult if not impos- sible at the beginning of the project, you should take extra care in identifying the list of requirements. As project complexity increases, the task is even more difficult mostly due to the dependence between requirements becoming more complex. Factor the client into that experience, and the difficulty increases even further. The client may be relatively inexperienced in identifying require- ments and doesn’t seem to engage in the process with the enthusiasm and commitment you would like. Perhaps a workshop approach makes sense. All of these factors suggest using a PMLC model that is closer to the APM, Extreme Project Management (xPM), and Emertxe Project Management (MPx) end of the

454 Part IV ■ Managing the Realities of Projects project landscape than you might have otherwise selected. Err on the side of being more suspect of the completeness and accuracy of the requirements. As the project commences, you may find reason to move back toward the Adaptive and even Iterative end of the landscape and use a different PMLC model. The issue to consider here is completeness and clarity of the Requirements Breakdown Structure (RBS) and what PMLC model is the best fit for such a project. Be cautious in your choice of PMLC model. Make sure you are not back- ing yourself into a corner by making assumptions about solution content and committing to something that won’t work. Err on the side of pessimism rather than optimism, and you will be on safer ground. Say that all signs suggest that the project can be managed using a Linear or Incremental PMLC model. For this project, the safe ground might be to use an Iterative PMLC model regardless of your confidence in the defined solution. You may have some history work- ing with this client on previous projects. That will be a big contributor to your decision on the best-fit PMLC model. If the project has never been done before (for example, one that involves the development of a new system), you might do requirements decomposition using two completely different approaches and use the results to cross-check and confirm that decomposition. Once requirements decomposition has been confirmed, consider simulating the solution by building a quick prototype (not a production prototype) around the confirmed RBS. Test your prototyped solu- tion with a broad audience of end users to further confirm the requirements. WBS Construction If the project is closer to the TPM end of the landscape, the Work Breakdown Structure (WBS) becomes the foundation of your choice of PMLC model. Generating a clear and complete WBS is the most difficult part of the project planning process. Building the WBS is a very intense and tiring exercise. You and the planning team will find yourselves rushing just to get the exercise over. Resist that temptation. If you felt rushed at the end, come back to the WBS a few days later. Share what you have with a trusted colleague and get that person’s opinion. Objectivity is important here. Don’t be afraid to criticize your work. If you don’t get this part right, the risk of project failure increases. Having a complete and correct WBS is critical to the success of a Linear or Incremental PMLC model. The entire project plan is based on the assumption that you have a complete WBS. Whatever difference there is between your WBS and a complete WBS will probably be reflected in the number of scope change requests you get. Processing those scope change requests will seriously com- promise the project plan. Recall from the pain curve discussed in Chapter 5 that the maximum pain occurs in the generation of the WBS. Doing it right is

Chapter 13 ■ Prevention and Intervention Strategies for Distressed Projects 455 just plain hard work, but you have to get it right. Don’t shortchange the exercise. Do it right! I have found that the following three strategies help me complete the WBS effort as painlessly as possible: ■ Use all of the project team members and client representatives that have been identified. You need as much expertise and as many pairs of eyes as you can assemble. Bring them together in one place for a single planning meeting. Any other approach is a distant second in terms of effectiveness. ■ Put the initial version of the WBS aside for a few days and come back to it with a critical eye. There will be enough loss of memory about what you did, and you should be able to approach validating it with a bit more objectivity. It’s amazing how many logic faults you will find. ■ Defend the WBS in front of a few respected peers who did not participate in building the WBS. They can be far more objective than you or the planning team and may find some problems with your WBS that you couldn’t see. Dynamic Risk Management Process A lot of risk management plans gather dust on the shelf of the project manager. They were completed as part of project planning and never looked at again. Those plans that are referred to are referred to after the fact. That’s too late. Effective risk management is probably your best weapon to protect the project from becoming distressed, but it has to be monitored continuously for any changes that might suggest heightened attention to one or more risks. Remember, as the project type moves from TPM toward xPM, project risk increases, and so should the intensity of your risk management efforts. The first thing I would do is assign one of the senior members of the project team as manager of risk for the project. This individual’s assignment begins with building the risk management plan during project planning. There should be a metrics-driven risk monitoring and control process included in the risk management plan. Use tight control values around these metrics to alert the team to early warning signs of changing conditions. Every team meeting should include an update on risk and recommended actions given the state of the project. Scope Change Management Process Scope change is the bane of the TPM project, and lack of it is the bane of APM, xPM, and MPx projects. In either case, you must have a well-defined and well- managed change management process in place. And most importantly, it must be understood and accepted by the client. In the case of TPM projects, the process

456 Part IV ■ Managing the Realities of Projects must put some controls on the frequency and number of change requests. In the case of APM, xPM, and MPx projects there is a certain level and frequency of change requests that must happen, and you must put metrics in place to track that cumulative history. Scope change is an area that often gives rise to most project problems. It doesn’t really make a difference whether this is the result of doing a poor job on gathering and documenting requirements or dealing with a client who has lots of ideas. If there is no management control exercised over the frequency of scope change requests, there are going to be problems. The time to process a scope change request comes from the value-added work time of the team mem- bers, which means an aggravated schedule, errors, and ultimately, schedule slippage. The seeds of distress have been planted. Here is an example from the case study of a change control process that you might put in place for a Linear or Incremental PMLC model. Recall that for these projects, the solution is clearly known and documented. There should be few scope change requests. PIZZA DELIVERED QUICKLY PDQ: ORDER ENTRY SUBSYSTEM The requirements of the Order Entry subsystem were gathered through a series of use cases. Client participation was exemplary even though it was the first time PDQ employ- ees had engaged in such an activity. There was an online Order Entry Screen, so custom- ers could go directly to the system to enter their orders and pay with a credit card. That was easily defined. A one-stop entry was created for telephone orders that replaced the need for customers to call the store they preferred to use. The order would then be routed to the Logistics subsystem and assigned to the appropriate production facility (store, pizza factory, or pizza van). The Order Entry subsystem was estimated to require 32 days for development, testing, and deployment. That completion time was firm, because an outside consulting company had been hired to develop the Logistics subsystem beginning 36 days after the start of the Order Entry subsystem. The Logistics subsystem was dependent on the Order Entry subsystem, and work on it could not begin until the Order Entry subsystem was deployed. Pepe discussed the criticality of the schedule with the Order Entry project team and the client. He proposed a management reserve of three days to accommodate unexpected change requests. Having management reserve is an effective insurance policy to protect the start time of related systems. In its absence, there is a strong likelihood of schedule slippage being passed on to the dependent systems. Without a management reserve, the Logistics sub- system in this example would likely be in a distressed condition even before it started. Milestone Trend Charts The milestone trend chart introduced in Chapter 7 is one of the few metrics that I know of that looks ahead in the project schedule for expected slippages and