Rescuing A Project, Part Two

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