Changing Your Viewpoint of the Project Management ‘Iron’ Triangle (Part 1)
This will be the first of two posts to help you understand the alignment between Agile approaches and traditional phased-gate approaches when it comes to project management. The Project Management Institute defines a project as a temporary endeavor undertaken to create a unique product, service, or result. A project is temporary in that it has […]
This will be the first of two posts to help you understand the alignment between Agile approaches and traditional phased-gate approaches when it comes to project management.
The Project Management Institute defines a project as a temporary endeavor undertaken to create a unique product, service, or result. A project is temporary in that it has a defined beginning and end in time, and therefore a defined scope and resources. This brings to bear the limits of scope, time, and budget (which pays for people, equipment, and consumable materials). This is known as the ‘Iron Triangle’.
Later, well known Agilist Jim Highsmith defined the Agile Project Management Triangle, where the PMI-based elements of the triangle become known singularly as constraints, and the other two points of the triangle are quality and value. Jim is a brilliant individual and I want to show you how you can view these elements, particularly value, in the original triangle’s view. This hopefully will help give you a better feel for how to make the transition in your thinking to Agility.
Project scope is identified as a static set of items, with a set of ‘must-haves’. This scope is then used to estimate the budget and schedule from the project (often the projected end date of the schedule then becomes an arbitrary deadline). So let’s presume that all the scope equates to some value of working software (after all it’s probably something the business said they must have). In a traditional phase-gate project, this would produce value as such:
We get this big bang at the end, as soon as things are tested and deployed (presuming the tests all passed successfully). After that, our product passes along to an Operations and Maintenance state (usually looking like these phases in much shorter time frames). In each of the phases leading up to this deployment, I’ve been dealing with the full stack of must-have requirements in one large batch.
If the project runs late, quality usually suffers as the later phases of development and testing get short-changed as the team rushes to meet the deadline. If the deadline is a hard one (one dictated by statute or regulation, or perhaps by some fixed market window) then if I hit it but haven’t finished with the project yet, what choices do I have to realize early? None really.
In our next post, we’ll examine how just two small tweaks to how we view scope and its requirements and the manner in which we execute the project can shift your thinking to one of Agile terms.
You Might Also Like
Virtually everyone who has ever been part of a team using Scrum or practicing Agile...
In the last post, we looked at the traditional approach to project management in terms...