February 29, 2012 at 1:21 pm #154535
Every so often, a project manager has to step in to save a project that is falling apart. What are the immediate steps you should take to stop the “bleeding?” What are long-term actions that you can implement to save the project?
February 29, 2012 at 1:47 pm #154551
Some off the top of my head thoughts —
First question — Should the project be saved or ended? Is the original goal still relevant and possible? Is this project the best way to acieve that goal or would the organization be better served by starting over with an entirely new project?
Second question — What caused the project to go off the rails? Are the current project team members part of the problem, part of the solution or both? Has scope creep overburdened project resources? Were project resources realistic at the start?
Third question — How much time is available to analyse and plan a new direction? A day, week month?
Fourth question — What is the project managers level of authority? Can team members be changed? Are additional resources, particularly budget and time, available?
Action item — Given answers to the above questions, determine what critical tasks must be accomplished in what order and in what time frame to complete the project.
Action item — Shoot allegators quickly. The project’s mission may be to drain the swamp but that will not be possible from the belly of an alegator. Sometimes the urgent must take priority over the important.
Action item — If current resources are sufficient to complete the project, allocate them to urgent critical tasks and get started. If current resources are not sufficient to complete the project, discuss first question with senior executives.
March 2, 2012 at 6:12 pm #154549
March 6, 2012 at 2:01 pm #154547
Thanks so much for your insightful and timely response, Peter. Your questions and action items are going to be accompanying me to a meeting this morning.
March 6, 2012 at 4:50 pm #154545
“Shoot allegators quickly” – sounds like a great title for a blog post! 🙂
March 6, 2012 at 5:08 pm #154543
This challenging question seems to be addressed to a member of the project governance board, or the project management team, i.e. the project executive or sponsor, the project manager or project director. However:
1.-The project is falling apart, thus the problem/issue is already defined. This means that a project control mechanism, at the project steering committee/project board level or at the project manager level carefully implemented by the project manager during initial (overall) project planning, triggered a red-light warning that the project is on a wrong way/supposed to falling (e.g. project tolerances or stage tolerances are not respected). This might be thought as a project issue or a project problem which could have associated or not (unknown unknown) a former risk, actually produced with a negative impact as a threat for the project. It is well known that one of the quality assurance tasks for the project manager is to prevent problems and issues instead of resolving them after their occurrence.
2.-A good project control mechanism and well implemented should indicate a first-level cause of deviation or falling of the project from the right way. Sometimes, a such smart mechanism is missing in the project management plan or in the project progress tracking so, it is necessary to start a tough and quick working process at the level of the project manager and consequently at the level of the project steering committee/project board.
3.-This tough work is usually done by applying the RCA-Root Cause Analysis, to be performed in a fast way for finding the “cause path” or “cause chain” by tracing back and digging from the current and most visible cause to the initial one, respectively the “root cause”. Also, it is possible to use the Six Sigma’ Kaizen method for identifying and solving the “root cause” of the problem. Anyone of them is helpful in order to proceed to a short-term then to a long-term making decision based on alternative solutions to be implemented. This process involves participation of the whole project governance team and project management team together with project technical team(s) representatives being familiar with respective cause.
4.-Usually, the RCA must start from “what” lately happened to the project as it started to fall apart, determine “why” and/or “how” this happened (analysing the events sequence and tracing back the causes and ways of slipping from one cause to another one, by backwarding on the “cause path”). Each cause might appear due to one or more causal factors, so it is necesasry to find all of them by drilling down deeper and deeper and/or using different alternative tools and techniques, e.g. CED-Cause and Effect Diagrams or the Six Sigma’ DMAIC 5 Whys. Finally, it is possible to find more than one “root cause”.
5.-In parallel, investigate the type of each cause pertaining to the current project falling (human/team type, resource type, organizational type, management type, etc.).
6.-Finding the real root causes of project falling and specific types allow to the project management team to define and recommend alternative solutions as corrective actions to be implemented for putting back the project on the right tracks.
7.-Now, it is possible to differentiate among different solutions if the project might continue or not. In case of not, it is necessary again to differentiate between project stopping (for a reasonable interval of time) or to officially close it by evaluating all the implied risks. For example, in terms of costs and reserve analysis, funding limit reconciliation and a careful EVM analysis, if the project contingency reserve at the project manager level (which is included in the project cost baseline) was already spent and the project management reserve (which is one step over the project baseline and it is included in the project cost budget) was also spent, then the project has not any other funding source and in this case the project sponsor from the project governance must look for additional external funding sources and consequently to stop the project until new funds are available, or to close immediately the project.
8.-In case of which the project might continue, the alternative solutions available to be implemented should be submitted also to: a risk analysis process including the short-term or the long-term impact and a EMV-Expected Monetary Value analysis, a FMEA-Failure Mode and Effect Analysis for identifying possible failure points of each solution possible to be implemented on short-term or on long-term. A change request process/methodology might also be necessary for any changes to put the project back on tracks by implementing the most appropriate solution.
9.-Distinction among short-term and long-term solution implementation should be based also on: project contract type, resource availability, time duration for solution accomplishment, full or partial approval or rejection by the project governance authority and many other factors. Usually, if the project does not follow anymore the last instance of the revised business case and/or it does not bring anymore tangible or intangible benefits, the usual way is to stop or to close the project. However, the last decision should be taken by a combined staff from the project governance and the project management levels.
a).-Immediate steps, if solution allows project continuance:
- perfoming above mentioned analyses, i.e. RCA/Kaizen, EVM, EMV, FMEA;
- resource (all types) availability checking, change request management, revision of the project business case and project management plan updatings for all included plans
b).-Long-term actions: implementation of best solution with appropriate redimensioned resources (human, financial, etc.), revised business case, revised project management plan, revised project/product tolerances, revised risk register content, revised issue register content, continuous enhancement through preventive actions based on different RCAs processes.
March 6, 2012 at 8:49 pm #154541
@Mihail – Wow! Thank you for a comprehensive and great response to the question! You may want to do a posting explaining some more about Root Cause Analysis. Very helpful technique to have.
March 7, 2012 at 7:57 am #154539
Thank you very much for your appreciations. I’ll post a more detailed presentation on the RCA process and its environment.
March 8, 2012 at 12:11 pm #154537
RCA-Root Cause Analysis is not a single but a class of problem-solving techniques (also defined as problem-solving strategies and being different of problem solving methodologies) pertaining to the more general category of problem solving process. The RCA class techniques are used for identification of general problem or event “root causes” and their elimination when: a problem or an issue appeared, a harmful outcome occurred as consequence of former events, or just an unexpected event was produced. The problem solving process is performed by the human mind and arrives in the final part of the problem process after problem finding (aparition/identification) and problem shaping. The RCA class techniques should be generally applied to program and project problem-solving on the reason that it is considerably more important for the program/project in question and to its managers to identify and eliminate the root causes through corrective and even preventive actions, instead of addressing and resolving the last occurred problem/issue/event through a fast workaround action (plan) without any deeper investigation of the real cause. Applying specific corrective and preventive actions to the real root causes of a falling program/project, based on a detailed RCA class selected technique, will put back on tracks the program/project in a more consolidated manner and will give to all program/project stakeholders a higher percentage of trustness that the occurred problem recurrence will be highly prevented in the future, however not necessarily 100%.
The RCA class is also linked to the Six Sigma ( 6σ ) Business Management Strategy developed by Motorola in 1986 and widely used in many sectors of industry including program and project management. Six Sigma was designed to improve the quality of different industrial process outputs by identifying and appropriately removing the real causes of defects (errors) as well as minimizing the variability in manufacturing processes and business processes. When speaking about projects, the Six Sigma projects may be managed using one of the two specific Project Management Methodologies (PMM), each consisting of 5 phases and following the Deming-Shewart well known PDCA (Plan-Do-Check-Action) cycle: DMAIC used in projects for enhancing an existing strategic or a business process, and respectively the DMADV or DFSS used in projects for new products creation and/or new processes design. Any project under Six Sigma DMAIC or DMADV/DFSS deployed by an organization according to its business strategic plans should follow a clear sequence of stages, specific steps and activities based on previously detailed quantifiable financial objectives or goals, e.g.: production and product design costs reduction, a higher after tax financial rate of return on investment and on equity (and not the IFRR), net worth increase or net profit increase, etc. The project managers assigned 100% to the Six Sigma projects are the Master Black Belts and the Black Belts who under Champions supervision must manage and apply the Six Sigma respective PMM concepts.
Among a Six Sigma project phases and/or stages using DMAIC or DMADV/DFSS PMM the project manager may use well defined quality management tools and methods, however also being used outside of Six Sigma projects. Among them, is the class of the RCA problem solving techniques. During DMAIC Analyze (A) phase, the project falling problem statement is defined and confirmed as measurable, then the next step is to analyze its root causes of the problem/issue, this process being performed by the project manager, in this case the Master Black Belt professional, who must apply the technique to sequentially ask why that happend until real “root causes” will be found (e.g. the “5 Whys” RCA class technique). Another aspect is that of finding a real “root cause” and when to stop during the investigation process of applying the “Whys” technique or another technique (however the number 5 for Whys is not a limit).
Anyway, there are a lot of different definitions or interpretations of what constitutes a real “root cause” and in the most part a such called “root cause” does not represent the real initiating cause of a “cause chain” (or “casual chain”), this one representing the events sequence (any event in the chain representing a cause for the next. ). The Web literature on this subject is large and real characteristics of a “root cause” may be found here: http://en.wikipedia.org/wiki/Root_cause .
In case of which the “root cause(s)” was/were clearly defined and accepted, the selected RCA class technique process should follow some general principles. These are described together with the specific steps to be performed for a corrective action, based on a selected RCA class technique, on the site: http://en.wikipedia.org/wiki/Root_cause_analysis .
In my former answer to Bill Brantley challenging question I have presented a short version of a simple general RCA process, however the last mentioned Wikipedia hyperlink site is very well presenting all current RCA techniques.
You must be logged in to reply to this topic.