Replacing the Iron Triangle of Project Management?

Last Updated on Thursday, 15 November 2012 01:04 Written by Mike Cottmeyer Thursday, 28 January 2010 03:36

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

My Life is a Project?

Last Updated on Thursday, 15 November 2012 01:04 Written by Mike Cottmeyer Wednesday, 23 December 2009 04:23

When I’m giving talks or teaching a class, I often talk about how I think about nearly everything in my life as a project. So much so that my wife sometimes complains that she is not a project that I have to manage! She get’s tired of talking about risk mitigation strategies and desired outcomes. She isn’t particularly interested in understanding our assumptions or constraints and really does not like being called a primary stakeholder.

In all seriousness… I don’t quite take it that far… but I do tend to see things through a ‘project’ lens.

Earlier this morning I came across a great post by Scott Berkund titled ‘Everything is a Project‘. I liked the post so much (for obvious reasons) that I sent it out as an ‘Interesting Post…’ over Twitter. Several folks re-tweeted my tweet and a few folks commented. One of the comments came from Bob Marshall, aka @flowchainsensei. Here is what Bob had to say:

@flowchainsensei Way too many things are projects – especially projects. Projects are dysfunctional, wasteful and anti-flow. Let’s put an end!

And my response…

@ mcottmeyer I think that the project metaphor can be useful when we don’t have level investment across product lines.

Clearly this was way too deep a topic to explain in 140 characters, so I wanted to share my thoughts around projects and where I think they are useful… and where I think the concept is overused.

First… the simple definition of a project goes something like this… ‘a project is a temporary endeavor, with a defined beginning and end, that is created to achieve some particular goal or desired outcome’. I’m pretty sure that definition came from the PMBOK, but I lifted the language from Wikipedia. Pretty basic and seems to make sense, but does it fit the way that our organization really does work?

Project Management 2.0

Last Updated on Friday, 16 November 2012 12:50 Written by Mike Cottmeyer Friday, 18 December 2009 06:01

I put Project Management 2.0 as the title just to give Glen Alleman a moment of pause Actually, Andrew Filev has posted 33 of his favorite thought-provoking blogs on Innovation, Project Management, and Web 2.0. Since Andrew was kind enough to include Leading Agile… and he is asking his readers to vote for their favorite… I thought I would include a link to his post here.

Managing Expectations about Uncertainty

Last Updated on Friday, 16 November 2012 12:50 Written by Mike Cottmeyer Thursday, 10 September 2009 10:59

One of the biggest differences between the PMI crowd and the Agile crowd has to do with our expectations about uncertainty.

The PMI crowd generally believes that a Project Manager is supposed to manage uncertainty out of the project. The Agile crowd tends to believe that uncertainty and change is something that should be embraced. Rather than managing OUT uncertainty, the agilist chooses to manage FOR uncertainty.

This difference fundamentally influences how we go about the business of planning projects… the artifacts we create… and how we interact with and manage our teams. The reality is that both worldviews have a place depending upon your context and problem domain. It’s up to us [as Project Managers] to recognize the nature of the projects we are working on and choose the strategy most likely yield a desireable outcome… for both our project stakeholders and our external customers.

We cannot check our brains at the door and blindly follow ANY methodology. It’s up to us to assess our situation and choose an approach that is suitable for the task at hand.

Why Project Managers Like Documentation

Last Updated on Friday, 16 November 2012 12:52 Written by Mike Cottmeyer Monday, 1 December 2008 12:39

Reposted from Artem’s Agile Software Development Blog

Most software project managers have very little power in an organization. They are on the hook for delivery, but have very little control over the actual resources required to get the job done. Project managers have to broker agreements, hold people accountable, and get people to do things that they are not otherwise incented to do.

Fixed Constraints and Up Front Design

Requirements documents are created early, and often with little input from the delivery team. Budgets are set and timelines negotiated, prior to the project team even being engaged.

In other words… project managers are in a pretty bad spot. They are trying to manage in a situation where the triple constraints are all set for them, they have little direct control over resources, and the resources they have are matrixed across several projects with competing priorities and differing agendas.

Project Managers Want to Succeed

Project managers are often very driven people. They are detailed oriented and focused. Believe it or not, project managers don’t want to fail. Project managers are people that are committed to being successful… they want to deliver and do a good job.

So… what can a project manager do to ensure success? Focus on paperwork and process.

Paperwork and Process Defines Success

Because project managers are in an impossible situation, they retreat into self-preservation mode. They focus on comprehensive documentation and sign-off to hold people accountable. They put process and documentation over working software because the constraints of the organization ensured failure from the very beginning.

Over time, people get used to operating in this manner. Project managers get promoted and run PMOs. They run development organizations. They become a part of the business. The challenge is that they carry these self-preservation attitudes with them as they move up the ranks.

We have ended up with a bunch of leaders that think this is the way software gets created. They think that paperwork and process is the way software gets delivered to market. The thinking is so pervasive, no one even questions how we got here.

Changing Behavior Will Take Time

If we want to change this behavior and begin to tear down these walls, we need to encourage transparency and create an environment of trust. Project managers need to be able to bring the difficult issues to the business and be assured that the business will not punish them for their integrity.

Companies need to create a culture where assumptions get validated, and when they are not valid, the plan changes. We need to create a culture where risk is managed, but when it is realized, we accept responsibility for our mitigation strategies. We can talk about change management, but we have to understand that change is not free.

I understand it is difficult to run an uncertain business. We can’t wish that uncertainty away and we need structures and frameworks to help deal with it. Agile project management is just such a framework. Agile help us embrace uncertainty and deal with it.

Holding Project Managers Accountable

Hold project managers accountable for effectively managing assumptions and risk, good decision making, and proper escalation to the right people. Hold them accountable for how well they communicate and keep the business informed. Reward them for coming up with creative proposals and implementing effective strategies.

Unless we want mountains of documentation no one will ever read, let’s stop holding project managers accountable for plans that should never have been laid in the first place.

Subscribe to this blog

Photo Credit: www.polaricecapz.com/books_b.html