Author: Stephan Bals

Welcome back to part three of this article. By now customer and Project Rescue Manager have selected each other, the mandate has been signed.

The analysis phase has been ongoing and – by now probably – some people have seriously scratched their heads.

The discovery during an analyze phase is mostly this: some things that have been discovered most of the time show(ed) that very positive willpower was present, hard work has been done and much effort and sweat and tears has been spent getting where the project is now. But somehow, somewhere, things started going wrong a bit, then another bit and it ended up with an avalanche of problems. Some felt or knew, but did not speak out in fear of losing their head. Others did speak out and where silenced, if not sometimes removed literally from the premises. But this is no story about the adventures of Alice in Wonderland. And even in Wonderland, when the queen shouted “off with his(/her) head” it never brought a good solution… This is a story where millions of dollars could be lost for every second that the right corrective actions are not taken. And someone wanted to save the day by digging his or her head in the sand….?

So, now it is time to continue our path to set things (as) right (as possible again). Or maybe not, in case we decide in stage three to kill the project…..
REMEMBER: you may not get all what you originally had in mind when you started the project. REMEMBER also: rescuing a project is about getting still as much as possible of what should be have been delivered, but it will cost you more and you may possibly not reap all the benefits.
You have chosen – in this scenario and for the sake of the flow in this article – that your project should be rescued.

Let us continue along that scenario. We have arrived at stage three: the initial report stage.

3. Initial Report

By now a whole load of million-dollar-questions will have been asked and answers will have been found. Meetings, one-on-one, or one-on-team, meetings with decision makers, meetings with stakeholders, meetings with 3rd party suppliers if involved, meetings, meetings, notes, sub reports per topic will have been written, informally reviewed and discussed. Tons of information and findings will have been assembled and looked in to.

Also, very important, by now the business case will have been revisited. Like I said before: no (valid) business case, no project. I add to that: if the business case has been revisited during the Analyze phase and it is turning out to be no longer valid, be nice to yourself as a customer and kill the project. Unless of course, you have a very good reason not to kill your project even if costs double as much. If so, then document that motivation and make your decision.

You may ask yourself at this point “is it even possible to re-analyze the business case in two to three weeks?”. The question is not strange, especially if you take in to consideration that certain business cases will have taken up to 6 months if not a year to build and get approved.

But it is possible when all work together as expected on their Project Rescue. A process can be followed which was already described in a book by Thiry Michel, PhD., titled “Value Management Practice” (Publish. Project Management Institute, January 1 1997(C), ISBN 978-1880410141).

Mr. Thiry describes this process as a “guerrilla value management analysis” if I remember correctly. During this “guerrilla”-activity a high-pressure cooker environment is formed during which value of activities, moments, environment and so on in the business case are analyzed, or in this case: re-analyzed. All those, from high to low, that needed to be involved where involved.

I mean to say that whilst the Project Rescue Manager has setup his first team to perform interviews and fact-finding, a second team could and should be occupied with revisiting the business case.

The first can feed in to the second set of activities and vice versa, in the end leading to a report and advice on required trade-offs or not, leading to advice if the project should continue or not and if so, to deliver what and why, based upon a revisited business case.

The Project Rescue Manager delivers this Initial Report or Advice Report as it is also sometimes called, to you as the customer at the end of the initial four weeks of work (if no need exists for more time). He/she sends you – his customer – this report whilst at the same time inviting you (the Project Rescue Board members and key stakeholders and members of the research team(s)) to an Initial Report Review Meeting. The meeting should be held within 3 days of you receiving the report. Why? Because time is money and the clock does not stop ticking.

Also, most of the time when you as the customer has received this report you will want time to read it yourself and think about the content and any advice given, and possible devise your own advice and options to present during the meeting, if not send some quick questions on certain items in the report before the meeting. As to such questions: do not expect them to be answered – unless necessary for your view – before the meeting. It could be best for questions to be looked at during the meeting with the rest of the people assembled.

What should be the contents of the initial report? I prefer a short list of items, simply because the discussions during Initial Report meetings can already be very heavily loaded, especially emotionally. Which is also why I ask of all of you involved in such a meeting: stick to business, allow some room for emotion but do not allow emotion to lead you all the way.

The shortlist for discussion items during the meeting or meeting agenda could look something like this:

