Using the Tools, Templates, and Processes for Maximum xPM Effectiveness

The key here is to create an environment in which the project team can freely exercise their creativity without the encumbrance and nuisance of non-value-added work. The agilist would say that this should be an environment that is light or lean versus heavy.

This section gives you a quick look at each part of the Extreme PMLC model to see how the process group tools, templates, and processes might be used or adapted to the best advantage of the xPM project team.

Scoping the Next Phase

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's approval to plan the project

A loosely structured COS for the next phase is the starting point. Hold off on any attempt at specificity. That is not the nature of an xPM project. If this phase is among the first few phases of the project, expect them to focus on a general investigation of high-level ideas about a solution. There might be several concurrent ideas to explore in an attempt to further define possibilities. These are very preliminary ideas and must be treated as such. After some possibilities are identified, more Probative Swim Lanes might be launched to drill down into the feasibility of these ideas. A POS might be drafted that will remain valid for a few phases, but expect it to be superseded quickly and often. The approval to actually plan the phase will be a client approval.

Planning the Next Phase

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's approval to launch the project

Planning is a two-level process in xPM projects. The first level is to satisfy senior management's requirements and get approval to do the project. After that approval is granted, planning can move to the phase level. Planning at the phase level isn't much more than just deciding what Probative Swim Lanes make sense and can be completed inside the phase timebox. So the little bit of detailed planning that is done is done at the swim-lane level. The subteam will plan what is to be done and who will do it. Don't burden them during the early phases with needless planning documents and reports. Leave them free to approach their swim-lane tasks in a way that makes sense for them. Detailed dependency diagrams are usually not prepared. However, there should be a lot of verbal communication among the team members as to the status of their swim lanes.

xPM projects are very high risk, and a solid plan is needed. Just as in the case of APM projects, you should appoint a team member to be responsible for monitoring the plan. The plan itself can take on different characteristics than planning in all other types of projects. Here is an application of risk planning that I have used with success. To the extent that you can identify the requirements or functions that the solution should have, prioritize that list from most risky to least risky as far as implementation is concerned. The early phases should focus on this list from top to bottom. If you can resolve the risky requirements or functions, then you can resolve other requirements or functions further down the list. Of course, the list will change as new learning and discovery takes place. Always attack the riskiest parts of the project first.

Launching the Next Phase

The Launching Process Group includes the following:

• 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

My comments here are exactly the same as they were in the APM project (see Chapter 11). You do each of these things once and then forget about it. You don't need a scope change process either. Use the Launching Phase to decide how to handle what otherwise would have been scope change requests.

Monitoring and Controlling the Next Phase

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

If you are able to use the daily 15-minute team meeting effectively, I don't see a need for much more in the way of monitoring and controlling. I remain pretty steadfast in not interfering with the creative process. As a project manager, your major responsibility is to facilitate the team and stay out of their way.

Closing the Phase

The same comments as I offered for the APM project in Chapter 11 are appropriate here.

Deciding to Conduct the Next Phase

Again the client drives this decision process. The temptation is to hang on to the project much longer than makes sense. If there isn't measurable progress toward an acceptable solution after the first few phases, think seriously about abandoning the project and restarting it in a different direction. Save the time and budget for more fruitful pursuits.

Closing the Project

The Closing Process Group includes the following:

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

The same comments as I offered for the APM project in Chapter 11 apply here.