Understanding the Complexity/Uncertainty Domain of Projects

The four-quadrant project landscape (Figure 9-1) is used first to categorize the project to a quadrant, and within that quadrant to select a best-fit PMLC model. But even having made that categorization and selected a best-fit PMLC model based on goal and solution clarity, you are not quite finished. Contemporary projects have become more uncertain, and along with this increased uncertainty is increased complexity. Uncertainty is the result of changing market conditions that require high-speed and high-change responses to produce a solution in order to be competitive. Complexity is the result of a solution that has eluded detection and will be difficult to find. That imposes a challenge on the project manager to be able to respond appropriately. Hence the complexity of project management increases as well. Uncertainty and complexity are positively correlated.

Figure 9-1: The Project Landscape

As you move through the quadrants from clarity to lack of clarity and from low uncertainty to high uncertainty, the project management processes you use must track with the needs of the project. Here's a general word of advice: As you move through the quadrants, remember that “lots is bad, less is better, and least is best.” In other words, don't burden yourself and your team with needless planning and documentation that will just hinder their efforts. As my colleague Jim Highsmith said in his book Agile Project Management: Creating Innovative Products (Addison-Wesley Professional, 2004): “The idea of enough structure, but not too much, drives agile managers to continually ask the question, ‘How little structure can I get away with?’ Too much structure stifles creativity. Too little structure breeds inefficiency.”

TPM projects are plan-driven, process-heavy, and documentation-heavy and hence are very structured projects. As you move to Quadrants 2 and 3, project heaviness gives way to lightness. Plan-driven gives way to value-driven, rigid process gives way to adaptive process, and documentation is largely replaced by tacit knowledge that is shared among the team members. These are some of the characteristics of the many approaches that fall in the APM, xPM, and MPx quadrants. You will learn how to choose and adapt several models and approaches that fall under the umbrella of agile.

This notion of heavy versus light is interesting. I've always felt that any project manager must see value in a project management process before they are willing to use it. Burdening them with what they will perceive as a lot of non-value-added work is counterproductive, to be avoided and will probably not be used by them in the spirit in which it was intended. This becomes more significant as the type of project you are managing falls in the PM, xPM, or MPx category. Furthermore, project managers will resist, and you will get a token effort at compliance. My overall philosophy is that the less non-value-added time and work that you encumber your project managers with the better off you will be. Replacing non-value-added work to make more room for value-added work will increase the likelihood of project success. Time is a precious (and scarce) resource for every project. You need to resist the temptation to add work that doesn't directly contribute to the final deliverables. Up to a point project managers should determine what is a value add to their project processes and documentation. Make it their responsibility to decide what to use, when to use it, and how to use it. A good manager makes it possible for his or her project managers to be successful and then stays out of their way. I'll get off my soapbox for now and get back to the discussion of project complexity and uncertainty.

Each quadrant of the project landscape has different profiles when it comes to risk, team, communications, client involvement, specification, change, business value, and documentation. This section examines the changing profile of each domain as a project moves from quadrant to quadrant.

Complexity and uncertainty are positively correlated with one another. As projects become more complex, they become more uncertain.

In the TPM models, you know where you are going and you know precisely how you are going to get there. The definition of where you are going is described in the RBS and how you are going to get there is described in the WBS. Your plan reflects all of the work, the schedule, and the resources that will get you there. There's no goal or solution complexity here. As soon as you move away from a clearly specified solution, you leave the comfort of the TPM world and are in the APM world, which is no longer as kind to you. The minute you have uncertainty anywhere in the project, its complexity goes up. You have to devise a plan to fill in the missing pieces. There will be some added risk — you might not find the missing piece, or when you do, you find that it doesn't fit in with what you already have built. Go back two steps, undo some previous work, and do the required rework. The plan changes. The schedule changes. A lot of the effort spent earlier on developing a detailed plan has gone to waste. By circumstance, it has become non-value-added work. If you had only known.

As less and less of the solution is known, the realities of non-value-added work become more and more of a factor. Time has been wasted. APM models are better equipped than TPM models to handle this uncertainty and the complexity that results from it. The models are built on the assumption that the solution has to be discovered. Planning becomes less of a one-time task done at the outset and more of a just-in-time task done as late as possible. There is less and less reliance on a plan and more reliance on the tacit knowledge of the team. That doesn't reduce the complexity, but it does accommodate it. So even though complexity increases across the TPM to APM to xPM to MPx landscape, you have a way to deal with it for the betterment of your client and your sanity as a project manager.