• Lessons discovered; a short history of the project up to now, a list of maximum 10 hot items that need (urgent) corrective measures, the Project Rescue Manager should deliver maximum three suggestions per item and an indication as to the preferred measure to be implemented and justification for such;
• Business case review; don’t be nice, but do be honest; politics have created more undesirable situations than honesty has; this topic should give a view on budget, spend per stage vs expected/predicted, burn rates, milestones achieved (on date, delayed, reasons/owner….), deliverables met and capacities achieved and working and which have not been achieved, benefits per stage and achieved or not et cetera
• suggestions to go forward, meaning what is still deemed realistic, what deliverables, what benefits per deliverable and capacity, when that benefit is now expected, how high the benefits will be, an overall view of what should be delivered that ties in to the expected outcomes
• risk analysis, owners, proposed countermeasures, costs involved, when expected, where expected et cetera
• organizational change impact, where, owner
• a new plan, based upon the advice of the Project Rescue Manager and his team, depicting the way forward, containing a list of things to do and deliverables to be produced, resources required (human and other), financial plan, renewed benefits plan, et cetera.

The list of items for the Initial Report meeting should not be too long. The meeting itself should not last too long, but it could take up to a week of meetings to crunch all the details. I’ve seen it happen.

All those invited, especially decision makers, should have freed their calendars and make sure they are present.

As to the mentioned draft plan your Project Rescue Manager (and his team) will bring to the table, please note that this plan will still probably have a certain degree of high-level-ness, since we must never forget that a plan is just what it is: a snapshot in time. Further adjustments may be required, as the future unfolds and decisions are made during the mentioned meeting.

But whatever the plan is that gets accepted in the end, we need to remain agile and adaptable to new challenges that come our way, and keep on working as a team on all levels!

4. Evaluate, Adjust, Agree

Your Project Rescue Manager has sent the initial report. You as the customer (project director/owner and colleagues on the newly appointed Project Board) have had your three days to look in to the initial report you received. You have had time to look at it from your different responsibilities and perspectives. You also had time to formulate your questions.

---

---

IMPORTANT NOTICE: one thing I may have forgotten earlier on, is very important during any phase during a project recsuce: that is do NOT play the blame-game. Projects are started for many reasons. Some of those reasons maybe subjective (personal interest, wanting to show off how good someone is, wanting to achieve a higher position, suppliers may want to make more money, customers may want to get work done for as cheap as possible). Other reasons may be objective: simply wanting to get a new product in the market because it is useful to all kinds of people, getting more people to read and write by education programs, useful research to reduce the cost of production and delivery of energy, reducing error and costs in a process. Some products may be a mix of both, but still carry good and/or logical purpose and goal(s). But if something goes wrong in a project there can be a thousand and one good reasons for that very project to have gone wrong. Whatever happens, whatever mistakes were made, we should not be dishing out blame. We should learn from what went wrong and we should try to improve on that. Lessons learned are not called for nothing lessons learned.
It is how we humans improve ourselves: by learning, constantly learning. Blaming does not help. It does not make team members better team members, it does not make bad managers better managers. We need to learn what improvement points are, provide training, coaching, guidance. The thing is: if the project failed, all members in the team failed. So, we all need to learn.

I have witnessed those meetings about bad projects as organizer, moderator, coach, project manager and program manager. It simply does not help you progress one inch. If necessary, it can be good to allow for a minute of sarcasm, irony or such. It will never help however if meetings turn in to mud throwing. People leave the table, then the room and the project strands completely …. because no new positive energy can be built and maintained. So, do not blame, but evolve. Do not get angry, get positive. And rebuild. And remember: even rebuilding can mean stopping the project completely, if that is logical. The only people that should be removed from a project are those that caused the problems and are not willing to learn what they can do better. (I said this regularly when during several project rescues).

Having said that, the meeting calendar has been determined and now comes the time to crunch. There is a reviewed and adjusted if not possibly a renewed draft business case, suggestions as to draft scope changes, new draft financials, renewed draft RAID-log, new draft project assumptions, a new draft list of deliverables and capacities these will support, a new draft project plan with stage definitions and milestones, new draft communication plan(s), resource reviews for critical positions and/or complete resource plans and so on or possibly a mix of “old with new”. Whatever the mix is, decisions will need to be made.

