Author: Neville Turbit

Read Part One... Read Part Two…

Overview

This is the third in a three part series about rescuing a project in crisis. Most career project managers will be faced with the task at some point in their career. These articles will hopefully give you a context and some guidance to move into project rescue mode.

The first part talked about the personality of the person undertaking the rescue. The second provided a list of topics you may need to look at as part of working out where you are. In this third and final part of rescuing a project in crisis we look at what you actually need to do.

Who is in Charge?

The first thing you need to do is to identify who is in charge of the project. We are not looking for the Project Manager, but rather the Sponsor.

• The person who signs the cheques.
• The person who can stop the project if necessary.

I spoke with a consultant once who was given the job of analysing a major political party and making recommendations as to how it could be more effectively structured. A number of financial supporters were concerned that the organisational structure was causing the party to loose popularity. He told the financial supporters that he would only take on the job if it could be agreed who the top person was in the party. He was not talking about a person with a title to reflect his position, but about who really held the reins.

There were a number of contenders. The Prime Minister of the time was one. The Party Boss was another. There were one or two very influential financial supporters who could have been considered. As with most parties there were some long term “numbers men” who had enormous influence in the way the party ran. They knew exactly where the bodies were buried and the intimate details of how the body had become deceased.

What he was looking for was a consensus as to who was the main mover and shaker. He flew around the country meeting with party officials including all of the above and tried to get agreement. He was told things “on the record” and “off the record”. After two years he had not even come close to a consensus. He eventually declined the assignment. As he said:

“If we can’t agree who is running the show, how can we even imagine we will be able to reorganise it?”

You need to determine in the project, who pulls the strings – even if a few of them are frayed. The usual tactic is to point to a committee. My response is to ask who is responsible for the committee. Who is the chairman? Who ratifies decisions? Who can overturn committee majority decisions? You need to find one person.

Project Scope

The next step is to identify the scope. This is typically two parts:

1. What was the scope when the project started
2. What is the current view of the scope

Very often this is at the core of the problems. In fact it is not unusual to have violent disagreement about what constitutes scope. Some of our other white papers focus on scope so we will not go into detail as to how scope should be defined. If there are different views of the scope, list them all down and identify the differences.

Resolving the Scope

If there are unresolved issues relating to scope, now is the time to resolve them. It might be through negotiation with key stakeholders or it might be simply asking for a decision from the person responsible for the project. Unless you can determine exactly what it is you are trying to deliver from the project, any further analysis is fruitless.

I always try to set the expectation that this is a “working scope”. In other words, it is not the finally agreed scope for the project, but a current estimate of what the project is going to produce. The scope may well change as other factors are taken into account. For example the effort to deliver the full scope may be more than the organisation is prepared to make. The scope may need to be trimmed. The project may be broken into a couple of sub-projects. Always explain that in order to move forward, an assumption needs to be made about the scope. This assumption will be validated or modified as the investigation and proposal to proceed evolve.

Expectations and Reality

At the same time you can start listing what people expect, and what is reality. The purpose is to identify perceptions and differences between people within the project’s sphere of influence.

Here are some examples.

The purpose of creating this list is to bring together all the expectations that are not being met, and have created the “perception” that the project is in crisis. Perhaps the project is not in crisis. If expectations are better managed, people may be comfortable with the direction and outcome.

Issue Resolution

There is a temptation to resolve problems as they arise. I suggest this is a slippery slope that leads to quicksand. Even rescues can fail if they become bogged down. Identify the issues but do not waste time trying to solve them. The blindingly obvious solution is often simplistic and will never work. Once you start to implement the obvious solution, you can easily get bogged down in the technical detail below the surface.

On one rescue mission, it was obvious from very early that the biggest problem was about 15 to 20 major decisions that needed to be taken. Many parts of the project were stalled awaiting the decisions. Most were quite complex problems or situations however a few were unresolved through pure lack of prioritisation. People were devoting all their time to solving the big problems and not taking time to solve the small ones. There was a temptation to take time out of the review to solve the small issues. Fortunately I resisted the temptation and quickly finished the review.

