Managing Distressed Projects

,

In general, there are two types of strategies for dealing with distressed projects. Every project that becomes distressed was once not in distress, and there are prevention strategies to minimize the likelihood of projects becoming distressed. Despite your diligence, the prevention strategies might not work due to prevailing conditions beyond your control, and your project will still become distressed. If this happens, there are intervention strategies that you can use. This section describes both strategy types.

Prevention Management Strategies

Prevention strategies are proactive practices and processes that you can employ to significantly reduce the number of projects that become distressed. For the typical company situation, you may be able to enhance some of the processes covered previously in this book to decrease the likelihood of a project becoming distressed. These enhancements are briefly discussed in the next subsection.

Again, it is not possible to eliminate all projects from falling into the distressed category, but you can significantly reduce their numbers. In establishing your prevention strategies, you have to take your efforts to the next level. Considering the high failure rate of projects, I suggest that you take some of the actions described in this section with every project. If for some reason you find these efforts burdensome to do on every project, you might consider them as part of your risk management plan and be more selective in how you apply them.

Using Tools, Templates, and Processes to Prevent Distressed Projects

Although there is no guarantee that prevention strategies will actually prevent a project from becoming distressed, they are your best protection against such an outcome. In this section, I discuss some specific prevention strategies you might use to reduce the likelihood of a project becoming distressed.

You learned about the following six processes earlier in this book, which are also irreplaceable tools for formulating prevention strategies:

• Requirements gathering
• Work Breakdown Structure (WBS) construction
• Dynamic risk management process
• Scope change management process
• Milestone trend charts
• Earned value analysis

These processes are briefly discussed in the following subsections with a focus on prevention strategies.

Requirements Gathering

Knowing that complete requirements documentation is difficult if not impossible at the beginning of the project, you should take extra care in identifying the list of requirements. As project complexity increases, the task is even more difficult mostly due to the dependence between requirements becoming more complex. Factor the client into that experience, and the difficulty increases even further. The client may be relatively inexperienced in identifying requirements and doesn't seem to engage in the process with the enthusiasm and commitment you would like. Perhaps a workshop approach makes sense. All of these factors suggest using a PMLC model that is closer to the APM, Extreme Project Management (xPM), and Emertxe Project Management (MPx) end of the project landscape than you might have otherwise selected. Err on the side of being more suspect of the completeness and accuracy of the requirements. As the project commences, you may find reason to move back toward the Adaptive and even Iterative end of the landscape and use a different PMLC model.

The issue to consider here is completeness and clarity of the Requirements Breakdown Structure (RBS) and what PMLC model is the best fit for such a project. Be cautious in your choice of PMLC model. Make sure you are not backing yourself into a corner by making assumptions about solution content and committing to something that won't work. Err on the side of pessimism rather than optimism, and you will be on safer ground. Say that all signs suggest that the project can be managed using a Linear or Incremental PMLC model. For this project, the safe ground might be to use an Iterative PMLC model regardless of your confidence in the defined solution. You may have some history working with this client on previous projects. That will be a big contributor to your decision on the best-fit PMLC model.

If the project has never been done before (for example, one that involves the development of a new system), you might do requirements decomposition using two completely different approaches and use the results to cross check and confirm that decomposition. Once requirements decomposition has been confirmed, consider simulating the solution by building a quick prototype (not a production prototype) around the confirmed RBS. Test your prototyped solution with a broad audience of end users to further confirm the requirements.

WBS Construction

If the project is closer to the TPM end of the landscape, the Work Breakdown Structure (WBS) becomes the foundation of your choice of PMLC model. Generating a clear and complete WBS is the most difficult part of the project planning process. Building the WBS is a very intense and tiring exercise. You and the planning team will find yourselves rushing just to get the exercise over. Resist that temptation. If you felt rushed at the end, come back to the WBS a few days later. Share what you have with a trusted colleague and get that person's opinion. Objectivity is important here. Don't be afraid to criticize your work. If you don't get this part right, the risk of project failure increases.

