Gareth Byatt, Gary Hamilton, Jeff Hodgkinson, and Duke Oakes

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 limitedconstraints 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 aproactive 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 riskthroughout 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 tocompensate 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 1through 5 are for problem diagnosis, and 6 through 10 for solution implementation.

  1. Define the Problem: What occurred, where and when was it identified, when did it begin, and how significant is it?
  2. Understand the Process: What were the process steps that should have been carried out before
    the problem was found?
  3. Identify Possible Causes: If they did not occur as planned, which of the process steps could have
    caused the problem?
  4. Collect Data: What information could indicate which of the possible causes actually occurred in a
    way that would create the problem?
  5. Analyze Data: What does the data indicate about which of the possible causes did or did not
  6. Identify Possible Solutions: What changes to the processes of project planning and execution
    might keep those processes from failing in the future?
  7. Select Solutions: Which of the possible solutions identified are the most viable?
  8. Implement Solutions: Plan and carry out the selected solutions.
  9. Evaluate the Effects: Were the solutions implemented and have they worked?
  10. Institutionalize 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.

There are many barriers that prevent corrective action from being carried out effectively. We have already alluded to … a lack of guidance … a process … for carrying it out. That’s the purpose of steps 1 through 10. Other barriers and resulting imperatives for project managers include:

  • There is often a tendency for a single individual to try to perform the investigation and solve
    the problem without help. However, project failures are often the result of incremental variations within multiple processes, and a single individual is unlikely to be sufficiently familiar with all processes to be able to evaluate them effectively and without bias. Therefore, project managers must ensure that they involve multiple players in the diagnosis of complex problems. They need
    to encourage their team to “put their hand up for help”.
  • In the rush to solve
    problems, people make assumptions and jump to causes or solutions without having data to back them up. This leads to tampering with processes, which can result in further problems. Project managers need to be certain that adequate information is available before deciding which actions to take.
  • Corrective action often has a negative connotation in organizations, which means people don’t
    look forward to being involved. However, many studies have shown that humans and organizations learn more from their failures than from their successes, so corrective action needs to be viewed as simply the process of learning more about how processes actually operate. Project managers need to employ positivity when assessing the need for corrective action and putting the case
    forward to do it.
  • Corrective action is seen as something that is in addition to the “regular work”, rather than as part of effective business management, as indicated by the Plan-Do-Check-Act cycle. Project managers who emphasize the PDCA cycle as part of day-to-day thinking, as well as during major milestone
    reviews, will help others see the more complete picture of their roles. It is certainly an embedded part of Quality Management.
  • Many organizations want to automatically assign the cause of all problems to human error. The
    problem with this is that it is insufficient to provide identification of solutions, since the cause for that human error would need to be known. Many of the causes of human error turn outto be deficiencies in information, equipment, and management processes. Project managers who focus on process deficiencies rather than blaming people will find that others are more willing to dig down to the real causes of problems.

There are also challenges specific to project management which serve to make the activity of corrective action more difficult. These include:

  • Many projects involve multiple organizations, each a separate legal entity having unique
    knowledge/skills for which they are being contracted. This means players may try to protect their own turf (think of the BP disaster in the Gulf, and how the various contractors blamed each other), making the truth hard to find.
  • Project personnel may only consider the current project, rather than future projects, as potential
    beneficiaries of corrective action. The reality is that all players should be able to learn from investigations and often carry that knowledge into future projects.
  • Similarly, due to the fact that each project has an end-point, it may be difficult to do a full-on
    evaluation of effectiveness. The value of solutions may only be appreciated in the course of future projects.

Another significant advantage of developing better root cause analysis skills within the project team is that such thinking is fundamental for risk management, quality management and the creation of a“learning culture.”




Article Author Bios as of November 2011








Their Roles

Their Plans,

And Their Goals




Gareth Byatt, Gary
  Hamilton, and Jeff Hodgkinson are experienced PMO, program, and project
  managers who developed a mutual friendship by realising they shared a common
  passion to help others and share knowledge about PMO, portfolio, program and
  project management (collectively termed PM below). In February 2010 they
  decided to collaborate on a three (3) year goal to write 50 PM subject
  articles for publication in any/all PM subject websites, newsletters, and
  professional magazines / journals. So
  far 33 have been written, published, and translated into Arabic,
  Czechoslovakian, French, German, Indonesia, Italian, Spanish, Portuguese, and
  Russian and published on websites in 26 countries including Australia,
  Brazil, Canada, Chile, Czech Republic, Finland, France, Germany, Hong
  Kong, Italy, India, Jamaica, Netherlands, New Zealand, Nigeria,
  Pakistan, Panama, Poland, Russia, Singapore, Sri Lanka, Trinidad, Turkey, UK,
  Ukraine and the USA. Their mission is
  to help expand good program and project management practices by promoting the
  PM profession, to be a positive influence to the PM Community, be known as
  eminent influencers of best PM practices, and in earnest hope readers can
  gain benefit from the advice of their 60+ years of combined experience and
  expertise and include the expertise of co-authors who write with them on
  certain articles and subjects. Along with writing
  articles, each also champions a role in the overall writing program
  collaboration process:

  Gareth manages all
  requests for additional guest author collaborations

  Gary manages the
  article development tracking and readership metrics

  Jeff manages the
  article distribution and new readership demographics