The main thing is to decide on the ((re-)newed) business case, deliverables, capacities, benefits and plans. If there is a deliverable that needs to be built that will deliver a certain capacity (e.g. “faster handling of travel bookings by employee, booking department), that will need to be described in the business case.

The business case – in short some more – needs to tell you what is to be delivered, by whom, by when, at what cost and what will be the benefit and over which time that benefit will be achieved in support of what outcome(s). THIS is a business case. Anything else, is just a waste of time and paper.

Any question in today’s project management is and should remain to be driven – in my opinion – by one simple thing: what capacities and benefits will we achieve to support what strategic desired outcomes?

There are some funny things though about business cases…..

Many business cases are seldom of the solid type. Let me tell you another short story. I mean, years back I had a manager, on an internal project, who when asked “how did you build your business case and based upon what assumptions did you arrive at your conclusions and project proposal?” stuck his thumb in his mouth, sucked on it a bit, pulled it out and said “this is how, now do your job”.

I thought to myself “really?”. I declined this gentleman’s project, saving the company at least 1 million $ by declining to accept and execute this project, since having reviewed his business case in some detail I had become convinced it was unachievable.

All I mean to say: business case driven project management (and program management for that matter) is a rarity. And it should not be. The business case should the logical center of focus and drive and passion for the project. The business case is THE leading document. It is however one of the main failure points in project management and program management that is made once, then put away in a drawer somewhere.

Business Cases are usually not reviewed on a regular basis. I have personally seen many customer environments where project management tools are present if not used in abundance. But in most cases I have also noted to my surprise that headers like “Benefits” or “Value estimate” in such tools are almost never used, not kept up to date. Why? Because no one regularly reviews and updates the business case versus the real-life situation.

The business case seems like a “fire-and-forget” kind of tool? Maybe it is more than time to correct on this.

But let us continue. You have discussed with your Project Rescue Manager and the Project Rescue Board members, possibly involving also key decision makers/influencers and change advocates from within the customer organization.

What needs to be done has been analyzed from mountains of information. You have discussed and agreed that stuff needs changing on your project. You need to change your scope to include new features for your deliverables or deliverables need to be scrapped. Your supplier contracts and the way you work with your supplier(s) and quality assurance processes have been optimized. It is now clear how (remaining) delivered capacities will bring more or less benefits via the project rescue efforts. Higher or lower levels of risk may need to be accepted and risk management plans and budgetary risk reserves may need to be changed.

Decision making on what needs to be done, changed, discontinued or otherwise should not be much of a problem, unless anyone has come to the meeting unprepared.

So make your project scope adjustments or whatever kind of adjustments needed. Now.

Time is a wasting and money is a burning.

Maybe a test team consisting of juniors and one medior tester needs to be replaced by a team all seniors, or a product needs to be scrapped because it is no longer has any right of existence.

Decide. Now.

Then, after having decided on what will be adjusted or what will be killed, you give your Project Rescue Manager his/her walking orders and let them get to rework on final versions of all plans, budget, deliverables list, test approach and plans and whatever else needs to be adjusted so that you have the final plan.

One last short review during one last review meeting on final plans and documents, one round of adjustments, then you GO .

We continue in part 4 of this article.

For those of you reading this part two of my article on Project Rescue Management: welcome back. For the new readers amongst you: welcome.

After having read part one you may have asked yourself “why would anyone need a project rescue process or an experienced Project Rescue Manager?”.

The question is logical but the following facts will tell you more about the need for such a process and such a type of professionals:

• When I did a lookup for the words “project problems” on Google, I got a screen showing there are (at least) +23 700 000 pages found; the sheer amount of discussion on problems around project management indicates that some heavy problems exist and a structured approach to solving such problems is needed;
• When we look at the financial impact on regional economies (e.g. the USA or the EU-region) the estimated financial size of problems around (IT-related) projects gone bad is simply staggering