Having a complete and correct WBS is critical to the success of a Linear or Incremental PMLC model. The entire project plan is based on the assumption that you have a complete WBS. Whatever difference there is between your WBS and a complete WBS will probably be reflected in the number of scope change requests you get. Processing those scope change requests will seriously compromise the project plan. Recall from the pain curve discussed in Chapter 5 that the maximum pain occurs in the generation of the WBS. Doing it right is just plain hard work, but you have to get it right. Don't shortchange the exercise. Do it right!

I have found that the following three strategies help me complete the WBS effort as painlessly as possible:

• Use all of the project team members and client representatives that have been identified. You need as much expertise and as many pairs of eyes as you can assemble. Bring them together in one place for a single planning meeting. Any other approach is a distant second in terms of effectiveness.
• Put the initial version of the WBS aside for a few days and come back to it with a critical eye. There will be enough loss of memory about what you did, and you should be able to approach validating it with a bit more objectivity. It's amazing how many logic faults you will find.
• Defend the WBS in front of a few respected peers who did not participate in building the WBS. They can be far more objective than you or the planning team and may find some problems with your WBS that you couldn't see.

Dynamic Risk Management Process

A lot of risk management plans gather dust on the shelf of the project manager. They were completed as part of project planning and never looked at again. Those plans that are referred to are referred to after the fact. That's too late. Effective risk management is probably your best weapon to protect the project from becoming distressed, but it has to be monitored continuously for any changes that might suggest heightened attention to one or more risks. Remember, as the project type moves from TPM toward xPM, project risk increases, and so should the intensity of your risk management efforts.

The first thing I would do is assign one of the senior members of the project team as manager of risk for the project. This individual's assignment begins with building the risk management plan during project planning. There should be a metrics-driven risk monitoring and control process included in the risk management plan. Use tight control values around these metrics to alert the team to early warning signs of changing conditions. Every team meeting should include an update on risk and recommended actions given the state of the project.

Scope Change Management Process

Scope change is the bane of the TPM project, and lack of it is the bane of APM, xPM, and MPx projects. In either case, you must have a well-defined and well-managed change management process in place. And most importantly, it must be understood and accepted by the client. In the case of TPM projects, the process must put some controls on the frequency and number of change requests. In the case of APM, xPM, and MPx projects there is a certain level and frequency of change requests that must happen, and you must put metrics in place to track that cumulative history.

Scope change is an area that often gives rise to most project problems. It doesn't really make a difference whether this is the result of doing a poor job on gathering and documenting requirements or dealing with a client who has lots of ideas. If there is no management control exercised over the frequency of scope change requests, there are going to be problems. The time to process a scope change request comes from the value-added work time of the team members, which means an aggravated schedule, errors, and ultimately, schedule slippage. The seeds of distress have been planted.

Here is an example from the case study of a change control process that you might put in place for a Linear or Incremental PMLC model. Recall that for these projects, the solution is clearly known and documented. There should be few scope change requests.

Milestone Trend Charts

The milestone trend chart introduced in Chapter 7 is one of the few metrics that I know of that looks ahead in the project schedule for expected slippages and warns the project manager ahead of time that there may be problems later in the schedule if established trends persist. This information is made available early enough in the project time line to give the project team time to analyze and correct any anomalies. The milestone trend chart is an excellent early warning system and should be part of every monitoring and control process.

Milestone trend charts are of recent vintage. I introduced them in 1995. As a protection against potentially distressed projects, you might want to consider establishing very conservative trigger values, trends, and control limits that hint of potential distressed projects. Some examples are shown in Figure 16-1 and Figure 16-2.

Figure 16-1: Conservative trend patterns to signal potentially distressed projects

Figure 16-2: Tighter control limits as an early warning of a potentially distressed project

Figure 16-1 is one example where tightening the trend pattern will get the attention of the project manager sooner rather than later. Recall that a trend in the same direction for four or more consecutive report periods signals a potential problem that could lead to a distressed project. For good reason, you might tighten that to three or more as shown in Figure 16-1. If a project displays this type of pattern, look deeper into the causes and fix them.

