Perhaps you’ve seen a sign at a car repair shop that asked, “What do you want: good, fast, or cheap? Pick two.” While humorous, the sign is also wise: it acknowledges the reality of tradeoffs. You generally cannot optimize every desired outcome of a given situation.
People often apply this so-called “iron triangle” or “triple constraint” to software projects. The problem is that I have seen numerous representations of the triangle with various parameters on the triangle’s vertices—size, cost, time, or scope—and various assumptions made about what is being held constant, such as quality or functionality. I’ve also seen diagrams that show four project dimensions. So, in my view, the “triple constraint” is wrong, although the concept is valid.
The Five Dimensions
I think in terms of five dimensions we have to manage on a software project (Figure 1, adapted from my book Creating a Software Engineering Culture). First, of course, there are the features (aka scope), which itemize the product’s functional capabilities. But it’s important to distinguish quality from scope. I can write software very fast if it doesn’t have to work correctly. The other three dimensions are the time we have available before delivery (schedule), the budget for the project (cost), and the staff available to work on the project. We shouldn’t lump staff and budget together and just call the combination “resources” as is often done. Most of the project cost is indeed staff salaries. I’ve seen situations, though, where a team had adequate funding but could not hire additional staff. In this case, perhaps the project manager can use the available money in different ways, such as outsourcing some work, buying automated test tools, or bringing in consultants.
Figure 1. The five dimensions of a software project.
For each project, we need to decide which dimensions are most critical and how to balance the others so we can achieve the key project objectives. The tradeoffs among these five dimensions are not simple or linear. For example, if you add staff, the schedule might be shortened (although not necessarily) and the cost could well increase. A common, but unfortunate, tradeoff is to shorten the schedule or add features while sacrificing quality. Anyone who has been the victim of buggy software questions these kinds of tradeoff decisions, but they do take place.
Each of these five dimensions can take one of three roles on any given project: a constraint, a driver, or a degree of freedom. Constraints define restrictions within which the project manager must operate. The project manager has no flexibility around a constraint dimension. If a team of immutably fixed size is assigned to a project, staff becomes a constraint. Cost is a constraint on a project being done under a fixed-price contract (at least from the client’s perspective). Quality will be a constraint for a project that develops software for a medical device. Y2K projects were schedule-constrained.
A driver is a key objective or success criterion for the project. For a product with a desired marketing window of opportunity, schedule is a driver. Commercial desktop applications often have features as a driver. The project manager has a little flexibility around the drivers. A specified feature set might be the primary driver of the project, but features are a constraint if the feature set is not negotiable.
Any project dimension that is neither a driver nor a constraint is a degree of freedom. This is a factor that the project manager can adjust within certain limits. The manager’s challenge, then, is to adjust the degrees of freedom to make the project succeed in meeting its success drivers within the limits imposed by the constraints. Suppose that on some corporate information system project the drivers are features and quality and staff is a constraint, so the degrees of freedom become schedule and cost. The implication for this profile is that the features demanded by the customers will all be included, but the delivery time for the product may be later than desirable and the project might cost more than planned.
Here’s a little safety tip: all five dimensions can’t be constraints and they can’t all be drivers! Something has to give to be able to meet the key objectives. If the project is over-constrained, with no degrees of freedom, then you will almost certainly fail. The first added requirement, the first team member who gets the flu, the first risk that materializes will trash the schedule because the project manager has no flexibility to respond to these changes. A student in a project management class I taught once said, “Our project has a fixed budget, we can’t add any people, all of the features are critical, there can’t be any defects, and we have to finish on time.” This project isn’t likely to succeed.
Negotiating Priorities
An important aspect of this model is not which of the five dimensions turn out to be drivers or constraints on any given project, but that the relative priorities of the dimensions be negotiated in advance by the project team, the customers, and management. This negotiation process helps to define the rules and bounds of the project. For instance, schedule is often presented as a constraint when in fact it is a driver. The way to tell the difference is to ask, “Okay, you want this delivered on June 30. What happens if it’s not delivered until, say, July 14?” If the answer is to forget the whole thing because it won’t be useful to us or we’ll be socked with penalties from the government or our client then, yes, schedule truly is a constraint. But if the answer is, “Well, we’d sure like it by June 30, but I guess we’ll live if it’s not available for two more weeks,” then schedule is a driver. If there is some flexibility around a dimension, then it is not a constraint. A little bit of flexibility makes it a driver, and a lot of flexibility makes it a degree of freedom.
Let me illustrate how this five-dimension idea works in practice. Once I heard a discussion between a senior manager and a project manager about a new project. The senior manager asked, “How long will this take?” The project manager replied, “Two years.” “That’s too long,” said the senior manager. “I need it in six months.” So what did the project manager say? He said, “Okay.” Now what changed in those few seconds? Nothing at all! The project didn’t shrink by a factor of four, the team didn’t get four times bigger, and the team didn’t magically become four times as productive. The project manager simply said what the senior manager wanted to hear. (The project took more than two years to complete, incidentally.)
What are some other ways the project manager could have responded instead of simply saying okay? Let’s look at the five dimensions. Maybe he could have asked what portion of the product absolutely must be available within six months. That is, can we cut back on the features intended for the initial release? The project manager could question the schedule, asking, “What’s so vital about six months?” Perhaps this system is replacing a legacy system that runs on an antique computer and they’re removing that computer from the building in six months. Okay, that’s a good reason. Or maybe there’s nothing magic about six months, but we understand there’s a strong desire to get the system operational quickly. In that case the target date of six months is a driver, not a constraint.
You can continue this analysis down the list of the five attributes. Can I get more people or more money? Does the software have to work? Some organizations deliver something on the scheduled release date, but it is severely crippled in functionality and full of bugs. Nonetheless, they declare victory and claim they shipped on schedule, even if what they shipped wasn’t useful. It’s just a little game they play.
Contemplating these five dimensions is a better way to understand your project priorities instead of just assuming that every aspect of the project is both critical and non-negotiable. In part two of this series, I’ll describe two ways to represent the information about a project’s constraints, drivers and degrees of freedom and show you some examples.
Also read The Five Dimensions of a Software Project, Part 2
Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.
