Three easy steps to recovering your project

Statistics continue to show that many IT projects remain challenged. The Standish Group, a Boston, Massachusetts-based IT project management research finn, “found a decrease in IT project success rates and an increase in IT project failures over the past two years” (Levinson, 2009, ? 2). According to Levinson (2009), the research found “thirty two percent of IT projects were considered successful… and one-in-four (24 percent) IT projects were considered failures, having been cancelled before they were completed, or having been delivered but never used… and forty four percent were considered challenged” (? 2). Levinson also indicates that the CHAOS summary report from the Standish Group revealed the recession over the past few years lias exacerbated the situation through “budget slashing” (para. 1) and personnel reductions impacting IT project success rates.

Given the persistent trend in projects running into difficulty, it is highly likely that at some point a project manager will be faced during llis or her career with a recovery situation. Knowing how to put a stalled project back on track, whatever the product methodology (e.g., waterfall, agile) can mean the difference between success and failure for both the project manager as well as the business.

There are numerous approaches that can be taken to recovering a project. The more generic traditional approach often leans toward focusing on in-depth analysis to find the root causes of the troubled project issues. Frequently, this will entail appointing a consultancy to conduct this process. Although this approach has clear benefits, it potentially will take time to accomplish and, in the process, break down the team, often losing people and their knowledge, which then has to be rebuilt. As well as being costly, the project can go into paralysis. Typically, the project manager can come under threat and potentially lose llis or her position.

This paper will illustrate, through a real case study, how, with the application of a simple three-step process and technique, the project manager can quickly turn around a failing or struggling project, and bring it back on track and under control while maintaining trust and confidence with stakeholders.

Troubled Projects

A key point, when realizing a project is in trouble, is approaching the go-live date. At this point of realization the tendency is for the project to descend into confusion, panic, and then blame. This descent can perhaps be compared with the phenomenon of the seven phases of project management :(1) Wild enthusiasm (2) Disillusionment, (3) Confusion, (4) Panic , (5) Search for the guilty , (6) Punishment of the innocent, and (7) Promotion of non-participants (е-Coach, n.d., p.l). This comparison is illustrated in Exhibit 1.

Exhibit 1 - Seven Phases of Project Management on a Troubled Project

Many troubled projects have classic symptoms, which are illustrated in Exhibit 2. Project health checks will help identify many of these issues, but often only focus on the tangible aspects of the project, such as the plan or budget. The well being of the project manager and team are also a barometer as to the status of the project and should also be assessed.

Exhibit 2 - Troubled Project Symptoms

‘Research has shown that when organizations take action on recovery projects they are successful eighty percent of the time…. most organizations do not have a standard approach or process for troubled project identification and recovery’ (Project Management Solutions, 2008, р 2). When it is realized that a project is in trouble, and panic occurs, the tendency and reaction of most managers is to focus on common “options.” These common options, as illustrated in Exhibit 3, are important elements to explore, but they may not address all the underlying issues. This common approach to recovery does not provide a process or structure, and generally continues to focus on the existing plan. Failure to address the underlying problems and only center on specific, more easily accessible options often causes the project to continue to be derailed, resulting in more delays.

Exhibit 3 - Common Troubled Project Recovery Options

When a project is in trouble, the behavior of many of the senior stakeholders can change. Managers will typically descend onto the project and place it under intense scrutiny. “Behavior is a key aspect of the crisis management process and where flexibility, sensitivity, and intelligence is required” (Loosemore, 1998 p. 117). In a recovery situation the reverse behavior is often displayed, causing an already stressful situation to deteriorate. This reactive behavior will impact the project manager through requirements for many meetings, constant updates (sometimes to multiple stakeholders) generating a micromanaged environment. “Micromanagers will immerse themselves in overseeing the project… .discourage others from making decisions without consulting them… .effectively disempowering” (Mindtools, n.d., para. 7) the individual, and in this case, the project manager. This can impact a projects manager’s “confidence, hurt their performance, and frustrate them to the point where they quit” (Mindtools, n.d., para. 2). In essence, the project manager can feel beleaguered.

This reactive behavior from stakeholders ultimately influences the characteristics of a troubled project, namely:

• Increased Time Pressures: the project is invariably behind schedule and there is a great deal or urgency adding to the heightened pressure
• Blame culture: with team de-motivation and increased focus there can often be a real or perceived feeling of blame, which in turn leads to a cycle of mistrust, confusion, and a poor performing team. There may well be a lack of trust, and as a result, defensive behavior
• Stakeholder focus: the project has often gained a new level of profile with management requiring quick results
• Politics: a troubled project will have heightened politics
• Legacy issues: the further into the life cycle of a project, the increased likelihood of legacy issues, and the more threat to a successful recovery