Figure 16-2 is an example of tightening control limits using trigger values that dictate a potentially distressed project as you reach the outer schedule of the project. The solid line in the Late section of this project shows a control limit that ranges from 8 weeks late by reporting month 1, to 4 weeks late by reporting month 7, and then to 2 and 0 weeks late for the two remaining months of the project. The issue here is that the closer you get to the scheduled project completion date, the less likely you are to be able to make up serious slippages. A two-week slippage in the first month of a nine-month project is nowhere near as serious as a two-week slippage in the last four weeks of a project. Sooner or later you can't get there from here. This is the reason for tightening the control limits as you move to the outer part of the project schedule. Without that tightening, you will reach a point where the slippage cannot be made up, and the project will fail to meet the scheduled completion date.

Earned Value Analysis

Tracking trends in schedule performance index (SPI) and cost performance index (CPI) values and displaying them in the form of a milestone trend chart is one of the most intuitive metrics that I know of for early warnings of cost or schedule problems.

Earned value analysis, also called earned value management (EVM), has been used in the federal government for nearly 50 years. Only recently has it become popular in the private sector. It was discussed in detail in Chapter 7.

As you may recall from Chapter 7, actual cost (AC), earned value (EV), and planned value (PV) yield one additional level of analysis The SPI and CPI are further refinements. They are computed as follows:

SPI = EV / PV

CPI = EV / AC

Schedule Performance Index

As you saw in Chapter 7, the SPI is a measure of how close the project is to performing work as it was actually scheduled. If the SPI is greater than 1, the project is ahead of schedule. Obviously, this is desirable. An SPI value below 1 would indicate that the work performed was less than the work scheduled — hence, the project is behind schedule. The trend in SPI values tracked over time will be an indicator of problems.

Cost Performance Index

As you saw in Chapter 7, CPI is a measure of how close the project is to spending on the work performed to what you planned to spend. If the CPI is greater than 1, you are spending less than was budgeted for the work performed. If you are overspending for the work performed, the CPI will be less than 1.

Trend plots (like the milestone trend charts) are intuitive displays of the project history with respect to schedule and cost variances from plan. These indices are displayed graphically as trends compared against the baseline value of 1.

Just to refresh your memory, the earned value terminology has changed recently. I am using the terminology as defined in PMBOK. The old terminology compares to the new terminology as follows:

• Actual Cost of Work Performed (ACWP) is now called the actual cost (AC)
• Budgeted Cost of Work Performed (BCWP) is now called the earned value (EV)
• Budgeted Cost of Work Scheduled (BCWS) is now called the planned value (PV)

Integrating Milestone Trend Charts and Earned Value

Using both milestone trend charts and the EV for a project provides you with yet another early warning sign of potential distress. Chapter 7 gave several graphical examples of how the milestone trend chart format could use the SPI and CPI trend data to alert the project team of potential distressed project situations. To use these graphical tools, you should establish boundaries for the plots. Any trend line outside of the boundaries would trigger some form of corrective action to be taken.

Intervention Management Strategies

Despite all of your protections against a project becoming distressed, it may still happen. Depending on the seriousness of the situation, you may postpone any further work on the project while corrective actions are formulated and implemented in a revised project plan. For less serious situations, and because of resource constraints and previous schedule commitments, you might continue the project work while a resolution is defined and implemented.

Intervention occurs when the project has been deemed to be in distress. Intervention is a four-step process as defined in Figure 16-3.

Figure 16-3: The intervention process

I answer each of the four questions shown in the figure in the sections that follow.

Analyze Current Situation: Where Are We?

Once a project has been determined to be distressed, the current status of the deliverables should be determined. A chart like the one shown in Figure 16-4 will be helpful. This is the starting point for further analysis and eventual re-planning of the distressed project.

Figure 16-4: Current deliverables status

The next question to be answered is just how serious this out-of-control situation is. If it's not serious, maybe it will self-correct. If it's serious, some intervention may be needed. How do you know what must be done and what form that intervention might take? That is the topic of this section. There are several ways to approach the analysis of the situation. The most useful tool for analyzing causes of distressed projects is Root Cause Analysis.