Requirements

The first place that you encounter complexity is in the RBS. As project complexity increases, the likelihood of nailing the complete definition of requirements decreases. To all observations it might look like you have defined the necessary and sufficient set of requirements that when built into the solution will result in delivering expected business value. But due to the complex interactions of the requirements that value is not realized. Perhaps a missing requirement will surface. At a more fundamental level maybe project scope needs to expand to include the additional requirements needed to achieve expected business value. In a complex software development project, the extent of the number of requirements can be staggering. Some may in fact conflict with one another. Some may be redundant when it comes to contributing to expected business value. Some will be missing. Many of these may not become obvious until well into the design, development, and even integration testing tasks.

I recall a project to develop a wage and salary administration system. The system I envisioned was way ahead of its time and would strain the available technologies and software development tools. I was the senior budget officer for the organization, business analyst, and client for the project and was responsible for facilitating the process to gather and document requirements. I was familiarwith all of the conventional processes for gathering requirements and felt that I had done an exemplary job. The resulting RBS and WBS was a 70-page listing of more than 1400 functions and features. Looking back on that project I don't see how anyone could absorb a 70-page document and conclude that the WBS was complete. We assumed it was only to find out later that it wasn't.

Flexibility

As the project complexity increases, so does the need for process flexibility. Increased complexity brings with it the need to be creative and adaptive. Neither is comfortable in the company of rigid processes. APM projects are easily compromised by being deluged with process, procedure, documentation, and meetings. Many of these are unrelated to a results-driven approach. They are the relics of plan-driven approaches. Along with the need for increased flexibility in APM and xPM projects is the need for increased adaptability. Companies that are undergoing a change of approach that recognizes the need to support not just TPM projects but also APM projects are faced with a significant and different cultural and business change. For one thing, the business rules and rules of the project engagement will radically change. Expect resistance.

Flexibility here refers to the project management process. If you are using a one-size-fits-all approach, you have no flexibility. The process is the process is the process. This is not a very comforting situation if the process gets in the way of commonsense behaviors and compromises your ability to deliver value to your client. Wouldn't you rather be following a strategy that allows you to adapt to the changing situations rather than being bound to one that just gets in the way?

TPM projects generally follow a fixed methodology. The plan is developed along with a schedule of deliverables and other milestone events. A formal change management process is part of the game plan. Progress against the planned schedule is tracked, and corrective actions are put in place to restore control over schedule and budget. A nice neat package isn't it? All is well until the process gets in the way of product development. For example, if the business situation and priorities change and result in a flurry of scope change requests to accommodate the new business climate, an inordinate amount of time will then be spent processing change requests at the expense of value-added work. The schedule slips beyond the point of recovery. The project plan, having changed several times, has become a contrived mess. Whatever integrity there was in the initial plan and schedule is now lost among the changes.

APM is altogether different. APM, like all project management, is really nothing more than organized common sense. So when the process you are using gets in the way, you adapt. The process is changed in order to maintain focus on doing what makes sense to protect the creation of business value. Unlike TPM processes, APM processes expect and embrace change as a way to find a better solution and as a way to maximize business value within time and budget constraints. That means choosing and continually changing the PMLC model to increase the business value that will result from the project. Realize that to some extent scope is a variable in these types of PMLC models.

xPM projects are even more dependent upon flexible approaches. Learning and discovery take place throughout the project, and the team and client must adjust on a moment's notice how they are approaching the project.

Adaptability

The less certain you are of project requirements, functionality, and features, the more need you will have to be adaptable with respect to process and procedure. Adaptability is directly related to the extent to which the organization empowers your team to act. The ability of your team to adapt increases as empowerment becomes more pervasive. To enable your team members to be productive, senior managers need to stay out of their way as much as possible. One way to stay out of their way is to clearly define and agree with them about what they are to do and by when, but be careful not to overstep your role as an effective project manager by telling your team members how to complete their assignments. Don't impose processes and procedures that stifle team and individual creativity! This would be the death knell of an APM project. Instead, create an environment that encourages creativity. Don't encumber the team members with the need to get sign-offs that have nothing to do with delivering business value. Pick your team members carefully and trust them to act in the best interest of the client.

Risk vs. the Complexity/Uncertainty Domain

