PM Articles > Kent McDonald > How to Deal with Fixed Triple Constraints

How to Deal with Fixed Triple Constraints

by Kent McDonald

A common piece of project management wisdom is that you cannot hope to successfully deliver a project if all three constraints -- scope, time, and cost -- are fixed.

Generally speaking, I agree with that wisdom. Yet I've found that organizations continuously insist on ignoring that advice and demand that IT project teams deliver a specific scope, by a specific date, within a specific budget.

The secret to dealing with fixed triple constraints is to change how you define those constraints.

Instead of arguing project management semantics and "best practices" and obstinately protesting "I can't do that!" I've found it's better to use those expectations as a signal. Let the constraints drive conversations about what your sponsor is really asking for.

The secret to dealing with fixed triple constraints is to change how you define those constraints.

Fixed Time -- What's Driving the Deadline?

When you face a time constraint, dig deeper. Why does that deadline exist?

Did your sponsor set that deadline because there's a compelling, externally driven reason? Do you have to comply with a new piece of legislation or regulation? Are you trying to get ready for a trade show or conference? Did one of your customers create a contractually required delivery date?

These are examples of externally imposed deadlines and they can actually be helpful. You can use the reason for the deadline to help you establish decision filters to determine what you are and are not going to deliver by that date.

On the other hand, did the sponsor pull a date out of thin air (or some other place where the sun doesn't shine) to satisfy their bosses or because the date sounded good?

These types of time constraints are not helpful. While they may provide some artificial focus, there's not a good reason behind them that aids decision making. The only advantage arbitrary time constraints provide is that the person who set the arbitrary date inherently owns responsibility for deciding what won't get produced in order to deliver by that date.

If you find yourself with a time constraint, talk to the sponsor and find out what's behind it. If it's an externally imposed date, discover the specifics and use them to guide decisions about what you deliver. If the time constraint is arbitrary, find out if there are any real deadlines under the surface and suggest that you target those instead. If your sponsor can't come up with any compelling deadlines, suggest that time really shouldn't be a fixed constraint.

Fixed Cost -- Teams as a Constraint

In a typical IT project, the largest component of cost is people -- the salaries of the employees working on the teams or the fees of the contractors/consultants you've brought in to do the development work. That's certainly true where the projects are primarily application development or configuration.

If you find yourself facing a fixed cost constraint and the biggest component of that cost is people, then your constraint is not cost but the capacity of your team(s) to satisfy demand.

If you have a set budget with which to deliver a project, that means your choices for staffing that project are constrained. You can have one of the teams (hopefully cross functional) in your organization work on that project, or you can farm the project out to an outside team.

Chances are there's a specific team, or a few teams, with the appropriate subject matter expertise to work on that project. So if you'd like to keep the work inside your organization, you have to wait until that team is available and then allocate them to work on that project for a given time frame -- defined by an externally imposed deadline as described above, or based on how long the team believes they'll need to deliver the outcome, as described below.

If you choose to farm the work outside your organization you have more flexibility in which team does the work, but you lose the advantage of subject matter expertise. You may have to spend more to get the same outcome, if for no other reason than that the outside teams will take some time to develop the required subject matter expertise.

There's no right or wrong answer; your budget constraints and time pressures will probably determine the right course of action.

What you should not do is think that you can address this problem by giving a team that is already at capacity this new project and expect them to "fit it in." That's a recipe for disappointment and failure.

Fixed Scope -- Define as Outcome

In many cases, fixed time and cost can be liberating. They provide criteria the team delivering the project can focus on. However, for that to work the team needs flexibility somewhere, and that usually comes in the guise of scope flexibility.

So what happens when your sponsor insists that a certain set of things must be done? The trick here is to stop tying agreements about scope to output, and instead define your scope based on outcome.

The normal way of defining scope is to establish a list of deliverables or scope items. Deliver these features, roll out to these departments, provide these documents, or develop these reports -- these are all examples of scope defined in this manner. This is defining scope by output.

The difficulty with this approach is that you define these items at the start of the project, when you know the least about the project. You assume that you need to deliver this list of things in order to successfully complete the project; however, you most likely aren't 100% clear when you create that list why you're doing the project in the first place.

Instead, establish a shared understanding of the outcome you seek to deliver with the project, and set your definition of scope based on that outcome. For example, "We will reduce wait times by 15% by the end of 2018." This allows you to adjust the outputs you seek to deliver based on what you learn as you proceed with the project.

This means you can focus on solving the real problem rather than getting into continuous arguments about whether or not you're going to be able to deliver on the list of outputs you set at the beginning of the project (even though halfway through you realize that half of those things are no longer necessary, or that an entirely different set of outputs are needed instead).

When you define scope based on outcomes, you acknowledge the uncertainty at the beginning of a project. You also set the team up to have a better shot of resolving the outcome by the fixed delivery date, because they have freedom to learn, adjust, and deliver the right outputs as they determine what those are.

A key caveat about outcomes -- you need to make sure that the outcomes you seek for a project are closely aligned with broader outcomes for your organization, and that everyone working on the project understands the connection between the project and the broader organizational outcomes.

Don't Lock All Three Constraints If You Don't Have To

At first glance, constraints seem to be -- well, constraining. But if you define them in the ways described above they can provide strong guides to decision making.

That said, if you don't have to fix all three constraints, don't. A tool I've found useful for guiding discussions about the triple constraints and which ones are fixed or not is the Constraints Matrix. You can use this as a guide to figure out where -- in terms of time, cost (teams), or scope -- you can adjust as you learn.

That's how I typically deal with fixed triple constraint situations. How have you approached similar situations?

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.