Abstract
As project managers, we frequently have an ambiguous attitude toward a troubled project. On one hand, on a personal level a troubled project is demanding, with unfulfilled expectations, pressure, conflict, and hard work. On the other hand, it requires us to practice the best of project management: establish direction, prioritize issues, gather people around a common objective, negotiate objectives, and solve problems.
This paper suggests an approach for identifying and dealing with troubled projects with confidence and control. The approach deals with redefining project objectives and identifying and fixing problems across people, process, and product dimensions. The rescue process is broken down into distinct phases to improve control: mandate, assessment, definition, intervention, and transfer. Many of the suggested techniques were developed through trial and error by progressively customizing classic project management approaches to a crisis environment.
Introduction
Understanding troubled projects
The meaning of trouble
Standard project management practice uses a combination of project objectives and value to define project success. Objectives should be defined in terms of scope, schedule, costs, and quality in order to be feasible, verifiable, and integrated. But objectives must also be aligned with value, from both the customer and the supplier perspectives. Through a combination of science and art, integration and communication project management processes try to keep these dimensions aligned during the project life cycle.
This perspective on project success can help us clarify the meaning of a troubled project. A project would be considered troubled, if accumulated or estimated variances can compromise the value delivered to one or both parties of the project.
Exhibit 1 –Project success and project trouble
From a customer's perspective, a project could be in trouble if the product is not aligned with its business need. Maybe the product does not perform against its requirements or it might be plagued with errors, limiting its usability. Or maybe the product complies with specifications but does not adhere to changing market requirements. The customer would also classify a project as troubled if schedule variances threaten to compromise the required time to market, or if the cost of change requests jeopardizes the project business case. From the supplier's perspective, a project could be in trouble if an unfavourable cost variance can compromise the project's financial return. Risks to company reputation, team morale, and fear of legal action, can also be good reasons for a supplier to classify a project as troubled.
Exhibit 2 – Tolerances and variances
The meaning of failure
Projects fail when accumulated or estimated variances go beyond a tolerance limit, when they are neither acceptable nor recoverable. A troubled project is not a failed project but it has a distinct possibility of becoming one if appropriate measures are not implemented.
Projects can fail at every phase of their life cycle. Some projects fail during their conception, because they are based on an unrealistic business case or unsound technology. Other projects fail during planning by accepting unfeasible objectives. Other projects fail due to poor technological solutions or because they do not adequately control changes. Projects can even fail at their very latest stages, due to lack of acceptance criteria or poor scope verification.
Understanding the roots of trouble
Troubled projects are often results of poor project management processes or poor process implementations. But following good project management practices does not guarantee project success. People or product-related problems, like team knowledge, project management experience, and solution complexity might also compromise the project outcome. At the organizational level, factors like management and user support can also influence project success. Outside the organization, market and economic context may lead to frequent changes or impose budget and time constraints that can put the project in peril.
The trouble with trouble
On a troubled project typically there isn't just one problem, but several underlying problems. These problems tend to be complex, multidisciplinary, and interdependent. For example, the absence of a change control process can generate problems throughout the project. Changing scope without changing other constraints will place an increased amount of work on a limited amount of resources and time. The additional scope will place strain on the team and may lead to an increase in product defects. This combination of changes, pressure, and defects can strongly limit or even inhibit project progress. Even with an integrated change management process, significant changes in the product scope may stall the problem, inducing the addition of a lack of progress problem.
Exhibit 3 – Example of a poor change control process
Lack of progress creates new challenges. It may be perceived by the customer as team incompetence and may lead to conflict and raise trust and motivation issues.
Exhibit 4 – Lack of progress spiral effect
Another example of how a problem can spread from the process to the people and product dimensions is an unrealistic deadline. Such constraint generates too much pressure on the team and can lead to sacrificing quality and overtime work, which can lead to morale, productivity, and progress problems.
Problems can be particularly endogenous when the people side of a project is affected. Following are some examples of how people problems can influence other project dimensions:
- Pressure on the team generates additional errors and lack of progress;
- If people believe that the project will go off track, it is more likely that they will negatively impact project performance (self-fulfilling prophecies);
- If the project objectives are unrealistic, most people will not try to achieve them;
- Lack of progress can limit management support, and lack of management limits progress;
- Conflict and trust issues may lead the supplier to scope creep to avoid conflict;
- Past overruns can be used to justify future overruns;
- People overreact in troubled projects; and
- People may believe that they were treated unfairly and may be unwilling to compromise.
Understanding project rescue
The meaning of rescue
The project is in trouble if accumulated or estimated variances compromise the value delivered to any side of the project. If a project has accumulated significant or multiple variances, it is not likely that all initially established objectives can be met. Project and product scope can be reviewed, and timeline and budget can be extended. Furthermore, revised objectives must be periodically monitored until proved feasible.
Exhibit 5 – New objectives scenarios
But reviewing and stabilizing objectives are not enough. Only by changing the trouble root causes can future variances be prevented. Remedial actions are probably required on the people, process, and product dimensions. Furthermore, actions may be recommended to respond to identified threats and opportunities. Examples of rescue remedial actions and risk responses include:
- Fixing a defective product;
- Implementing process improvement;
- Acquiring additional resources; and
- Completing absent or inadequate project management documentation.
A project rescue is a structured combination of sustainable negotiation, corrective actions, and risk responses on a troubled project in order to maximize value to all parties.
Suggesting a rescue framework
Simple project adjustments might be feasible in relatively small troubled projects. In larger projects, the complexity and nature of problems, strongly recommend that a rescue be treated as a project. This paper suggests a structured approach for dealing with troubled projects, broken down into distinct phases:
- Mandate — Formally recognizes that the project is in trouble and commits to fixing it. Authority and support are obtained to manage resources, reset expectations, negotiate objectives, and implement fixes.
- Assessment — Assesses the project, based on documentation, questionnaires, checklists, and interviews.
- Definition — Redefines the project, setting a new preliminary scope, schedule, and budget. Processes, teams, and communication are redesigned to fit a rescue process.
- Intervention — Implements remedial actions and risk responses. Monitors the troubled project until meaningful and credible baselines can be established.
- Transfer —Transfers the responsibility over the rescued project and closes the rescue process.
Exhibit 6 – Project rescue approach
Although the approach has distinct phases, some overlapping may occur. Such are the cases of fixes and opportunity improvements that often must be dealt with as soon as possible. The suggested phases and deliverables are not specific to any application area or any project life cycle.
Identifying Troubled Projects
The trouble with identifying troubled projects
While approaching troubled projects, an early rescue is essential. Delaying an intervention, will increase exponentially the effort required to correct the variance. Using earned value management terminology, the project To-complete performance Index (TCPI) increases geometrically with time. The TCPI indicates the future required cost efficiency to achieve the project Budget At Completion (BAC). The project TCPI is calculated as (BAC-EV)/(BAC-AC), where EV is the project Earned Value and AC is the actual cost.
Exhibit 7 – Exponential growth of correcting variances
Nonetheless, trouble is usually recognized late in the project life cycle, compromising the extent of the rescue. The reason behind this late acknowledgment is that organizations judge trouble by accumulated variances, and such variances are not easily detected due to poor project management processes and human nature.
The reasons why poor control processes delay the acknowledgment of variances include:
- Past performance may not be used to forecast future performance. Even worse, projects often forecast that past variances can be recovered;
- Without specific rules to measure progress on ongoing activities, progress may be assessed as a percentage of time passed or budget spent;
- The remaining work at the end of each activity is usually underestimated (Pareto's law);
- Work performance information may not be properly or timely accounted;
- Excessive, or poor quality data, might inhibit management reaction when a true variance is detected; and
- A poorly decomposed WBS makes it difficult to assess progress (tunnel effect).
The reasons why human nature may, voluntarily or not, delay the acknowledgment of trouble include:
- People deny variances because they wish reality was different;
- People anchored to past decisions may feel reluctant to change opinion;
- People might suppress problems for fear of blame or penalty;
- People might delay the start of the more complex and uncertain activities (student syndrome); and
- Lack of accountability may lead into situations in which everyone is feeling that it is not his or her problem.
Watching for symptoms
Although project variances are not easily detected and acknowledged, there are symptoms that could help in recognizing trouble. These symptoms are manifestations of underlying problems that might not be visible. Detecting these symptoms does not mean that the project should be rescued. It does mean, however, that further analysis should be conducted on the project root-cause problems.
The following exhibit summarizes some of the main symptoms and potential causes that can be detected on project management documentation and human behaviour.
Exhibit 8 – Symptoms and Causes
Mandate Phase
Establishing a mandate
The main objective of a mandate is recognizing that the project is in trouble, accepting that objectives must be reviewed, expectations need to be reset, and problems fixed. A rescue mandate does not itself revise objectives. These should be revised later on. The role of the mandate is establishing which objectives are really constrained and which are negotiable. To set priorities for future negotiations, the project mandate should define:
- If the project scope, product scope, and quality requirements can be reviewed and to what extent;
- What is the project deadline;
- What is the budget constraint;
- Constraints that affect planning decisions, such as resources available and external events; and
- Priorities between project objectives.
From the very onset of the rescue, the project manager requires operational authority to acquire, manage, and release team members, and to implement new processes and approaches, but the project manager must also have executive authority. Stakeholders expectations need to be managed and objectives negotiated and renegotiated. The project manager is not the only one requiring authority. A new approach will be implemented and will likely face scepticism, fear, and resistance. Management should use the mandate, to lend their authority to the new approach and provide confidence that it will bring about a positive outcome. A mandate should also identify the information requirements used during the assessment phase.
Establishing roles
A mandate should identify the rescue project roles. The following roles should fit most project organizations:
- Rescue project manager – Manages the project during the rescue. Preferably, should not have been involved previously on the troubled project, to avoid preconceptions, biased perceptions, and prejudice.
- Project manager – Manages the project after the rescue process is complete. Should be mentored during the rescue process to smooth the transfer of the responsibility, once the project has been stabilized.
- Steering – Advisory group, which includes high-level stakeholders who provide guidance, key decision making, control, and protection over the project.
- Supplier and customer sponsors – Own the project resources, budget, and results and are the main representatives for the supplier and customer sides.
- Customer – Receives the final product. Is often accountable for defining and verifying scope.
- Suppliers – Third parties that provide products or resources to the project.
- Customer team – People from the customer side who perform scope definition and verification activities.
- Supplier team – People from the supplier side who build the product.
Assessment Phase
Developing an assessment
Negotiating new objectives is not enough to rescue a project. If the rescue process does not deal with the trouble root causes, the project may fall back into trouble as soon as the problems resurface. An assessment should be conducted in order to get a full picture of the process, people, and product dimensions of the project.
The proposed assessment report is elaborated through activities that are often performed concurrently and iteratively:
- Review documentation — The process starts by analyzing the main project management documents including: WBS, scope statement, contract, schedule, network diagram, histogram, issue log, defect log, change request log, risk register, subsidiary management plans, lessons learned, status reports, and meeting minutes. Some of these documents may be incomplete or not even exist. The project rescue should include time to produce or complete these documents. Checklists can facilitate the assessment.
- Distribute questionnaires — Specific questionnaires should be distributed to the customer, team, management, and suppliers, to look for symptoms of poor morale and communication, disruptive behavior, and unmanaged expectations. They can also clarify adopted processes, determine if they were implemented, and are being followed. On the product side, questionnaires can raise issues regarding requirements, solutions, approaches, technology, team knowledge, and skills. Questionnaires and checklists can help to prepare a draft of the project problems, threats, and opportunities.
- Conduct interviews — Based on the preliminary findings, the rescue manager can conduct interviews, preferably face-to-face and individually. These interviews have different objectives:
- Improve trust and communication, by listening, avoiding preconceived ideas, and blame;
- Identify issues that could not be identified on project management documentation;
- Prioritize previously identified problems, threats, and opportunities;
- Clarify roles and responsibilities that may look ambiguous or contradictory;
- Identify and remove obstacles felt by team members, generating both productivity and trust;
- Collect potential corrective action and risk responses; and
- Collect impressions on what people expect of the rescue project manager.
- Prepare an assessment report — The report prioritizes problems and threats, along with product, people, and process improvement opportunities. It should also include the completed checklists and guidance on whether to proceed, freeze, or cancel the rescued project. The assessment report does not include remedial actions or risk responses. Those will be identified later on the process; however, a fast track approach might overlap the rescue phases, anticipating the planning and implementation of such actions.
Definition Phase
Redefining the rescued project
The first step in redefining the project is identifying all the potential work. Potential work can include contracted deliverables, approved change requests, scope creep, errors corrections, remedial actions, risk responses, process improvements, and missing project management documentation.
The second step is establishing a reference scenario, made of contracted scope and contracted change requests. It is very likely that this reference scenario is unacceptable. There may be critical scope and quality gaps or its schedule and budget may not adhere to identified constraints.
Starting from the reference scenario and its impact on schedule and budget, the rescue manager can negotiate alternative scenarios by adding and removing scope according to priorities. At the end of this negotiation, the project should adopt a commonly accepted scope, schedule, and budget scenario. This scenario should fit the mandated high-level objectives and constraints and take into account customer satisfaction in the long-term. Further negotiation might occur should the scenario prove to be unfeasible, by adding or removing scope or by reviewing the project constraints.
Planning the rescue process
Rescue priorities
A rescue management plan defines the approach, schedule and budget, transfer criteria, and plans the adopted processes once the rescue is completed. The rescue approach should aim to:
- Establish command and control — A troubled project needs direction and control. This can be achieved through a combination of techniques, like reducing control cycles, using micro plans, changing control processes, and controlling the communication channels.
- Improve communication — Improving communication is a broad concept, because every project management process involves some degree of communication. In a troubled project, consideration should be placed in increasing transparency, streamlining, and controlling communication.
- Stabilize the product — In troubled projects, stabilizing the product can be more important than making progress. Only when the product is relatively stabilized, should the team focus on progress. If the root cause of the defects is an unstable or unfamiliar technology, the project manager should consider changing it to a more familiar technology.
- Improve team performance — Poor team performance may have a combination of root causes, including insufficient or inadequate resources, unstable resource allocation, lack of business or technical training, lack of tools, lack of compromise, low morale, confusion, pressure, and burnout. Actions should be taken to improve team relations, accountability, direction, inspiration, and buy-in.
- Fix processes — New processes can be implemented and existing processes fixed. Particularly important is making sure that a strict change control process is in place. Generating an early win could smooth the rescue process, by helping to establish confidence and reducing resistance to change.
Micro plan
A micro plan is a detail-level, short-term plan, in which the deliverables are decomposed into small and verifiable activities, preferably with a maximum duration of one or two days. Whenever possible, micro plans should decompose activities until activities can be performed by one person. Further effort to avoid multitasking can increase individual productivity and accountability. Although the micro plan is used to detail project activities, it does not require extensive maintenance work, because it only represents deliverables with ongoing work.
A tabular format should be used, instead of a Gantt chart, to increase flexibility. A micro plan is a flexible tool because it does not follow formal planning and controlling procedures, like dependencies maintenance, resource allocation, and baseline changes. The micro plan supports an approach in which individual direction takes precedence over team direction, and short-term takes precedence over long-term.
Macro plan
A macro plan is a high-level project plan that includes status and forecast information. Unlike a typical project plan, a rescue process macro plan does not establish baselines. Preliminary estimates are progressively reviewed until credible baselines can be set. Combined with the micro plans and adopted project metrics, the macro plan should help to establish command and control and regain trust.
Communication plan
The following communication guidelines can assist while preparing a communication plan:
- Wide control cycles reduce communication costs and implement some degree of management by exception approach. In troubled projects, widespread problems, recommend introducing short control cycles to improve control over work.
- Communication between team members and external stakeholders that is not required to perform their work should be channeled though the project management team to avoid scope creep and gold plating.
- Meetings should be previously approved to avoid interruptions and should also follow an agenda and be documented in meeting minutes. Before holding meetings with the steering committee, meeting agendas should be shared and discussed previously to manage expectations, reduce conflict, and improve the meeting effectiveness.
- Meetings with team leaders and key team members should be held daily to review the project detailed status. Meetings with key decision makers should be held daily or every two days, to report status and close issues. Meetings with the steering committee can be held weekly or biweekly until the level of control has improved.
- Project management documents such as status reports, plans, risk registers, and issue logs should be simple, easily accessible, prepared, maintained, and understood. Documentation involving external vendors should be simple but support traceability with contract deliverables.
Planning teams for war rooms
Decisions to improve the team overall performance may include:
- Removing the organization obstacles that prevent the allocation of resources according to plan;
- Acquiring more people with the skills needed;
- Changing the allocation and timelines of existing resources;
- Releasing resources that are not appropriate;
- Redefining roles and responsibilities;
- Acquiring required tools;
- Collocating the team into a single location to improve communication and team spirit;
- Cancelling overtime and planning allocation using a more feasible work ratio;
- Elaborating or validating estimates with the team;
- Reducing multitasking; and
- Considering a short break.
Intervention Phase
Understanding the rescue control process
With a revised scope, schedule, and budget it's now time to implement remedial actions and start making progress. During the intervention phase, the rescue control process will be implemented and repeated in short-term cycles until the project proves it can meet planned progress sustainably.
Work performance information is collected, micro and macro plans are updated, project documents are maintained, project metrics are analyzed, and performance is reported. Like any other project, the project management plan specific to the rescue process should be updated to reflect changes on adopted procedures, schedule, and budget. When the project reaches established criteria, the project baselines should be implemented, and the transfer of the project propriety should be initiated.
Collecting work performance information
A routine and frequent, collection of performance data is critical for a project rescue process. Work performance information can include the start and finish status of scheduled activities, estimated completion dates, actual and remaining work, resources used, variance root causes, and percentage of physical completion. To collect work performance information the project can combine:
- Frequent face-to-face meetings or at least live distance meetings;
- Frequent on-the-job reviews;
- Collaboration tools to collect status information and update project documents; and
- A project management information system to distribute information.
Updating micro and macro plans
The micro plan should be updated daily, recording actual and remaining values. Future activities, estimates, and sequences are permanently reviewed to ensure a high level of detail. The macro plan can be regularly updated using the information on the micro plans and available resource capacity. Project performance metrics can be used to trim the macro plan.
Exhibit 8 – Exponential growth of correcting variances
Analyzing metrics
Metrics that can be use to monitor the rescue process include:
- Number of open problems, risks, and defects organized by priority
- Schedule variance expressed in days or percentage
- Work variance expressed in hours or percentage
- Cumulative slip —Sum of variances in days between schedule and actual finish dates
- Activity closure index = (activities closed)/(activities planned closures)
Customized earned value management metrics, using a preliminary estimate (EAC’) instead of a budget at completion (BAC), can also be used:
○ Percentage of physical progress, percentage budget spent, percentage of progress scheduled;
○ Customized cost performance index – CPI' = EV'/AC where EV' = EAC' x physical progress; and
○ Customized to complete performance index - TCPI' = (EAC' – EV’)/(EAC' – AC).
Transfer Phase
The transferring process
Transferring the project responsibility to the performing organization can include:
- Introducing baselines — Project management baselines should be in place and used to assess variances.
- Introducing post rescue processes — Rescue project management processes are time and energy consuming and are not sustainable for long periods of time. Once the rescue is complete, the rescued project should be realigned with standard project management practices as defined in the rescue management plan.
- Transferring responsibilities — Control should be handed over to the organization's project management.
- Generating lessons learned — The organization should understand what went well, and what could have been improved on the rescue process.
- Communicating results — Project results should be communicated to the organization to overcome negative perceptions accumulated overtime.
- Releasing resources — The rescue team should be progressively released from the project.
Final Words
Dealing with a troubled project raises challenges. Trouble often generates a spiral effect and trouble is not easily identified due to poor control processes and human nature. In order to recognize trouble and launch a rescue process, attention should be placed in symptoms. The complexity and nature of problems strongly suggest that a rescue be treated as a project. A rescue initiative should generate tradeoffs between project constraints to provide an acceptable outcome to all parties. The rescue project regroups people and energy and establishes corrective and preventive actions to dealing with the trouble root causes.
