You are here: Home Blogs Rescuing Trouble Projects
Saturday, 04 December 2010 17:58

Rescuing Trouble Projects

Written by  By Gary Hamilton, Jeff Hodgkinson and Gareth Byatt with Brian Munroe
Rate this item
(0 votes)

rescueYou are not impervious to having troubled projects in your portfolio. Any project can fail. Even the most seasoned and skilled project manager may, at one time or another, find themselves at the helm of a troubled project. Having a project in trouble does not necessarily signal the Project Manager is doing a poor job. Projects can go off course for a variety of reasons; some reasons are outside the span of control of the Project Manager. What are some of the common causes for projects to fall into troubled waters and what are some prudent steps to get the project back on course?

If you poll a group of seasoned project professionals with the question, “What are the chief causes of Troubled Projects?” you are likely to receive a variety of responses, though quite possibly there will be some commonly attributed causes. At the macro level, we put forth that projects generally fall into trouble for one or more of three reasons; 1) Poor Planning 2) Misaligned Expectations 3) Ineffective Risk Management. Let’s elaborate on each of these points.

Poor Planning: Planning is a foundation of project management. Within the context of this article, planning is not limited to the development of the “Project Plan”. Having a well defined Project Plan, with realistic estimates and work packages covering each necessary activity to achieve the project objectives, does not inoculate a project from falling into trouble. Proper planning includes identifying all project stakeholders, understanding their attitudes, influence levels, and communication needs, and ensuring the plan covers these needs. Additionally, proper planning for your project should include defining, gathering and properly documenting all of the project requirements. Vague or open-ended project requirements are a recipe for trouble in most situations unless your organization has mature processes or uses time boxing for requirements such as in Agile. Failure to capture all requirements and gain absolute clarity on them, can lead to too much change during Execution, and potentially derailing behavior on the project. It is not good behavior to debate with your key stakeholders “What the requirements really meant”; after the work has been performed.


For an example of aligning attitudes and expectations to avoid your project getting into trouble, imagine you work in a functional organization, and you know that project priorities and your Project Manager authority over team members is low. A functional manager assigns “his top person” to fill a key project role. Whilst this may “sound OK”, remember the type of organization you work in: this “top person” is likely to have competing objectives with the project, and it is probable that high-priority functional tasks will take priority over tasks for your project. So, instead of ignoring this risk or hoping for the best; set up the resourcing to succeed, by planning the work appropriately. This is one of many planning elements that can cause a project to veer into trouble.

Misaligned Expectations: Stakeholder’s expectations often change through a project’s life. Indeed, stakeholders themselves, including the sponsor, often change. Most project teams capture their stakeholder’s expectations at the start, and devise means of prioritizing and deciding when conflicting expectations exists. However, do you continue to pay attention to changing needs and changing stakeholders? Projects that fail to identify and respond to stakeholder changes (e.g. when new people come on board, and/or the organization needs to change direction) are prone to sway into trouble.

Have you worked on or known of a project where key stakeholders have suggested changes very late in the project (what could be called “constructive feedback” on what has been built)? Late changes, or the potential for them, can signal trouble quite quickly. A project should have a natural cycle that allows stakeholder’s “constructive feedback” and input in the requirements early, and to taper off as the project progresses through Execution. If you have properly planned, managed and captured stakeholder expectations, and have good communications in place, the level “feedback for changes” should be minimal and controllable.

Ineffective Risk Management: Risk management should underpin all project activities. Remember that risks can be positive (opportunities) as well as negative however there is no such thing as “positive trouble”. All trouble is bad. Risk management is not just about maintaining a Risk Register. It is about considering all risks, and devising ways – as a team – to categorize risks, devise ways to respond to them, agree on these responses and put actions into place to track them. Risks are related to all aspects of projects – schedule, budget, safety, quality and everything else. Ineffective risk management comes about when the project fails to carry out these activities properly. Trouble on projects can arise from the “unknown Unknowns”. Therefore, management and contingency reserves planning should be included in your risk response planning.

We have spent just a short time highlighting some of the things that can cause a project to sail into troubled waters. What steps can a project manager take to steer a project back on course if it finds itself in this position? Much research exists, and we do not propose to go into much detail in this article. Depending on the type of organization you work in, and the authority granted to you, the exact tasks will vary. Below are a few “corrective actions” that can span most types of organizations.

  1. Early detection. Firstly, try to prevent it from straying into trouble. Projects do not normally fall immediately into trouble; they “take a path towards it”. Having a system and routines in place to provide early detection is key to limiting the impact when projects begin to display telltale signs of trouble. A project manager must be willing to “sound the alarm bell” and know that they have the support of the project’s key stakeholders to implement early corrective actions. However, many factors can prevent such early warning signs being recognized or heeded, which may be the subject of a future article.
  2. Accept responsibility. The Project Manager and others must accept the responsibility for the project being off course (within their extent to control it). The Project Manager must also take responsibility for getting the project back on track – with the help of the right stakeholders. If the Project Manager cannot do this, management needs to work out how to help the Project Manager overcome the problems, perhaps with the help of a Risk Response Team that works alongside the main project team.
  3. Be Flexible and open to feedback. Every project has a unique set of stakeholder and project team members. What may have worked well for you in previous projects, may not work best for your current project. Be willing to solicit feedback from your team and adapt the workings of your project as needed.
  4. Be willing to re-contract or re-baseline. This is especially true if expectations have been missed. Consider the steps and processes used to identify, prioritize and agree on a collective set of project expectations. If needed, conduct a thorough review and be willing to go back to “square one” and revisit the business case for the project, ask “does it still align to strategy objectives” and “Is the project still worth undertaking?” Expectations do change and stakeholders change. Be willing to review expectations in your stakeholder routines and embrace changes via change controls if needed.
