Rescuing A Project, Part Three

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.