Change vs. the Complexity/Uncertainty Domain

As complexity increases, so does the need to receive and process change requests. A plan-driven project management approach is not designed to effectively respond to change. Change upsets the order of things as some of the project plan is rendered obsolete and must be redone. Resource schedules are compromised and may have to be renegotiated at some cost. The more that change has to be dealt with, the more time is spent processing and evaluating those changes. That time is forever lost to the project. It should have been spent on value-added work. Instead it was spent processing change requests.

You spent so much time developing your project plan for your TPM project that the last thing you want is to have to change it. But that is the reality in TPM projects. Scope change always seems to add more work. Did you ever receive a scope change request from your client that asked you to take something out? Not too likely. The reality is that the client discovers something else they should have asked for in the solution. They didn't realize that or know that at the beginning of the project. That leads to more work, not less. The decision to use TPM models is clear. Use TPM models when specifications are as stable as can be. The architects of the APM and xPM models knew how stability of specifications affected choice of PMLC model and so designed approaches that expected change and were ready to accommodate it. You'll see how WBS stability and completeness impacts PMLC model choice in more detail in Chapters 10, 11, and 12.

The less you know about requirements, functionality, and features, the more you have to expect change. In TPM, you assume that you and the client know everything there is to know about requirements, functionality, and features for this project as can be known. You assume that the RBS and WBS are complete. The assumption then is that there will be little or no internal forces for change during the development project. Externally, however, that is not the case. Actions of competitors, market forces, and technological advances may cause change, but that is true for every project and can only be expected. The best the enterprise can do is maintain a position of flexibility in the face of such unpredictable but certain events.

APM is a different story altogether. Any change in the position of the project in this quadrant will come about through the normal learning process that takes place in any project. When the client has the opportunity to examine and experiment with a partial solution, they will invariably come back to the developers with suggestions for other requirements, functionality, and features that should be part of the solution. These suggestions can be put into one of two categories: either they are wants or they are needs.

Wants may be little more than the result of a steak appetite on a baloney budget. It is up to the project manager to help clients defend their wants as true needs and hence build the business case for integrating the changes into the solution. If clients fail to do that, their suggestions should be relegated to a wish list. Wish lists are seldom revisited. On the other hand, if a client demonstrates the true value of what they want, it can be transferred to a true need. It is up to the project manager to accommodate that new requirement, functionality, or feature into the solution set. It may have to be prioritized in the list of all needs not yet integrated into the solution. The COS session is the best place to make these decisions. Often you should back this up with a Root Cause Analysis (see Chapter 15). For more details on distinguishing the difference between wants and needs see The New Rational Manager by Charles H. Kepner and Benjamin B. Tregoe (Kepner-Tregoe Publishers, 1997).

In xPM projects, there is yet a further reliance on change to affect a good business-valued product. In fact, xPM projects require change in order to have any chance at finding a successful solution. Change is the only vehicle that will lead to a solution.

The bottom line here is that as the project type moves across the landscape, the scope change management process changes as well. Chapters 10, 11, and 12 track the changes in the scope change management process for you.

Business Value vs. the Complexity/Uncertainty Domain

This domain would seem to be trivial. After all, aren't all projects designed to deliver business value? These projects were commissioned based on the business value they would return to the enterprise. This is all true. However, TPM projects focus on meeting the plan-driven parameters: time, cost, and scope. When the project was originally proposed, the business climate was such that the proposed solution was the best that could be had. In a static world, that condition would hold. Unfortunately the business world is not static, and the needs of the client aren't either. The bottom line is this: what will deliver business value is a moving target. TPM PMLC models aren't equipped with the right stuff to assure the delivery of business value. TPM PMLC models deliver to specification within cost and time constraints.

It follows then that TPM projects deliver the least business value and that business value increases as you move from TPM to APM to xPM. At the same time, risk also increases, which means that higher-valued projects are expected in order to be commissionable as you move across the quadrants. Remember that the expected business value of a project is the product of (1 – risk) and value. Here, risk is expressed as the probability of failure, and the probability of success is therefore (1 – risk). So if you were able to repeat this project a number of times, the average business value you would realize is the product of (1 – risk) and value.

What does this mean? Simply put, whatever PMLC model you adopt for the project, it must be one that allows redirection as business conditions change. The more uncertainty that is present in the development project, the more need there is to be able to redirect the project to take advantage of changing conditions and opportunities.

As projects move through TPM, APM, and xPM, they become more client-facing. The focus changes from conformance to plan to delivery of business value. The TPM models focus on conformance to plan. If they also happen to deliver maximum business value, it would be more the result of the inevitable statistical probability that sometimes things just turn out well than the result of a clairvoyant project plan. The focus on delivery of business value is apparent in all of the APM and xPM project management approaches. It is designed into their PMLC models.