Top Navigation

The only thing better than a perfect plan, is a perfect back-up plan. It’s an unfortunate truth that as intelligent and well prepared as our plans are, there’s no escaping that eventually one of our projects will fail (and fail spectacularly) to the point that the only viable solution is to restart. And as we make that march to our superior’s office with the dark clouds of dread following our every footstep, we can thank our lucky stars that we know exactly how we’re going to get out of this mess – with a clear plan and process through the use of the Project Failure & Restart Model

While every project has its ups and downs, there are definite strategies for mitigating failure as seen in our previously published paper, Warning Signs of Project Failure and Resolution Methods. At times, however, a project will veer so far off of the expected trajectory that the only reasonable option is to pause, hit the reset button, and restart the project with a new and improved plan. To aid in the project restart process, we have developed the Project Failure & Restart Model. This framework will provide a project team with the structure needed to solve the right problems and begin a successful project restart by:

• Reviewing the current strengths and weaknesses of the project
• Characterizing the project failure
• Identifying strategies/corrective actions

A project restart can be a challenging process that lacks a clear structure for success. There are certainly issues that need to be resolved but accountability and clarity on future expectations can be difficult to achieve. While the project management team will be struggling with the question of, “How do we restart the project?” the question should be, “Why do we need to restart the project and how do we make sure it will go better?” Only a clear understanding of the types of project failure will allow for a new plan to be implemented that will improve performance.

In addition to introducing the Project Failure & Restart Model, an example project will be described and the Project Failure & Restart Model will be implemented to provide a “start-to-finish” use case.

Project Failure & Restart Model

Projects can and will fail for a variety of reasons – some of these will require a project restart. In order to better understand these projects and develop solution The Project Failure & Restart Model focuses on:^[1]

• Forcing analysis of the project by considering both technical and managerial issues
• Profiling the nature of the need for the project restart by matching characteristics with those accountable for failures (and successes)
• Provide actionable strategies for the project restart to create a more successful management model

A key characteristic of the Project Failure & Restart Model is that it is intended to analyze projects that have already been deemed necessary to restart by the appropriate stakeholders. Actually determining if a project needs to be restarted is a different analysis that will likely require supplemental work (such as: project health check, review of project management documentation, schedule analysis, financial analysis, etc.) that may be referenced to aid this framework.

Given that background information, the Project Failure & Restart Model is comprised of the three major components:

• Technical Influence axis, x-axis – characterizes the influence of technical issues on the need for the project to restart. There are five possible characterizations: minimal, few, moderate, significant, critical
• Managerial Influence axis, y-axis – characterizes the influence of managerial issues on the need for the project to restart. There are five possible characterizations: minimal, few, moderate, significant, critical
• Project Failure Profiles – four descriptive profiles grouping and differentiating projects that require a restart via the intersection of the Technical and Managerial Influence axis.

Combined these three components comprise the Project Failure & Restart Model as see in Figure 1 below. Each component will be described in greater detail in the following sections.

Figure 1: The Project Failure & Restart Model

The Project Failure Model in Action

A global company has recently decided to employ a new cloud based software suite (CaaS) that will replace their current tools used for sales, branding, and other revenue generating activities and events. The project team consisted primarily of a project manager and various work stream leads and representatives from Sales, IT, and the CaaS vendor. There has also been significant input and requirements from Finance, HR, and Marketing for alignment across the organization. The anticipated scope of this project was to have a completed and functional tool within 18 months at a price of $45 million.

Issues:

• There was substantial difficulty in aligning the various stakeholders to a concrete organizational structure
• Product requirements would often change causing re-work or delayed processes that increased activity time
• Project managers were switched due to failing performance after two months
• It was decided by all involved that the project should restart after four months into the project with $18 million spent (only $13 million was expected to have been spent at this point)

Technical Influence, x-axis
The Technical Influence axis reflects the technical issues, changes, and complications in the project that contributed to the restart of the project. Ultimately this axis should reflect any of the “hard” skills needed throughout the project that compromised success and were influential in causing the project restart.

