Root cause analysis and corrective action for project managers
- 31 October, 2011 08:13
Project managers have the immense task of juggling requirements and resources that are often not under their direct control in order to produce the required project deliverables within the limited constraints to which they must adhere (scope, time, quality, etc.). Even if the perfect project plan could be designed and executed, it would not remove all of the risks that could ultimately impact a project. Plans must inevitably change for one reason or another.
During the phases of a project, it could be said that there are three major activities focused on reducing project risk. The first risk reduction activity occurs during project planning, when a proactive risk assessment is conducted and the identified risks are either mitigated or avoided (e.g., by modifying the project plan), transferred (such as through insurance) or accepted (by doing nothing and accepting that “if it happens, it happens”).
The second activity is the continual assessment of risk throughout the project. The final risk reduction activity is to hold a retrospective “lessons learned” at the end of the project, which will have the least impact on the current project but will serve to benefit others in the future.
However, for the unforeseen problems that occur throughout a project, risk management is too late, since it has already been completed, and lessons learned are too early, since that is conducted at the conclusion of the project. Corrective action is then a critical process for dealing with ad-hoc problems encountered during projects.
Unfortunately, actions taken to resolve an issue often only address the problem itself, not its underlying causes. Symptoms of the problem are addressed and project resources are adjusted to compensate for the problem, but true corrective action may not be taken. In other words, the causes of the problem remain unknown, meaning the problem may reoccur later in the project and/or in future projects.
Consider this example:
Problem: A design project to develop a new vehicle has come to a complete stop because one of the key work packages for it is on the critical path but is behind schedule.
Action taken: The work package behind schedule is deemed to be a low risk, so it is decided that it will proceed in parallel with other modules, changing the critical path. This means that if no major problems found are with the module, there will be no additional delay.
Note that while the action taken in this example may allow the project to proceed along a modified critical path, nothing was done to identify why the work package was behind schedule in the first place. That is, while the problem was resolved (corrected), no action was taken to ensure that the same problem would not occur in the future (corrective action).
In our example, was the module behind due to inadequate capacity of the assigned resources, or for some other reason?
Corrective action consists of two major phases:
- Diagnosis: Performing an investigation to find the root causes of the problem
- Solution: Taking action to prevent the causes from recurring
To provide a more detailed breakdown of these steps, we put forward an example “10-step problem solving model” that we hope will be of use in guiding you through a corrective action process. Steps 1 through 5 are for problem diagnosis, and 6 through 10 for solution implementation.
- Define the problem: What occurred, where and when was it identified, when did it begin, and how significant is it?
- Understand the process: What were the process steps that should have been carried out before the problem was found?
- Identify possible causes: If they did not occur as planned, which of the process steps could have caused the problem?
- Collect data: What information could indicate which of the possible causes actually occurred in a way that would create the problem?
- Analyse data: What does the data indicate about which of the possible causes did or did not contribute?
- Identify possible solutions: What changes to the processes of project planning and execution might keep those processes from failing in the future?
- Select solutions: Which of the possible solutions identified are the most viable?
- Implement solutions: Plan and carry out the selected solutions.
- Evaluate the effects: Were the solutions implemented and have they worked?
- Institutionalise the change: Update project management guidelines and tools to ensure that future projects are carried out in alignment with the improved processes.
Note that steps 1 through 5 are typically done iteratively, until the causes found are at a depth sufficient to prevent recurrence. For example, if on a software project testing, delays are due to inadequate capacity of the testing software, the reason for the capacity problem would need to be determined in order to prevent such a failure in the future.
Of course, it is not necessary to carry out this level of investigation and action for every problem that occurs during a project, so an important component of the corrective action process is risk assessment and agreement on a sensible course of action. That is, for each problem that occurs, the relative magnitude and likelihood as part of a risk assessment should be considered before assuming root cause analysis is required.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.
Why change management doesn’t work
Larry Page wants to see your medical records
Dual-Persona Smartphones Not a BYOD Panacea
After two-year hiatus, EFF accepts bitcoin donations again
CIOs struggle to deliver timely mobile business apps: survey
CSO Spotlight: Security-as-a-Service Gaining Popularity
Organizations that are looking for security features including identity management, encryption and access control — and at the same time want to take advantage of the cost and flexibility benefits of the cloud —might check into security-as-a-service offerings available now from several vendors. Download now to find out more.
IDC: Delivering Customer Value with Enterprise Flash Deployments
When it comes to flash, “one size does not fit all.” IDC examines recent flash trends in enterprise storage deployments. This includes: highlighting how SSDs are filling in gaps of existing storage systems when coupled with intelligent archiving and automated tiering, the pros and cons of different SSD approaches, and tips to overcome concerns of reliability, manageability and scalability.
HP Helps NEC Reduce Network Management Costs and Gain Efficiencies
NEC wanted to reduce network management costs, while increasing network visibility, decreasing mean-time-to-repair, improving stability and mitigating the risk of downtime. Download today to hear from Cameron Craig, Senior department manager of NEC on what approach they took and why.