Knowing that an undesirable situation exists is the starting point for Root Cause Analysis. Root Cause Analysis was discussed in detail in Chapter 15. Root Cause Analysis is represented as a hierarchical chart and is very intuitive. Starting from the top, the structure and terminology of Root Cause Analysis is as follows. At the top is the problem statement. The only restriction is that it must be a single problem. It must be clearly stated. Avoid jargon or terminology that might not be understood by anyone who might have the occasion to read it. The second level consists of one or more reasons that might have brought about the distressed condition. You must have the assurance that the reasons you state really are the reasons and not someone's conjecture. The reasons should be commonly accepted by the organization so that they do not need to be defended. The next several levels are “why” questions. There may be more than one “why” question per reason and more than one answer per “why” question. The answer to one “why” question gives rise to one or more additional “why” questions. At some point in this hierarchy, an answer becomes a statement for which no further “why” question makes sense. That statement is a root cause. You can expect to discover several root causes for the distressed condition.

In the experience I have had helping my clients manage distressed projects, there seems to be a pattern as to the road to defining a root cause. These are identified and briefly discussed in the following sections.

On the Road to Root Causes — Project Conception

Innocently buried in the Idea Generation Phase of several of the agile PMLC models discussed in Chapter 11 are the seeds of the project distress factors. These factors include the following:

• The project is based on an unrealistic business case.
• The project is based on executive leverage.
• The client cannot clearly define objectives.
• The project is based on state-of-the-art and immature technology.
• There is lack of client ownership.
• The client's funding or timescale is unrealistic.
• There is a failure to decompose the project into smaller feasible steps.

The first three factors are usually associated with wants, not needs. That reinforces your questioning of the client as to why they want what they want. If that is not defensible for any of the first three factors listed here, you have the makings of a distressed project. You need to take remedial action right then, during project inception, to avoid the possibility of the project becoming distressed later for any one or more of these three factors.

If the project will use the latest and greatest technology, you might not be equipped from a staffing perspective, and the project will be exposed to staff shortages or become too dependent on outside vendors. I have always stressed the importance of meaningful client involvement, and that involvement increases as you move from TPM to APM to xPM projects. As I have already discussed, the latest results from the Standish Group in their CHAOS 2010 survey report lists lack of User Involvement as the major reason for project failure. As I have commented in several places, for several years now, and at the risk of being repetitive, I can't stress enough the importance of meaningful client involvement. The extent to which you will or will not have meaningful client involvement is the driving factor in your choice of a best-fit PMLC model. I have had cases where the best-fit PMLC model required more client involvement than I could expect from my previous projects with the client. Workshops either before or during the project are highly recommended. Take the time to prepare the client for their roles and responsibilities. It will have good payback. When funding and time are unrealistic, it is usually related to the project scope being out of line with the time and cost. As you have already learned from the scope triangle presented in Chapter 1, scope, time, and cost are a dependent set. Specify any two, and the third is defined. This factor is usually a result of the client specifying all three and expecting a satisfactory result. It will never happen!

The size of the project is positively correlated with risk. The longer the project, the higher the risk of its becoming distressed. Project duration should be less than a calendar year and not span more than one fiscal year. If you have durations that are longer than that, I strongly advise decomposing them to more manageable lengths.

On the Road to Root Causes — Project Planning and Initiation

There is always the impatience to get going, and planning takes the back seat. Because of the high change environment that most projects find themselves in, many say that planning is just a waste of time. If that is the attitude of your client and your team, you have a problem and had better deal with it up front. Otherwise, your reward will be failure or at least a distressed condition. Here are some of the planning related reasons I have seen for distressed conditions on projects:

• Unrealistic cost, time, and capability estimates
• Failure to clearly define requirements
• Poor client/team relationships
• Poor scoping activities
• Lack of meaningful client involvement
• Poor WBS specification
• Unreliable risk management plan
• Poor planning
• Failure to clearly define roles and responsibilities