Possible Components – The following components are samples of the technical issues that could be considered/reflected on the axis:

• Late completion of work activities
• Change requests due to poor work
• Insufficient technical performance of work
• Defined processes not followed properly
• Technical failure (data vulnerability, compatibility issues, security, etc.)

Ways to Analyze – Several different analyses may be needed depending on the information available and the “appetite” of the project management team to perform forensic analysis while preparing for the project restart. Possible examples include:

• Schedule delay analysis
• Review of change orders
• Review of meeting minutes
• Contract(s) review
• Audit of time/billings

Classifications – The following classifications are suggestions that could be altered depending on the nature and scope of the project. All time/cost criteria reference the unexpected or changed technical work not the total planned work:

• Minimal – There were minimal technical issues that occurred prior to the restart (<3% of total work time/cost). In fact, the overall technical performance of the project would be considered near exemplary with only very insignificant and cosmetic changes required.
• Few – There were a few technical issues that occurred prior to restart ( >3% and <5% of total work time/cost).
• Moderate – There were moderate technical issues that occurred prior to restart ( >5% and <15% of total work time/cost).
• Significant – There were significant technical issues that occurred prior to restart ( >15% and <25% of total work time/cost).
• Critical – There were critical technical issues that occurred prior to restart ( >25% of total work time/cost).

Developing the Technical Axis – To develop the scale of the Technical Axis, the project team decided to use the prescribed nomenclature of minimal, few, moderate, substantial, and critical with the total number of days delayed per activity used to determine the severity. For this example it was decided that 3, 5, 10, 15, 20+ days would be used for the respective categories. A detailed schedule analysis revealed that although there were many delays on the project only 5 days of delay were actually attributed to technical issues/performance. It was decided that that project should use a Few value for the Technical Axis.

Manager Influence, y-axis
The Managerial Influence axis reflects the managerial issues, changes, and complications in the project that contributed to the restart of the project. Ultimately this axis should reflect any of the “soft” skills needed throughout the project that compromised success and were influential in causing the project restart.

Possible Components – The following components are samples of the managerial issues that could be considered/reflected on the axis:

• Project schedule not accurate or poorly maintained
• Management failure to recognize and resolve any milestone, submission, or other time-sensitive issues
• Resource allocation not reasonable for the planned work
• Lack of leadership or sponsorship at an executive level
• Limited or conflicting motivations behind key stakeholders

Ways to Analyze – Several different analyses may be needed depending on the information available and the “appetite” of the project management team to perform forensic analysis while preparing for the project restart. Possible examples include:

• Schedule delay analysis
• Review of change orders
• Review of meeting minutes
• Project Health check^[2]
• Gap analysis of key roles and responsibilities on project

Classifications – The following classifications are suggestions that could be altered depending on the nature and scope of the project. All time/cost criteria reference the unexpected or changed technical work not the total planned work:

• Minimal – There were minimal managerial issues that occurred prior to the restart (<3% of total work time/cost). In fact, the overall managerial performance of the project would be considered near exemplary with only minimal changes required.
• Few – There were a few managerial issues that occurred prior to restart ( >3% and <5% of total work time/cost).
• Moderate – There were moderate managerial issues that occurred prior to restart ( >5% and <15% of total work time/cost).
• Significant – There were significant managerial issues that occurred prior to restart ( >15% and <25% of total work time/cost).
• Critical – There were critical managerial issues that occurred prior to restart ( >25% of total work time/cost).

Developing the Managerial Axis – To develop the scale of the Managerial Axis, the project team also used the prescribed nomenclature and used a similar method to classify using total number of days delayed per activity. They also chose to use the same number of days per classification (3, 5, 10, 15, 20+ respectively). A detailed schedule analysis revealed that there were several delays of managerial activities (namely approvals, signoffs, and decisions) that created a delay of 18 days. It was decided to round this value to 20 and deem that the project should use a Critical value for the Managerial Axis.

