Adapting and Integrating the APM Toolkit

The APM PMLC models define a world that is a fascinating challenge to the chefs and an overwhelming problem for the cooks.

The chefs will consider the current characteristics of the project goal and solution; reach into their tools, templates, and processes for the best fit; and adapt it to the project. In many cases, their creativity will be brought to bear on their management needs.

The cooks will try to use an APM PMLC model right out of the box and fail. I'll give them the benefit of the doubt and allow that they may well pick the best-fit tool, template, or process and then try to force fit it to the project. Frustration and high failure rates are the predictable result.

If you are going to be a chef, you have to be flexible and discerning about what you are doing. There is no substitute for thinking, and you must be thinking all of the time to stay on top of an APM project. Therefore, I'm going to describe some typical situations that demand flexibility and adaptability.

This section gives you a quick look at each part of the APM PMLC model to see how you might use Process Group tools, templates, and processes to best advantage in an APM project.

Scoping the Next Iteration/Cycle

The Scoping Process Group includes the following:

• Eliciting the true needs of the client
• Documenting the client's needs
• Negotiating with the client how those needs will be met
• Writing a one-page description of the project
• Gaining senior management approval to plan the project

The first three items embody the COS and the RBS, and getting this right is critical. Remember you are exploring the unknown in an APM project. The project is a critical mission project, and you can't afford to leave any stone unturned at this definition stage. You might want to consider doing a Root Cause Analysis if there is any doubt about the client confusing wants and needs. Remember, wants are often associated with how the client sees the solution to a problem; they may not have even conveyed to you. Needs are what you need to begin crafting a solution. With respect to the RBS, err on the side of deciding that it is not complete. That will lead you to choose a more appropriate APM PMLC model.

The POS will be the template that sells your goal and objective statements to the approving manager. Most importantly, it must use language that anyone who reads it will understand. It must be based on facts that anyone who reads it will nod in agreement (the Problem/Opportunity Statement described in Chapter 4). The success criteria must clearly state the quantitative business value that will result from the successful completion of the project. You will not be present to defend the POS. It must stand on its own merit.

Planning the Next Iteration/Cycle

The Planning Process Group includes the following:

• Defining all of the work of the project
• Estimating how long it will take to complete the work
• Estimating the resources required to complete the work
• Estimating the total cost of the work
• Sequencing the work
• Building the initial project schedule
• Analyzing and adjusting the project schedule
• Writing a risk management plan
• Documenting the project plan
• Gaining senior management approval to launch the project

Most of these tools, templates, and processes are part of the Traditional approach to planning a project, and they can be used as described in Chapter 5. The only difference is that you are planning for a two to four week horizon. Err on the side of using as little technology as makes sense. Burdening yourself with an automated project plan may be overkill in that you inherit the maintenance of that plan as well. APM projects are much higher risk than TPM projects, so you need to pay particular attention to your risk management plan. Give one of your team members the responsibility of managing that plan. As part of the daily 15-minute team meeting, review and update the risk management plan.

Launching the Next Iteration/Cycle

The Launching Process Group includes the following:

• Recruiting the project manager
• Recruiting the project team
• Writing a project description document
• Establishing team operating rules
• Establishing the scope change management process
• Managing team communications
• Finalizing the project schedule
• Writing work packages

These processes will be done once in the APM project. You will not need a scope change management process. The Client Checkpoint will incorporate the evaluation and response in the form of a re-prioritized functions and features list.

Monitoring and Controlling the Next Iteration/Cycle

The Monitoring and Controlling Process Group includes the following:

• Establishing the project performance and reporting system
• Monitoring project performance
• Monitoring risk
• Reporting project status
• Processing scope change requests
• Discovering and solving problems

My best advice is to avoid making any changes to the iteration or cycle plan in midstream. Do what you planned inside the planned timebox. Ideas and suggested changes will arise during the iteration or cycle plan. This is only natural, because an APM project is a learning and discovery project. Post the ideas and suggestions in the Scope Bank, and then wait for the iteration or cycle close and checkpoint to decide how to handle them.

Closing the Next Iteration/Cycle

Unlike a TPM project where the schedule can slip or be changed, that doesn't happen in an APM project. The cycle timebox is cast in stone. It is never extended to accommodate one of the swim lanes whose schedule has slipped. The iteration or cycle may be closed if all swim lanes are complete ahead of schedule.

Deciding to Conduct the Next Iteration/Cycle

This is not part of any TPM PMLC model. It is unique to APM and xPM. The client is the driver of this decision process. The current solution and its history along with the Scope Bank are the inputs. If the metrics you are collecting suggest that the solution is converging on the goal, there is good reason to continue with another iteration or cycle.

You need to keep in mind the following aspects of this decision-making process:

• The client manages the decision process.
• The client must be fully engaged in the process.
• The atmosphere must be completely open and honest.
• The decision must be based on expected business value.
• The solution must be converging to a solution that aligns with the goal.

Closing the Project

The Closing Process Group includes the following processes:

• Gaining client approval of having met project requirements
• Planning and installing deliverables
• Writing the final project report
• Conducting the post-implementation audit

An APM project ends when one of the following occurs:

• The time and budget are expended.
• An acceptable solution with the expected business value is found.
• The project is abandoned.

All of the processes in the Closing Process Group are conducted in an APM project just as they would be in a TPM project. The Scope Bank in an APM project will still have some suggestions and ideas for solution enhancement when the project is ended. These as well as experiences with the current solution will become the business justification for the next version.