The first factor may be more related to the organization's steak appetite on a baloney budget. Capability is a human resource issue, and too many organizations overlook capability and the availability of skilled human resources when they approve a project. Resource contention, too much task variety, and mistakes are the result. All of these contribute to the occurrence of distressed projects. The Graham-Englund Model that I discussed in Chapter 14 must be used in deciding whether or not to add a project to the portfolio. Too many clients and teams do not give the attention to requirements gathering that they should. They are too quick to accept a requirement without the due diligence needed. The temptation to say “We'll deal with the details later in the project” is planting the seeds for distressed conditions. Take the time up front to do your best. It is worth the investment. During the Launching Phase, spend the time to build the project team and that means the client members as well as the development team. Their work environment needs to be open and honest, and you have to do whatever you can to establish that environment. Again it is worth the investment of time up front. As you move from TPM to APM to xPM projects, the WBS becomes less of a factor to initial planning, but that doesn't mean you can slack off on your efforts to build the WBS. Many of the APM and xPM PMLC models require a partial high-level WBS during the Scope Phase and partial detailed WBSs for the functions and features chosen for a cycle or iteration. If you can't get the WBS correct, the entire project plan or cycle plan is not built on a solid foundation. Risk management becomes more important as you move from TPM to APM to xPM projects, and your efforts to do risk management planning and monitoring should be heightened.

On the Road to Root Causes – Solution Definition

Many projects do not start out with a complete solution definition, so there is a high risk of project failure. These projects are complex, and there is a great deal of uncertainty associated with them. Here are some of the reasons I have seen repeatedly on these APM and xPM projects:

• Failure to apply appropriate scope management
• Poor choice of a technical platform or architecture
• Starting a phase prematurely
• Poor choice of requirements definition approach
• Poor preparation for requirements definition
• Lack of proper review
• Lack of skilled resources
• Poor standards deployment
• Poor requirements traceability

In any APM or xPM project, processing scope changes is relegated to the checkpoint that occurs at the completion of each iteration, cycle, or phase. These checkpoints are the heart and soul of every APM and xPM project, and must be taken seriously. The decision to continue and in what direction is the most important decision you have to make in these types of projects. You need to have the meaningful involvement of your client as well as the flexibility and ability to support a variety of requirements gathering approaches. The characteristics and experiences you have had with the client are major determinants in deciding how to gather requirements. Don't take the client outside of their comfort zone if you can help it. If you have to, make sure they are properly prepared to do so. That probably means training either beforehand or concurrent with the requirements gathering exercise itself.

On the Road to Root Causes – Solution Development

TPM, APM, and xPM projects all have potential problems as they try to develop the solution. Here are some of the frequently occurring reasons that I have observed:

• Technology advances overtaking the project
• Lack of proper change control
• Inadequate training and supervision
• Inadequate client review
• Poor management of outside contractors
• Lack of formal testing and integration approaches

The project is underway, and a new technological breakthrough is announced. You can ignore it and continue as planned, or you can stop the project and re-plan. What do you do and why? Whichever decision you make, there are cost implications. Adopting a new technology into a project that is already underway can be disastrous. Your capability to adopt the new technology is probably limited, because you will not have had previous experience with it. You may need to use outside consultants. On the other hand, ignoring the new technology can have severe market implications if your competitors have adopted the new technology and you haven't, because they will now have a competitive advantage in your markets. Client review is critical in APM and xPM projects. That review must be open and honest. If the client is unwilling or unable to push back, or if you can't push back, bad decisions are going to be made. The project will become distressed.

On the Road to Root Causes – Solution Implementation

I've seen so many examples of clients not taking the time to plan and implement the solution. All they are doing is laying the foundation for failure. Here are some reasons that I can recall:

• Inadequate client or end user training and support
• Catastrophic failure with no mitigation plan
• Missing a critical go-live date

The Closing Phase of any project should include implementation of the deliverables and handoff to the maintenance and support functions. This is part of the WBS, so it must be part of the project proposal. The establishment of a user training and support function in advance of implementation and handoff is often an afterthought rather than part of the project plan. To avoid catastrophic failure after implementation, some project plans include a warranty period — three months is typical. At the end of the warranty period, the deliverables are formally released to maintenance and support. That makes for a good mitigation plan.

Revise Desired Goal: Where Can We Go?