“One estimate of IT failure rates is between 5% and 15%, which represents a loss of $50 billion to $150 billion per year in the United States. Another study estimated that IT project failures cost the European Union €142 billion in 2004.”
(Source: Gallup (2012)

The estimate given above is based on research from 2004 as you probably read yourself if you looked up the article I am quoting from. And those figures are only the estimated financials. They do not include negative psychological, public/commercial impacts or costs of other types of impacts and their associated monetary value.

This short introduction alone shows you why Project Rescue Management is a thing to be thought about.

It could also be worth thinking about from a commercial aspect. A consultancy organization could for example define a new and very disruptive business line: making projects gone bad right again….

If THAT is not disruptive, I don’t know what else is.

My position is: it needs to be done. How? By orienting ourselves much more on the benefits of what needs to be done or what we should not do and why, a.k.a. Business Case Development and Business Case Management. And making sure that selected projects are – based on their business case – ordered and aligned to company strategy. Strategic alignment to organizational goals alone gives projects a better chance of success (by 54% at least as some research by the PMI stated some time back).

But we need a new type of project managers (and managers) with new skillsets to get this cultural shift started towards Business Case Driven Project and Program Management done (“BCDP^2M”, copyright S. Bals, 2017). I already mentioned some personality traits and characteristics such project managers should have. They will also need new skillsets. Which ones? I take the liberty to quote again from mr. Kerzner’s book “Project Management Metrics, KPI’s and Dashboards” (Publish. John Wiley & Sons, 2013(C), ISBN 978-1-118-52466-4, page 3):

• Business Analyst Skills or Business Management (*)
• Program Management (*)
• Business Processes (*)
• Managing Complex Projects (*)
• Six Sigma
• Risk Management (*)

(*: I actually received some very negative comments about my additional areas of knowledge and experience ; in a job interview some time back I got accused of being “more of a business analyst or business consultant than a project or program manager; but as it turns out, when you look at the shortlist above, those skills are exactly some of the plus-knowledge-packages a good PM or PgM should have nowadays….)

Some other trainings that could be beneficial for PM’s or PgM’s are also described by mr. Kerzner on the same page:

• Establishing metrics and KPI’s
• Dashboard design
• How to perform feasibility studies and cost-benefits analysis
• Business analysis
• Business case development
• How to validate and revalidate project assumptions
• Establishing project governance
• Managing multiple stakeholders
• How to develop coping skills and stress management skills

Note the emphasis on business analysis, process analysis, cost-benefits analysis, business analysis, business case development. I add here that business case management should also be included to the list.

In short: the emphasis lies on the business, it’s processes and a business case for the project (or program) aligned to the strategy of the organization.

That’s also why in project rescue management the business case remains a leading document. THE leading document if you ask me.

Let’s talk some more on how to get on with a project rescue. On the following pages, you will find he first two steps in a six-step process (or nine steps if you prefer to really go step by step, sometimes that’s useful).

0. Initiate

Before we continue I would like to give you a bit of a view of the standard Project Rescue Plan I have grown fond of using.

(Copyright Stephan Bals, not to be used, stored in any form, distributed in any form without authorization of the author)

---

---

I use this slide to show this to my potential customer/employer when discussing Project Rescue Management and later during the definition of Project Rescue Mandate. Consider it like a place holder, based upon which you can explain to your potential customer/employer what the different stages are and describe at high level what your customer/employer will get per stage. It’s always handy to show you know what you are talking about.

As you can see in the slide, phase 0 is the Initiation Phase.

During this phase, no mandate for work has been signed yet, expectations have not been made 100% clear. That comes after the Mandate Stage. This is like a “meet and greet”-stage for candidates for the Project Rescue Manager role. It’s is just you as the shortlisted candidate Project Rescue Manager and (a) representative(s) from the company wanting to hire your services having a meeting and discussing on a high level what the problem is during the first meeting. Don’t drill down too deep on the problem(s) yet, you will be doing a lot more of that when you as Project Rescue Manager have obtained your signed Mandate.¹

You as the potential Project Rescue Manager and the potential customer are getting to know each other, discuss your cv, discuss work you have done before and possibly you will be asked to share a couple of references your potential customer can check.

A first interview like this – in recent times – most of the time starts via phone-chat with a recruiter. I say “don’t”. If you can, you – as the owner of the troubled project (or program) -should at least meet via Skype of video conferencing but preferably face to face right from the start.

When It comes to meeting that very important person who can possibly help you get your project going again, you as the party looking for that Project Rescue Manager, have a bit of a budget ready for the interview sessions. Like I said, you will preferably want to meet your candidate(s) face to face and they will probably want to see payment for travel costs and possibly one night of hotel costs. And you do not want to look avaricious. Do not be penny wise, pound foolish. Be a good host when inviting your candidates. A well served table builds the biggest smiles and shows appreciation to your guests. First meetings can be short. If you as a potential customer don’t get the right gut feeling about your potential Project Rescue Manager during this short (max. 30mins) talk, thank him/her for her time. If the candidate at the table catches your attention, then talk some more, possibly take them out for a bit of dinner. You as customer/problem owner have little time, but you need to take some time to get to know someone asap.

If you do select some candidates, second talks should be held in more detail on the problems requiring a Project Rescue. Also, the second (and third) round of talks can be held on the same day and with different representatives from your organization. Again, for second and/or third talks, have a bit of a budget ready for all the reasons I already mentioned earlier.

1. Mandate

As part of the final selection process, during interviews you as customer/employer will automatically drill down to one candidate. To get there, like I suggested you will have discussed with the two remaining candidates of your selection process. During your last meet-up, you also define and preferably finalize the mandate for your Project Rescue Manager.

Defining this key artefact together will help you in making clear on how you will work together, what levels of autonomy and what obligations the remaining Project Rescue Manager will have. Your Project Rescue Manager should be able to help you shape his/her mandate coming from experience on this kind of work.

The candidate that gives you the feeling – because that is in the end what any decision is based upon – he/she is working together with you on a well-defined and usable Project Rescue Mandate is the one you will select. Logically.

As a customer, be prepared to talk about things disgustingly honest. Do not act shocked, do not fake false pride. You and your selection board cannot afford it and your Project Rescue Manager cannot afford it. Every day not used well is after all spent burning money for no purpose.

How honest can you expect? Let me give an example of something that happened with one of my clients. I remember one occasion a long time ago, having arrived at the final selection moment, I looked my client in the eye and clearly stated that I wanted the following lines added to the Rescue Mandate: “if any party involved at the decision-making level from your side lies or deliberately gives wrong facts, figures or any other kind of wrong information or bad cooperation I will walk away without having any further contractual or other legally binding obligations to you as my client and this will be the [sum of money] you will pay me without delay if the company is at the cause of my departure coming from not following this agreement”. The gentleman that sat across the table from me blinked, but after a couple of seconds simply said “understood, agreed and so noted in the mandate” and wrote it down.

This gentleman became a friend of mine and still is a good friend of mine now many years later. Was I brutal? Was I – in the eyes of certain readers – possible a bit rude? I do not think so. I wanted to see and feel how this gentleman and the board behind him would react if I gave direct, blunt opinion, feedback, statements or questions.

This gentleman and his board reacted correctly. By giving an honest reply. Would I have stayed if he had said “not acceptable” and he had motivated his reply in an honest way?

Yes. Because my aim was testing the honesty-level. I just wanted to point out (again): being honest in Project Rescue Management will have big paybacks!

During the definition of the Project Rescue Mandate also discuss other items that may be of Interest to your Project Rescue Manager. For example: access to personnel files of team members, access to contracts with suppliers and/or other external 3rd parties and so on. Decide and register in the mandate on these and any other valuable topic that comes to mind what your Project Rescue Manager can/needs/will have access to. Think for example, of the project business case, project status reports, risk reports, board meeting memo’s, the last version of the signed project SOW, number of changes, project assumptions, project quality reviews, test information or any other documents that apply.

Your Project Rescue Manager should be able to give you a list.

Also, as Project Rescue Manager you should have the right to interview anyone involved  in the project, external or internal, high or low, without this having any consequence towards individuals being interviewed.

Also, decide on how many team members your Project Rescue Manager will want to add.

And do not forget to talk on the current status of the project! (frozen, partially frozen, continuing? And why?)

2. Analyze

The customer has selected the Project Rescue Manager and a signed Mandate is now on the table. We move on to stage two. This stage – to my modest opinion – falls in to three subparts.

A. Meet, greet and learn

We can make this bit as long and as difficult as we want, but beauty lies in simplicity and love is fed by honesty and loyalty. So, let us keep things short and sweet here.

Your (s)elected candidate will right from day one need to be announced, introduced to a large number of people and shown around. As to the meeting and greeting part, it is nothing less than professionalism if you from the customer-side have prepared a list of people (with a picture if possible) for your Project Rescue Manager to meet and greet. This could have been prepared during the Project Rescue Manager Selection and Mandate Process. Make someone available to support him/her during the first two weeks, if but a couple of hours a day. I would even go so far as to advise you as the higher-up who hired the Project Rescue Manager that you show him around to key people yourself. It is a good opportunity for you as higher-up to have some face-time with the work floor.

It will also be of interest to have the list of project meetings, locations, persons attending, time & days of week already available including access to project documentation from start to current date, teams, team compositions, phone numbers, email addresses, availability and location and contact information of decision makers, stakeholders, customers, 3rd party contacts, team members, PM’s, line managers, functional managers, et cetera. To name but a few information topics that might come in handy right from the start.

Elements such as having a desk or office space and all the usual stuff as a cell phone and a laptop should also have been taken care of right from the start of course. I always like to have a meeting room available for my use on the job in which at least 8 to 10 people can be present, work, or even have a chat amongst each other when needed and which has working video conferencing and phone in place. Bad Managers would call it a War Room. I hate war rooms. The very word brings an image of negative pressures and bad energies. I prefer to call it a Safe Room. What is said in confidence in this room stays in this room. People need to feel safe in this room.

But back to business. Your Project Rescue Manager will need such a room to be able to read, meet and talk with people, if not but simply think.

B. Analyze

You have decided on the information to be available to the Project Rescue Manager. Now make that information available.

I for example want to understand the following:

• what is the customer company culture and what is/are the cultures in 3rd parties involved?
• Was the plan and number of deliverables, PBS, WBS, capacities, benefits unrealistic/overestimated, meaning: did the project have to deliver too much in too short an amount of time? Why?
• Was this project of personal or political importance to someone or did the whole organization stand to benefit from this project?
• If any external parties are involved, how is the relation between customer and 3rd party/parties? and why? Duration of that relation?
• from a business case perspective, what is purpose of the project, what departments or division(s) will it influence, what products, capacities, benefits in support of what capacities, products, services will it deliver to meet desired strategic outcomes, and is the business case still valid, do we need to adjust deliverables and outcomes, or do we simply need to scrap it?
• what performance indicators have been selected, used for this project and why?
• was/is benefits management in place and does it play an active part in the project?
• how has the project been doing up to now?
• was there a process for change control and a CAB (Change Advisory Board)?
• was the CAB also responsible for OCM (Organizational Change Management) activities that where related to the project?
• What was the level of autonomy of the CAB?
• was there a Customer Involvement (sub-)plan of what activities customer representatives will be involved with, when, how many, locations, levels and number of supports from the project team (or a separate sub-project team), trainings, purpose, group descriptions and roles attending, et cetera? If no, why? If yes, where is this (sub-)plan? Who owns it and drives it (from supplier and/or internal to the customer)?
• Have we received all weekly, monthly. half year reports and/or deep dive reports?
• what problems have arisen on the project on the whole and what actions have taken to solve these problems up to now? (to be asked at different levels to capture different views)
• having a good look at RAID-logs, who owns what, what was done, when was it done, what where the effects of what was done?
• was the Project Board involved, supporting or just bullying (honesty ….. but it does happen)
• how many change requests came, how many where approved/denied/why, scope/time/cost?, how many times was the project base line and project budget adjusted?
• how many team member changes happened, how many Project Board member changes happened, how many times was the project manager changed, and why?
• do stakeholders still believe and support the project? If yes, why? If not, why?
• how is the project team structure organized? Partially onsite, some nearshore, some offshore? How many team changes (members, team size, et cetera) happened per location? And why?
• Are there any corporate directives on cost reductions on our side or third party side that influenced the project? And why did such directives come in to view?
• In what phase is the project currently? Is anything being worked on or is it in “full freeze”? And why?
• What are the performance indicators used?, who selected them and why?
• what was the workload per team member? And per team? How much overtime did team members put in and the team overall?
• How were team members treated? (internal and external team members alike)
• How regular was overwork for (certain) team members?
• How are team members holding up? (happy, unhappy? why?)
• How where business/customer project team members treated? Why?
• Has the difference in “people-management-approach” per type of team led to additional annoyances? Why?
• How is risk management set up?
• is there a PMO involved or not? what is the role of the PMO and its level of support and influence?
• what is the project complexity and why?
• what is the level of commercial/political/strategic need for this project in the organization and why? (it’s a good question to ask certain decision makers and stakeholders besides getting answers to this one from revisiting the business case)
• What was the level of autonomy of the Project Manager(s)? (or Program Manager(s))
• what type of project management methodology(-ies) was used? Why?
• How did people (customer, supplier, others) react to working within this(/these) type(/s) of project management methodology?
• Would another type of project management methodology (or (mix of) methodologies) have been better suited for this project and why?
• How where Project (or Program) Manager(s) treated? (as equals, as “simply do what you are told”, as valued colleagues who were also consulted on problems, issues, risks, improvements on how to do things better?)
• …….

You could decide to split up these questions in certain categories. I do. For sure you will not ask these questions to everyone. For example: a Project Board member may not be asked all the questions a project team member will be asked. I divide my questions in to categories, but I take the liberty of not showing you an example of such here, since you may have your own lists.

I will tell you my favored way of getting the answers to most of these questions. In some cases, it’s just getting hold of the numbers and/or documents. But on people matters, it’s always best to do a representative number of one on one interviews. The Safe Room where the Project Rescue Manager works is probably the best place. People can talk in safety, away from prying eyes and ears or interruptions from others.

As to the above displayed list of questions, and some of them might sound double, these are but a handful of questions I (and my team members, when I appoint more people depending on the sizing of the work at hand) need answers to. I actually have quite a list that I like to go through. This is information. Based upon information I can build a picture of the project as it came to be, started, had its lifecycle up to this moment where I appeared and if the project still has a valid business case after having been reanalyzed itself, what possible trade-offs that need to be negotiated and what chances such possible trade-offs have of being accepted or not.

This is a lot of work that needs to be done in a short time. It is especially a lot of work for one person. Which again is why your Project Rescue Manager will need all the support he/she asks for (including the budget and the autonomy to install an assisting team to the Project Rescue Manager when called for), especially the cooperation coming from you as the customer.

C. The First Draft Rescue Plan

During this Second phase (that should last no longer than one to a maximum of four weeks (depending on the size and complexity of the project it could take twice as long), he/she (and his/her selected team) will take in all this information made available per the mandate (and maybe more) and your Project Rescue Manager should also build and present a Draft Rescue Approach Plan that will last up to the GO-stage. At least after two weeks it should be clear what parts of the project or even the project on the whole should be frozen, continued, partially continued for now.

But as to the first draft Rescue Approach Plan, like I said before, I usually use my time-line slide and build on that. But the Rescue Approach Plan needs to be built in more detail. In four weeks’ time at the most (again depending on the size and complexity of the project), it should at least have a clear definition of the Analyze, Initial Report, Evaluate/Adjust/Agree and Go stages, things required per stage (types of information and/or actions) and deliverables (from the Project Rescue Manager, project team, decision makers, customers, suppliers or other teams). People that need to deliver part(s) of the Rescue Project Plan should be held to their obligation without delay or excuse. The Project Rescue Manager will also have drafts of the Rescue RAID Log, Communications Plan, Team groupings and activities, and a draft financial plan up to the Go-Stage.

One should also have revisited the Business Case for the project during the first two weeks and a report on the status of the Business case should coincide with the delivery of the first Project Rescue Report. More about this later.

It is also imperative this stage to formally(!) decide on a Project Rescue Board. Your Project Rescue Manager may not have all the information yet to choose the best formation, so some blanks are logical. But during working between Project Rescue Manager and customer, names & roles & responsibilities must become visible. Fill in the blanks during the Analyze stage. Your Project Board may or may not contain members of the original project board. Remember: you are in a rescue situation. Other influencers and/or decision makers might be beneficial to the project being rescued. Why? Because simply speaking, there are gatherers and there are hunters and there are protectors.… I’m sure you understand the difference.

But you will need a Project Rescue Board with the right people on board. Project Rescue Management is not something you do alone. It is also never about doing a bit more of the same thing with the same people in the same way that got your project in the mess it is in.
You will need people with power in the right places to help you out. It is just simply so that at the same time when considering this, you also need to consider that the people on the “old” project board might not be the right people to be involved in the rescue.

For now we have arrived at the end of part two.

I will show you more steps in the process in part three of this article, coming soon.

As before, if you have remarks, suggestions, or need help on a project rescue, you can reach me at [email protected].

1 Please remember for later: no Mandate, no work! If the customer says they have selected you, make them write an email to you confirming that on the spot, containing price, a timeline and a “breach of contract” set of rules. If you are experienced in this game, you can bring your standard terms to the table for quicker discussion

“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.