Why Projects Fail & What to do About It

As you probably know, the typical project is less than successful. Can you name the top ten reasons why? Come participate in a discussion of the causes of failure and potential solutions. This session of the Breakfast Roundtable was facilitated by Bruce Martin, a frequent attendee at these sessions.

Highlights:

Click on photos to enlarge

When was the last time that you worked on a troubled project?

On April 22nd, Bruce Martin - PMP, a frequent participant at our Breakfast Roundtables, facilitated a discussion titled “Why Projects Fail and What to Do About It”. Often, a Project Manager is recruited to fix a project that is already in trouble; however, this does not mean that the new Project Management is NOT at risk. Troubled projects can have a succession of project managers, each accompanied by failures.

What are some of the root causes for these projects to fail?

• Incomplete and/or continually changing requirements
• Lack of management/sponsorship involvement
• Inadequate resources/funding
• Unrealistic expectations
• Inadequate planning
• Obsolete system or solution
• Lack of project processes and procedures

The focus of our discussion was on the importance of developing processes to manage risk. Project risk is a forecast of an event that may influence an aspect(s) of the project, potentially exposing the project to missing its commitments. The assessment, identification, prioritization, analysis, logging and tracking of risks and their accompanied actions throughout the life of a project is called Risk Management. The actions are often part of the project plan.

Participants cited the following “Lessons Learned”:

• Monitor risks that have a medium or high probability and severity regularly as risk status can change. The Project Manager determines the mitigation strategies to contain, reduce or eliminate risk events. The Project Manager owns the Risk Management Plan.
• Establish Risk Management processes with standard tools that regularly assess risk. Build the tool into the processes, not vice versa. Interestingly, few participants use a standard tool.
• Inform stakeholders regularly through status reporting.
• Foster relationships with Quality Assurance to conduct health checks, based on complexity and current project posture. Malcolm Pirnie, for example, assigns a quality consultant on each project to assess the technical risks.
• Present to management the unknowns by quantifying risks and their potential outcomes.

In addition, communicate the risk management plan at least during the following five events:

• Project Charter
• Phase Checkpoints
• Kickoff
• Project Status Meetings
• Steering Committee meetings