Toggle Menu

Insights / Agile Transformation / Changing Your Viewpoint of the Project Management ‘Iron’ Triangle (Part 2)

November 19, 2015

Changing Your Viewpoint of the Project Management ‘Iron’ Triangle (Part 2)

3 mins read

In the last post, we looked at the traditional approach to project management in terms of how scope, budget, and schedule relate. Now we’re going to make a couple of shifts in how we look at the resulting triangle.

When looking at this triangle through an Agile lens, we make two fundamental changes. The first is how we view our requirements. Each requirement is prioritized from the most valuable to the least. Our picture looks remarkably similar:

PM Iron Triangle 2_1

We still may estimate our budget and schedule the same way AND we may still have a deadline (real or arbitrarily set).

The second fundamental change is how we execute the work; we will execute in iterations (we could also execute in a flow-based approach with the same effect). This produces working software starting with the most valuable requirements first. In each iteration, we have working software as a product. Our value production now looks like this:

PM Iron Triangle 2_2

As we produce the most valuable items first, we get an initial bang. Then each iteration is slightly less bang as the value of items decreases. Our iterations have everything needing to be done to have our product potentially shippable.

Now we have lots of choices of when to be done. We may decide the project delivered enough value early and after fewer than the planned number of iterations. This happened on a USDA project I had within the Branch I managed. We released early and at less cost, not because Agile promises anything cheaper, but because the amount of value our customer (as defined by our product owner) decided was good enough for what they needed and they had other higher value needs for the money.

Or we could hit the hard deadline and release what has been built because we’ve produced something that works and has some value, though it may not be as complete as we like. Again at USDA, this happened while I was working on a program in support of the American Recovery and Reinvestment Act of 2009. By being able to release, we provided working software to the program and its customers so that loan applications could be received when the customer was required to receive them.

With the concentration of ‘milestones’ occurring at the end of iterations and producing working, releasable software, quality is baked in. A separate beauty of this approach is I only need to know the details of what I am starting work on at the moment, not in the future. It’s rolling wave planning to its fullest.

So with that said, there are lots of avenues to explore? What are your concerns or interests? Let me know and we can explore them here together.

You Might Also Like


Overcoming Obstacles to Continuous Improvement in Your Organization

Does driving change in your organization sometimes feel like an uphill climb? You’ve tried implementing...


Simplifying Tech Complexities and Cultivating Tech Talent with Dustin Gaspard

Technical Program Manager, Dustin Gaspard, join host Javier Guerra, of The TechHuman Experience to discuss the transformative...


How Federal Agencies Can Deliver Better Digital Experiences Using UX and Human-Centered Design

Excella UX/UI Xpert, Thelma Van, join host John Gilroy of Federal Tech Podcast to discuss...