The recommendation was to stop the project for a week or two and hold a series of facilitated workshops with key decision makers to resolve the identified issues. No time frame would be set on the workshops other than it was like a jury. Nobody got out until a decision was made. Of course it relied heavily on getting senior management full time involvement for a period of several days. That brought some urgency to the resolution.

Some decisions took less than an hour but one took two days. Nobody was let out of the meeting because we had instructions from the CEO that whatever it takes, you devote yourselves 100% to the resolution. ERP system implementations do that to a company. The point is however, that you should not try and resolve the issue on the first pass. Do the fact-finding as quickly as possible then look for solutions. Remember people are waiting for you to plot a course. The longer they have to wait, the less likely they are to be responsive to your recommendation.

In terms of looking for issues, you should use the checklist in part two of this three part white paper as a guide to the project management aspects. The business or technical aspects will vary for each project. For example, if you are renovating an office building, there may be issues relating to building materials, access to the building, architectural drawings, council approvals etc. If you are building software, the business issues may relate to legislation, business process, marketing etc. and technical issues relating to security, data storage and hardware upgrades. You need to create your own checklist for each type of project.

The Blame Game

It is inevitable that people will blame others for the project reaching a crisis point. Blame rarely contributes to resolving a crisis. It is a technique to muddy the water and shift the focus from the future to the past. Avoid discussions of blame but use it as a filter to interpret the information you are receiving.

I interviewed two people – one after the other – as part of a PIR (Project Implementation Review). It was the first time I had met the people as I was brought in as an independent reviewer. It was hard to believe they were talking about the same project. Each blamed the other for the failure of the project to deliver on time and budget. Each had presented the facts (and a little fiction) in such a way that you would have fired the other person for incompetence if one person’s opinion was the only evidence. The truth lay in the middle, or a little to one side of centre. It took many more interviews to uncover the reality.

Always be aware that what you are hearing is distorted by a sense of self preservation and a belief that “my way of doing things is the only way”. Each person will likely have a view of what is happening that is one sided. Listen to what they say but ask yourself why they are saying it.

A final word on blame. Look for the root cause. An incompetent project manager was appointed by someone. Why was that person appointed? In the case above, the project manager was not experienced enough to have run a large complex project. Whilst he made numerous mistakes, the root cause was that the Project Delivery Manager for the organisation did not have sufficiently skilled resources to appoint to projects. This was because the organisation had a policy of not using contract project managers and not spending enough to recruit sufficiently skilled permanent staff. Compounding this was the lack of an adequate training budget. My recommendation was nothing to do with sacking the project manager. It was to increase the training budget, pay market rates for Project Managers and recruit a couple of skilled Project Managers who could mentor existing Project Managers.

Understanding what went wrong is purely of use to identify issues. Once you have identified what caused the project to move into crisis, you can add those causes to the issue list.

After Scope

After you have established the scope, you need to look at the plan including resources. What resources do you have available, and what resources could you likely get approval for? At this stage it is often useful to do two or more scenarios. The work can be identified and you can then look at various resourcing levels. For example with the two people we currently have, it will take 3 months. If we could get another resource we could complete it in 2 months.

Once the plan is in place, it should be costed. In fact if several plans are produced, they can all be costed. Go back to the original budget and review the expenditure items to see how they have varied. At this point it is more likely you can push the idea of a contingency. For example assume a project had an original budget of $20k for testing software, but the software was far more complex than anticipated and had delayed the project. You might make the budget $25k and add a contingency of $10k because of the lack of understanding of the impacts of the complexity on testing. It is not until the complexity is fully understood that you will know how much testing is needed. Having been bitten once, the organisation is likely to take a more conservative approach to estimating future costs.

Another key point is to review roles and responsibilities in conjunction with the planning. There is little point is saying you want a tester if your understanding is that you need a person with a particular skill set, and the decision maker believes it is a warm body.

Benefits

Assuming there were some benefits associated with the project at some point. You should re-visit these benefits and see if they are still valid. Also look for benefits that may not have been identified early in the project. Sometimes as a project evolves, new benefits become evident.

Initial Report

By now you should have:

• The key player identified. You now have a person who can make decisions, or at least take recommendations to boards or executive committees
• An understanding of the scope of the project – both as it was in the beginning and as agreed now
• A listings of expectations and reality and identification of the gaps between the two
• Identification of the major issues or problems confronting the project
• A definition of the roles and responsibilities required to move forward
• One or more work plans to complete the project
• A new cost benefit calculation

You are now in a position to make recommendations. Never rule out the “do nothing” or “cancellation” alternatives. Sometimes you will find that the real problem is the gap between what people believe should happen and what really needs to happen. If the problem is that everyone expected the project to complete in 6 months and it will take 12 months, the solution may be to take 12 months. The problem to address is the expectation that it would take 6 months. The project can continue to roll on without change but a communication exercise may need to happen to explain why it is taking twice as long as planned.

In a similar fashion, just because people are emotionally bound up in the project does not mean it should not be cancelled. Play the devil’s advocate. Ask people

“Why should we continue with the project?”

If there is not a good, business reason than put forward a recommendation to cancel. Even at recommendation stage, the “cancellation” option is a good one to put on the table. The reality of organisations is that often, nobody wants to be seen promoting the hard decisions. If you only suggest moving forward with the project, some people may think it should be cancelled but be afraid to speak us as they see it as a career limiting move. Your role is to place all the options on the table for discussion.

After the Decision

Once a decision is taken, you are faced with a number of human factors to consider.

• Resources may need to be replaced, or additional resources recruited. Remember it is not a court martial. If someone is to be removed from the project, talk to them first, then allow them to leave with dignity. Consider how you announce the removal of a person.

“Bill is leaving because he does not have the skill to manage the project. In fact Bill is a crap Project Manager who should be dismissed.”

Or

“The project has turned out to be far more complex than we anticipated and now has been given new deadlines that require a super human effort. We have been lucky to recruit Superman to lead the project. Our thanks to Bill for getting us this far under enormously difficult circumstances. We have asked him to assist Superman come up to speed on the current status.”

Remember Bill probably tried to do his best but it was beyond his ability to meet the unrealistic expectations placed upon him.

• The other factor to consider is team morale. After having someone come in to review their project you will likely have a low moral in the group and even factions formed. There are many things you can do to overcome the morale issue but my favourite way to address this is to create the feeling that the team has been neglected for too long and now the importance of what is happening is being recognised. Typically I explain to the key decision maker that they are a manager and it is time to manage. That requires them to make the time available to help boost team morale.
  A few techniques I have used are to have the key person take the team out to lunch, attend team meetings, talk to individuals to explain how their contribution is valued, provide rewards to the team (anything from movie tickets to bonuses), and provide feedback on progress, weekly reports and key documents. It is also useful if you can find something that makes the team feel special. On one occasion, I arranged for the team to have preferential parking spots closer to the building because of the long hours they were working. It cost the organisation nothing except a few cans of paint to stencil “Reserved for Project Team” on the bitumen. The impact on morale was exceptional.

Implementation

Assuming the project is to proceed, take at least a day out to gather the team and key stakeholders together. Make sure everyone understands:

• Their role and responsibilities including any role changes
• The scope of the project
• The agreed plan including milestones
• The way in which the plan will be managed
• The involvement and support from senior management
• The current hurdles and how they will be overcome
• The communication plan for the project to manage expectations

It is likely there will be more planning to do, but “a plan for the plan” is part of the moving forward. If the next week will be taken up with preparing a plan, explain how the process will happen and who will be involved. Hold another workshop when the plan is complete.

Conclusion

Getting an out of control project back on the rails is never easy. You do need a structure however to work through or you will become buried in the project trying to sort out each problem as you come to it. Crisis management requires a particular set of personality skills. It also requires a detachment from the past and is best carried out by someone independent to the project, and preferably to the organisation. Someone who can dispassionately review the situation and make recommendations to meet the goals of the project. The three white papers we have prepared provide a good guide as to what needs to be done. It will never run exactly as outlined, but by following the process outlined in those three papers, you will quickly see where you are, where you are going and how to get there – or not get there as the case may be.

Copyright Project Perfect