10 Tips for Project Rescue

Tip #1
Don’t make any assumptions on why the project has gone awry. While there are some "usual suspects” that should be investigated during your rescue, each project is unique, and so are the project team and its stakeholders. After all uniqueness is the very definition of a project.

Go into the rescue with an open mind and seek facts rather than opinions. When you’re called upon to rescue a project there will be a lineup at your office door consisting of team members and stakeholders with their own political agenda to pursue – don’t get caught up in those agendas, you have your own.

Tip #2
You will have 2 human relations problems that you have to sort in short order: a demoralized team and distrustful stakeholders. You won’t be able to attack the first problem until you’ve done your assessment of the project and established a new plan. The second problem can be attacked immediately. Set reasonable expectations for your rescue. Set delivery dates for the new plan as soon as possible, don’t wait until you’ve completed your assessment. You can set dates for a new set of plans after the first day or two if you can get a sense of how much re-adjustment will be necessary and this can usually be done by examining the project schedule or MS Project plan.

Once you’ve made a commitment, keep it no matter what it takes. Even if you have to deliver a set of incomplete plans they can always be refined afterwards. You only need to have a schedule of dates for individual work packages for the first month or so of work and forecast dates for milestones and deliverables for work occurring after that.

Your opportunity to raise team morale will come after you have re-planned the project. Share the plans with the team and make sure due dates are reasonable and attainable with the existing team. You can do this by having the people responsible for doing the work, work through the schedule with you and verify dates. You’ll need to have plans to acquire additional resources if the current team isn’t sufficient to meet the new schedule.

Once you’ve implemented the new plan, look for the first opportunity to reward an outstanding contribution. A confidence in the plans and their ability to execute will get the team on the road to a higher morale. Rewards and recognition will get the team the rest of the way. Read more......

Tips #3
Start your assessment by reviewing all the project documentation starting with the MS Project file or other schedule document. Is the file up to date? How many tasks are behind schedule? How many tasks are started but not completed? Gathering this information will help give you an accurate picture of how badly the project is behind schedule. An out of date schedule will indicate a different sort of problem: the previous project manager either didn’t have time to do this work, or didn’t think it was important enough to keep on top of.

Other artifacts to check: Business Requirements documents, design documents, test plans, quality management plans, procurement management plans, risk management plans and most important of all: the change management plan. Remember, if there is no document there is no plan so you’ll have to draft the plan yourself. Check the existing plans for the documents they call for. Are the documents available? Do they verify adherence to the plan? Do the plans seem adequate? Are roles and responsibilities specified? Are the people responsible for executing the tasks called for by the plan aware of their responsibilities? Read more.....

Tip #4
Scope creep is one of those "usual suspects” I mentioned. Any project without a good Change Management plan will be hobbled by scope creep. If the project to be rescued doesn’t have a good Change Management plan it will suffer from scope creep sooner or later.

A project that is constantly having additional work added without changing the plans will fall behind schedule because the team can’t do the work assigned to them by the undocumented changes on top of the planned work. Something has to give and this is often the planned work, especially when the folks requesting unplanned work are management. How do you tell if this is happening? Compare work results to the plan. Work results that aren’t in the plan usually reflect undocumented change. The results might be whole work packages not in the plan or changes to existing work packages. Check for anecdotal evidence as well. Competent workers who habitually fail to meet deadlines usually have a reason for the failure and unplanned work is often the culprit.

Even projects that have a good Change Management plan can fall prey to scope creep. Another "usual suspect” for rescued projects is poor requirements gathering. Were the right stakeholders solicited for input? Are there requirements in the Business Requirements Document feasible? Are they prioritized? Stakeholders can change their minds after identifying their requirements and often do, and for good reasons. These are the changes the Change Management plan is designed to handle. Stakeholders who were not solicited and have no other way to have their requirements addressed will force changes through the back door. You’ll need to address the root cause of this problem by soliciting the missed stakeholders and re-base lining the scope if necessary. Read more.....

Tip #5
Don’t throw the baby out with the bathwater. The assessment phase of project rescues often leads to the conclusion that some members of the project team aren’t performing. There are different ways of addressing performance problems and these should be explored in every case where there is time to implement the improvement plan excepting one: where the reason for poor performance is not a lack of skill or ability. Team members who have contributed to project failure because they have a political agenda that conflicts with the project’s goals and objectives will need to go. Others should be helped wherever possible. Giving the saboteurs their walking papers will improve team morale while sacking those that put forth an honest effort but just can’t meet expectations won’t.

