The Triple Constraint

In classic PM, projects are treated as distinct entities within the business. They have a scope, resources, and a schedule that are more or less self-contained. The project manager must work within these boundaries, sometimes referred to as the triple constraint or iron triangle of project management, to deliver the expected results. Any decisions that require changing one of these boundaries must come from outside of the project—typically from functional or executive management. For example, if something unexpected happens that requires changing one of the boundaries (i.e., either the scope, resources, or schedule), then the project manager collects all of the relevant information and brings the issue to the project sponsor. The sponsor, in turn, listens to the situation and takes the recommendations of the project manager under advisement. Before making a decision on how to proceed, the sponsor may add new information to the mix, confer with her peers, or bring it to the next level of management. This whole data collection, analysis, escalation, and decision-making process usually takes time, during which the project may be stalled.

This process is valid in many industries, especially mature ones where much of the uncertainty has been removed from the decision-making process by years of experience. In this case, the management decision makers are hopefully seasoned veterans with their finger on the pulse of the business's finances and market environment. Taking the time to prepare an in-depth analysis for management will likely pay off in the long run on the operational side of the business in areas such as lower production costs, lower support costs, and better overall product quality.

Now let's take a look at a company operating in an environment of internal and external uncertainty but that is trying to apply classic PM methods. The project comes to a decision point, but the project manager sees no obvious answer from his perspective. He starts collecting data so that he can create an analysis to present to the sponsor. However, in this environment there are limited solid facts upon which to build an analysis. This leads him to make educated assumptions, perhaps based on the consensus opinion of his team, which takes additional time. At the completion of the analysis, he notices that there are multiple possible paths with no clear "best option" to recommend. Oh well, perhaps management has additional information that will help make the decision? And he's right. Management does add new information to the equation, but they also add some external uncertainties. The analysis now has so many dimensions and possible outcomes that it becomes nearly useless. Yet somehow, a decision is finally made and the project progresses.

Let's examine what just happened. To make a mediocre decision, the project manager involved himself, a good part of his team, and management. This is both time-consuming and an inefficient use of resources, especially since the same decision, or perhaps a better one, could have been made a lot quicker if the project manager had access to the right information from the start and was allowed to look "outside his box" (i.e., his triple constraint) to make the decision.

In the classic PM model, the project manager is basically put into a box, albeit, a triangular box. He is usually given considerable liberty to operate within the box but very little leeway to work outside it, which is where traditional management gets involved. Even if no explicit directions are given to the project manager, it is human nature to focus on things within one's control, which again is inside the box.

For the large, complex company, this makes pretty good sense. It is only logical that a large organization requiring numerous distinct roles in order to operate should create a project manager role to run the project and a management role to set the boundaries for the project. However, if freed from the complexity constraint inherent in large organizations, would you still choose these distinct roles for your company?

I would argue that while the natural evolution of project management has created these project boxes that cut across the functional silos of large companies, this is not the most agile way to organize projects for smaller organizations. While this model works for corporate giants in mature industries, it falls apart badly as you move to the opposite end of the PM agility spectrum—where speed is required and uncertainty abounds.

Agile Strategy

View your projects in the same perspective as your business, by integrating project and business decision-making processes, and you will better achieve your business objectives.