These characteristics need to be borne in mind when undertaking a recovery project, as they will influence the strategy and the way it will need to be managed.

Case Study

A UK global utilities company required a pilot to be delivered to assess the benefits and viability of integrating a global tracking system for the engineers into its scheduling system to gain more accuracy in delivering appointments to customers. The pilot would assess the supplier’s out-of-the-box functionality, in tenns of improved operational efficiencies, as well as determine the technical feasibility. The pilot would be delivered into a live operational situation and therefore into a production system.

The project had stalled in the month of October, while the business case was being approved, and the project manager had left the company during this period. The business still had expectations that the pilot be delivered in the original timeframe by December, which would be during its peak winter season. A new recovery project manager was appointed to investigate the situation and put in place a recovery strategy to deliver the pilot.

Most stakeholders want to be able to see quick results, so there is usually little time to undertake a protracted quality assurance investigation. This case was no exception and therefore a rapid project recovery? three-step process and technique was deployed. Exhibit 4, to (1) rapidly investigate the status of the project, (2) bring the team together to rapidly develop a recovery strategy and plan, and (3) convert and restore the output of the workshop into a recovery strategy.

Exhibit 4 - Rapid Project Recovery ? Process

Despite investment in recent years in improved project management “methods” (or methodologies), a survey by Project Management Informed Solutions (PMIS) revealed that some of the common issues as to why projects fail remain largely unchanged:

unclear goals and objectives….lack of aligmnent to project goals across stakeholders….poor communication of objectives and targets across the team….unclear responsibilities across the project….lack of /poor quality planning / resource planning… .poor supplier integration / management….lack of commitment or team working. (PMIS, n.d.,?. 4)

First Step on the Process - Rapid Review

The purpose of this stage is to rapidly health check the project and to identify existing or potential problems on a project and as results of the output, recommend solutions, and/or corrective action. (Outperform, 2011) On this case, a rapid “Hot Spot” analysis was undertaken. The basis of a Hot Spot analysis is that whatever the product methodology used to deploy the IT solution (e.g., waterfall, agile,) the principles of IT project delivery remain the same: design, build, test and implement.

A “Hot Spot” review has two key aims to (1) Assess the quality of deliverables: to understand what documentation is in place and how the documentation has been compiled, communicated, and signed off, (2) People aspects: understand any underlying project issues. For instance, how the team is working together and the interaction between the business and IT, this is done through interviewing team members. Exhibit 5 illustrates the correlation between the projects pitfalls and the product life cycle. Exhibit 5 highlights where the hot spot documentation review is most critical in the typical project life cycle.

Exhibit 5 - Hot Spot Reviews

During the Hot Spot analysis, in which key documentation are targeted for review, some of the more common documents and the potential critical breakpoints are investigated, while also identifying the potential impact to the recovery of the project. The nature of the information and the interpretation as to the kinds of issues that will be faced are illustrated in Exhibit 6.

Exhibit 6 - Hot Spot Reviews and Question examples

In this instance, the Documentation review revealed:

• High Level Requirements were in place, and had been produced by the business analyst. They had involved the business and were signed off; however, they were produced so long ago, and the business had matured in its view of what the operation required, so there was missing scope. There were also no processes or non-functional requirements.
• The plan had only IT activities, and had been compiled on a one-on-one basis. While it is useful information, it was now out of date, and the strategy, for instance to deliver the hardware required for the pilot in parallel, could no longer be attained, as it had not been managed.
• No pilot criteria had been defined, and therefore the pilot estimated timeframe was not valid. This fundamentally meant that the overall plan was flawed, and the promised delivery dates for a national roll to the business could not have been substantiated.
• Solution design in place, but it emerged that the software was embedded in a large service pack, which had not previously been realized by the test team, and as such the testing would take much longer than estimated, and the test strategy required revision.
• The business activities to prepare for business readiness were not on the plan, and there was no consideration to business processes or training. The implication of this missing information meant that there could be issues once delivered in the pilot, as no thought had been given to how the out-of-the-box functionality and the new concept would work.

The Team Review revealed:

• The team was essentially disparate, as the project manager had left
• Testing manager was new in the role
• Supplier was not integrated into the overall project plan, yet integral for delivery
• Business was not integrated

The output of this first stage provided an insight into the potential challenges that could be faced throughout this pilot project and provided a basis for the planning for the next stage.

Second Step – Rapid Project Recovery? Workshop

A main reason for project failure is poor planning, which remains the responsibility of the project manager. The second step in recovering a troubled project is therefore crucial in that it (1) is the stage at which the recovery plan is formed by the team, but (2) commences the change in team dynamics, forming a collaborative and high-performing team led by a strong project manager. This second step in the recovery process is the rapid project recovery workshop, which will:

• Align the team, both IT (including suppliers) and the business to obtain buy in, accountability, and collaboration
• Deliver an integrated recovery strategy and plan, which identifies the key activities, deliverables, risks, and issues
• Begin to re-motivate and move the team from individual and often silo working to a collective and collaborative team moving in the same direction
• Enable the budget to be updated.

While the regular project deliverables are produced, at the heart of this workshop process and technique, is the emphasis on team building. There are many theoretical models, which show how groups develop, including Lewin’s (Wekipedia, Kurt Lewin, 2011) three-stage process, which recognizes that individuals in change need to undertake three stages from unfreezing, which dismantles the current mindset, to the second step of change, where there is a period of confusion, to the third step of re-freezing, where the new mind set is crystallized (para. 12), as well as Tuckman’s (Wikipedia, Group Development, 2011) classic group model of, “Forming, Storming, Norming, and Performing” (para. 8). Whatever the group dynamics model, it can take time to deliver a high-performing team from a troubled project. In the case of recovery projects, tmst may have been lost, particularly if a blame culture has developed. Trust is an essential ingredient for developing highly motivated teams, and this workshop approach rapidly speeds up this goal.

It is therefore important from the onset that team members from all parties participate face to face to commence this essential group trust and formation. In this instance, the primary supplier, the IS team leads, and the business were all involved.

To deliver the output of Step 2, there are three components to the workshop that are required in order to deliver a recovery strategy and plan output: (1) Project Scope Definition, (2) Mind Mapping, (3) Plotting the Recovery Strategy.

1. Project Scope Definition

Teams are comprised entirely of individuals, who all bring their own values and interpretations to the project. As a result, it cannot be assumed that the team is collectively aligned in their understanding of the overall business objectives and project scope. If the team is not aligned, this can lead to confusion and the team may present resistance to change merely for a lack of understanding the change required (Kaufman, Oakley-Browne, Watkins, and Leigh, 2003, p.101). It is therefore fundamental that the team members provide their understanding of the overall project scope, not the project manager who is there to lead and facilitate, to agree one overall project definition at the beginning of the session.

2. Mind Mapping

A common tendency when planning is for project managers to commence with a work break down structure, or even in some cases try to build a project plan with the use of a project tool. These approaches assume that all team members understand project management, which many do not. Fundamentally, using this type of approach can inhibit open discussion among team members because the project manager is trying to put the plan and approach together without the full buy-in and input from the team. Additionally, on a recovery project team, members may be defensive, uneasy, and unsure.

An example of a mind map exercise is shown for a business trip in Exhibit 7. Mind mapping, provides a framework, which will:

• Be visual and driven contextually from the center, or key point, encouraging the individual to think broadly about the situation both critically and innovatively
• Begin to build the team through encouraging collaboration while understanding team dependencies, moving the individuals from just a “me” mentality to a “we” thought process.

Exhibit 7 - An example of a Mind Map for a Business Trip (Illumind Training, 2011, Example 10)

In this case study there were two activities to this mind mapping exercise:

1. The team was asked what were the remaining activities required to deliver the project to pilot,
2. A rapid comparison was then undertaken with the output from Step 1 Rapid Review, to identify any gaps or re-work that may be required and would need to be woven into the recovery plan.

In half an hour, the team had disclosed the information needed to move to the next step, developing the recovery plan

3. Plotting the Recovery Strategy

The final component of the workshop is to layout the recovery strategy based on information in the mind mapping step. This involves two stages:

1. To establish if the original projects key milestones can be met,
2. If the original milestones cannot be met, then to plot out and concur the recovery strategy.

According to Kaufman et al. (2003), if individuals do not understand the new direction they will hold onto the old one because that is what is more familiar to them (p. 59). This step, therefore, builds on the mind mapping, and is visual, to allow the team to collectively see the plan as it fonns, encouraging debate, lateral thinking, open discussion and consensus. This process continues to rapidly build the team and generate collaboration, accountability and responsibility.

In this case, the chart baseline, illustrated in Exhibit 8, details the dates on a day-by-day basis, for the first three months, and then weekly after this period for the next three months. Two original key milestones were put up on the chart. Taking the information from the mind map, the team was asked to confinn what activities were required for the first milestone. It rapidly became evident that the milestones could not be achieved, and the team began to sílift toward a consensus of understanding. As the team worked through the plan, they were able to identify the activities, dependencies, key risks, and issues.

Exhibit 8 - High Level Overview of the Chart generated in the Workshop

