Introduction and Background
Abstract
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.
Triggers
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.
The Method:
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 gatheringand 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.