Chris Vandersluis, President
This paper was originally delivered at the PMI Global Congress in New Orleans in October 2013.
Abstract
We project managers are a result-oriented, hard-driving, never-quit sort of people. So, it goes against the grain for us to have to cancel a project we’re managing. Most of us would rather do anything but cancel a project and many of us have tried countless other options. We’ll consider merging this failed project with another to see if the two together will do any better. We’ll change the project manager, change the team, change a vendor or change the project title.
Anything but cancel it.
Yet, cancelling a project can often be the very best thing for not just the organization who can stop investing in something that has no hope of ever giving a return but also for the team members who can move from a project they know has no hope of ever making a difference to one where they can make a contribution.
This presentation will discuss how to identify a project which should be cancelled, distinguish it from a project that is merely troubled and then if need be, actively cancel a project in a way that is empowering to the project team, the organization, the stakeholders and even the project manager.
Overview
Quit? It’s not in our nature. As project managers, we’re hard-wired not to quit. Project managers are, by nature, optimistic. We are the results-oriented, challenge-motivated, never-say-die, make-it-happen, see-the-glass-half-full sort of people. After all, when the project is in its infancy, where there is nothing at all to show for it but a good idea, the project manager carries the vision of the completed project with them. They are the evangelist for the project completion.
Even now, aren’t you reading this very article and thinking, “I hope he’s going to tell me how to save that project that I really don’t want to cancel”?
You wouldn’t be alone.
As a culture, project managers are natural cheerleaders. We are expected to shepherd the project from conception through completion.
Sometimes, it’s just time to stop
The American Plains Indians have a saying, “If the horse dies, dismount.” Project managers would prefer to do anything but. Rather than getting off a dead horse (project), project managers are more likely to change riders (project managers), put two dead horses (projects) together to see if they pull the cart faster as a team. We’d prefer to rename the horse, send the rider for more training, add funding to the horse or just wait quietly on top of it hoping that no one notices that it’s not breathing and avoid declaring what everyone already knows. The horse isn’t going any further forward.
Yet, in a modern project management world, our focus is likely to extend beyond a single project and into portfolio management and when projects must compete for the same resources, there may come a time when cancelling a project is the best path forward for the entire organization.
The first step in stopping a project is identifying whether it is appropriate to continue. This may not be immediately obvious. Two techniques which are popular to aid organizations in revealing projects which are in trouble are Dashboarding and Stage-Gating. Organizations which have adopted a dashboard evaluation system or a formal stage-gating process have created evaluation mechanisms within those processes to identify projects which should come under further scrutiny.
A well-designed dashboard environment will keep track of metrics for a large number of projects and can highlight projects which have exceeded acceptance thresholds. There are several key criteria that must be implemented as part of a dashboard environment for it to be effective at showing which projects should be reviewed in more detail. These include ensuring that the metrics used are objective to the maximum extent possible, ensuring that the dashboard shows all the data, not just some of it and ensuring that the metrics measure something actionable.
A well-designed Stage Gate environment is a formal pause or stop of a project between one phase and another so the merits of continuing the project can be assessed. There are several key criteria of a Stage Gate environment that will make it effective at identifying and helping to slow or pause a project which should not continue. These include making the evaluation panel at each gate as objective as possible, ensuring that the metrics used to evaluate the project measure objective criteria and, most importantly, being able to close a gate when it is required.
Even in this type of formal evaluation process, there is still resistance to stop any project once it has started. Stage Gating may exist, but all the gates are locked in the open position. If you can’t slow, pause or cancel a project, then the Stage Gating process has questionable value.
A culture of blame can be a major contributing factor to why a project manager won’t suggest a project should be cancelled. Yet the reason the project shouldn’t go forward may not be anyone’s fault. There are a limitless number of possible reasons that pausing or cancelling the project is the right course of action. Perhaps the economics of the project have changed. The expected return on investment might now not be possible because the price you thought you’d get for the finished product is no longer likely. Perhaps the economy itself has changed. A project of luxury goods perhaps has no place in a region where luxury is no longer sellable. Perhaps a competitor has changed the landscape by releasing a competing product before you expected and before you’re ready. Perhaps you’ve lost some key personnel with critical knowledge and expertise that are required for the project’s success or perhaps the project has exceeded budget, schedule, risk, quality or complexity thresholds that makes continuing with it questionable.
Whatever the reason, avoiding blame makes an enormous impact on making the right decision moving forward. In some organizations, blame is so engrained in the culture that just association with a project that might not be doing well is a career limiting condition. Such organizations can spend enormous effort determining who is at fault and miss the chance to move more effectively to pause or stop a project and to reap some of the benefits that might come from such actions.
Instead, creating an evaluation criteria and an action plan on how projects can be identifying, evaluated and paused or cancelled can focus on more objective criteria.
Can you identify a project which shouldn’t continue?
Whether you use a formal stage-gating process or an ad-hoc business review process, there are a number of methods to determine that a project should not go forward. Using objective criteria enables us to apply basic comparative measures to this project versus other projects and other opportunities. We never have to say “That project is bad”. We can simply point to an analysis which indicates that our efforts would be better rewarded at this time by redirecting our resources to another opportunity and having this one pause or stop.
When a project surfaces as requiring additional review, one of the first and most obvious actions that is impactful is to go back to basics and back to the beginning. Start with a business case “refresh”. Whatever business driver metrics you used when the project started should get reviewed. Does the project still have the chance to deliver the expected return on investment? Is the deliverable from the project still desirable? Using the same structure you used to evaluate the project before it started, allows you to compare what the current situation is.
It is not uncommon at this juncture to find out that the project that is in trouble actually doesn’t have a business case. If not, it’s a great time to write one. Your analysis will point the stakeholders to the basic questions we ask at the beginning of any project: What are your success criteria? What return on investment do you expect? What constraints of time, resources, budget and quality are key? What business metrics will be used to evaluate the value of this project?
Another method of evaluating a project is to use the 10 knowledge areas of the Project Management Institute’s PM Body of Knowledge. Evaluate the status of the project from each of these areas and compare that evaluation against the expectations at the beginning of the project:
Project Integration Management
· Project Charter
Is there a Project Charter? It isn’t uncommon to find out that projects in trouble never had one made or never had it approved or that no one has looked at it in some time. Does the Project Charter represent the direction the project is in at this time? For example, excessive change orders might have moved the trajectory of this project sufficiently that it no longer reflects the Project Charter.
· Project Management Plan
Do you have a Project Management Plan? Is it up to date? Is there a baseline or baselines for comparison against the current plan? Are the plans being maintained and tracked? Does the current project plan reflect the project’s original expectations? Often we can find a schedule from the original business plan but no baseline to use for later comparison and no updates since the project’s debut.
· Monitor and Control Project Work
Do you know how much time is being spent on tasks compared to their estimates? Does your timesheet system reliably measure the actual hours and/or costs and is that information returned for comparison to the project plan at a level where decisions can be made? Often we find a project plan, but actuals are collected only at a time and attendance level. We know how much we’re spending for people’s time but we don’t know what the people are spending their time on.
· Integrated Change Control
How much change occurs on this project? Are the changes documented, approved and monitored? Can you identify the costs of each change? In some organizations original plans are highly managed but changes are allowed on an ad-hoc basis without any tracking. They are considered more tactical decisions from the front line. When the number of changes are excessive however, they can become more costly than the whole of the original project.
Project Scope Management
· Collect Requirements
Do you have a reliable list of the requirements? Often we find a project is extending its scope, resource requirement and costs because requirements were never agreed upon at the beginning. The results can be runaway change requests.
· Define Scope
Was the scope well defined before the project started? Is the original agreed upon scope still reflective in the current project or has the trajectory of the project changed and is that new trajectory acceptable. One key measure is the change in the size of the scope. If a project started at one size and has dramatically changed its size over time, then even though there may be a good change management process, the project begs review with its sponsors.
· Control Scope
Is there control over any scope changes? Is there a good documentation of any changes that are requested and approved? Can you identify approved and proposed changes from the original project?
Project Time Management
· Estimate Activity Resources
Is the original estimate of the work being reflected in the current status? Are assignments taking approximately the time originally estimated? For the effort expended to date, has the appropriate amount of work been completed? Earned Value is a tool that is considered in this area as it can highlight the changes from the original expectation of work accomplished for effort expended.
· Estimate Activity Durations
Aside from the resources, were the estimates originally made for tasks accurate? Is it taking significantly longer (or shorter) than was expected?
· Sequence Activities
Are we seeing a lot of Out of Sequence activities? Perhaps the original logic of the project isn’t accomplished in the sequence that was anticipated at the start. Perhaps looking forward we should pause and reassess the sequence of future work.
· Control Schedule
Do we have good tracking and control of the schedule? Can we compare the original baseline, the current approved baseline and the current schedule? How do we approve official changes to the schedule? At a very basic level, is the schedule updated with actual progress? Do we trace progress to an activity-based-timesheet records?
Project Cost Management
· Estimate Costs
Were our original estimates of costs correct? Are the costs tracked so far exceeding the original estimates and do we need to re-estimate the remaining work?
· Determine Budget
Was a budget for the project approved? Is the projection of expenditures commensurate with the project budget? Were all changes to the budget and estimated work approved and is there a process for approving budget changes? One metric that can point to problems in this area is the frequency with which the budget must be changed.
· Control Costs
Do you have a comparative cost control process? Are both labor and non-labor costs tracked? Is there an audit process that can show how costs compare to the original budget and current accepted budget? Are estimates of future costs calculated from trends in the project thus far and is the current trajectory of project costs acceptable?
Project Quality Management
· Perform Quality Assurance
Is quality assurance being measured, documented and tracked in any way? Are there quality acceptance metrics that were established at the start of the project and are those metrics being followed?
· Control Quality
Is the quality of the project output being tracked against original metrics? Is there a process for intervening if the project is not meeting the accepted metrics?
Project Human Resource Management
· Acquire Project Team
Was the project team that was originally envisaged ever assembled? In some projects, one of the success criteria in a project charter identifies the types of skills and knowledge that must be found amongst the team members. If those skills were never located, this can be an indication that the project’s chances for success are limited.
· Develop Project Team
If the project team is never developed as a team or if factions are creation or if the team was expected to develop internal knowledge and skills and this never happened, this can be a key indicator that the project will be challenged.
· Manage Project Team
Is the team producing what it expected? Have team members who indicated they had certain skills been able to deliver the results of those skills? Are the timesheets of team members being maintained? A project which is currently being challenged will often have the characteristic of overburdened team members who are being pressured to perform to excess in order to keep the project afloat. Team members who have reached a point of burn-out become much less productive very quickly. Another related indicator of a project with challenges is a high degree of turnover in team members. Finally, if the project team is changing, are the skills and knowledge that were identified in the Acquire Team section, still available to the project?
Project Communications Management
· Manage Communications
When the news is bad, it is not uncommon to find breakdowns in communication. If there is no communication plan then a lack of communication is often common but even if there is a plan, one indication of how things are going is determining if communications are being managed through the plan or not.
· Control Communications
Are communications devolving into ad-hoc conversations? One indicator of a project which is in trouble is that the stakeholders are starting to get the most current information extraneously through the organizational rumor mill, water cooler talk and even social networking. Just controlling communications with a heavy hand doesn’t fix a problem however. But, an indicator of communications protocols unravelling is a good signal that more investigation into how the project is doing is warranted.
Project Risk Management
· Identify Risks
Were risks to the project identified at all? In some projects were risks have appeared or more risks are appearing, it can be an indication that an adequate assessment of the challenges the project is facing is missing.
· Perform Qualitative Analysis
Aside from a list of risks, is there adequate analysis of the potential impact of those risks? Often a project in trouble will have had some risks already realized. If that is the case, did the original assessment match the impact when the risk factor actually occurred?
· Perform Quantitative Analysis
Quantitative Analysis can project future impact of the risks that have been identified. Not every project needs a Monte Carlo analysis but for those projects which carry risks with high impact, it is worthwhile to do some level of quantitative analysis. If some risks have occurred, then a review of the impact of the actual risks vs. the original expectation from the quantitative analysis can give an indication of what might be expected in the future. One metric that can be implemented here is comparing quantitative analysis for the project now with what the analysis was at the start. In theory, on the last day of the project, there should be no risk left. On the first day of the project there should be the maximum amount of risk. If, at a mid-point of the project, there is more risk than was there at the beginning, this may be an indication that the project scope requires review.
· Plan Risk Responses
Are there mitigation plans in place for the most impactful risks? Have any of those risks materialized and, if so, were the mitigation plans effective? Are there effective mitigation plans for the risks that still remain in the future?
Project Procurement Management
· Control Procurements
Are purchases being managed according to an established process? Is there a comparison to the original purchase request to ensure the correct quantity and quality of the product or service purchased was delivered and that the pricing matched the original purchase order? A runaway procurement process can be a signal that the project is at risk, particularly when the project has a high degree of sub-contracting or material purchases.
Project Stakeholder Management
· Identify Stakeholders
Were the stakeholders ever identified? Are they part of the communication process? If there are personnel changes, have new stakeholders replaced those who have left or have others already present taken over the roles that have been vacated?
· Management Stakeholder Engagement
Have all the roles which must be fulfilled by stakeholders been filled? Are the stakeholders delivering what they are expected? A measure of a project in trouble can be a key stakeholder who does not engage or participate.
If you do a Return on Investment (ROI) analysis (always a good thing to think about when you pause a project for a business review), don’t forget that the “I” in Investment is not zero. You’ve already spent some of that money so the investment you’ve got to consider is the remaining resources and money it would cost to complete the project. A business review and a return on investment calculation might result in a negative return on investment if the entire cost is calculated. But the money spent is already spent. There is no un-ringing the bell. When you pause a project with the intent to determine if you should go forward or not, the Return on Investment Calculation that is critical for that decision is the remaining investment versus the return that is expected.
If the project must be cancelled, you may be giving up on the R in Return but at least the I in Investment won’t get any bigger.
Another calculation that is often forgotten during a business review of a project that has been paused for evaluation is Opportunity Cost. If you weren’t spending any more on this project and your resources weren’t tied up on this project, could they be doing something on another project that would be so valuable, that the loss of the return on investment here would be overcome?
The benefits of stopping the project now
Cancelling a project isn’t all bad news. When a project ends, some benefits occur naturally and others can be discovered with good project-cancellation practices. When doing a business review to consider cancelling a project, including only the costs and challenges would be incomplete. A list of possible benefits should be included. Some of the most common project cancellation benefits include the following:
Increased Resource Capacity
The first and most obvious benefit is the newfound availability of the project team. If they aren’t working on this project, they will immediately become available for other projects. Before the project team disperses to the four corners of the organization however, make sure that they are available for proper wrap up and, in particular, for the salvage benefits we’ll talk about next.
Salvage
It is often surprising to people how much work-in-progress can be adapted to other purposes. In some cases, this can be a complete (but more modest) product. In other situations there may be recoverable modules that are immediately valuable on other projects. Throwing out everything that has been accomplished in the work to date just because the project is being cancelled is a common and often big mistake. Include in your salvage thinking things that have been procured or services subscribed to as well as any services that have been pre-paid or cannot be cancelled immediately. Perhaps another project in the organization can use those products and services for something productive.
Improved Morale
A soft-benefit to project cancellation is almost always improved morale. It is typical that most of the project team working on a project that needs to be stopped knows that cancellation is a real possibility. There is almost always a sense of relief that the challenges facing the project are out in the open and the knowledge that the end of the project doesn’t mean the end of their employment is usually great relief for staff who can now work on something more productive.
How do you stop a project? Very carefully
If you do have to cancel a project, make sure you do so consciously. Just ending a project in an emotional tirade has the potential to cause more damage than keeping it going.
End of project best practices
Develop and adopt some key end-of-project best practices and make sure you apply them in this situation. They might include meeting the staff to review what can be salvaged from the work in progress. You may find that there are significant benefits to be found in the work accomplished to date.
Business Review
Consider the Business Review during the identify phase as a starting document for those involved in the decision to stop the project. In particular, focus on the return on investment calculation of stopping the project now. This includes potential benefits realized for the amount of effort and money expended as well as the opportunity cost of not focusing the resources elsewhere.
Communicate, communicate, communicate
Make sure you take care of the team members who are on the project that is about to be cancelled. Over-communicate and make sure the staff have an opportunity to give feedback during the business review. Perhaps they have a perspective that you haven’t considered and all input at this time is probably welcome.
A no-blame zone
Make a determined effort to keep blame out of this process. Blame is generally useless anyway but focusing on who to blame instead of what to do can rob you of any opportunity to get positive results out of this otherwise unhappy result.
Wrap up meeting
Do a wrap-up meeting to close off the project and thank all the team members for their participation. Make sure that any lessons learned and other project documentation is recorded and archived along with any work-product.
Make sure there is a final accounting of the project so the true cost vs. benefit can be calculated. Also make sure not to forget your sub-contractors. Make sure all outstanding invoices are resolved and that there is nothing outstanding with your vendors such as long-term subscriptions. After all, you may be working with them again on the next project soon.
What about my career? Am I now associated with a failure?
In 2005 KPMG did a Global IT Management Survey. In it they discussed projects that had to be stopped and one commentator said, “Cancelling a project unlikely to deliver expected benefits should not be seen as a failure – failing to cancel such a project should be.” It makes perfect sense. If you are a steadfast cheerleader for a project that should not continue, then you’ve just become part of the problem, not the solution.
As a project manager who must guide a project through early cancellation of the process is that you become an “honest-broker” to management. You are showing that you are willing to stand up and share the bad news and your credibility with management as a result will almost certainly increase. If you’ve done a good job of closing out the project you’ve also got a lot of data and benefits to offer.
If you have looked at both the challenges and benefits, you can present the decision to management without focusing on only bad news. Salvage benefits in particular affects the return on investment decision for continuing the project. The benefits to the rest of the organization should also be pointed out as you’d like management to know that cancelling a project isn’t always a catastrophe. After all, freeing up the availability of your team members almost certainly improves the resources for other projects and makes their success more likely.
No project manager wants to quit on a project. It’s not in our nature. But it’s a natural part of being a project manager and something every project manager needs to be ready to face.
References
PMI (2013). A Guide to the Project Management Body of Knowledge (PMBOK® Guide – Fifth edition. Newtown Square, PA: Project Management Institute
KPMG (2005) Global IT Management Survey. Retrieved on August 5, 2005 from www.kpmg.com