Taking all of the previous root causes into consideration, the project team needs to figure out whether they will go forward with the project, and, if so, how to go forward. The first step in that decision is to revise the original project goal. That might be straightforward or very complex given the extent of distress in the project and the criticality of the project. Maybe the project should be decomposed into several shorter-duration projects. Maybe the project should be abandoned and restarted at a later date in an entirely different direction. The process defined in this section of the chapter can work for all extremes — from minimal change to totally revised projects.

The Workshop

One highly recommended option is to hold a workshop to redirect the project. Analysis of a distressed project is a group activity. Speed is of the essence, because the project is in trouble and may still continue in that direction while the intervention process is underway. The following list describes how the ideal workshop environment should be configured:

• Hold the workshop offsite at a comfortable hotel.
• Have a good restaurant nearby.
• Book a large room with lots of whiteboard space.
• Have several flip charts.
• Have breakout rooms for private discussions.
• Use an experienced outside facilitator.
• Agree on the ground rules.

Remember that the project may be on hold while you and the project team try to figure out how to get it back on track, so the workshop needs to be planned and executed quickly. The workshop itself will probably be a tense session. The project is distressed for some reason or reasons, and the client will probably have to give up or postpone getting some features and functions. They won't be happy, especially if they see this distressed condition as your fault.

The Process of Revising the Original Goal

In order to revise the project goal, you follow the process depicted in Figure 16-5. The sections that follow discuss the process depicted in the figure.

Figure 16-5: The process of revising the original goal

Reviewing the Original Business Goal

Requirements descriptions must be reviewed to determine if they are essentially complete and relatively stable. As in all projects, there are both fixed requirements and evolving requirements. Fixed requirements are nice — straightforward and relatively easy to satisfy. Evolving requirements are much more delicate and are usually those that drive the project outside its boundaries. To go one step further, you and the client must determine whether or not there are any high-level requirements that need further refinement or if there are any requirements in the TBD (to be determined) category. These must either be defined or eliminated, because undefined requirements are difficult to track at best and tend to yield scope creep. There are three parts to the process of reviewing the original business goal, as follows:

• Reviewing the original business case
• Defining the current business needs
• Realigning the business case to current business needs

Reviewing the Original Business Case

In order to get the project approved for planning and then approved for execution, you and the client had to prepare a Project Overview Statement (POS) and project proposal. What did you do to justify that the project had acceptable business value to proceed with it?

Defining the Current Business Needs

There is no reason to expect the current business situation to be the same as it was when the project was originally defined and planned. The project itself is different than was planned simply because it has drifted into a distressed situation. The business climate has changed as well. These two factors influence the project going forward and must be accounted for in the revised project goal.

Even if only a few weeks or months have passed since the project began, there is a high probability that the world is different now than it was before. That opens the potential for a change in business needs. Document the current business needs and compare those to the original business needs. The variance between the two has to be resolved in order to update the business case.

Realigning the Business Case to Current Business Needs

How does the variance between the original and current business needs impact the original business case? Revise the business case if senior management requires such revision so that the revised business case aligns with the current business needs.

Taking all of these factors into consideration, the original business goal is revised to reflect the current situation.

Preparing a List of Corrective Actions

Depending upon where the project was in the PMLC model when it became distressed, you can take different actions to resolve the causes that led to the distressed condition. They are listed and briefly commented on in the following sections.

Corrective Actions — General

These are global corrective actions that apply across the entire PMLC model. They include the following:

• Strengthen, replace, or reorganize management where needed
• Implement improvements in the deployment and test environment where needed
• Consider redistributing work to commercial off the shelf (COTS) vendors

Corrective Actions — Requirements

It almost goes without saying that these corrective measures will result in a restriction of functions and features. The list of possible corrective actions includes the following:

• Establish a client-based scope change request process.
• Remove functionality where the business case is weak.
• Prioritize functionality (MoSCoW).
• Review requirements for any package customization.
• Prioritize functionality by business unit and remove functions as required.

Corrective Actions – Design/Develop/Integrate

These corrective actions apply inside the iterations, cycles, and phases. They include the following:

• Review the solution for more use of commercial off the shelf (COTS) software.
• Partition the project work into swim lanes for schedule compression.
• Consider incremental releases.
• Simplify interfaces to external applications.

Corrective Actions – Testing and Implementation