I mentioned "back door” changes in Tip #4 and this is a frequent cause of poor performance. Check for this condition when a historically competent resource starts to consistently miss deadlines or produce poor quality work. The work they are tasked to do may not have anything to do with the project. For example, resources that are assigned to your project 50% of the time may actually be contributing significantly less than this. Often the reasons for the change in time contributed to the project are valid. The resource may have operational duties to perform the other 50% of the time and be called upon to contribute more than 50% in times of emergency. These situations go back to the Change Management plan. A change in the time a resource contributes to the project must be covered by a change request, even if the change request is initiated after the emergency.

Lack of training is another culprit to look for when investigating poor performance. Have the resources the necessary skills and experience to perform their work? Are junior resources struggling because they don’t have the experience they need to do the work? Do senior resources have to invest significant time to help out junior resources? Have resources been trained on any new technology they use? Was the training they received adequate? You may have to investigate training where resources haven’t received any or additional training where the training was inadequate.

Contract resources that don’t have the level of experience they claim are another source of poor performance. Actually the poor performance is caused by the gap between the experience they claimed to have when interviewed and the experience they actually have. Contractors who have misled the interviewer about their abilities can be terminated for cause without penalty and they should be. You should investigate the impact of their dismissal on the project of the dismissal; you may find that the disruption caused by dismissal will outweigh any benefits gained by the search for and acquisition of a contractor with the right experience level. Read more.....

Tip #6
Your rescue will involve interviewing the team to gather anecdotal information about the project. Handle these interviews should be handled delicately. You may intimidate your interviewee especially where you have the power to fire poor performers, you can’t do much to eliminate their fear but don’t stoke it by personalizing issues. Remember that your focus is on the project, not on individuals. Ask your questions in terms of the project, its goals and objectives. Base questions on facts and not your opinions. It’s OK to suggest a cause for a failure but don’t present your opinion as fact. If you want to find out if "back door” work is the cause of a team member missing deadline, tell them that on such and such a date they were to have delivered a work package but the schedule doesn’t indicate it was delivered. Ask them if unplanned work they were asked to do was the cause, if they agree that the work wasn’t delivered.

Avoid using pronouns whenever possible. Stating that "you missed the deadline for work package A” is an accusation whereas "the project missed the deadline for work package A” is a statement of fact. The first statement will have the effect of putting your interviewee on the defensive while the later will tend to make them more forthcoming. It may be tempting to put some team members on the defensive but doing this will limit the amount and quality of information you get. Read more.......

Tip #7
Don’t be afraid to begin at the beginning. If the Business Case the project was based on is flawed the right decision might be to pull the plug on the project. If it’s apparent that the original work estimates, cost estimates, and schedule were unrealistic, update the Business Case with more accurate estimates. There is no crime in underestimating if all the available information was consulted when making the estimates but it is a crime not to update flawed estimates once you’ve had your attention drawn to them.

Organize a meeting with the project sponsor if you’ve updated the Business Case and discuss the changes and the impact on the organization’s Return on Investment that result. Projects are often launched without a formal Business Case. Estimates and forecast benefits might be captured in the Project Charter, some other document, or not at all. A significant change in the estimates for cost or work should be reviewed with the sponsor. The decision on whether to continue with rescue of the project is theirs to make at that point.

Tip #8
Don`t be afraid to try a different approach. Organizations tend to stick with methods, processes, and procedures they are familiar with rather than try anything new. This is OK when the project is performing work that the organization is used to performing, however can cause trouble when the work undertaken is new. The difference between the Waterfall approach to software development and an iterative approach is a good example. The Waterfall method is great for projects that the organization has performed successfully many times in the past but not so great when the project is using a new technology or delivering a product or service new to the organization. That's when work can be missed during the work breakdown process or work packages can be badly underestimated. An iterative approach that allows the team to learn as it goes and take advantage of the things learned in the last iteration can overcome many of the problems introduced by the Waterfall approach.

Tip #9
The initial deliverable of the rescue effort is the new set of project plans. These will consist of new plans covering areas not addressed by existing plans, and updates for plans that didn’t meet the needs of the project. Updates will also include baselines, cost, schedule, and scope. Updated scope baselines may be captured in updates to the Project Charter, Business Case, Scope Statement, and Business Requirements Document. The new plans should be approved by the stakeholders at a Gate Review meeting. This meeting should be conducted just as you would conduct a gate meeting marking the project’s advance from the planning phase to the implementation phase.

Tip #10
Consult an expert. I mentioned that it would take a book to fully address a project rescue in even one industry. I had a book in mind, Project Rescue: Avoiding a Project Management Disaster. This book was written by Sanjiv Purba and Joseph Zucherro. I had the opportunity to work with Sanjiv on a couple of projects and can guarantee that he knows what he`s talking about when he offers advice on rescuing projects.