Rescuing Troubled Projects: Part I (the Formal Method)
Projects that are not performing as planned can be cancelled or if there is enough earned value and if the expected return is high, they can be rescued. I've been a part of many rescuing efforts for colleagues and know our first reaction may often be one of inquisition. However, instead of viewing this situation as another layer of inheritance and more work, you can turn the situation into an opportunity to show your organization and customers the power of applying sound PM methodologies. While you may start to see an increase in requests for your expertise, it is our professional obligation to educate our co-workers and customers about best practices and to also personally apply them ourselves in all we do.
Below are a few steps you may follow in assessing a project in need of repair:
- Project Documentation & Budget Discovery – You’ll need to review existing project documentation including the project charter, project plan documents, budget expended, requirements, and any other related documents. This will give you a feel for the goals of the projects, deficiencies and other key information.
- Meet with Business Owners – You should meet with the project business owners on the original need, current need, budget and definition of project success. Ask questions, but also allow them ample time to let you know their opinion of what was working, not working and what they are really looking for.
- Meet with Project Team – You should also meet with the project team on their views on what was working and not working. Create an open exchange where you listen to their input. You don’t need to offer solutions at this stage. The most important thing here is to truly listen.
- Analyze the Situation - Once you have acquired all relevant material and perspectives, you’ll need to analyze the information received and plan your approach for starting anew. This is now your project. While it is important to learn from previous actions, you have been assigned to turn this effort into a success.
- Document Lessons Learned – While we know that we should document our personal lessons learned on our projects, it is equally important to document lessons learned from your predecessor. These will benefit your team, other PMs and even yourself. While we may not have been initially part of the challenges on the project, we could easily fall prey to the same mistakes in the future.
- Hold a Kickoff Meeting – An initial kickoff may or may not have been held. In any case, another kickoff should be planned to invoke excitement and state the changes you are making and how things will be different and better this time around.
- Measure Results – Use some of the data collected in your discovery step to create a baseline. Start capturing and comparing new results to this baseline. It is important to capture as much data as possible upfront. To do this you should structure your time recording and estimates in a manner that will allow this to occur. Ongoing results should be compared to the original baseline. You should even create a new baseline for when you took over the project.
- Reassure All Affected – In the case of troubled and failing projects, it is going to be even more important to show the business owners, internal stakeholders and your team that together the project will succeed. Show them how they can make a difference and don’t forget to market your successes and the obstacles you overcame. This will help build momentum and credibility with your team and organization.
Of course each project situation is unique, but the ideas above should help in the restructuring and team building that is needed after taking over an existing project.
Next month I will write about tips for handling an informal project takeover, where all parties are not necessarily aware of your role.
Capture the issues as relayed by the project Stakeholders and team in the Stakeholder Analysis Summary Table to gain perspective and help define your approach. Learn from others by reading the paper Rescuing and Revitalizing the Problem Project. To avoid that deer-in-the-headlight look from the team when soliciting lessons learned about the best way to capture lessons learned without making people feel bad?