Defining Distress/Basic Life-Cycle
Over the past few years, assignments involving “distressed projects” have been far too frequent for the maturing state of corporate project management. Requests to “recover” a project that has strayed into the territory called “distressed” usually come complete with a panicked urgency to locate and solve issues including emotional distress, protectionism, and a myriad of other valid reasons for the current condition. Amidst the chaos and high-
emotion, the project must be assessed without prejudgment or bias, and lead to a path of recovery. This article will deal with a consulting life-cycle approach to uncovering issues that have contributed to the distressed condition and recovering as many of the project’s original objectives and expectations as possible. Distressed projects have no industry preference; they are equal opportunity employers. Therefore, the practices discussed here are
applicable to all industry types.
In our consulting practice, we generally use the term “distressed” to represent a project or program that is 20%> off its cost and schedule baseline targets, exhibits missed milestones and has missed key deliverables. For the sake of recovering a project to its original scope expectations, the earlier the project is recognized as “sliding” the better. You may be asking, “Why only recover the scope expectations?” In many recovery efforts, our involvement begins well beyond the beginning phase of the “slide”. It is a foregone conclusion that the schedule and budget will need to be expanded to allow for original scope expectations to be met. In cases where schedule and budget cannot be expanded, scope is decreased to meet these constraints. PM stands for project management, not project magic! When a project has slipped into serious distress, recovering scope expectations in a stressful environment without major time and cost overruns is a feat in and of itself.
The Basic Life-Cycle
Although all distressed projects have unique issues, we have had success in using a basic and consistent life-cycle approach. The four-phase life cycle pictured below (truncated) has been developed over time and over many of these types of assignments. It is free of non-value added deliverables and is aimed at quickly and accurately getting to the heart of the distress, implementing the corrective action plan, executing and controlling new deliverable development, and executing formal project closure practices/processes.
Someone once asked me why we call it “entering” and not “initiation”. My response was that the project already had an initiation phase. We are not initiating a project; we are entering a project that is in progress and has specific history associated with it. The term “entering” reminds us that we are not starting with a clean slate. To the contrary, we are in the middle of something failing that requires professionalism, patience, insight, tact and critical thinking in order to make a positive impact. Also, we are reminded that entering in the middle means we must exercise diligence to quickly get caught up on the underlying context of the project. This requires much listening and observation.
Whether we are consultants or internal resources, developing the consulting scope to recover a distressed project generally involves achieving clarity around and documenting the following areas:
- Initial project expectations (history)
- Current organizational assessment of the project
- Expectations of the recovery assignment
- Agreement on our approach (or variations) to the assignment
Schedule Initial Interviews and Data Gathering
In order to properly assess the project, we must interview a varied group of individuals who are directly and indirectly involved with the project. Generally (and hopefully), the individual responsible for our involvement with the project will have identified the organization’s key resources. At a minimum, the following resources should be interviewed:
- Project Sponsor and/or Steering Committee Members
- Project Customer
- Project Manager and Staff (collectively and individually)
- Key Functional Managers
- Key Technical SME’s and/or Team Leads
- Schedulers, Controls Resources, and PMO Resources (if applicable)
- Key Project Team Resources (formal and informal leaders)
As mentioned earlier, each will have a story to tell about the original intent and why they feel the project has declined to its current status. One must be careful not to get hooked into the emotion of the situation. I recently entered into a very large program that was in a critical state. The emotions were highly charged, fingers being pointed in all directions and mistrust was on the rise as various functional groups took up their positions of defense. Experience teaches one to get past the emotion by calling them back to the real events, what happened (not why) versus their opinion of what happened.
Analysis and Assessment Phase
Also, when one gets caught up in the emotions of the project, it is easy, with no malice, to agree with folks about just how distressed the project is. As innocent as this may be, it should be avoided at all costs. One of the first cautions of “entering” into a distressed project that will assist us in being quickly accepted as a non-biased peer reviewer is being very careful not to disregard the entire project. Regardless of the current condition of the project, many people have worked very hard and generally have done what they thought to be the right thing. They have been surrounded by the project daily, which, after a while tends to limit one’s observations and insights. We come in fresh and our lack of specific history and emotion allows us to see things they may not. A good rule to use is not to make any observations or pronouncements (public or private) until you have thoroughly assessed the current situation. Project resources appreciate this type of professional restraint and are much easier to work with if they are not on the defensive.
Analysis and Assessment Phase Depending on the point of entry, i.e., the level of current distress, this phase can be the most labor intensive of the assignment and not a glamorous one either. This is where the picture of the project, past and present, comes together for us. One must have a great deal of tact, yet possess plenty of tenacity in order to get to the nexus of the distress without alienating everyone at the same time. We will need to maintain very professional relationships during this phase as we will need buy-in and validation for our proposed solution later on.
Conduct Initial Interviews – Data Gathering, Documentation and Data Review/Evaluation, and Probative Interviews
Although distinct, the three processes above share enough commonality for us to discuss them together in this format. Many of the initial interviews will give us access to the project’s required documentation/data. In some instances, the data may be presented to us prior to the interviews. I prefer the latter. Having an opportunity to examine project documentation/data helps me form pointed questions for the interviews. This helps keep the participants focused on what happened, out of the emotional realm. From the consultant’s point of view it helps to keep the interviews from becoming a blur of repetitive conversations.
Once the first round of interviews and documentation/data review has been executed, we will conduct probative interviews that will be used to “drill” into specific areas uncovered earlier. Projects create a great deal of documentation and we can get overwhelmed if we allow the client to make a doc/data dump. To begin with, we will review the following specific documentation:
Charter and Project Approval Documentation
- Project Charter (Initiation Mechanism)
- Scope Statements (preliminary and definitive), Scope Development
Documents, Reviews, and when Scope was “frozen”
- Baseline Development Documentation
- Project Estimates including basis of estimate documentation (ROM, Conceptual and Definitive; consistent with project size and complexity)
- Project Schedules (with resource loading)
- Project Design Basis Documentation, Reviews, and when
Design Basis was “frozen”
- Project Execution Plan Elements including (at a minimum)
- Communication Management Strategy
- Scope – Change Management Strategy
- Risk Management Strategy
- Procurement-Vendor Management Strategy
- Project Controls Management Strategy
- Integration – Handover – Closeout Management Strategy
Many times, these documents-artifacts have not been created. Or, they were created in order to gain project approval and have not been kept up to date; both are signs that project execution planning may not have been robust enough. Benchmark studies confirm that a lack of execution planning is a key cause in project distress and failure. This will be discussed later.
Developing Conclusions and Solution Approach
This area is where experience plays a predominant role. As previously mentioned, projects are unique in their specific characteristics, yet sources of distress usually align with benchmark findings and common empirical results from one distressed project to the next.
This certainly isn’t a rule yet; we do see many of the same “snags” from project to project.
Below are just a few of the common distress factors we have seen in the past few years:
- Ineffective and untimely senior management decisions
- Ineffective expectations transfer from client to provider (contract terms misunderstood)
- Ineffective Stakeholder Communication
- Lack of Execution Planning
- Lack of Scope and Design Basis Freeze prior to final estimation or definitive contract terms
- Project or Program is beyond the experience level of the
- Inadequate project structure and/or resources
Solutions are comprised of specific responses to causal factors and vary project to project based on culture, organization, resource levels, management buy-in, etc.
Gaining Approval and Consensus (findings and solutions)
Difficulty or ease in gaining approval, validation, and consensus is usually and directly related to the level at which the causal factors occur. Strategic or senior management level – difficult, Operation or Management level – easier, and Tactical or team resource level – much easier. Regardless of the level, the solution(s) must be presented in a logical, “threaded”, and no-blame manner in order to gain approval and consensus across the necessary constituencies.
Execution and Control Phase
Of the four required phases involved in recovering the distressed project, the Execution and Control phase signals a temporary sigh of relief. Although much more work will be required, it signals that we have properly assessed the issues with the prior project difficulties and our solution has been validated and approved.
During the Analysis and Assessment Phase a fair amount of execution planning would have been committed to in order to develop sound and approvable solutions. In this phase, we will complete the definitive execution planning for our solution. Over the years, we have seen that most distressed projects lack proper execution planning and where there is a lack of execution planning; there is a lack of execution cognizance and the lack of proper resources for execution and closeout. Elements of a sound project execution plan (or project plan) include the elements-areas listed below and will vary from industry to industry.
|Controls (Scope, Time, & Cost)
|Quality – Testing – Validation
|Implementation – Closeout
With the proper execution elements addressed, planned for, and documented it should be very clear which resources we will need to execute our overall recovery plans.
Roles and Responsibility Determination
With a solid execution plan in place and the team resources identified, alignment sessions are utilized to review all deliverables, major roles, support roles, interdependencies and the required timing for deliverable development. Regardless of the size of the project effort, roles and responsibilities should be clearly documented using a basic RASCI (Responsible, Accountable, Support, Consult, & Inform) tool. For more definitive detail a complete WBS Dictionary may also be utilized.
Schedule and Budget Development
As with execution planning, we would have determined initial schedule and budget implications during the development of our recovery solution. In this phase, we will be developing the definitive master schedule and associated budget baseline (supported by our definitive execution plan). In sizeable project efforts is advisable to utilize a dedicated scheduling resource (master scheduler) to develop and administer the project schedule. Many best-in-class organizations have realized that expecting the project manager to develop and maintain a complex network schedule and manage the various constituencies on the project is a tall order to say the least. Scheduling is a professional discipline and project scheduling on large and complex projects borders on being an art form. Developing accurate baselines that can be monitored, trended, and controlled is well worth the additional cost of the scheduling resource and in a recovery effort, we can’t afford to miss the target a second time.
Project Control Strategies in Place
Developing sound project control strategies begins with accurate and “controllable” baselines. As mentioned above, a dedicated scheduling resource can make this “control” possible for the project manager. Experience has clearly shown us that for any sizeable effort, the project manager will not be able to successfully perform both the management and control duties required by such a project. In addition to accurate baseline development, sound project control requires the development of the following elements:
- Key milestones identified and attributed with deliverables
- Key deliverables with clear completion metrics
- Formal execution reviews (performance and risk related)
- Earned Value and Burn Rate strategies (monitoring and trending analysis)
- Defined and consistent performance reporting requirements for team members
Deliverable Execution and Validation
Once controls strategies are in place deliverable execution may begin again. Our control strategies and practices will assist in trending actual performance against our baselines and incrementally validating deliverable execution (and reacting to variance).
For most projects, especially those that are large and complex, project closing is accomplished in a phased manner, or “rolling-wave” closing. It is not inconceivable to have early deliverables or portions of the project in implementation/Operation while we are still completing later deliverables. The “fast track” expectations of most projects will ensure such a phased closing schema and adds another layer of chaos to the project. Also, and as true for many projects, organizations begin to “strip” resources from projects as they appear to be reaching the finish line. The project manager will want to guard against this by modeling (in the risk assessment) the adverse effects of prematurely diverting key resources to other projects.
Solidify the Transfer, Handoff, and Implementation Plans
This element of the overall project execution plan (project plan) requires a great deal of time and coordination to develop and solidify. Customer and project resources must be in alignment on roles and responsibilities for:
- Final testing and validation
- Training (content, materials and facilitation)
- Implementation assistance
- Timing for “custody” handoff of phased deliverables (project-based to operations-based transfer) the “roll-over”; the graphic below illustrates what we refer to as the “rollover”, i.e. the Project Manager rolling down to the support role and the Customer rolling up to the leading role.
Execute Phased Implementation and Signoffs
If the Transfer, Handoff, and Implementation Plans are complete than the phased implementation and required signoffs can be executed as scheduled. For projects where the closeout phase is highly complicated, a separate and more detailed completion schedule (inch-stone schedule) may be needed to ensure a successfully executed closeout.
Final Audits and Lessons Learned
In a phased closeout the final audits and final lessons learned sessions will coincide with the phased execution schedule. It seems that no matter the size and criticality of the recovered project, there are always plenty of reasons to avoid the audits and lessons learned sessions.
These practices are important for any project and organization and in the case of a recovered project where we will have spent significant sums of time, money, and attention to rein it in; we should commit to their execution in order to memorialize the initial issues and their costly solutions.
In summary, with a detailed and methodical approach to recovering projects, the effort need not be cathartic yet, it is still a wiser and less stressful approach to commit to the proper planning and diligence initially.
Don’t forget to leave your comments below.