Project managers often talk about the
triple constraint or scope, schedule and resources/budget. A project has goals, deliverables and
activities that must be performed for it to be successful. That is the scope constraint. A project has a defined start and end date in
which all activities must be accomplished.
That is the schedule constraint.
A project has limited amount of resources based upon the budget at its
disposal. That is the resource/budget
constraint.
A project manager and the project team
create a project plan that makes the best use of the available resources within
the project time constraints to complete all the activities of the project
scope. And then reality happens. Something unexpected occurs that impacts a
portion of the project requiring more work than was planned – and it must be
done immediately. Now the project
manager is faced with a dilemma.
The project manager can refuse to do the
work and maintain the original scope, schedule and budget. But then the project is considered to be a
failure because the delivered scope is inadequate for what is really needed. The project manager can do the extra work and
bring on extra resources to complete it within the original schedule. But the project is considered to be a failure
because it is overrun. The project manager
can do the extra work with the existing resources by delaying some of the planned
tasks. But the project is considered to
be a failure because it missed the scheduled completion.
So the project will be considered a
failure. The project manager must determine
what type of failure they want to have, a scope failure, a budget failure, or a
schedule failure. They can pick two, but
they will miss one – and probably miss it badly.
Research Shows ...
This is not a hypothetical situation. A 2014 report published by Standish Group
concerning project failure rates found that for IT projects in large
corporations, only 9% finished on time and on budget. But though the project manager picked those two constraints, they missed scope. Those projects finished with results that had only 42% of the originally proposed features and
functions. Small companies did somewhat
better. A whopping 16% of their projects
completed on time and on budget.
Over half the time, the project managers picked scope and schedule. But then projects were overrun and the
overrun percentage was 189% of the original budget. When projects were delayed, the average delay was 222%. Fully 31% of the projects were so bad that
they were just cancelled.
A Case Study
How do projects get into such death
spirals? Let me illustrate with a project on which I had experience. This was a large defense development project with
new technology and an aggressive schedule.
During the development, unexpected problems popped up with the
technology. The project manager was
adamant that the schedule and budget must be maintained, so the project team
members kept going with the planned project tasks, even though everyone knew
that there were unresolved technical problems. These problems kept growing in their magnitude
and impact until finally a spectacular test failure occurred (the fireball was
awesome!). By this time the project was
also several months behind schedule and about 10% overrun. The project manager was fired and I was
appointed the new project manager.
When I was assigned to the project, I asked
senior management what the goals were.
And their response was to find out what was wrong and fix it. They also told me if I needed something, come
back and ask for it. Beyond that they
had no specific guidance. In my first
meeting with the team, it was obvious that they were demoralized and scared. I asked which of the three constraints, scope,
schedule, or resources/budget was most important and which was the least
important. The team’s response was that
everything was of the highest importance.
They had to deliver all the features and functionality, they had to do
it on time, and they had to do it within budget. When I pointed out that they were currently
failing all three aspects, their comment was they just needed to try
harder. Yet I could see in their eyes
that everyone felt the project was doomed (and so were they).
In this case, I didn’t even think I had an opportunity
to pick two of the constraints; I had to just pick one. Based upon the nature of this project and the
overall organizational strategic goals, I picked the scope constraint. I directed the team that we would fix the
technical problems. No matter what it
cost or how long it took, we would make sure this thing worked, and worked
well. With that single-minded focus, we went
to work and in a few months we had fixed the technical problems. I then refocused the project team to recover
the schedule. We worked our critical path
closely and aggressively went down the other paths. A year later we finished the project on time
with full functionality. And we were
about 25% overrun. I picked two – scope
and schedule – but missed the third.
That project was considered a success by
the organization because it had recovered from a disastrous state. The overrun was covered by senior management
from a reserve fund, and the system was deployed to our military troops on-time
and worked well.
So What Constraint Is Most Important?
The correct answer is not always to
overrun. When we built the house we are
living in, we had a few unexpected problems that caused extra expenses. We did not want to go back to the bank for
more money, so we choose to reduce the amount of landscaping. In this case I picked schedule and
resources/budget and descoped the project.
As another example, I am in the process of doing an overhaul and update of my company website. The work was started. A new design was established and the resources identified. But then I was pulled into a big project requiring most of my time. I put the website update on hold. Rather than change the scope, or switch to more expensive resources, I decided to delay the project.
As another example, I am in the process of doing an overhaul and update of my company website. The work was started. A new design was established and the resources identified. But then I was pulled into a big project requiring most of my time. I put the website update on hold. Rather than change the scope, or switch to more expensive resources, I decided to delay the project.
Ideally projects complete on-time, on
budget, with all of the requested scope.
But the Standish research shows we should be prepared for the fact that
the project may not. A project manager
should work with their stakeholders to determine which two of the constraints
they will meet, and which one they will miss. Yes, project managers are cursed. But they do get to pick which curse.