The all familiar iron triangle represents the essence of project management. Conceptually its very simple. Scope, Schedule and Cost are the three corners of the triangle. Impact on one or more of these factors results in a positive or deteriorating effect on quality. For most projects (and most fall under this category by the very definition of a project) all three of these variables are fixed i.e we are expected to deliver a defined scope to a fixed schedule at an agreed cost.
Schedule and cost cannot be accurately estimated and though we have agreed numbers or guidelines on what is the cost and duration. They are estimations and what we do is make an effort to stick to those. Scope is fixed generally and not changed.
In the real world, there are uncertainties that put pressure on the iron triangle – mainly on the cost / schedule variables. Unforeseen problems require additional resources that must be assigned to deliver the same scope or inadvertent delays push the schedule further.
The estimations do attempt to cover certain uncertainties by various techniques like reference class forecasting or basing estimates on historical data. These essentially cover the known-uncertainties – the ones we expect that may come. But given the real world that we live in, execution related uncertainties cannot be fully predicted. These are the ones that cause the most damage and probably what results in the statistics collected by Standish group. In their 2009 bi-annual report, the Boston-based consulting firm The Standish Group reported a significant increase in failed projects. Measured by cancellation prior to completion, or delivered but never used, the project failure rate in 2008 was 24%. Forty-four percent of projects were defined as late, over budget, and/or with less than the required features and functions; 54% of projects had cost overruns and 79% had time overruns.
The question now – is our fundamental model that expects to deliver projects for a defined scope at a committed price and schedule flawed ?
Proponents of Agile would argue that having an iron triangle set the constraints is not practical (see article) and so we must move to a model where we commit to a set of features in a given time and at a certain cost. The customer could change the requirements – remove something before adding more – for that duration – allowing us to deliver predictable number of features at a predictable cost in a predictable duration.
This may work for product development or where software are built from ground up, but for COTS (Commercial Off the Shelf) based implementations, its not that straightforward. The constraints of the iron triangle are a reality for most COTS based implementations that cannot be changed. The scope is fixed and the vendor must commit to a cost and schedule. Also by nature of these projects, the development/implementation work is generally 15-20% of the overall cost/effort of the project. Also the customer needs to have a “live” system that caters to all its needs especially if they are migrating from an old system to a new system. The new system must support all the features in the old system on day 1 of the implementation and so an incremental agile approach is not always feasible.
So the fully agile model also has its challenges as well as the BRUF (Big requirements up front) model. We must cater to uncertainties yet manage the triple constraint put by the iron triangle successfully. What is essentially needed is something of a combination – taking the best from both worlds and catering to the specific COTS implementation.
Would love to hear what the community has to say about this.