Client Involvement vs. the Complexity/Uncertainty Domain
,Consider for a moment a project where you were most certain of the goal and the solution. You would be willing to bet your first-born that you had nailed requirements and that they would not change. (Yes, that type of project may just be a pipe dream, but give me the benefit of the doubt for just a moment.) For such a project, you might ask: “Why do I need to have my client involved except for the ceremonial sign-offs at milestone events?” This is a fair question, and ideally you wouldn't need the client's involvement. How about a project at the other extreme, where the goal is very elusive and no solution would seem to be in sight? In such cases, the complete involvement of the client, as a team member perhaps, but at least as a subject matter expert (SME) would be indispensable. What I have been describing here are the extreme cases in the project landscape.
TPM projects are plan-driven and team-driven projects. Client involvement is usually limited to answering clarification questions as they arise and giving sign-offs and approvals at the appropriate stages of the project life cycle. It would be accurate to say that client involvement in TPM projects is reactive and passive. But all that changes as you move into APM projects. Clients must now take a more active role in APM projects than was their role in TPM projects. For xPM projects, meaningful client involvement is essential. In fact, the client should take on a proactive role. The project goes nowhere without that level of commitment from the client.
Finding the solution to a project is not an individual effort. In TPM, the project team under the leadership of the project manager is charged with implementing a known solution. In some cases, the client will be passively involved, but for the most part, it is the team that will solve the problem. The willingness of clients to even get passively involved will depend on how you have dealt with them so far in the project. They are clearly in a followership role. If you bothered to include them in the planning of the project, they may have some sympathy and help you out. But don't count on it. Beginning with APM and extending through xPM, there is more and more reliance on meaningful client involvement. Clients move from a followership role to a collaborative role and even to a leadership role. In your effort to maintain a client-focus and deliver business value, you are dealing with a business problem, not a technology problem. You have to find a business solution. Who is better equipped to help than clients? After all, you are dealing with their part of the business. Shouldn't they be the best source of help and partnership in finding the solution? You must do whatever it takes to leverage that expertise and insight. Client involvement is so critical that without it you have no chance of being successful with xPM projects.
Meaningful client involvement can be a daunting task for at least the three reasons cited in the following subsections.
The Client's Comfort Zone
Ever since the 1950s, project managers have trained clients to take up a passive role. We trained them well, and now we have to retrain them. In many instances, their role was more ceremonial than formal. They didn't understand what they were approving but had no recourse but to sign. The sign-off at milestone events was often a formality because the client didn't understand the techie-talk, was afraid not to sign-off because of the threat of further delays, and didn't know enough about development to know what kinds of questions to ask, when to ask them, and when to push back. Now we are asking them to step into a new role and become meaningfully engaged throughout the project life cycle. Many are not poised to take up that responsibility. That responsibility is ratcheted up a notch as the project moves further into the APM quadrant toward the xPM and MPx quadrants, where less is known about the situation. The project team is faced with a critical success factor of gaining meaningful client involvement throughout the PMLC. In an xPM project, the client's involvement is even more proactive and engaging. xPM projects require that the client take a co-leadership role with the project manager to keep the project moving forward and adjusted in the direction of increasing business value.
At the same time, the clients' comfort zone is growing. They have become smarter. It is not unusual to find clients who are now more willing to get technically involved. They go to conferences where presentations often include technical aspects. They now know how to push back. They know what it takes to build solutions. They've built some themselves using spreadsheet packages and other applications tools. That has two sides. These types of clients can be supportive, or they can be obstacles to progress.
Ownership by the Client
Establishing ownership by the client of APM and xPM projects' product and process is critical. I often ensure there is that ownership by organizing the project team around co-managers — one from the developer side and one from the client side. These two individuals are equally responsible for the success and failure of the project. That places a vested interest squarely on the shoulders of the client co-manager. This sounds really good on paper, but it is not easily done. I can hear my clients saying, “This is a technology project and I don't know anything about technology. How can I act in a managerial capacity?” The answer is simple, and it goes something like this: “True, you don't have a grasp of the technology involved, but that is a minor point. Your real value to this endeavor is to keep the business focus constantly in front of the team. You can bring that dimension to the team far better than any of the technical people on the team. You will be an indispensable partner in every decision situation faced in this project.” This ownership is so important that I have postponed starting client engagements because clients can't send a spokesperson to the planning meeting. When they do, you have to be careful that they don't send you a weak representative who just isn't busy at the time or who doesn't really understand the business context of the project. Maybe there was a reason that person wasn't busy.
Client Sign-Off
This has often been the most anxiety-filled task that you will ever ask of your clients. Some clients think that they are signing their lives away when they approve a document or a deliverable. You are going to have to dispel that perception. We all know that we live in a world of constant change, high speed, and high risk. Given that, how could anyone reasonably expect that what works today will work tomorrow? Today's needs may not even come up on the radar screen next week. On no project, no matter how certain you are that you have nailed the RBS, can you expect the RBS to remain static for the length of the project. It simply won't happen. That means you had better anticipate change as a way of life in most PMLC models.
Specification vs. the Complexity/Uncertainty Domain
What does this mean? Simply put, it advises you that the choice of PMLC model should be based on an understanding of the confidence you have that the specifications have been completely and clearly defined and documented and that scope change requests will not arise from any shortcomings in the specifications documents. As specification uncertainty increases, your best choices lie first in the Iterative models that populate the APM quadrant and then in the Adaptive models that populate the APM quadrant — those that allow the solution to become more specific and complete as the project commences or that allow you to discover the solution as the project commences. If you have very little confidence that you have clearly and completely documented the specifications, then your PMLC model takes on the flavor of the research and development models that populate the xPM and MPx quadrants.
The PMLC models that require a high level of specification certainty (Linear and Incremental) tend to be change-intolerant. Consider the situation where a significant change request comes early in the project life cycle. That could render much of the planning work obsolete. A large part of it will have to be done over. That contributes to the non-value-added work time of the PMLC model you have chosen. If changes like that are to be expected, a PMLC model that is more tolerant and supportive of change should have been chosen. The non-value-added work could have been greatly diminished or removed altogether.
If you look inside the specifications document, there is more detailed information that might help you decide on the best PMLC model. Specifications are composed of the RBS and WBS. These are often displayed in a hierarchical structure that was introduced in Chapter 4 and is reproduced here as Figure 9-2.
Figure 9-2: The Requirements Breakdown Structure
At the highest level are the requirements. These form a necessary and sufficient set for meeting the expected business value. The illustrated hierarchy is the complete hierarchy that even the most complex and comprehensive requirement might need in order to be clearly understood. In most cases only some subset of the hierarchy will be needed for a requirement. Remember that your objective in defining this hierarchy is so that the client and the project team will clearly understand what the requirement entails. Use your common sense in deciding what that decomposition should look like. There are no objective criteria for deciding on that decomposition.
Uncertainty at the requirements level has more impact on your choice of PMLC model than does uncertainty at the functionality level, which has more impact than uncertainty at the feature level. And despite all of your efforts to the contrary, you can still have changes on any one of these three fronts that could have significant impact on your decisions and best efforts. That's just some of the surprises you will encounter in your daily life as a project manager.
Gauging the integrity of the specification document will always be a subjective assessment. Based on that subjective assessment, you choose a PMLC model, make the appropriate adaptations, and hope you made a good decision. Time will tell.