Skip to main content

Saved Posts

Replacing the Iron Triangle of Project Management?

Mike Cottmeyer
Reading: Replacing the Iron Triangle of Project Management?

Last year sometime, I heard Jim Highsmith do a talk on replacing the traditional project management iron triangle with a new ‘agile triangle’ that is based not on time, cost, and scope… but instead, based on value, quality, and constraints (time, cost, and scope). This is a concept Jim introduced in the latest release of his book Agile Project Management: Creating Innovative Products. Something in the idea has been bugging me a little, so when I read Isreal Gat’s post this morning, discussing ways to use Jim’s agile triangle, it got me thinking.

The general idea behind the agile triangle is that we need to take the focus off of delivering to a set schedule, a fixed budget, and some predetermined set of deliverables; and focus more on the value the product is delivering. In principle I agree, but does it make sense to modify to triangle to deliver that message?

I’ve always looked at the iron triangle as a way to explain the relationship between time, cost, and scope. If you change one of the three variables, the physics of project management says that one of the others has to change too. If I want to add scope, time or cost has to go up as well. If I want to deliver in less time, I either need more budget or I need to reduce scope. If I want a less expensive product, I either need to reduce scope or reduce the time it takes to build it.

I’m curious if the agile triangle follows this same pattern. If I increase value, does quality have to go up or down? Do the constraints have to change? What about if I change quality? Does value go up? Do I have to change the constraints? What about the constraints? If I tweak the constraints, does that always impact value or quality? There are some guesses that we can make, but the agile triangle doesn’t give us any guidance. The relationships between the variables are less precise, and therefore I think using the triangle metaphor is less powerful.

We all know of projects that have come in on-time and on-budget, with everything the customer wanted, and have been total failures in terms of market performance. I agree that we need to focus on value and quality as first class citizens in the project management discussion. To me though, quality and value are attributes of scope, and it just comes down to the definition of done. Do we have features in our backlog that are ‘done’ when they have poor quality? Are they ‘done’ if the customer does not accept their value? Value and quality are part of the acceptance criteria of scope.

I would probably flip what Jim did a bit and leave time, cost, and scope as the vertices of the triangle, but just like Jim broke the constraints into three attributes, I would break scope into three attributes… requirements, quality, and value. So, the question is… are value and quality project constraints or attributes of scope. I think you know where I stand ;-)

Next Agile Methodology : Explaining Agile

LeadingAgile CEO and Founder, Mike Cottmeyer is passionate about solving the challenges associated with agile in larger, more complex enterprises. To that end, he and his team are dedicated to providing large-scale agile transformation services to help pragmatically, incrementally, and safely introduce Agile methods.

Comments (10)

  1. Max Walker
    Reply

    Great analysis, Mike. I tend to agree with your thinking, that the relationships reflected in the Time-Cost-Scope triangle are more meaningful than the proposed alternative. I also agree that there is not enough focus on the value created in a project, that it's not used nearly often enough as a firm measure of project success. To limit one's metrics of success to Time-Cost-Scope is short-sighted. But we need to add to the view, not replace it, or we're just as short-sighted, only looking in a different direction.

    Reply
  2. Paul Boos
    Reply

    I like this a lot more when discussing projects; especially the way you use it on a specific project to show how trade-offs effect one another (I can deliver faster if we cut the # of deliverables). And especially that as you build a scope for a project based on a "date you need it by" or "budget you have" you need to encapsulate those into what the scope looks like. I'd like to think of it as a triangle in a triangle.

    However…

    When you are looking at analyzing projects in a scorecard approach, you would probably want to use the triangle Gat and Coté (Highsmith's) are using. You could even prioritize the triangle elements to business value (or more precisely perhaps risk to delivering the value required), quality (or risk of low quality), and meeting constraints (or risk of not meeting one of the constraints). If any of those are too high, then the project is subject to termination from the portfolio.

    BTW, I may want to replace this inner triangle (in the project management sense) with a square; adding in a learning or added capability element to the scope and assigning a metric to it as well. Thus a project isnot just about a product deliverable at a certain quality delivering some ROI (value), it is also about building the capability of the team (skills/the ability to do more).

    Reply
  3. Federico Zuppa
    Reply

    Why value would be part of the scope? I see value as the final objective of the project. If the requirements are delivered with the required quality (and meeting the time/cost constraints) (probably) value is delivered. I see Jim's triangle more ambiguous, but more meaningful in the Agile context. Value and quality are very ambiguous words for me (compared to cost, scope and schedule) but I see it this way: We are focused on providing value (meeting customer needs). Sometimes, the customer needs something fast, constrained by a date. Our Agile team will be focused on finishing fast, probably sacrificing quality (accumulating technical debt) but nonetheless providing value. It seems that value should be fixed and we could play with quality/constraints (in the previous example, if quality does not want to be sacrificed and the date is fixed, the cost will go up).

    Reply
  4. joshilewis
    Reply

    I agree that the proposed 'Agile' triangle does not represent a 'law of reciprocity' or proportional relationships.

    I disagree that value is a function of scope. As Federico said, it might be more valuable to the customer to get a lower-quality product early rather than a high-quality product later. Cost may also come into it, in the same way.

    Reply
  5. Mike Cottmeyer
    Reply

    Paul,

    Your suggestion about organizational learning reminds me of Cockburn's idea of software as a cooperative game. Is that what you were getting at? If so, would you look at learning as a project constraint? Something that you might negotiate with the customer at project inception?

    Mike

    Reply
  6. Mike Cottmeyer
    Reply

    Federico and Joshilewis…. I think I am going to respond to your comments as a blog post… it needs a more thorough (and public) treatment. Just because quality and value are attributes of scope (IMO) doesn't mean that I am saying high-quality or high-value… of course we dial those in based on client needs.

    What is the difference between a low-end Chevrolet and a high-end Mercedez Benz. At the end of the day, they are all steel, rubber, paint, and fabric. It's quality and craftsmanship… value is built into how we spec the deliverable.

    Reply
  7. Mike Cottmeyer
    Reply

    Derek, thanks for the link. I had not seen Mike's post.

    That explanation is fine, but I don't agree that quality is a fixed constraint. If we don't make quality part of the acceptance criteria, someone besides the customer decides what is good enough. Should Microsoft not have ever shipped Windows until all the bugs were gone? What is an acceptable level of defects in a product? It is easy to say 0, but pragmatically, does ANY software really have 0 defects? Not often.

    Should it ever make sense to release a product that is good enough… less than perfect? If so, quality should be part of the scope discussion.

    Mike

    Reply
  8. Project Management Software
    Reply

    Executing consists of the processes used to complete the work defined in the project management plan to accomplish the project's requirements. Execution process involves coordinating people and resources, as well as integrating and performing the activities of the project in accordance with the project management plan.

    Reply

Leave a comment

Your email address will not be published. Required fields are marked *