Graphing the triple constraints of IT failure

Graphing the triple constraints of IT failure

Summary: Every project management trainee is (or should be) taught the triple constraints of time, scope, and cost. These constraints represent trade-offs; you can't change one without affecting the other two. For example, increasing scope has a corresponding effect on both project time and cost.

TOPICS: IT Employment, CXO

Every project management trainee is (or should be) taught the triple constraints of time, scope, and cost. These constraints represent trade-offs; you can't change one without affecting the other two. For example, increasing scope has a corresponding effect on both project time and cost.

In this classic diagram, changing one leg of the triangle affects the other two:

Project management triple constraints

The mysticMundane blog offers an unusual presentation of this fundamental set of project management relationships:

Triple constraints graph

Looking at this graph, I mentioned to project failures guru, Ed Yourdon, that it all seems so obvious. His comment:

It may be obvious, but as Voltaire (and Will Rogers) have said, "Common sense isn't common"

If you're managing a project, it's imperative to understand the relationship between all sides of the triple constraint triangle. The seemingly obvious triple constraint laws are ignored every day, much to the chagrin of those responsible for the failed projects that result.

Topics: IT Employment, CXO

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Problem with triple constraints

    The problem with applying the classic triple constraints to
    IT projects (and often other engineering-type projects) is
    that the trades are generally highly non-linear.

    Resources often differ in productivity by at least an order
    of magnitude and the productivity of resources is only
    weakly correlated to their cost.

    The other problem is that so often IT people (and others,
    but IT is the worst) by the size/scale of the projects on
    which they've worked. This leads to a perpetual over-
    architecting (or I should say ignoring architecture in the
    name of architecture), which further compounds the
    problem by making systems and infrastructure so complex
    (and largely unknown and undocumented) that behavior
    might as well be non-deterministic.

    What am I saying? I don't think the classic rules apply
    enough to be useful. As Brooks said, adding people to a
    late software project just makes it later. A handful of good
    people are worth more than an army of above average
    ones. The resource dimension of the triangle is broken.
    Erik Engbrecht
    • General trends are accurate

      I won't disagree with your points, but the constraints are remain directionally accurate. If you add scope, costs rise, and so on.

      Given some of the failures out there, it seems many project participants need to get a grip on the most basic application of these constraints.
      • I disagree

        It's counter intuitive, but I can think of a number of
        occasions where decreasing budget can enable you to deal
        with increased scope. Decreased budget often gives you
        justification to shed negative producing team members,
        and can quickly force "over architected" solutions off the

        Of course there is some dependence on how you define
        scope. Project managers love to define scope as
        "performance of tasks" rather than "delivery of value" or
        value approximated by "delivery of functionality."

        Equating scope to tasks is about as useful as equating it to
        phases of the moon.
        Erik Engbrecht
  • This is not new

    It is basic economics. The graph in the article is a preference curve. Equillibrium occurs on the curve. Throw in a cost curve to complete the picture.
  • RE: Graphing the triple constraints of IT failure

    I think we call this "Fast, Cheap or Good: Pick 2"
    • Absolutely right

      The basic law - you can't get all three at the same time.
    • Wrong attitude

      Why do startups produce so much for so little compared to big
      vendors and large IT departments?

      Why do shadow IT groups always emerge in large organizations?

      Teams with large budgets lose their creativity. So do IT
      departments with lots of specialized people.

      Statements like this presuppose a mediocre organization.
      Erik Engbrecht
  • RE: Graphing the triple constraints of IT failure

    Just like I tell people when they want a construction job done: Fast, cheap, quality. Pick 2.
    • IT isn't construction

      I don't know how long it will take to shake that myth, so
      people stop trying to directly apply techniques developed for
      large scale construction projects and manufacturing
      operations to IT and engineering project management.

      Operations research contains tons of good stuff, but it tends
      to rely on value, or a reasonably approximation thereof,
      being directly measurable.
      Erik Engbrecht
  • RE: Graphing the triple constraints of IT failure

    Backing up one step...

    I've just concluded my participation in a project where we ripped out Email A in favor of Email B. At the end of the day, it's akin to shopping at Walmart instead of Target -- both do the same basic things, in the same basic ways. We spent a boatload of money that will never have a ROI, will never make us more productive, and probably not make us happier.

    IT seems to be as bad as any other industry in its fads, and I'm wondering if many projects are doomed from the beginning because no one knows what they're looking for in terms of ROI, or productivity, or happiness. Even if the migration or rollout is flawless, at the end of the day it will fail because nothing was gained to justify the cost. In my case, even though the migration went well from a technical point of view, the project fails to justify its cost.

    BTW, in our case, millions was spent, the annual email budget increased by a noticable amount, and the old email system won't go away for years 'cause it does things that we need to do (that the new one won't do).
    • Trading Email A for Email B

      So, I have to ask: "What genius approved that expenditure??"

      Most likely some dodo in management's [b]Ivory Tower!![/b]
    • Perfect example!

      It's simple and to the point.

      Value and completion of tasks are largely independent.

      IT's problem isn't that it can't get tasks done, it's that it
      performs so many worthless tasks.
      Erik Engbrecht
  • RE: Graphing the triple constraints of IT failure

    Hi Michael,
    Thanks for the comment. LOTS of good comments here. It was your diagram I was referring to (I'll edit to include a link).

    Frankly, I think the Triple Constraint is getting a little long in the tooth. To Eric's point, projects shave away at the definition of scope so that they deliver features that may even formally resemble the intended results, but without substantive conformance to the original requirements.

  • RE: Graphing the triple constraints of IT failure

    No, sometimes there are "just win" scenarios whereby all four dimensions: quality, scope, schedule, and resource are all either improved or held constant. To believe that it is a trade off is to believe that innovation and genius is non-existant. To believe that it is a trade off would also mean that all communication has proceeded as optimally as possible and has already uncovered all possibilities of improvement and all the people involved are cooperating selflessly. And because the ability to improve any of these would also constitute a "just win", and because it is highly likely that one of the above is suffering, there are always opportunities to improve things without sacraficing something else. This is what PM is all about, not excuses and tradeoffs.
  • RE: Graphing the triple constraints of IT failure

    Gusto, I agree that there can be "just win" scenarios. Of course this sounds unrealistic in the real world where there are always setbacks and complications. However, if you account for possible setbacks when making your project schedule and you have a realistic budget, then I think it is possible to achieve a certain scope and quality.

    For those of you who are interested, my colleague is hosting a webinar called "Mastering the Triple Constraint" on Sept. 8th. She will show how to maximize your budget while maintaining a set scope and schedule (without sacrificing quality, resources, etc). You can register at