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.
In my experience, the driver of cost and schedule is always scope. I am referring to business transformation software projects. In a new development project, unforeseen problems are usually the reason for delays with a cut back in requirements to make the date. The most common solution today is COTS based. Invariably, during the agreement to purchase it is sold (at the management level) as requiring less change because the devil is in the details. After purchase, when the business implementation teams dive further into the details, it becomes obvious that more change is required, the scope is increased and cost, schedule and quality are blown. I believe in the “horses for courses” approach and on the scale of change required, and not reinventing the wheel, COTS is the way to go. But, the only way to go in knowing that the endpoint scope is correct is to do the project in two distinct pieces or two projects. The first being definition & design, with appropriate resources. Followed by a reset of cost and schedule based on fact, approved by Management. Then essentially a new project resumes at build, with a small component of overlap design. Even then scope issues will arise that threaten the cost, schedule and quality balance, but risk management and experienced foresight should control it. It is also important to set (management) expectations at the front end, in order not to surprise them at the end of the first “project”.
You captured it rightly Pete. One question though – You said do it in two projects – first being definition and design, When we do typical COTS based implementations and capture big requirements up front, we enter a detail scoping or a design phase, isn’t it same ? It would make sense if you meant that the vendor does not actually commit to a price before the first project starts and even an indicative price is only committed at the end of the first project – the real project being the second one.