Inverting the Iron Triangle

I'm curious. Do we all agree that you cannot predetermine the time, cost, and scope of a project and  have any hope of being successful? Is it not an axiom of project management that you can fix any two of the constraints but the third has to be variable? Up until recently I had always assumed this was the first law of project physics, the one rule that could not be broken. For some reason I thought that everyone understood this concept.

It is amazing to me how often I find myself talking to people about the triple constraints of project management. I am usually off talking to a group about Agile Project Management when someone raises their hand and asks THE QUESTION:

How does this work on my project where time, cost, and scope are all fixed?

The simple answer is this… it doesn't. The reality is that no project management methodology works when you try to lock all three of the constraints. If this is really true, why is it that Project Managers are constantly asked to manage projects with all three constraints determined in advance? As project managers, why are we so willing to go along when we know we're on a path to failure.

I want everyone to know that I totally understand the desire to have it all figured out up front. It is incredibly appealing to think that we can do enough due diligence and planning such that all three constraints become perfectly clear and manageable. The reality is that it just doesn't work that way. Claiming that this is our reality does not make it so.

Project Managers are in a tough spot. When you have a team of execs that are convinced we can plan our way into certainty, it is very difficult to be the person that raises the flag. Being the guy that draws attention to the elephant in the room is not a formula for career advancement. Put your head down, do the best you can, and hope for the best. Maybe we'll get lucky.

The data is showing us that more often than not... we don't get lucky.

If we are willing to accept the reality of the triple constraints, maybe we can begin to have a reasonable discussion about the kinds of decisions we are making about our projects. Let's talk honestly about what is really flexible and what is not. If we have no room to adjust the plan, what does that mean about the risk to our initiative?

When considering Agile methods, there is a fundamental shift in what we are choosing to assume about our project constraints.

Traditional project management usually starts with a discussion of scope, as in "what's the scope of the project?" From there we estimate the amount of work required to deliver the scope, set the project budget and resources, and determine the timeline. If your lucky, you get some room to negotiate on the front side. More often than not, the discussion ends with someone telling you to get it all done by next Tuesday. Even with room to negotiate, the goal is to lock the constraints and get moving.

Agile Project Management starts with a discussion of time to market and cost, as in "when do we need to get a working product to market and how much are we willing to invest." From there we begin the process of estimating how much scope we think can fit into the window. That estimate is not a fixed commitment. We started with the assumption we wanted to fix time and cost. Scope has to be negotiable.

There are implications to taking this approach. We'll need to look at how we structure contracts, how we forecast revenue, and how we make commitments to our customers. When we plan our portfolios, we have to ask if we can realize sufficient ROI - understanding we might not get every feature we originally hoped for. This is what is means to REALLY manage our projects.

Dealing with reality is not always easy. Agile is not a silver bullet. Pretending is not an answer.

Comments

[Machiel Groeneveld]

This is a great (and simple) way of explaining a fixed project vs. Agile project! The time to market and cost is a great way to do a pitch for our customers in stead of doing scope estimates. Finding out what is the least amount of functionality to get a working product is something you need to discover. But that's exactly where the big potential of agile development lies.

[mike crocker]

Hi,
With 10 years experience as a Project Manager in the software and web area, I agree completely. To often the feature sets are not well defined but the market launch and budget are hard numbers. If everyone took the agile approach of developing features as you move toward the "end" date, we would have less failed projects. When the organization is not ready for Agile, I have tried to use an iterative approach to define and build the most important features first. It is unfortunate when the product management group clings to the illusion of control using a waterfall approach.
Mike
Department of Doing