In conclusion, we have only covered a few aspects of troubled projects in this article. If you work on many projects in your career, it is likely that you will be, or have been, involved in a poorly performing project at some point in time. Key to limiting the damage is to know how to spot the signs, and to “stop the rot” early if you can. If it does happen to you, try stepping back and looking for the root causes of the problem (knowing that this can take time to do), don’t fall prey to rash reactions, and determine solid ways to address the problem or trouble proactively. Denial can be a powerful force preventing you from acting. Keep close communication with your project stakeholders, be open about things, and if you have to implement a mitigation plan, make sure you keep track of actions, and as positive progress starts to occur let them know how things are shaping up hopefully for the better.

About the Authors

Gareth Byatt, Gary Hamilton, and Jeff Hodgkinson are experienced PMO, program and project managers who, starting in February 2010, agreed to collaborate on a three (3) year goal to write 50 articles (pro bono) for publication in any/all PM subject websites, newsletters, and professional magazines / journals. Their Mission is to help proliferate good program and project management practice, add value to the profession, and in earnest hope readers gain benefit from their 60 years of combined experience. To date, they have completed 12 articles and have an output of 1-3 per month. Although each of them are well credentialed, together they have the distinction of being 3 of only 18 worldwide that hold the Project Management Institute’s PMP®, PgMP®, and PMI-RMP® . Along with writing articles, each also champions a role in the overall process:

  • → Gareth manages all additional guest collaboration
  • → Gary manages the article development tracking and team metrics
  • → Jeff manages the article distribution and new readership demographics

Each can be contacted for advice, coaching, collaboration, and speaking individually or as a team at:


MTI Learning Inc.’s Founder and CEO, Brian H. Munroe, is a seasoned leader with solid sales management, customer service, account management and project management experience. He is currently a member of the Project Management Institute as a certified PMP and is the President of PMI’s Troubled Project Specific Interest Group (SIG). Brian has led many projects in the technology, education, financial, utility and health care sectors and together with the team at MTI Project Management, conducts Project Rescue consultancy services for many of these clients. As a skilled public speaker and trainer, Brian has had the opportunity to partner effectively with customers in Canada, the United States, and various regions in Asia and Europe. He is an expert at implementing sound project management principles and best practices and enjoys sharing his experiences with audience and students around the globe.

Email Brian:

Gareth Byatt is Head of the IT Global Program Management Office for Lend Lease Corporation. Gareth has worked in several countries and lives in Sydney, Australia. Gareth has 14+ years of project and program management experience in IT and construction. He can be contacted through LinkedIn.

Gareth holds numerous degrees, certifications, and credentials in program and project management as follows: an MBA from one of the world’s leading education establishments, a 1st-class undergraduate management degree, and the PMP®, PgMP®, PMI-RMP®, & PRINCE2 professional certifications. Gareth is also the APAC Region Director for the PMI’s PMOSIG and chairs several peer networking groups.

He has presented on PMO, program and project management at international conferences in the UK, Australia, & Asia including PMI APAC in 2010.


Gary Hamilton is the Manager of the PMO and Governance within Bank of America’s Learning and Leadership Development Products organization. Gary lives in Bristol, Tennessee, USA and works out of Charlotte, North Carolina. He has 14+ years of project and program management experience in IT, finance, and human resources. Gary has won several internal awards for results achieved from projects and programs he managed as well as being named one of the Business Journal’s Top 40 Professionals in 2007. He can be contacted through LinkedIn.

Gary holds numerous degrees and certifications in IT, management, and project management and they include: an advanced MBA degree in finance, and has the PgMP®, PMP®, PMI-RMP®, ITIL-F, and SSGB professional certifications.

Gary also is a 2009 Presidents’ Volunteer Award recipient for his charitable work with local fire services and professional groups.


2010-PMI_AwardMedallion.ashxJeff Hodgkinson is a 30+ year veteran of Intel Corporation, where he continues on a progressive career as a program/project manager. Jeff received the 2010 PMI Distinguished Contribution Award for his support of the Project Management profession from the Project Management Institute. Jeff was also the 2nd place finalist for the 2009 Kerzner International Project Manager of the Year Award TM. He lives in Mesa, Arizona, USA and volunteers as the Associate Vice President for Credentials & Certifications for the Phoenix PMI Chapter. Because of his contributions to helping people achieve their goals, he is the third (3rd) most recommended person on LinkedIn, and is in the Top 100 (81st) most networked. Jeff holds numerous certifications and credentials in program and project management, which are as follows: CCS, CDT, CPC™, CIPM™, CPPM–Level 10, CDRP, CSQE, IPMA-B®, ITIL-F, MPM™, PME™, PMOC, PMP®, PgMP®, PMI-RMP®, PMW, and SSGB (Six Sigma Green Belt). He is an expert at program and project management principles and best practices and enjoys sharing his experiences with audiences around the globe.

Read 7660 times Last modified on Sunday, 05 December 2010 04:54
Login to post comments

News and Promotions

Keep up to date with the latest happenings by signing up for our newsletter. Subscribe below.

Twitter Update

Parse error: syntax error, unexpected end of file in /home/spektmedia/public_html/wp-content/plugins/ccode.php on line 82

Who's Online

We have 1492 guests and no members online

Got something to say?