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 built will remain in the application. Further to the point, TPM projects are often killed, if at all, very late in the game when all the money is spent. APF projects are killed at a point where it becomes obvious that the solution will not be acceptable. That will generally happen while there is still money and time left in the budget. Is the Team Working as Expected? Real teamwork is a critical success factor in APF. A lot of worker empower- ment is threaded throughout APF. If you count the frequency of the use of the word I as compared to the use of the word we, you will have a pretty good metric for measuring team strength. The formula would be as follows: Team Strength = number of We’s/(number of I’s plus number of We’s) You would like to see this number hovering around 1. The APF team needs to work in an open and honest environment for this to happen. That means that every team member must be forthright in stating the actual status of their proj- ect work. To do otherwise would be to violate the trust that must exist among team members. The project manager must ensure that the working environ- ment on the project is such that team members are not afraid to raise their hand, say they are having trouble, and ask for help. To do otherwise would be to let the teammates down. What Was Learned? This question is perhaps the most important one of all. Here is where the process will be reviewed to provide more value to the client. The new ideas that are generated here could not have come about through the TPM approach. This point in the process is where APF (and xPM, in all fairness) really shine. Both APF and xPM take their value from learning by doing. Adjusting Functionality for the Next Cycle Plan Once the answers have been given to the preceding questions, it is time for the client and the project team to look forward to the next cycle. The inputs to the next cycle planning activity are as follows: ■■ Any functionality completed during the previous cycle ■■ Any functionality planned but not completed in the previous cycle ■■ The functionality planned for this cycle ■■ The functionality planned for all the cycles beyond the next one Client Checkpoint 321 20 432210 Ch17.qxd 7/2/03 9:34 AM Page 321 ■■ All learning and discovery that took place in all previous cycles (Scope Bank) ■■ Any items still remaining on the Issues Log ■■ Any changes that took place in the business environment during the previous cycles From these inputs, you generate the following outputs from the Client Check- point phase: ■■ Updated functionality list ■■ Reprioritized functionality list ■■ Next cycle length Updated Functionality List We started this whole process with the Conditions of Satisfaction, and it is to the COS that we now return. The only question to be answered here is this: Are the COS still valid? If yes, continue on. If not, revise accordingly. These revisions are the planned functionality for the next cycle. The client and the team should spend most of a day in frank and honest con- versation, considering all of these factors and then agreeing on the functional- ity that will be planned for the next cycle. Do not underestimate the value that can come from the sharing of learning and discovery. That will be your most important information because it really helps both parties understand what this solution is really all about and what should be offered as a final solution. This part of the process is no trivial task. Reprioritized Functionality List The process that was used in the first cycle to prioritize functionality can be repeated here. The criterion that was used to determine the priority may be the same or different. Again, take advantage of all the learning and discovery from the previous cycles. Next Cycle Length The initial estimates of functionality duration for those functions planned for the next cycle may require a change in cycle length. Remember to be true to the overall timebox for the version. That cannot be adjusted. Chapter 17 322 20 432210 Ch17.qxd 7/2/03 9:34 AM Page 322 CROSS-REFERENCE See Chapter 14 for a more detailed discussion on prioritizing functionality and work- ing with cycle length and timebox constraints in APF. Putting It All Together In this chapter we have tried to give you an understanding of how important the Client Checkpoint phase is to the success of an APF project. As we have already discussed, APF embraces change, and it is through change that we can converge on a solution that delivers maximum business value for the time and money invested. All of the change that occurs in APF occurs in the Client Checkpoint phase. There is no separate change management process as there is in the traditional approach. Make the Client Checkpoint phase the high spot of your APF experience and you won’t go wrong. The Client Checkpoint phase is the last phase in a loop that returns back to the Cycle Plan phase. The loop cycle plan–cycle build–client checkpoint repeats itself for as many cycles as have been planned within the version timebox. In the next chapter, we look at closing the version project with the post-version review. Discussion Questions 1. 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 the client is, shall we say, technically challenged. How would you handle this dilemma? 2. You are the project manager over one of your company’s first APF projects. You are having trouble getting the client’s involvement. What would you do? Client Checkpoint 323 20 432210 Ch17.qxd 7/2/03 9:34 AM Page 323 20 432210 Ch17.qxd 7/2/03 9:34 AM Page 324 Installing Custom Controls 325 Post-Version Review The only thing we know about the future is that it is going to be different. —Peter F. Drucker CHAPTER 325 J ust as the traditionalist conducts a post-implementation audit at the end of the project, so also does the APFist conduct a post-version review at the end of the current version (see Figure 18.1). There are a number of similarities between a post-implementation audit and a post-version review, but there are differ- ences, too. The traditionalist is looking for final closure on the project, while the APFist is looking for ways to further increase the business value of the solution. In other words, the APFist is never looking for final closure; instead, he or she is always looking for more business value. The version just com- pleted is just another step toward increasing business value. In that sense, APF is quite like the production prototype because it consists of a never-ending cycle of repeated solution improvements. The only ending that is ever encoun- tered is to retire the solution altogether. 18 Chapter Learning Objectives After reading this chapter, you will be able to: ◆ Explain the significance of the post-version review ◆ Describe the deliverables from a post-version review ◆ Conduct a post-version review ◆ Extract lessons learned from the version project 21 432210 Ch18.qxd 7/2/03 9:34 AM Page 325 Figure 18.1 Post-Version Review phase. Let’s look at the series of actions that take place in the APF post-version review. Checking Explicit Business Outcomes The project was justified on the basis of explicit business value as defined by specific business outcomes. The Post-Version Review phase is the time to check to see if the project has achieved these outcomes. Oftentimes, however, these outcomes cannot be measured until weeks, months, or even quarters have passed since the version was put into production status and the success criteria can be measured. This part of the review is no different than in the 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 Check on Business Outcomes Lessons Learned to Improve Next Version Lessons Learned to Improve APF Chapter 18 326 21 432210 Ch18.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 the validation of a business out- come is related to the business reason for doing the project and in no way affects the team. Depending on that business outcome, another project focused on the same application may be commissioned and a new team assembled to do that work. Reviewing Lessons Learned for Next Version Functionality We know that learning and discovery are very important parts of the Client Checkpoint phase because that phase leads the client and the team to adjust the cycle plans going forward. Similarly, in the Post-Version Review phase, the client and the team consider all discovery and learning experiences with a view toward the next version’s functionality, on the assumption that there will be a next version. This information is the major input to the Version Scope phase for the next version. The analysis of this information will be the major part of the business validation of that next version. Assessing APF for Improvements So far, the lessons learned have focused on the solution (that is, the product) of the just completed version. The other type of lessons learned focuses on the process that was followed to create the solution and asks such questions as “How well did APF work?” and “How well did the client and the team follow APF?” In answering these questions, the client and the team offer suggestions for improvement of the process and the practice of the process. As you can see, APF has a built-in continuous quality improvement process. Putting It All Together Clearly, the post-version review is focused on the business value of what was just completed and on the business value of any future versions that might fol- low, which is as it should be. A guiding principle of APF is to deliver maxi- mum business value. We have shown how this applies to a critique of the solution just delivered and to a preparation for any version that might follow. In the next chapter, the final chapter in Part II, we consider some variations that might be encountered and how APF can be adapted to fit. Post-Version Review 327 21 432210 Ch18.qxd 7/2/03 9:34 AM Page 327 [...]... strategically aligned project portfolio ◆ Adapt the concepts and practices of project portfolio management 351 352 Chapter 20 Introduction to Project Portfolio Management In this first section, we set the foundation for our study of project portfolio management While everyone knows what a project is, everyone may not understand that not all projects will come under the purview of our portfolio management process... 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... sufficient to sell the project to senior management? Be specific 3 How does xPM differ from APF? Discuss the differentiating characteristics of each 4 Can APF be used on an extreme project? Why? Why not? Be specific 5 In the formation stages of a project, are there any distinct advantages to using xPM over APF for an extreme project? If so, identify them 6 In the formation stages of a project, are there... 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... (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... 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... project is to be open-minded The habits that you formed in traditional project management may have great application in extreme projects, but they might not You will be called on to be adaptive Keep the goal of your extreme project in mind, and use or adapt whatever you can from your earlier experiences with traditional or adaptive projects You should now have a better understanding of how this unstructured... 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... the decision to kill the project is made in APF versus xPM projects and what is known at the time the decision is made Defend your position with specifics PA R T THREE Organizational Considerations W e have completed our discussion of the three approaches to project management: TPM, APF, and xPM In the previous two parts, we discussed when to use the traditional, adaptive, or extreme approaches and... the place of projects in the organization: ■ ■ The first is project portfolio management Many organizations are changing their focus from the individual project to the collection of projects underway or proposed in the organization ■ ■ The second is the Project Support Office (PSO) If any of the three approaches are to succeed in the organization, it will be because the organization has an effective support . 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. cancel the current project and start two or more projects based on the learning and discovery to date with the now cancelled project. For exam- ple, R&D projects are extreme projects, and a. 331 Defining an Extreme Project The best way to define an extreme project is to consider its characteristics, which are discussed in the following list: High speed. The types of projects that are