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.
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.
Comments (10)
Max Walker
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.
Paul Boos
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).
Federico Zuppa
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).
Derek Mahlitz
How about Mike Cohn'a "one handed clock" to convey project goals – http://blog.mountaingoatsoftware.com/using-a-one-handed-clock-to-convey-project-goals
joshilewis
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.
Mike Cottmeyer
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
Mike Cottmeyer
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.
Mike Cottmeyer
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
Project Management Software
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.