Project Failure Profiles
The intersection of the Technical and Managerial axis creates a quadrant that groups the project failures prior to restart into four different groups. As depicted in the Project Failure & Restart Model in Figure 1, each of these quadrants can be summarized into profiles with prospective descriptions, risks, and possible next steps.

Well Planned & Executed
Description:  Projects that were properly managed and technically successful at completing the work. The project restart was mainly due to a major external factor that could not have been anticipated or possibly a major change in scope that required the project to re-baseline.

Risks:  Very little risk, though a possibility that scope needs to be better defined and/or major changes may be more probable than expected.

Possible Next Steps

• Redefine major project scope
• Consider any macro-level factors that could affect the project and build contingency as possible
• Increase contingency to consider any future issues, i.e. reconsider the risk profile of this project

Politically Problematic
Description:  Managerial issues were the primary cause for the project’s restart. Causes could vary but likely include issues such as: poorly defined processes, inadequate resource allocation, poor project management principles, lack of executive/stakeholder engagement, etc. Projects that have experienced this kind of failure are often the most difficult to correct. Identifying leadership failings and future necessities can be a tall order for anyone within the organization (particularly those close to the project). A fresh perspective from someone removed from the project or an external source may be needed to adequately observe, analyze, and correct the project.

Risks:

• Accountability can be much more difficult to determine or “spread” across the project management team. Many of the issues in these projects will require political posturing and savvy as opposed to clear technical issues – hiring more analysts may not be the solution. If there is poor alignment and accountability at the project management/ stakeholders/ executive level there is a good chance that the project will have poor performance while setting a less than adequate precedent for future projects.
• Motivation for “technical” workers will likely be lacking or difficult to engage. Poor managerial oversight on a project will likely result in an overabundance of PowerPoint presentations and an under-abundance of actual leadership on a project. This combination has the potential to quickly burn out employees who may no longer feel confident in the direction of the project. The true risk lies in burning out or disengaging key personnel to a degree where they consider transferring or leaving the organization all together.

Possible Next Steps

• Use Gap analysis to close any roles & responsibilities that may be lacking
• Reinforce any expectations at the stakeholders/executive level in a charter or other formal document to ensure clarity and accountability
• Provide any additional resources that may be needed to placate technical team members
•  Add/detract management members to reinforce commitment to project
• Borrow organizational structure from prior successful projects within organization

Technically Challenging
Description:  These projects were riddled with technical issues every step of the way. From unexpected changes to poor quality control, the work just wasn’t getting done the way that it was supposed to get done. There were likely more than a few reasons: inexperienced resources, lack of resources, improper or poorly defined processes, lacking quality control, etc. The plan was thorough and managed well, but getting the product to a satisfactory level took substantially more time and cost than was expected.

Risks:  Traditional risks (over budget, behind schedule, etc.) are generally associated with this profile. The project restart was likely expected after an abundance of performance metrics failed to deliver a positive outlook on the project. In short, the biggest risk is not getting the quality product that you anticipated at a cost or time frame that is deemed to be reasonable.

Possible Next Steps:

• Use Gap Analysis to identify resource experience requirements
• Strengthen product quality assurance (QA) requirements
• Update product quality and assurance processes, including sign-off and added accountability
• Revise estimated durations for activities by reviewing issues (issues log, change orders, after action review, etc.)

Perfect Storm of Failure
Description:  Projects of this nature had little to no real chance of success. They were likely undertaken without adequate planning to achieve an objective that was too lofty. The best thing going for these projects is that the failure was so obvious that initiating a restart was an easy decision. These projects, more than any other, need to identify all issues (both technical and managerial) in order to refrain from repeating prior mistakes. It is very likely that these projects will be facing a great deal of external pressure to continue and will require substantial discipline and effort to correct the current trajectory.

Risks:  In this case, the entire project is failing at some level and caused the restart. The product is not being produced as accurately or as efficiently as was anticipated and the project management team no longer has a pulse on the project and lacks the knowledge to right the ship. Time and money are leaking from the project budget and there doesn’t appear to be an end in sight.

Possible Next Steps:

• Use Gap Analysis to identify needed resources, roles, responsibilities, etc. – fill as needed
• Re-align focus of the project from the core values to the activity level
• Revise all project management documentation, processes, and schedules to align and remove any redundancy and/or gaps
• Create new baseline for financials and schedules while ensuring that tracking and measurement is accurate –audit as necessary
• Re-engage executive level management to establish commitment to the success of the project

Assigning the Project Failure Profile
After both the Technical and Managerial Axis, the project team plotted the results. It was determined that the project failure profile matched the Politically Problematic profile.

Restarting the Project Successfully
Once the profile was identified as Politically Problematic possible next steps were identified and discussed. It became clear to the project team that much of what delayed the project was the lack of structure and accountability among the key stakeholders. In order to resolve these issues a new project charter was developed with emphasis placed on clear roles and responsibilities of key stakeholders. New detailed processes were drawn out to clarify how issues, changes, and signoffs should be managed throughout the project and who is responsible each step of the way. In addition, a new management structure was put into place with a high ranking sales executive allotting 80% of his time to the management of this project and delegating his other daily responsibilities until completion.

With these changes the project continued with improved performance and better model for future projects of similar sizes.

Summary

Project management is a well-defined discipline with various models, strategies, and formats. However, there is not as much clarity to correct a failing project once it has been deemed poor enough to merit a restart. By using our Project Failure & Restart Model an organization can structure there analyses to identify the characteristics of their project that led to a restart and begin to formulate strategies for a successful restart.

About the Author

Bryce Ritter is a Consultant with Kenny & Company. He leads and supports the defining, analysis, planning, implementation and overall execution of client engagements. Bryce has a BS in Civil & Environmental Engineering from Virginia Tech and a MBA from the College of William & Mary.

About Kenny & Company

Kenny & Company is a management consulting firm offering Strategy, Operations and Technology services to our clients.

We exist because we love to do the work. After management consulting for 20+ years at some of the largest consulting companies globally, our partners realized that when it comes to consulting, bigger doesn’t always mean better. Instead, we’ve created a place where our ideas and opinions are grounded in experience, analysis and facts, leading to real problem solving and real solutions – a truly collaborative experience with our clients making their business our business.

We focus on getting the work done and prefer to let our work speak for itself. When we do speak, we don’t talk about ourselves, but rather about what we do for our clients. We’re proud of the strong character our entire team brings, the high intensity in which we thrive, and above all, doing great work.

Notes

1. While it is true that Agile, or similar repetition based project management frameworks, will use periodic check-ins to identify issues and improve performance we still feel that this framework is valuable in regards to larger projects (greater than 30 people), managerial issues, and systematic failings that may not be identified otherwise.
2. While it is true that Agile, or similar repetition based project management frameworks, will use periodic check-ins to identify issues and improve performance we still feel that this framework is valuable in regards to larger projects (greater than 30 people), managerial issues, and systematic failings that may not be identified otherwise.

Cited and Considered Sources

1. Cook, Rita. “Getting the Momentum Back” Mendix, 2013. (May 6, 2013). Web. November 2014
2. Cutting, Thomas. “How to Really Fix a Failing Project” Project Smart, 2008. Web. November 2014
3. Darling, Moore, and Perry. “Learning in the Thick of It” Harvard Business Review. (July 2005). Web. November 2014
4. Grier, Sam. “How to Restart a Stalled Project” IT Managers Inbox, 2014. Web November 2014
5. Grobenly, Marcin. “Warning Signs of Project Failure and Resolution Methods” Kenny & Company, 2012. (July 31, 2012). Web. November 2014
6. McCreary, Lew. “How to Kill Bad Projects” Harvard Business Review. (June 4, 2008). Web. November 2014
7. McGrath, Rita. “Six Problems Facing Large Government IT Projects (And Their Solutions)” Harvard Business Review. (October 10, 2008). Web. November 2014

This article was first published on www.michaelskenny.com on February 12, 2015.  The views and opinions expressed in this article are provided by Kenny & Company to provide general business information on a particular topic and do not constitute professional advice with respect to your business.