Choosing the Best-Fit PMLC Model

Choosing and adapting the best-fit PMLC model is a subjective decision based on several variables. Figure 2-9 is a display of the decision process.

Part II discusses the details further. It is sufficient at this point to be aware of the fact that having chosen a specific project approach you are not yet prepared to begin the project. Specific internal and external factors will have to be taken into account and final adjustments to that approach made. These are discussed throughout Part II.

Although you may have easily arrived at a best-fit approach and best-fit PMLC model based on the confidence you have with the RBS and the degree of completeness of the WBS, there is more work to be done before you can proceed with the project. First you have to assess the impact, if any, of a number of other factors. These are discussed below. Second, you have to make the necessary adjustments to the chosen PMLC model to account for that impact. These are discussed in Chapters 10, 11, and 12. The factors that I'm talking about here are those that might affect, and even change, your choice of the best-fit PMLC model. For example, if the PMLC model requires meaningful client involvement, and you have never been able to get that, what would you do? You'll examine the options in the chapters of Part II. For now I want to take a look at those other factors and how they might impact the PMLC model.

Figure 2-9: PMLC model choice process

Total Cost

As the total cost of the project increases, so does its business value and so does its risk. Whatever PMLC model you have chosen, you might want to place more emphasis on the risk management plan than is called for in the chosen model. If one of the team members isn't already responsible for managing risk, appoint someone. Losses are positively correlated with the total cost, so you should be able to justify spending more on your mitigation efforts than you would for a project of lesser cost.

Duration

A longer duration project brings with it a higher likelihood of change, staff turnover, and project priority adjustments. None of these are for the good of the project. Pay more attention to your scope change management plan and the Scope Bank. Recall that the Scope Bank contains all of the suggested ideas for change that have not been acted upon and the total labor time available for their integration into the solution. Make sure the client understands the implications of the Scope Bank and how to manage their own scope change requests. Staff turnover can be very problematic. Put more emphasis on the mitigation plans for dealing with staff turnover. Project priority changes are beyond your control. The only thing you control is the deliverables schedule. That needs to be on an aggressive schedule to the extent possible.

Market Stability

Any venture into a volatile market is going to be risky. You could postpone the project until the market stabilizes, or you could go forward but with some caution. One way to protect the project would be to implement deliverables incrementally. A timebox comprising shorter increments than originally planned might make sense, too. As each increment is implemented, revisit the decision to continue or postpone the project.

Technology

We all know that technology is changing at an increasing rate. It is not only difficult to keep up with it, but it is difficult to leverage it to your best advantage. If the current technology works, stick with it. If the new technology will leverage you in the market, you might want to wait but make sure you can integrate it when it is available. Don't forget that the competition will be doing the same, so rapid response is to your advantage.

Business Climate

The more volatile the business climate, the shorter the total project duration should be. For APM projects, the cycle timeboxes could also be shorter than typically planned. Partial solution releases will have a higher priority than they would in business climates that are more stable.

Number of Departments Affected

As the number of departments that affect or are affected by the project increases, the dynamics of the project change. That change begins with requirements gathering. The needs of several departments will have to be taken into account. Here are three possible outcomes you need to consider:

• The first possible outcome is scope creep during the project scoping process. Each department will have its list of “must haves” and “wouldn't it be nice to haves.” Not all of these will be compatible across departments, but one thing is for certain: these differences will cause scope creep. You may have to think about versioning the project — that is, decomposing it into several versions or releases.
• The second possible outcome is a higher incidence of “needs contention,” which means the needs from two or more departments may contradict one another. You will have to resolve the conflicts as part of validating requirements.
• The third possible outcome impacts the PMLC Model. As the project becomes more of an enterprise-wide project, the likelihood of the project becoming a multiple team project increases. There are several implications if this should occur. Chapter 17 takes up this important topic.

Organizational Environment

If your company announces reorganizations and changes in senior-management responsibilities quite frequently (such as once a week), you have a problem. The single most-frequent reason for project failures as reported in the past several Standish Group surveys is lack of executive level support. That includes loss of support resulting from company reorganization. For example, say a sponsor who was very enthusiastic about your project, and a strong and visible champion for you, has been replaced. Does your new sponsor feel the same? If so, you dodged a bullet. If not, you have a very serious problem to contend with, and you will need to amend the risk list and provide suggested mitigation strategies.

Team Skills and Competencies

The types of skilled professionals you ask for in your plan are often not what you eventually get. It's almost like availability is treated as a skill! One of the principles I follow in proposing resource requirements is to ask for the “B” player and build my plan on the assumption that that is what I will get. Requesting the “A” player can only lead to disappointment when a “B” or even a “C” player shows up. In general, TPM projects can handle a team of “B” players, and they don't even have to be co-located. APM projects are different. APM projects use two different PMLCs. When you are missing some of the features of the solution, “B” players, with supervision, will often suffice. When you are missing some of the functions of the solution, you would prefer “A” players, but you may be able to work with a few “B” players under supervision. The less you know about the solution, the more you are going to have to staff your project with “A” players or at least with team members who can work independent of supervision.