NOTE Note that by making these decisions at this point in the process, the APF approach wastes the minimum amount of time and money as compared to the traditionalist approach. Monitoring and Adjusting the Cycle Build Schedule The team will have morning team status meetings every day—no exceptions. The meeting need not last more than 15 minutes. Everyone is standing and everyone gives his or her status. If the status is behind, each should report what he or she plans on doing to catch up. Issues that affect only certain mem- bers of the team are taken offline by the affected persons so as not to waste the time of the entire team. Those who are ahead of plan become a resource for the others. We are talking here about minor adjustments to a few weeks of work. There are no big surprises. To help monitor and adjust the cycle build schedule, the team will use three tools continually throughout the Cycle Build phase: ■■ Scope Bank ■■ Issues Log ■■ Prioritized Scope Matrix Maintaining a Scope Bank The process of discovery and learning by the team is continuous throughout the cycle. Any new ideas or thoughts on functionality are simply recorded in the Scope Bank and saved for the Client Checkpoint phase. The Scope Bank can physically be a list posted in the team room, or some electronic form (spreadsheet or word processing document). Whichever form you decide to use, make sure it is visible to the team. Changes to scope are never made dur- ing a cycle. The cycle plan is adhered to religiously. There are no schedule extensions or additions of resources within a cycle. Whatever can get done gets done. All of these extraneous items are taken up in the Client Checkpoint phase. The following fields make up the Scope Bank: ■■ Date posted ■■ Posted by Cycle Build 311 19 432210 Ch16.qxd 7/2/03 9:33 AM Page 311 ■■ Brief description of scope item ■■ Assigned to ■■ Date scheduled for action ■■ Recommended action ■■ Reason for recommendation The Scope Bank is posted in the team war room. The first three items are com- pleted by the person who initiated the scope item. At the next team meeting, someone is assigned to investigate the scope item further. He or she reports back at the team meeting on or before the date scheduled for action. The report consists of a recommended action and a reason for the recommendation. The date scheduled for action is changed to the date of the next client checkpoint. Until that time, this information remains in the Scope Bank to be acted upon at the client checkpoint. Maintaining an Issues Log Despite all of the team’s due diligence in putting the micro-level schedule together, there will be problems. We don’t need to enumerate what they might be—we all know them by now. The bigger issue for APF is how to handle them within the context of a learning and discovery framework. The fields that make up the Issues Log are as follows: ■■ Date posted ■■ Date scheduled for resolution ■■ Posted by ■■ Assigned to ■■ Brief description of issue ■■ Current status of issue ■■ Next step The Issues Log is posted in the team war room and lists the problems and issues that the team has encountered during the cycle. Because the list is continually changing, we recommend that it be handwritten (we use nonper- manent marking pens) in a convenient location on the whiteboard. That facili- tates the updating and keeps it always visible to the team. It contains the information shown in this bullet list and is updated daily. The items in the Issues Log need resolution, and there should be a plan to resolve them. The person to whom the issue was assigned is responsible for developing that Chapter 16 312 19 432210 Ch16.qxd 7/2/03 9:33 AM Page 312 plan and keeping the team informed through daily team meetings of the status and next steps of the plan. Using a Prioritized Scope Matrix Any additions to either the Scope Bank or the Issues Log must take into account the prioritization of the project constraints. CROSS-REFERENCE Refer to Chapter 14, where we discuss how the prioritization is done. Here we dis- cuss how to apply it. ■■ For the Scope Bank entry, which was either a change request or an idea, a project impact statement should accompany the entry. At this point the impact statement should include comments relevant to the constraints that will be impacted if the change request or idea is incorporated in the version scope. There may be alternative ways to satisfy the change request or idea, and each of these should also have an impact statement relative to the constraints. Remember, the impact statement is brief. Don’t get all wrapped up writing the perfect document in the king’s best English. Just get the basic information recorded in the Scope Bank. Do it at the time the change request or idea is new, so that a good idea is not lost with the pas- sage of time. ■■ For the Issues Log entry, which is the statement of a problem or a condition that has arisen, the Prioritized Scope Matrix serves a different purpose. There will typically be a sense of urgency with an Issues Log entry. If it affects the current cycle, something must be done ASAP. Here is where the prioritized constraints help us. The constraints help us focus our efforts at finding a solution within the constraints that are available to us. These con- straints will save us the needless wasting of time pursuing solutions that are not feasible in the minds of the stakeholders and sponsor. Holding Team Meetings The entire project team meets every morning for about 15 minutes. These are stand-up meetings where status is reported. Each task leader should state where he or she is with respect to the time line (ahead, on target, or behind) and if his or her team is ahead or behind, by how many hours or days. If the team is behind, they should briefly state their get-well plan. If anyone in the meeting is able to help, that person should say so and take that conversation offline. Problems and issues are not discussed in the team meeting except to Cycle Build 313 19 432210 Ch16.qxd 7/2/03 9:33 AM Page 313 add them to the Scope Bank and Issues Log. Their resolution or further clarifi- cation should be dealt with by the affected parties offline. Do not use team time to discuss things that are of interest to only a few members. For larger teams (above 20 members) there is an exception to what we just out- lined in the previous paragraph. Such teams generally have task leaders who have a few team members responsible to them for their work. In such cases the task leaders should meet daily and inform their team of the outcome of those meetings. Once a week the entire team should gather for a team meeting. TIP While the project manager might be the first choice for leading the team meetings, this is not necessary. Rotating the person who leads the team meeting is a good idea. It gives others a chance to develop that skill. Status Reports The project status is always posted in the team war room and is kept up-to- date. Anyone who has an interest or a need to know can always go there for the details. Brief written status reports should be available for the client at the end of each cycle and more lengthy reports to senior management at the end of the version. While the project is underway, we tend to place responsibility for status reporting outside of the extended project team into the hands of the client. Placing it with the client maintains the core value of a client-focused and client-driven approach. Ownership is in the hands of the client, not in the hands of the project manager or project team. That is as it should be. The reason for this recommendation is that it puts the client in a position of respon- sibility for reporting the status of their project to senior management. It now becomes a business-type report not a project-type report. Putting It All Together With a few exceptions, the Cycle Build phase looks just like the traditionalist approach. Note, however, that the cycle plan and functionality is not tampered with. Whatever doesn’t get done within the cycle is reconsidered for the next or some future cycle. Change management, which is a big issue for the tradi- tionalist, doesn’t even come up in APF. It is imbedded in the Client Checkpoint phase as a routine activity. In the next chapter, we spend some time on the Client Checkpoint phase. It is the critical piece that makes or breaks APF. Chapter 16 314 19 432210 Ch16.qxd 7/2/03 9:33 AM Page 314 Discussion Questions 1. Make a list of the advantages and disadvantages of using a high-tech versus a low-tech approach in this phase of the project. Discuss your find- ings. Does either approach win out over the other? In what ways? 2. Clearly, this 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 members to do their work? Be specific. 3. 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. Cycle Build 315 19 432210 Ch16.qxd 7/2/03 9:33 AM Page 315 19 432210 Ch16.qxd 7/2/03 9:33 AM Page 316 Installing Custom Controls 317 Client Checkpoint Any plan is bad which is not susceptible to change. —Bartolommeo de San Concordio, Florentine painter and writer CHAPTER 317 O ne of the real advantages of APF over other approaches is that the client is involved as a principal and as a decision maker at all critical junctures in the project. Because cycle length is so short and is so controlled, there is little that can go wrong that is not easily corrected. Within the cycle itself, not even a day goes by that the team doesn’t take stock of where it is compared to where it was planned to be and adjusts accordingly. So it is true between cycles. Little can go wrong that cannot be corrected. Few dollars and little time are wasted because of the structure of APF. This chapter is really the heart of APF. It is here that the team and the client spend valuable time looking at what was done, reflecting on what was discovered and learned since the last checkpoint, and planning the functionality that will be built in the next cycle. 17 Chapter Learning Objectives After reading this chapter, you will be able to: ◆ Explain the significance of each input to the client checkpoint ◆ Assess the status of the completed cycle relative to its plan ◆ Describe the inputs to the next cycle plan ◆ Explain the outputs of the client checkpoint 20 432210 Ch17.qxd 7/2/03 9:34 AM Page 317 As you will see, this introspection with client and project team fully engaged is a very thorough process. If properly done, it is unlikely that anything signif- icant will be missed. Figure 17.1 is a graphical display of the Client Checkpoint phase. Figure 17.1 Client Checkpoint phase. Develop Conditions of Satisfaction Prioritize Functional Requirements & Develop Mid-Level WBS Write Project Overview Statement Prioritize Scope Triangle Develop Next Cycle Build Plan CYCLE PLAN VERSION SCOPE Schedule Cycle Build Build Cycle Functionality Monitor/Adjust Cycle Build Conduct Quality Review with Client Review the Version Results CYCLE BUILD CLIENT CHECKPOINT POST-VERSION REVIEW DELIVERABLES Quality Review of Completed Functionality Adjust Next Cycle Functionality and Timebox Chapter 17 318 20 432210 Ch17.qxd 7/2/03 9:34 AM Page 318 Inputs to the Client Checkpoint The following lists the inputs to the Client Checkpoint phase: ■■ Planned versus actual functionality added ■■ Scope Bank Planned versus Actual Functionality Added For the cycle just completed, the cycle plan called for a specific list of function- ality to be added to the deliverables. No changes were made during the cycle, so it is possible that not all the planned functionality actually made it into the deliverables. There are several reasons for that, which we will not discuss; they are obvious (schedule slippages that could not be recovered, a discovery that rendered the functionality unnecessary). Any functionality not completed in the just completed cycle will be prioritized along with this cycle’s functional- ity and any adjustments made in the cycle plan going forward. Scope Bank First discussed in Chapter 16, the Scope Bank is the cumulative depository of all the ideas and proposed changes that were generated during all previous cycles and have not yet been acted upon. Some of them were incorporated in previous cycles and are no longer in the Scope Bank, and some were not incor- porated and are still in the Scope Bank. In any case, the current contents are all of the items not previously acted upon. There may be cases where any ideas suggested earlier that had not been incorporated may now be viable. That is the reason the Scope Bank is cumulative. NOTE The only time anything is deleted from the Scope Bank is when it is incorporated into the solution. Questions to Be Answered during Client Checkpoint The following is a list of the questions to be answered during the Client Check- point phase: ■■ What was planned? ■■ What was done? Client Checkpoint 319 20 432210 Ch17.qxd 7/2/03 9:34 AM Page 319 ■■ Is the version scope still valid? ■■ Is the team working as expected? ■■ What was learned? What Was Planned? The answer to this question is nothing more than a list of the objectives and functionality that were planned to be completed during the previous cycle. What Was Done? This answer is nothing more than a checkoff of the objectives and functional- ity completed. There are often comments accompanying the checkoff because some items may not have been completed as planned. Subfunctions may have been left undone, and there may be good reasons for it. In such cases, the Scope Bank should reflect the situation. Again, the only questions to be answered here are these: Did the cycle meet its objectives? Did the cycle meet its planned functional specifications? If no, where are the variances? The answers will provide input into planning for the objectives of the next cycle and the functionality to be built in the next cycle. Remember, we already specified objectives and functionality for the next cycle in the Version Scope phase. So we have the original scope and potential revised scope to consider as we consider what the next cycle will contain. NOTE TPM defines a formal change management process that can be invoked at any time in the project. In APF the change process is imbedded in the client checkpoint. The only changes that are accommodated in APF occur between cycles. No changes to scope are incorporated within an ongoing cycle. Is the Version Scope Still Valid? Armed with the information discussed in the previous two sections, we now can ask a very basic question: “Is the version scope still valid?” If yes, we are on the right track. If not, we need to revise accordingly. Revisions to version scope can be significant. In some cases revisions may be so significant that the correct business decision is to kill the current project, go back to the drawing board, and start over again. You can see that the cost of killing an APF project will always be less than the cost of killing a TPM project. The reason is that TPM spends money and time on functionality that may not remain in the solu- tion. APF, on the other hand, almost guarantees that all functionality that is Chapter 17 320 20 432210 Ch17.qxd 7/2/03 9:34 AM Page 320 [...]... Objectives After reading this chapter, you will be able to: ◆ Use APF for proof of concept ◆ Adapt APF to revise the version plan ◆ Identify an extreme project ◆ Describe the four phases of the extreme project management approach ◆ Understand how extreme project management clarifies the goal and con- verges to a solution 329 330 Chapter 19 We have also seen how APF not only anticipates these adaptations... cycles High uncertainty Because an extreme project is innovative and researchoriented, 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 Furthermore, the time to complete the extreme project is not known The cost to complete an extreme project is not known either There will... (or even replace) the current version plan and basically start over NOTE this early point in the project, do not be afraid to kill the plan In almost every At case we can think of, you will be making the correct decision Extreme Project Management The third variation that we will discuss is extreme project management xPM and APF both originated at about the same time, so it is difficult to say which... success factor in every extreme project business endeavor High change The uncertainty about the goal or the solution means that as the project is underway, learning and discovery, just as in APF projects, will happen It will happen 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... comparison The changes in an extreme project may completely reverse the direction of the project We can envision cases where the changes might be to cancel the current project and start two or more projects based on the learning and discovery to date with the now cancelled project For example, R&D projects are extreme projects, and a discovery in one cycle may cause the team and the client to move in a... how APF can be adapted to fit 3 28 Chapter 18 Discussion Questions 1 You have completed your first APF project Compare and contrast the traditional and APF approaches when both of them reach this same point 2 What differences might you see if it were possible to do the same project twice—once using the traditional approach and once using APF? Be specific How might project differences affect your comparison?... is the nature of extreme projects, and that is where we begin our investigation of how xPM applies to them Variations to AP F 333 Overview of Extreme Project Management By its very nature, xPM is unstructured xPM (see Figure 19.1) and APF are both variations of the same theme The theme is that learning and discovery moves the project forward The idea is an adaptation of the Flexible Project Model introduced... xPM Project Overview Statement An example will help ground some of these new ideas Suppose the project is to find a cure for the common cold As discussed in earlier chapters of this book, the Project Overview Statement is a critical document in both the TPM and APF approaches, and so it is again in xPM projects However, because the goal was known in both TPM and APF 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 19.2 is the POS for the project to find a cure for the common cold 336 Chapter 19 PROJECT OVERVIEW STATEMENT Project Name Common Cold Prevention Project Project No Project Manager 02 - 01 Carrie deCure Problem/Opportunity There does not exist a preventative for the common cold Goal Find a way... heavily toward assumptions Having to make such assumptions happens to be the nature of this project Establishing a Project Timebox and Cost Contrary to an APF project, an extreme project is not constrained by a fixed timeframe or cost limit It is best to think of the xPM time and cost parameters as something to give the project team guidance on what the client expectations are It is much like having the client . revise the version plan ◆ Identify an extreme project ◆ Describe the four phases of the extreme project management approach ◆ Understand how extreme project management clarifies the goal and con- verges. Improve APF Chapter 18 326 21 432210 Ch 18. qxd 7/2/03 9:34 AM Page 326 traditional approach. The project has finished, and the team will be disbanded for reassignment to other projects. Waiting on. Company (see the case study in the Introduction)? Be specific. Chapter 18 3 28 21 432210 Ch 18. qxd 7/2/03 9:34 AM Page 3 28 Installing Custom Controls 329 Variations to APF Clearly no group can