The Curse of the Project Manager

The curse of the project manager is: “Scope, schedule, budget – pick two.” 

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.

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.