Rescuing A Project, Part One

“How do you go about saving a project that has gone bad?”. I get this question a couple of times a year. And yes, it is true.

Over the years I have been active in the areas of management, business improvement/business change, project management and program management, and I have indeed been called in to take over on projects (and programs) that had gone bad. And I have built a bit of reputation for turning bad projects in to “successful projects” if not at least “projects that went from bad to having delivered (most of the) benefits”. It is also true that over the years I have devised ideas on how to start and push towards a project and program recovery.

Since the question has been put to me so many times over the years I decided to write an article about it and post it here to give some insight in to the world of Rescue Project Management or at least to give a view on how Project Rescue could be approached from a real-life-practice-experience .

The way I have written this article is so that I have tried to give you an angle of view on the different parties involved. I hope it works out for you as the reader.

Before you start reading this article, I need to tell you up front: I am a very strong believer that there is no project without a sound business case. And that goes especially for a program. Before any project (or program) is started, there should be a clear business case which relates in a clear way to the strategy of your company or organization. If you don’t have a business case, my advice is: start nothing. Having a business case will – at the very least – help you and all your stakeholders and decision makers do a lot of work without a lot of politics. And PLEASE: make it a business case that sticks. If it does not have figures but a lot of loose statements, throw it out and (again) kill the project.

I once had a manager who, when asked how he his business case had been built, looked me in the eye, smiled and walked away laughing. In short: do not go to work without a business case.

Another thing I firmly believe in is this: yes, your Project Rescue Manager should have extensive experience in project management. But this is not the only thing he/she needs to have. He or she needs to on the one side “fit in with your organization” for say 50% but at the same time needs to stand out or “be a bit different” from your kind of employees and culture. This is because the Project Rescue Manager that will come do his/her thing for you will need to fit in, understand your business on a high level, but should not adhere to ways of thinking and doing and behaving as you expect from your “standard employees”.

He/She is there to generate movement and result(s). And generation of movement, or call it change, is not done by adding more of the same…
So do not just draw up a list of competencies and skills he/she should possess like you do with lots of standard job descriptions and profiles. Project Rescue Management is not a standard job. It never will be however much people want to make it sound or look easy for whatever reasons or motives.

Project Rescue Management: Think Before You Act

To start with there are several considerations that must be taken in to account when initiating a Project Rescue. Starting from the point of view that you have built a business case for your project but it still has gone wrong, then think about the following:

1. Not every project is recoverable, nor should we want to recover certain projects that went wrong; simply continuing with doing what has already gone wrong just so someone can say “we did that one” and claim a + on their annual appraisal can cost too much and may possibly deliver fewer or no benefits at all to all others involved;
2. On the other hand, certain projects are a “must do”; for example, if you are an insurance company and you need to do a project to meet regulatory/legal obligations then this is a “must do”-project; the risk of not doing that project could mean – worst case – having to close a business line if not – disastrous case – having to close your company doors;
3. When you do decide to start a Project Rescue, stakeholders and especially decision
   makers need to understand that in Project Rescue the aim is no longer to “finish on time”, the aim is to finish the project within a reasonable (renewed) time line whilst at the same time a readjusted but reasonable/acceptable level of benefits can still be achieved for all interested parties such as stakeholders, business users, department heads and other parties expecting to receive a benefit; You will not get everything you wanted anymore; decide what is still acceptable and go for that or kill the project and accept your losses.

Next to these key points you need to understand, again before you start your Project Rescue, there are two golden rules. These golden rules can never be forgotten and should even be registered in the mandate you will write down and agree upon with your Project Rescue Manager:

