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 ;-)
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)