The holidays are over and I’ve gotten my immediate tasks of closing out last years’ program results and setting up processes and establishing metrics for the New Year. Time to start blogging again! For my first blog it is the time that many programs and projects are reviewed formally or informally for last years’ results. It might also be the time that a program and/or project is formally considered, ‘in trouble’ or ‘failed’. Perhaps I can offer advice on ‘rescuing a troubled project.
Anyone is not impervious to having a troubled project. 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. Let’s consider together what are the common causes for projects to failing 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, 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. 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: A 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.
In highlighting some of the things that can cause a project to be ‘in trouble’, what steps can a project manager take to steer a project back on course if in this position? 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:
- Early detection. First, 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 the 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.
- 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.
- 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.
- 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, only a few aspects of troubled projects have been covered in this blog. 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. ...JGH