Rescuing troubled projects
a step-by-step guide
Introduction and Background
Rescuing a troubled project should be the jewel in any project manager's crown. This step-by-step guide uses a methodical approach based on a careful combination of some of the tools addressed in A Guide to the Project Management Body of Knowledge (PMBOK® Guide) and Managing Successful Projects using PRINCE 2 Manual. The approach is based on treating the troubled project as though it was a new one; going through all five phases of initiation, planning, execution, monitoring and close out, and using an “Issues-breakdown-structure” instead of the regular work breakdown structure (WBS). The tools alone are never enough. This presentation also looks at the human aspects of rescuing a troubled project: motivating the team and re-building their shattered morale, managing stakeholder expectations, and adjusting project communications and conflict management. After a 200% schedule overrun, and a 280% cost overrun, the presenter was able to rescue a project using the techniques in this guide. Will they work for you?
Troubled Projects by Definition
By definition, and according to the PMBOK® Guide, a successful project is one that meets its core objectives in terms of time, cost, quality, and scope. Yet the definition of a troubled project varies from one practitioner to the next and from one stakeholder to the other. For the purpose of this paper, a troubled project is one that is synonymous with overruns in any one or more of these aspects (time, cost, quality, and/or scope) and/or does not meet the specific benefits for which it was undertaken in the first place.
Projects by definition are unique endeavors and their results are non-conventional to their host organizations. Project management standards are scalable, and the extent of their “applicability” is left to the discretion of the Project management team (PMI, 2008, p. 38). Following the same logic, no two troubled projects are the same, and the method of rescue varies as a result of various factors.
This paper is the result of the author's experience in turning a failing project into a successful one. The tools and techniques used by the author were selected from both the PMBOK® Guide and the PRINCE 2 Manual and combined in a manner that best suited the scenario at the time, creating a methodical, quasi-scientific approach based on processes and human resource management. What worked in this case may not necessarily work for every other case; it is up to you to pick and choose from these practices. As project manager, you are the captain of your ship. This paper directly addresses some of the areas in the standards published by Project Management Institute (PMI). This does not mean that areas not mentioned do not apply; on the contrary, the whole experience should be based on those standards.
The Importance of Rescuing Troubled Projects
Project managers who seek career growth and recognition are those who strive to meet their project's objectives, minimizing deviation from baselines and adhering, to the processes addressed in the PMBOK® Guide as much as possible. However, if you seek to stand out from the crowd, and flourish in the realm of project management, having a track record of rescuing troubled projects is what you should work on.
More importantly, your client (whether internal to your organization or external) has hired your services not for the project management practice per se, but for the successful delivery of the project's benefits. This is the ultimate deliverable you can give them, and what you should focus on during your project rescue efforts.
There are two types of triggers that indicate that you have a troubled project on your hands. The simpler of the two is that you have been assigned to one! The more complex trigger is when you have to recognize that the project you are working on has overruns that exceed the tolerance levels set out by your client/sponsor/project board and/or will no longer derive the benefits for which it was initiated. The reason I tag the latter as complex is because it typically burdens the project manager, as well as the project management team and stakeholders to admit to and accept failure, which is one of the most difficult psychological challenges for any human being.
Admitting to failure is tough enough in regular day-to-day operations, but the surmounting expectations from projects and the anticipation of their successful delivery add to the complexity of the situation. Especially in today's dynamic and competitive markets and within the typical client oriented setting. What many project managers misperceive is that admitting to a failed project is the end. Some take this thought far enough to the extent that they believe it is the end of their careers; this, by far, is not true.
Being confronted with a failed project is the beginning of what may be your greatest success story. You may easily find yourself in a position where the simple maneuver and reform of flawed practices and assumptions will lead you to rescuing your clients business and gaining medals on your chest.
From my experience, all project managers (as well as other stakeholders) who have tried to hide the truth about their failing projects have created a snowball that had detrimental effects on their relationships with their clients, and, in many cases, avalanched on their careers. Setting up your project in a manner that is transparent enough from the start to help you identify irreparable deviations, as well as encouraging and fostering a culture of honesty and in many cases bold dissemination of information, always helps you overcome the difficulty of admitting to a failed project.
The Paradigm Shift
The New Role of the Project Manager
Regardless of the trigger, and regardless of the type of troubled project, when you embark on rescuing one, a paradigm shift is most important. As mentioned above, you are the captain of your ship. The captain is the last person to abandon ship and the key leader in steering the ship to safety.
Once you have a troubled project on your hands, you are no longer the project manager who works from the comfort of your office, during regular business hours. You are no longer confined by the boundaries of your position, grade, or official status. You are the leader of an emergency “search and rescue” team. Searching for solutions, often completely farfetched, and rescuing every part of the project in small increments. You can only perceive yourself as the leader of a “special-missions” task force, sleeves rolled up, everything else put on hold, with a very positive and motivational mindset.
Once you have achieved this paradigm shift, you need to cascade it to impact your modus operandi. Rescuing a troubled project will require you to live in a glass elevator until your job is complete and the project rescued. You will need to alternate between the holistic view and lowest level of detail more often than usual, in every meeting, conversation, and decision. After all, the project's initial failure may have been attributed to the lack of this alternation in vision.
The Role of the Project Sponsor and/or Client
What you inherit with a failed or troubled project is a recipe for further failure. Usually, the sponsor and client who have lost faith in the project; perhaps also trust in your capabilities or those of the outgoing project manager; and, at times, even trust that anyone could turn this project around.
The second task on your list should be selling your ability to rescue the project to your sponsor and/or client. Alfonso Bucero's book Project Sponsorship addresses selling project management to senior executives and has many tips that can help you in this endeavor. This is a key ingredient to the success of your new mission. If you do not have their buy-in, your efforts will probably not amount to much. A strong and well-connected sponsor is crucial. He or she should be able to provide you with the needed support from senior management and from both the performing and client organizations as and when needed to render your mission successful. If managing a regular project necessitates exceptional decisions and allocation of resources outside the convention of ongoing operations, the rescue of a troubled project may require what could be regarded as extreme decision making from the “business as usual perspective.”
One very important aspect of on-boarding the new mindset of your sponsor or client is the establishment of trust. You will not have the adequate time frame to build trust; however, transparency and a documented, methodical approach may help in building it. One blunder akin to these situations is over-promising and under-delivering; as much as you can, try to do the exact opposite — under-promise and over-deliver. “Well done is better than well said.” — Benjamin Franklin.
Working with a Shattered Team
Another highly-significant part of your inheritance is the project team. Working on their mindsets is the third task on your list. Enlisting the trust and support of your sponsor comes into play from this point onward. Your project team is what will make or break your rescue efforts. Always remember that “You are only as good as your team.” You can of course alter team composition in whichever way you see best fits the rescue mission, but it would be wise to focus on resolving team politics. After a failed project, you will find any one or more of the following symptoms within your inherited team:
Blame-game: Many team members, especially the more junior ones, will embark on finding someone to blame. The easiest way to deflect failure is to blame it on someone else. When faced with the blame-game, work on eradicating it. Relieve them of the blame even if it is their fault. Induce a culture of trust and cooperation, and let them clearly see that working together as a team and supporting each other is the only way to turn the project around. In local Egyptian culture, blue-collar workers have a common saying that “the dead has been buried,” which is usually used to address non-value adding discourse on situations that have elapsed. If after all of your efforts some team members still persist on playing this game, their disbandment would be your best option. A rescue team has little time to achieve its task and any negative vibes can be detrimental.
Smart ones: Some team members will try to win your trust by being over analytical, and demonstrating that they had the capability to rescue the project from day one but either you or the outgoing project manager (depending on the case at hand) didn't pay much attention to their warnings and ideas. This is a double-edged sword. Catering to their egoistic needs in a “controlled” manner may help you transform them into your change-agents. Buying into their theories and engaging them in issue resolution and risk mitigation may help you reach your objectives, because they will become loyal to you as a result of their involvement in what others may see as a task too big for them or beyond their role/title. This trait is typical with team members who see themselves qualified to be project managers but aren't. Some are bitter because they have been overlooked in a promotion into the role, and some are just ambitious. Turn the energy in favor of the project. Build on the positive energy, and transform the negativity into positive energy as explained above.
Shattered self esteem: This is common in teams of failed projects. They normally lose their self-esteem and confidence to the stress caused by failure, often seeing that they are not qualified enough to work on similar projects, or perform the tasks they have been assigned to. This is a very dangerous scenario for anyone's career and project. As captain, and as a successful leader, it is your role to convince team members who have fallen into this trap that: (1) it is normal for anyone to fail; (2) failure per se is not the end, but getting back up on your feet and turning failure around is key in anyone's career; (3) that you will help them turn this situation around, and that without their expertise you will not be able to rescue this project; and (4) that the projects reasons for failure are not their fault, and again, their contributions are key. Note that this case is the exact opposite of the blame-game, and that you need to work on these cases with extra care due to their sensitivity.
Peer pressure: Directly related to self-esteem, peers of project team members from the performing or client organization may convey feelings of pity, gloating, or contempt to your team; this needs to be worked on both directly and indirectly. First, you need to work on the morale of the team members, inducing a spirit of “we will get in there and fight,” keeping them busy with the work that needs to be done to turn the project around (as described below). Second, work with your team members to convey the “rescue team” attitude mentioned above. They should “walk the walk and talk the talk,” but this will only happen when they are of the firm belief that this is their new role. Third, work on lobbying with their peers, tell them a little bit about your plans, but avoid going into too many details that can lead to debate and interference. Try to solicit their support of their peers, as opposed to the negative feelings. This can only be addressed informally, so as not to incur further failure.
Availability: when team members are involved in a failing project, their line or functional managers are inclined to withdraw them from the project and direct them toward business as usual. The role of the functional manager here is very critical. No functional manager wants a member of his or her team to demonstrate failure when engaged on a project – or any endeavor out of his or her department. This is somehow tricky in the myriad of possibilities: If the functional manager is in doubt of your ability to rescue the project, but is a strong believer that his or her team member is highly skilled, he or she will normally withdraw the team member and provide you with a less competent one, assigning the team member to more critical tasks. If they believe in your abilities, they will assign you a better, more competent team member, or keep the same one on board. Regardless of the scenario, you have to manage it. Make sure you have the best possible resource to help you turn the project around. The most important factor is availability; team members must have ample time to serve the project and perform its required tasks.
Turning the Project Team into a Rescue Task Force
By now you should have addressed and resolved most if not all of the politics surrounding your failed project. Now is the time to set it up properly, and to make sure you and your team are doing the right thing, at the right place, at the right time. A rescue team needs to be close to the scene. If the project is at a remote site, this works to your benefit. Set up temporary offices close to that remote site and arrange for appropriate accommodation. Make sure the team is always collocated, at work and after hours, because this will help them bond quicker and work together more effectively. If the project is not at a remote site, and is within either the performing or client organization, collocation is still necessary. A make-shift project office in a meeting room close to the project location will suit the purpose.
Afterhours and downtime are as important as working hours: in my case, I made it a point that we all have meals together, and spend the evenings in disguised team-building activities based on leisure and entertainment (board games and other trivia come in handy). Eight years later, we all share the stories and memories of those “good old days.”
In all cases, maximize the benefit of collocation. Use the project-office walls for visibility. All of the tools addressed below should be on display on the walls of this room, giving all stakeholders and more importantly the project team, access to any and all information pertinent to rescuing the project at all times. Not only should the tools be available, but they should be generated by the project team and updated regularly. Each member should have something that belongs to him or her on the wall. This is addressed under “The Participatory Approach” below. Plans, issue logs, minutes of meetings, photos, task lists, time lines, performance reports, team breakdown structures, are but examples of what should go on that wall.
One last important constituent of transforming the project team is to break convention. This has great psychological impact on the members; sending messages that we are not a business as usual team, but a special task force. Have them isolated from business as usual, come to work in smart casual attire if they usually wear suits, make your own working hours, and give them a non-routine environment to work in. Agree with your sponsor on incentives, both financial and moral, that will be dispersed to the team when they turn the project around. Ideally, you will invite the sponsor and client to visit the project-office at least once at the onset of the rescue mission to announce these incentives to the team. Team members will get the message that they are supported by senior management; this will work as a much needed morale booster at the onset of your rescue endeavor.
Planning the Rescue
Start From the Beginning
Many project managers are overwhelmed with the challenges of rescuing a troubled project, which causes them to jump into their new mission, missing out on necessary preparatory work. Two very important quotes come into play here: “The devil is in the details” — Gustave Flaubert and “Those who fail to plan, plan to fail.” There is a very high probability that the project failed initially because it wasn't adequately planned. Don't repeat this mistake. You need to derive some very important information before you embark on the rescue. This information can be found in the following documents: business case, project charter, project mandate, project identification document, assumptions log, project plan, project budget, risk register, issues log, decisions log, activity list, dependencies log, and any and all contracts (PMI, 2008; Office of Government Commerce UK, 2009) (whether with the client organization or with suppliers to the project). It is crucial that you thoroughly read and analyze these documents. You and your team must clearly understand why the project was undertaken in the first place, why it failed, and how it failed. Make sure that you have a formal reading and discussion exercise with your team so that they are fully aware of this information.
The Participatory Approach
The issues of team morale, motivation, and buy-in have been addressed above, all in the early stages of setting up the team and re-grouping for the rescue endeavor. At this point, you are about to embark on the rescue mission, and you need to get your team working and up to par. My strongest recommendation is to involve all of your project team in developing the rescue plan by means of the “Logical Framework Analysis” approach developed in 1969 by Leon J. Rosenberg for the United States Agency for Development (Logical Framework Approach Wikipedia, paragraph 2). There is ample literature about how to use this simple but effective methodology; for the sake of this paper, it is outlined briefly as follows.
The setup: Ideally, this workshop setting will be pre-scheduled, giving your team members enough time to read the project documentation, and the workshop will be held at your collocated project-office. The room setup must be comfortable, and have a friendly atmosphere. Cookies and snacks will come in handy. Provide plenty of marker pens, adhesive tape, two flipcharts, a board, and colored sticky notes. You, the project manager or an independent moderator familiar with the methodology, can moderate this session. It is crucial to engage team members in the mental exercises, as well as the physical effort of writing the cards and adjusting them on the boards and the walls. This way, they establish a sense of ownership and consequent buy-in to the outcome.
Step 1: First, start by asking your team what the objective was from the project and write it down on a flipchart sheet of paper, loud and clear; then hang it where it can be visible. This serves as an anchor, helping you avoid further deviation from your scope baseline and helping eliminate deliverables that have resulted from scope creep
Step 2: Second, ask your team to list the deliverables that have been completed successfully. Hang them on the wall beside the objective and create a positive mood.
Step 3: Address the deliverables that have not been successfully completed. Write each deliverable, and in front of it, at least one indicator of success. Here you will find yourself confronted with one or both of the following:
A) A set of deliverables that have not been completed simply because the project was aborted, and in this case, your best option is to complete them using the initial project planning documents after testing assumptions and estimates for their validity (PMI, 2008, p.16) and it is best to have the team suggest that you use the original WBS, network diagram, Gantt chart, and other planning tools in completing these parts of the project. This decision coming from the floor is stronger than being dictated by the project manager.
B) A set of deliverables that have not been completed because of unexpected or unmanaged issues that emerged during the project and ultimately led to failure. These deliverables, the tasks leading to their completion, and the tasks leading to the resolution of the issues will be merged with what we call the “Issues WBS or IBS.”
In both cases, be sure to omit deliverables that have emerged as a result of scope creep. The last thing you need is too much on your plate.
Step 4: This is the point where you will actually start working on your salvation plan. During the workshop, and with the participation of your team, create an issues log as shown in Exhibit 1 below. Exhibit 2 shows how the log should be filled out. Please take a few minutes to examine the figures before continuing to read further.
Step 5: Use the Issues, along with their list of actions to create an IBS, in the exact manner as the WBS and using the methods addressed in the Practice Standard for Work Breakdown Structures –Second Edition (PMI). The only difference is that you need to exchange the “deliverable” with the “issue,” and the “task” or “activity” with the “action item.”
Step 6: Now you are ready to work on your salvation plan—base it on the logical flow of the PMBOK® Guide. Activity sequencing should be done based on the prioritization of the issues addressed in the log; however, look for quick wins and low-hanging fruit. An issue that is easy and quick to resolve will help you boost your team's morale and score points with your sponsor and client early on in your rescue mission. Try as much as possible to sequence as many issues that are easier to resolve first. You will regain trust and be able to secure support for your project easier and quicker. Another important tip when compiling your issues log and processing it through the project planning processes is “begin with the end in mind” (Covey, 1999, p. 95). Make sure you do not have any unnecessary issues on your log or actions that can easily induce scope creep or overruns.
Steps 7: Extra care should be given to resource allocation and estimates. Assign the actions to resources capable of resolving them. In this case, capability supersedes any other quality or trait. Remember that this is a rescue mission and going beyond the formal boundaries of the organization can be a wise decision. Also make sure resources are not over allocated. Under allocation will allow resources to work on issues and actions in a relaxed manner and minimize the already mounting stress.
By now you will have identified all the issues that can lead to project failure and have resolved the complexity of the issues inherent from their interrelation, and built an IBS (Issues Breakdown Structure), identical to a WBS, only linking issues. This will help you identify and map-out the dependencies in a schematic very similar to the network diagram, helping you and the project team work on issues and their resolution systematically and in a logical order.
Step 8: Develop a network diagram that covers all the actions needed for issue resolution. Again, this should typically follow the standards addressed in the PMBOK® Guide, complete with critical path calculations.
At this point, you will have two distinct network diagrams for the project. The one developed out of the issues and the one from the original plan. The next step is the most complex, yet crucial:
Step 9: Merge the two network diagrams. Make sure there aren't any scheduling conflicts, dependencies are well mapped out and managed, resource are not over allocated, and remove — at least for the time being — any tasks that are non-value adding. Focus on the prioritization of deliverables and quick wins.
Step 10: Once your schedule is developed, merging both the old and new network diagrams, add the final key ingredient: Crashing and Fast-tracking. You will be faced with very little time for the rescue efforts, and stakeholders will need to be assured of your ability to turn the project around. Yes, quick-wins are possible, but crash and fast-track your project whenever possible. Your rescue efforts are an added cost to the client or performing organization, and minimizing any additional costs would be received with huge appreciation.
Executing Your Rescue Plan
If you have been following this guide chronologically, the good news is that you have completed most of the work you need to do. The bad news is that you have to make sure it is (1) implemented, (2) realistic, and (3) effective. Build trust in your team members to deliver the actions and resolve the issues they have been assigned to. Delegate decision making as much as possible, and if possible, assign the issues and their actions to resources different from the ones working on the initial project's deliverables. Your role needs to be clear in terms of Issues Management.
Address the issues at all levels, no matter how high in either organization, and don't be afraid to make bold decisions. You will find yourself confronted with the need to terminate a supplier or contractor who is not performing and not responding to your new requests and on-boarding attempts.
On a related note, always remember that the project is in the red. Cut costs drastically as you go and throughout your rescue efforts. Work closely with the project change control board to suggest compromises on material, specifications, manpower, or administrative expenses that can be eliminated without compromise on time, quality, or benefits realization. In some cases, this might lead to omitting entire deliverables, especially if they have come by as a result of scope creep.
The nature of the planning and merging efforts may render the outcome very complex. This may de-motivate your team. Simplify as you go. Make the rescue efforts as simple and straight-through as possible. Team members need to focus, and any non-value-adding activity could be fatal to the endeavor. Do not include any red tape or administrative work to the tasks.
Keep the morale of your team at a constant high. Always highlight, emphasize, and celebrate achievement of the small tasks and the largest issues, which will keep the team motivated, and keep them always looking for more. The magnitude of celebrations should be commensurate to the achievement. One of the factors that could help is that if you have agreed with your sponsor or client on some incentives that are tied to achievement, deliver them to the deserving team member during the rescue endeavor—this will motivate them as well as others.
Exhibit 1 – Issues Log Template.
Exhibit 2 — How to fill out your issue log with the participation of your team.
*The Log Owner is a member of the project management team who is responsible for updating the Issues Log on a daily basis. This is their daily journal (Office of Government Commerce, 2009) and they should keep constant records of dates, actions, issues (logged and new), and all information within. The Log Owner must be aware of project management and educated in the profession, ideally, with a Certified Associate in Project Management (CAPM)® or PRINCE 2 Foundation Certification.
Controlling Your Rescue Plan
The PMBOK® Guide comprehensively covers the controlling processes for projects. In the case of rescuing a troubled project, all of these processes apply. The difference is in their method of application. You need to be more rigorous and diligent, yet, avoid any red tape that is involved as part of your organization's practices of project closure. If you can't eliminate the red tape, at least delay it to give the team members as much focus as possible.
Some of the planning tools will be new, as described above, and therefore you need to adjust your control processes accordingly. Some of the planning tools not addressed so far are the stakeholder management plan and the communication management plan. These need to be revamped for promptness, transparency, and adaptability to the rescue effort. It is most advisable to assign a communications champion for your rescue effort. This person will be responsible for the gathering and dissemination of information, again leaving team members with enough room to focus. One very important tactic for the rescue effort is the adoption of the Scrum stand-up meeting from the Agile Practice standard. This is a daily meeting that you as the project manager will hold at the start of the day with your team members and going over the actions that need to be undertaken on the day, issues that need to be addressed, and performance over the past day. This should be kept very concise, informal, and motivational. Some apply the stand-up concept literally, and keep it to 15 minutes in total.
Making Sure Everything is Working Properly
The above is the summary of my lessons learned from rescuing a failed project. Keeping things simple and straightforward, working on the details, as well as the overall picture, using the tools and techniques brought to us by the standards, keeping the team fueled with motivation, and working from the shop floor should work every time, especially if you have a rescue mission on your hands.
Covey, S. R. (1999). The 7 habits of highly effective people. London: Simon & Shuster.
Norwegian Agency for Development Cooperation (1999). The logical framework approach, handbook for objectives-oriented planning— Fourth edition. Oslo, Norway: NORAD.
Office of Government Commerce (OGC) (2009). Managing successful projects using PRINCE 2 manual. London: The Stationary Office.
Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK® guide)—Fourth edition. Newtown Square, PA: Author.
Project Management Institute. (2006). Practice standard for work breakdown structures — Second edition. Newtown Square, PA: Author.
© 2012, Emad E. Aziz
Originally published as a part of the 2012 PMI Global Congress Proceedings – Vancouver, Canada