How to save a failing project and when to walk away from one?

PMOs and project managers are faced with failing projects more often than they would like to and it often turns out to be a demoralizing experience for all stakeholders. Consequently, it is vital for PMOs to recognize the signs of a failing project and take corrective action before it is too late. In order to engineer a successful turnaround, PMOs and PMs need to watch for certain leading indicators of project failure.


Leading indicators of project failure

  • Progressive scope creep:  While some scope changes may be necessary, constant updates to the project scope indicates that the project sponsor and other stakeholders don’t have their business case buttoned up or the assumptions under which the project was sanctioned are no longer valid.
  • High rate of churn in project staff:  It is normal to have long projects to have planned rotation of staff.  However, you need to watch for unplanned attrition from the project team.  Each person who leaves in an unplanned way takes with him/her knowledge of the project.  Areas of the project can be put at risk and the team may need to revisit some past decisions because no one knows why the decision was made.  All this results in extra time and cost with no increase in value.
  • High cash burn rate: Are you tracking your Cost Performance Index (CPI)?  CPI = Earned Value/Actual Cost.  If your CPI is trending less than 1, then you are not using your budget efficiently and are burning through cash.

Reversing the trend (Turning around a failing project)

  • Revisit the scope statement periodically (say once a month) and verify if you are still delivering the same project.  If the nature of the scope change is so drastic that it will potentially change the deliverable, take it up with the project sponsor and decide if the project should be stopped in its current state.
  • Review the staffing situation every month.  Evaluate how many unplanned vs. planned exits have occurred.  If a critical resource or a member of the project leadership team has left, it is a red flag.  Summon a meeting with all stakeholders and the project sponsor to assess the situation and plan to bring in an alternate equally capable resource who is committed to delivering on the project.
  • If your CPI is trending less than one month over month, you are putting the project in a financially unsustainable situation.  You should jump into cost control mode and only approve critical expenses.  If you are buying from an outside vendor, use your purchasing team to negotiate a lowest possible price or do this yourself.

Walking away from a failing project

Pulling the plug on a project that is underway is often not an easy thing to do.  There usually are a lot of personal and political forces at play.   More often than not, people will waste money (and time) in order to justify costs they’ve already spent.  The key here is to maintain objectivity and avoid the Sunk Cost Fallacy.  Meet with your project sponsor and review the costs-benefits of the project and be prepared to justify why the project should be cancelled or stopped.

Improving PPM Maturity: Resource Leveling

A quick trip to Wikipedia yields the following definition for resource leveling:  ‘a project management technique used to examine unbalance use of resources (usually people or equipment) over time, and for resolving over-allocations or conflicts.’  In other words, through resource leveling we can ensure that the project schedule is reasonable and realistic from a resource perspective – that the people or equipment needed to execute the work will be available when and where they are needed.

Sounds simple? The reality is that resource leveling needs to take multiple factors into account and can be anything but simple.  And, like anything else that’s really complicated, most of us are looking for better tools to help us accomplish the task.  That’s when the question about automatic resource leveling comes up.

While some project scheduling tools provide a process to see if resources are overloaded, others also provide a function that will recalculate the schedule to eliminate any overloads. As exciting as it may sound, in practice, it’s common to see that managers either never use it or even if they do, they don’t use the resulting schedule without making a lot of other adjustments. Why?  Because even though automatic resource leveling can quickly ‘resolve’ overloads, it typically does it by delaying tasks until the resource is available.  What it cannot do is account for human or project variables; all it does is throw some simple numbers. The solution uses elementary level math to solve a calculus-worthy problem.

While some project managers often take advantage of the speed of automatic leveling they really don’t trust the inferences drawn from the calculation to make their final decisions. They recognize that a resource leveled schedule requires a deeper understanding of the project work and the resource requirement to perform that particular task. It also requires a deeper analysis of more subtle options, tradeoffs, or variables to yield the optimal schedule.

In order to level resources in an efficient, meaningful way, a manager must keep in mind the following:

  1. Resource leveling is not just a math problem. A project manager must consider more than the singular question of effort required over the duration of a task. Instead, one must also think about what makes sense for the type of work being performed.  Some tasks can be completed in less time by adding more people but sometimes splitting up the work canactually increase the time required to complete it, since multiple efforts need to be coordinated and integrated- which makes it even more time consuming.   If you have a team member that needs to attend a three-day class, adding another person will not reduce the time for the class to one and one-half days.
  2. Keep an open mind.  There are many different alternatives to consider when resource leveling. Sometimes it makes sense to work on multiple tasks concurrently while for other kinds of work dedicatedeffort is more practical.  For example,  having a team come together (either physically or virtually) to work through a plan or work through the details of a project deliverable may take less time than going through multiple cycles of email.  Conversely, if we expect to have a document out for review, it is entirely reasonable to schedule the same resources that created that document to work on another task.  You may also want to consider alternative ways of accomplishing the work – such as rearranging the order of tasks or using technological advances to reduce the time required for a given task.  You also need to consider general workload –even though your estimates may indicate that someone can work on 20 tasks simultaneously, you may be building in inefficiency by asking people to juggle too many things at once.  Ever tried reading a book in an airport and realize that you’ve just read the same paragraph three times (or more)?  The fact is that each time you’re interrupted by a flight announcement, you probably don’t pick up at the exact spot you left off – you end up re-reading from a logical spot.  The same happens when we try to rapidly switch between multiple tasks – the very act of switching makes us less
  3. Don’t try to be too precise – Remember that everything in the schedule that you’re trying to level is based on estimates – timelines may change along the course of the project. Good resource leveling requires that you keep your eye on the big picture rather than micromanaging or focusing on granularities.  Also, keep in mind that the further into the future you go, the less sure you will become of everything.  Give up on the notion of leveling to the hour six months into the future – resource leveling is about making a reasonable schedule, not a precise schedule.  The more granular you are, the more you will need to adjust when things change.

Resource leveling is an important part of the project management process, but it can’t be done automatically. While an automatic tool may be handy, it is not a substitute for good old-fashioned common sense from a real-live human being.   A software package cannot appreciate the need for variation in an individual contributor’s day, nor does it understand, as a good manager would that sometimes tasks must be performed concurrently, and they are other times when it they cannot be. The bottom-line is that an automatic tool can begin the resource leveling process, but it cannot finish it without human help.

On a closing note, if you haven’t read Fredrick Brooks’ book, The Mythical Man-Month: Essays on Software Engineering, now would be a good time.