Project risk increases as the project falls in TPM, APM, xPM, and MPx categories. In TPM, you clearly know the goal and the solution and can build a definitive plan for getting there. Templates that have had the test of time are often used and any risks associated with their use are minimal. The exposure to risks associated with product failure will be low. The focus can then shift to process failure. A list of candidate risk drivers would have been compiled over past similar projects. Their likelihood, impact, and the appropriate mitigation strategies will be known and documented. Like a good athlete, you will have anticipated what might happen and know how to act if it does.

As the project takes on the characteristics of APM, two forces come into play. First, the PMLC model becomes more flexible and lighter. The process burden lessens as more attention is placed on delivering business value than on conformance to a plan. At the same time, project risk increases. Risk increases in relation to the extent to which the solution is not known. On balance, that means more effort should be placed on risk management as the project moves through APM and looks more like an xPM project. There will be less experience with these risks because they are specific to the product being developed. In xPM and MPx projects, risk is the highest because you are in an R & D environment. Process risk is almost nonexistent because the ultimate in flexibility has been reached in this quadrant but product risk is extremely high. There will be numerous product failures because of the highly speculative nature of xPM and MPx projects, but that is okay. Those failures are expected to occur. Each product failure gets you that much closer to a feasible solution, if such a solution can be found within the operative time and budget constraints. At worst, those failures eliminate one or more paths of investigation and so narrow the range of possible solutions for future projects.

Team Cohesiveness vs. the Complexity/Uncertainty Domain

In TPM, the successful team doesn't really have to be a team at all. You assemble a group of specialists and assign each to their respective tasks at the appropriate times. Period. Their physical location is not important. They can be geographically dispersed and still be successful. The plan is sacred, and the plan will guide the team through their tasks. It will tell them what they need to do, when they need to do it, and how they will know they have finished each task. So the TPM plan has to be pretty specific, clear, and complete. Each team member knows his or her own discipline and is brought to the team to apply that discipline to the set of specific tasks. When they have met their obligation, they often leave the team to return later if needed.

The situation quickly changes if the project is an APM, xPM, or MPx project. First of all, there is a gradual shift from a team of specialists to a team of generalists. The team becomes more self-organizing, self-sufficient, and self-directing as the project moves across the quadrants. TPM teams do not have to be co-located. Although co-location would make life a bit easier for the project manager, it is not a necessity.

It is highly recommended that APM, xPM, and MPx teams be co-located. Research has shown that co-location adds significantly to the likelihood of successful completion of the project. Not being co-located creates communication and coordination problems for the project manager. One of the first APM projects that I managed had a team of 35 professionals scattered across 11 time zones. We were still able to have daily 15-minute team meetings! Despite the communications obstacle, the project was successfully completed, but I have to admit that this project added considerably more management overhead for me than there would have been if the team was co-located.

Communications vs. the Complexity/Uncertainty Domain

The Standish Group surveys over the past decade or more have found that the lack of timely and clear people-to-people communications is the most frequent root cause for project failure. I am referring here to both written and verbal communications media. The following is the current prioritized list of the top 10 reasons for project failure as reported in the Standish Group CHAOS 2010 Report.

Projects fail because of:

1. Lack of user input
2. Incomplete requirements and specification
3. Changing requirements and specification
4. Lack of executive support
5. Technology incompetence
6. Lack of resources
7. Unrealistic expectations
8. Unclear objectives
9. Unrealistic time frames
10. New technology

The first three items on the list are related to people-to-people communications, either direct or indirect.

As a project increases in complexity and heightened uncertainty, communication requirements increase and change. When complexity and uncertainty are low, the predominant form of communications is one-way (written, for example). Status reports, change requests, meeting minutes, issues reporting, problem resolution, project plan updates, and other written reports are commonplace. Many of these are posted on the project's website for public consumption. As uncertainty and complexity increase, one-way communication has to give way to two-way communication, so written communications give way to meetings and other forums for verbal communication. Distributed team structures give way to co-located team structures to support the change in communications modes. The burden of plan-driven approaches is lightened, and the communications requirements of value-driven approaches take over.

Value-driven communications approaches are the derivatives of meaningful client involvement where discussions generate status updates and plans going forward. Because projects that are high in complexity and uncertainty depend on frequent change, there is a low tolerance of written communications. In these project situations, the preparation, distribution, reading, and responding to written communications is viewed as a heavy burden and just another example of non-value-added work. It is more for historical record keeping than it is for action items. It is to be avoided, and the energy should be spent on value-added work.