At the end of the session, the recovery project manager had: a recovery strategy and plan that required agreement, a full understanding of the risks and issues, and importantly a fully mobilized team that collectively understood what they needed to undertake to deliver.

Third Step – Recovery Restoration

The final step, once the recovery workshop has been undertaken, is to convert the output from the workshop into (1 a Gantt chart, (2) a recovery PID, (3) revised budget, (4) revision of the risks and issues, and (5) a recovery plan. It is imperative that the momentum with the team be maintained, particularly in matrix management situations, and therefore the production of the materials needs to be done within forty-eight hours and played back to the team and signed off on.

Once there is team agreement and a baseline created, the recovery plan will then need to be taken for approval to the board or relevant steering group. It is at this point that there will be organizational politics, push back, and a period of negotiation. In this case, IT was not able to deliver to the original timeframes, but could deliver in January at the earliest; however, there were significant risks around the testing. As this was a seasonal business, January was a peak operational time, and the prospect of undertaking a release, which could have impacted the operation at this time, was not palatable to the business. The business was not prepared to admit that they were delaying the pilot, so asked for IT to guarantee no issues. As this could not be done, the business then requested the delivery in March, which ultimately suited IT.

Due to the extended period of delivery, the budget costs rose, which impacted the business benefits. What starts out as a “must do” project may look less tempting when a revised budget has been produced, and when the real impacts of the costs and risks are factored. Many organizations will have their own fonnulas for detennining whether or not the business benefits can still be realized; however, a profit curve (Johnson, 2008, p. 2) is a valuable tool, which can show the cumulated revenue minus the cumulated costs, and can be calculated, to determine if the project still has benefit realization, as illustrated in Exhibit 9.

Exhibit 9 - Example of a Profit Curve (Johnson 2008, p2)

Project Management Skills Required

The project manager throughout this recovery process requires strong leadership, facilitation, and communication skills in order to mobilize the team and manage the senior stakeholders, w hich involves directing a wide range of characters. Kaufman et al, (2003, pp 101-102) has identified organizational change indicators to resistance, which can also align with project change, these resistance indicators are:

1. Confusion: An individual does nothing from shock of the changes
2. Immediate Criticism: A belief of mistrust sets in and these begin to criticize the effort out of fear
3. Denial: people may deny that change is necessary and hold fast to the old ways
4. Malicious Compliance: These are the silent but fatal, they keep their silence during the meeting but afterward are not following through on assignments
5. Sabotage: These individuals try to stop any progress from happening
6. Easy Agreement: These individuals do not know much about the project and seem to go along without argument or discussion (these can also wake up to active resistance when they realize what is really going on)
7. Deflection: Look at something other than the problems
8. Silence: These individuals do not sliare any of their ideas and can with withhold information
9. Anger: Those who believe they are threatened by the change and try to intervene in progress
10. Depression: Some individuals may move into a depressive mode, and the project manager should be able to deal with this health issue because it could eventually impact the project
11. Acceptance: These individuals recognize that change needs to happen and whether or not they agree they move forward and are positive forces (Kaufman et al, 2003, pp 101-102)

In a recovery situation, these indicators may also be heightened. This case was no exception and therefore a Rapid Project Recovery?[ three-step process and technique was deployed. Exhibit 4,

Potential Challenges Post Recovery

A recovery plan is only the beginning of the turnaround and delivery. Depending on where the recovery starts in the life cycle, will depend on the extent of the legacy issues and number of hidden issues that may come to the surface during on recovery. Examples of the types of issues that can occur include:

? As in this case study, the operating model for project delivery does not cater to recovery; therefore, it can be difficult to report against standard quality gates, as recovery shaping and execution are happening at the same time and not sequentially. This can lead to confusion and hours of discussion with the Project Management Office.

? Scope creep: due to poorly defined requirements, when undertaking recovery it will come to light that there is missing scope.

In tilis instance, the business project manager, who signed off on the recovery plan was removed from the project, along with 40% of the business team. The next business project manager and team were new to project management, and therefore there was a learning curve not only in tenns of project management but managing the scope and quality of deliverables, such as the training strategy.

Summary

For as many signs and symptoms there are in troubled projects, so are there approaches to recovery. In this situation, a real case study demonstrated the success of a simple three-step process and technique, which can rapidly deliver the turnaround of a troubled project. There are many areas to address quickly in trying to recover a troubled project, including tangible hot spots in documentation and communication; however, a good project manager needs to also be cognizant of the intangible barriers to recovery project success—the team. At the heart of this technique is the ability of the project manager to develop, motivate, and build a highly perfonning team, which is essential to the recovery execution. In this case, the pilot was delivered successfully on time.