According to the Standish Group, over 60% of projects fail or are challenged.

Gartner Group 2011 research shows the same story; only it paints a slightly worse picture.

Based on these statistics, program/portfolio managers and PMOs need to have skills for rescuing troubled projects.

Determining if You Have a Troubled Project

It is important to determine if you have a troubled project before any significant intervention is taken. It is best to do this using predefined criterion that are administered at the PMO or portfolio level. The following criteria provide  some examples:

Project Planning

• The project does not have an agreed upon vision and clear set of objectives.
• Impacts that the project will have on the business architecture have not been identified and defined.
• A thorough stakeholder analysis has not been performed.

Discovery

• The solution scope has not been clearly defined as a set of features that can be delivered independently.
• Customers and users are not adequately engaged in project discovery activities.

Delivery

• Delivery team satisfaction is low.
• Agile team commitments have not been met.
• Velocity is decreasing.

Project Performance

• The  project  is  trending  20%  or  more over  its  estimated  budget.
• The  project  is  trending  20%  or  more over  its  estimated  deadline.

Benefits Realization  

• The  client  is  extremely  dissatisfied with  the  performance  of  the  project team.
• Benefits as defined in the business case are not being achieved.

Project Recovery Process

Turning around a troubled project is never easy, but there are approaches that can be used that provide a good chance for success.  It is important to note that success may not mean delivering the project within the original time and budget constraints. Rather the focus must now be on salvaging the project to ensure that the project addresses the business need and achieves the expected business outcomes. If it appears unlikely that the project is able to deliver the anticipated business value, then the project should be canceled instead of recovered.

The following project turnaround model presents a good method for getting the project back on track:

• Assess the Troubled Project
• Develop a Recovery Plan
• Execute the Recovery Plan
• Monitor and Measure the Recovery

Managing Solution Scope

A vast majority of projects run into trouble because solution scope is not well defined or managed. There are two types of scope on a project: project scope and solution scope. Project scope involves defining the work that will be performed. Solution scope defines the features and functions that will be included in the solution. Project managers are generally very good at defining project scope but generally not very good at defining solution scope as this is a business analysis responsibility and not part of the project management domain. However in most organizations, business analysis maturity is so low that BAs start with defining solution requirements and are not even aware of what solution scope is.

Defining solution scope is perhaps the most important part of the upfront process of planning a project. However, it is seldom done well. If you don’t know for sure what you are delivering and what the boundaries of the project are, you have virtually no chance of success. Managing solution scope is one of the most critical aspects of managing a project. However, if you have not done a good job of defining scope, managing scope will be almost impossible. Failure to define solution scope well almost always results in scope creep, as well as budget and schedule overruns.

In the most recent CHAOS Manifesto, Standish Group analysts strongly recommended two key practices concerning solution scope:

1. Break the project into small independent Components or Features that can be delivered independently.
2. Focus on high value features and eliminate features that provide little or no value.

The Standish Group flatly states that that “there is no need for large projects, and that any IT project can be broken into a series of small projects.”  It is important not to interpret breaking down projects into smaller projects as defining milestones, phases, critical paths, and activities. Delivery of concrete and usable results demarks a successful completed project. Small projects deliver a valuable result that is actually used to create a return on investment (ROI).  The benefits of using this approach are quickly evident when the organization starts to receive value early in the project cycle. The probability of success is 10 to 20 times that of running a single large project.

Standish Group Research shows that 20% of features are used regularly and 50% of features are hardly ever or never used. The gray area is about 30%, where features and functions get used sometimes or infrequently. Focusing on the 20% of the features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction. Reducing scope and not delivering 100% of the functionality is not only a valid strategy, but a prudent one.

The first step in recovering a falling project is to focus on the solution scope.  If it has not been defined well, then this is the place to start in the project rescue.  Organizations that place more focus on solution scope in the first place will have less need to rescue failed projects. If your organization is struggling in this area, please request a consultation from Enfocus Solutions. We offer consulting services and technology to help you in this vital area for successful projects.

[cta id=”7658″]