Although these could have been included in the general corrective actions list, I chose to separate them because they are quite different. This list includes the following:

• Consider incremental user testing.
• Use pilots for early release.

Evaluate Options: How Can We Get There?

The process for evaluating options is shown in Figure 16-6.

Figure 16-6: The process of evaluating options

Brainstorm Potential Project Options

This step involves the client and the project team. It begins with a review of the Root Cause Analysis results. For each identified root cause, brainstorm a list of possible remedial actions. Then identify the possible project options given that the remedial actions have been taken.

Prioritize Options

The client and the project team must now arrange the options in priority order. The priority is based on the business value of each option.

Conduct a SWOT Analysis

The prioritized list of options is now subjected to a Strengths, Weaknesses, Opportunities, Threats (SWOT) analysis. The SWOT analysis should address the following areas:

• The degree of PSO support offered to the project team throughout the PMLC model for this option
• The skill and competency profile of the team with respect to this option
• The degree to which the client has been meaningfully involved in the project and will be able to support this option
• The contents of the Scope Bank related to this option

Frame the Get-Well Plan

How are you going to approach the revised project? Will you use the same PMLC model as originally used, or is there some reason to reconsider that decision? If there is a PMLC model that will deliver intermediate results more often than the current model, you should consider switching to it. This might require the revision of timeboxes and deliverables allocated to each increment, iteration, cycle, or phase.

Is the Revised Business Case Feasible?

The answer to this question determines whether or not the project will go forward in its revised version. Just as the original business case was used to commission the project, the revised business case is needed to continue the project as revised. In its revised form, it may not make business sense to continue the project, and it will be terminated. Conversely, the possibility of continuing the project in some other revised form may make sense, so the project team will return to the drawing board to craft another revision. Scope reduction is often the way out. In other words, the revised business case addresses only part of the requirements. The unmet requirements from this version may be left for a later version.

If the revised business case does make business sense, then approval is granted to proceed to the Planning Phase. This is exactly the position of a project that was proposed following the normal process — submission of a POS.

Generate Revised Plan: How Will We Get There?

Using the results of the SWOT analysis, put together a high-level plan showing milestones, what will be delivered, and by when. The plan should also include the budget impact on both the client and the project team.

The three steps for creating a new plan to bring the distressed project back to health are the same steps you used to first plan and launch a project. They are as follows:

1. Prepare a revised project plan.
2. Get management acceptance of the revised plan.
3. Prepare to restart the project.

Prepare a Revised Project Plan

This activity begins with the revised business case and updated deliverables list as input to the planning steps that consist of building the WBS (deliverables-based); estimating the duration, resource requirements, and labor; creating dependency diagrams; and scheduling. The revised plan should be prepared as a collaborative effort with the client fully participating. Their buy-in is essential, and you won't get it if they are not part of the process.

Get Management Acceptance of the Revised Plan

Management won't be too happy about this whole experience. The original goal will probably not be met. A compromise is offered in the revised plan. Management's approval here is no different than it was for the project when it was first proposed. The only difference is that management now has a bad taste in their mouth over the failure to-date on this project, so they won't be as easy to convince this time. Their support is the highest-priority critical success factor for any project intervention.

Prepare to Restart the Project

The launch activities for an intervention are the same as those for a first-time project launch. Hopefully the same team is in place, so team operating rules are already in place. These rules may need to be tightened because of the higher risk that this distressed project will be exposed to. Some of the important tasks include making sure of the following:

• The team's skills and competencies are correctly aligned with the revised project plan
• There are clearly defined and assigned roles and responsibilities for each team member
• A revised risk management plan is in place and assigned to a team member
• A more finely tuned monitoring system is in place to detect minor trends in schedule or cost variances

An Intervention Process Template

For those of you who like to use templates here is one that I have found particularly useful as a starting point for an intervention. In the absence of details on the project situation, it helps structure your thinking as you begin an intervention. It is an eight-step template:

Interventions are not easy. The entire project team and even the client are put in defensive mode. If you are the intervention team manager, you have to be very careful how you interact with the team. To the extent you can, you have to make them your allies. In general, the closer you can keep them to you the better off you will be.