Each can be contacted for
  advice, coaching, collaboration, and speaking individually as noted in their
  bios or as a team at: This email address is being protected from spambots. You need JavaScript enabled to view it.   This month we are thrilled to have Duke
  Oakes as an additional co-author on this article.


Duke Oakes is an expert in Quality Management
  with 35 years of experience as a quality engineer, consultant and
  trainer. He has worked with dozens of
  companies in ten countries, and hundreds of organizations have attended his
  public workshops on auditing, quality systems, performance metrics and root
  cause analysis. He is an ASQ Fellow
  and certified by ASQ as a quality manager, engineer and auditor. He holds degrees in technology, business
  and education, and is a frequent conference speaker on quality management. He is the author of “Root Cause Analysis:
  The Core of Problem Solving and Corrective Action,” and has published dozens
  of articles on quality. He can be
  reached through his website at


This email address is being protected from spambots. You need JavaScript enabled to view it. has 15+ years of experience in project, program and PMO management in
  IT and construction for Lend Lease. Gareth has worked in several countries and lives in Sydney, Australia.
  He can be contacted through LinkedIn.

  holds numerous degrees, certifications, and credentials in program and
  project management as follows: an MBA from one of the world’s leading
  education establishments, a 1st-class undergraduate management degree, and
  the PMP®, PgMP®, PMI-RMP®, PMI-SP®
  & PRINCE2 professional certifications. Gareth is currently a Director of
  the PMI Sydney Chapter, he is the APAC Region Director for the PMI’s PMO
  Community of Practice and he chairs several peer networking groups.

  has presented on PMOs, portfolio and program and project management at
  international conferences in the UK,
  Australia, & Asia including PMI APAC in 2010. Email Gareth: This email address is being protected from spambots. You need JavaScript enabled to view it.


Gary Hamilton has
  16+ years of project and program management experience in IT, finance, and
  human resources and volunteers as the VP of Professional Development for the
  PMI East Tennessee chapter. Gary
  is a 2009 & 2010 Presidents’ Volunteer Award recipient for his charitable
  work with local fire services and professional groups. He has won several
  internal awards for results achieved from projects and programs he managed as
  well as being named one of the Business Journal’s Top 40 Professionals in 2007.  Gary
  was the first person globally to obtain the five credentials PgMP®,
  PMP®, PMI-RMP®, PMI-SP® , CAPM® . In addition to these, Gary holds numerous other degrees and
  certifications in IT, management, and project management and they include: an
  advanced MBA degree in finance, Project+, 
  PRINCE2, MSP, ITIL-F, MCTS (Sharepoint), MCITP (Project), and Six Sigma GB
  professional certifications.   Email Gary: This email address is being protected from spambots. You need JavaScript enabled to view it.  or
  contact him through LinkedIn.


Jeff Hodgkinson is a 32 year veteran of Intel Corporation  IT@Intel Expert and blogs on Intel’s
  Community for IT Professionals
for Program/Project Management subjects and interests. He is also the Intel IT PMO PMI Credential
  Mentor supporting colleagues in pursuit of a new credential. Jeff received
  the 2010
  PMI (Project Management Institute) Distinguished Contribution Award
for his support of the Project Management profession from
  the Project
  Management Institute
. Jeff was
  the 2nd place finalist for the 2011
  Kerzner Award
and was
  also the 2nd place finalist for the 2009 Kerzner
  International Project Manager of the Year Award TM.
He lives in Mesa, Arizona, USA and is a member of Phoenix PMI Chapter. Because of his contributions to helping people achieve
  their goals, he is the third (3rd) most recommended person on LinkedIn with 570+
  recommendations, and is ranked
  55th most networked LinkedIn person. He gladly accepts all connection invite requests
  from PM practitioners at: Jeff holds numerous certifications and credentials in
  program and project management, which are as follows: CAPM®,CCS, CDT, CPC™, CIPM™, CPPM–Level 10, CDRP, CSM™, CSQE,
  and SSGB. Jeff is an expert at program and project
  management principles and best practices. 
  He enjoys sharing his experiences with audiences around the globe as a
  keynote speaker at various PM events. 
  Email Jeff: This email address is being protected from spambots. You need JavaScript enabled to view it.