1. Honesty and openness is the number 1 golden rule; Project Rescue Managers do not have the easiest of jobs; by the time they come in faith in the project will most of the time already have sunk to levels below any workable level and communications will have deteriorated sometimes to the level of non-existence; trust will need to be rebuilt on all levels due to annoyed teams (angry team members may even have left the proverbial building) and frustrated managers and customers; to achieve any possible chance for success honesty is the key; if you want your project to continue failing then by all means keep your hidden agenda’s hidden, but do not expect your Project Rescue Manager to be successful in any way if this person cannot be fully and directly honest with you nor if you are not willing to be fully and directly honest with him/her; In any case: do not fire your Project Rescue Manager when he/she gets a lot of heat put on him/her shortly after starting his/her job; if this happens consider a) all the trouble you have gone through to find the right person and b)who (as in “individual” or “group of individuals”) is putting all this heat on the Project Rescue Manager and why is this happening?, the answers might be interesting to look in to;
2. Choose your Project Rescue Manager wisely; choosing a Project Manager who is already an employee within your company may be a good option since this person knows your company, its culture, the people, the processes, the internal politics; on the other hand, if the selected Project Manager has no success in the end it will almost automatically mean his career-death at your organization (something which will no doubt come to her/his mind on being invited to take the position of Project Rescue Manager); on the other hand again when you seek an external Project Rescue Manager this person may not know your Company, its culture, its politics, et cetera; The first type of candidate may fear for his career the second may not know enough about your company;
   You probably see that selecting your Project Rescue Manager can easily turn in to a political debate – which the most influential (group of) stakeholder(s) or decision maker(s) will probably win, even when the selected Project Rescue Manager is then not necessarily the best person for the job – and since time is ticking and money is burning away, political debates need to be kept to a minimum. Selection of your Project Rescue Manager needs to be as swift as possible when and if you decide on starting a Rescue Mission.
   One can move aside this discussion, make the discussion more objective if we take a number of personality traits and skills of the Project Rescue Manager in mind. Mr. H. Kerzner, Ph.D., is a worldwide authority who gives us a clear view on what we need to feel and have in a Rescue Project Manager. I take the liberty to quote from his book “Project Management Metrics, KPI’s and Dashboards” (Publish. John Wiley & Sons, 2013(C), ISBN 978-1-118-52466-4, page and applaud Mr. Kerzner for pointing out these items so clearly:

• Strong political courage and political savvy
• A willingness to be totally honest when attacking and reporting the critical issues
• Tenacity to succeed even if it requires a change in resources
• Understanding that effective recovery is based upon information, not emotions
• Ability to deal with stress, personally and with the team

From my side I would like to add that there are of course additional traits and skills one needs in the Project Rescue Manager. Some of these are for example:

• People management skills
• extremely direct communication skills at all levels, even up to the board room level
• the ability to assist decision makers and stakeholders on deciding “what do we really want at the end”, meaning making people decide on “must have” and not on “nice to see a little red star blinking at the bottom of the screen” when there is no need for that “nice to have” or “must have for a good reason but later on the roadmap will do”; at this point don’t necessarily think “minimum viable product” since you might then have a product that does not do what is needed in the end and for which no one will want to pay; ask simply “what do we need done now! ”
• analytical skills of project situation and elements
• business case building and managing/analysis skills
• strong and longtime project management skills
• knowledge and especially experience in working with one or more project management methodologies

You as the audience to this article will no doubt have your own list from which items can be added. Please do. But keep the list effective. Too long a list is likely to achieve paralysis by analysis.

But it is not only the Project Rescue Manager that needs certain traits and skills. The same traits and skills should be available in decision makers and key stakeholders to the project. Plan, do, check and act as likeminded people if you want to make your project rescue a success. Quid pro quo!

Once you have shortlisted your possible candidates, you and your selection board will preferably have a maximum of two candidates left. And this is where the real work starts.

END OF PART ONE

In part two of this article I will start explaining to you the steps in a project rescue process.

Thank you for your time and attention. If you have any comments or questions, don’t hesitate to reach out to me at [email protected]

Copyright Notice
The content of this article and the ideas, suggestions, process descriptions are the intellectual property of the author. Nothing in this article may be used, stored, printed, distributed, changed in any way without the written consent of the author. (C 2017)
Special Copyright Notice
Where applicable, information on other authors and their intellectual property have been added to the article. We inform you again that re-use of their materials and intellectual property is prohibited without their consent.