Skip to main content

Tag: Best Practices

Management Consultants and PMO failures

Having worked in the (Middle East- North Africa) MENA region for a number of years, it is quite disheartening to encounter PMOs that suffer from acute identity crisis and are locked in endless battles with other departments to prove their worth.

What is interesting to discover is that the usual culprit behind PMO failures i.e. the lack of executive support, is not the primary cause. The common denominator behind the failings of such PMOs can be attributed to the role played by management consultants in setting up PMOs. There are three distinct areas where management consultants have played an instrumental role in creating PMOs, with major structural defects and no matter how hard one tries to fix it, the defects remain as an indelible stain.

 

1.     Sowing the seeds of executive confusion

There is a perpetual confusion in the minds of the executive team about the roles, responsibilities and competencies of the PMO. This is borne by the fact that in most cases, the management consultants hired to launch a company or a new business line, focussed exclusively on establishing a PMO that exhibited the characteristics of a reporting function and nothing more.  In this arrangement, the status from different projects and programmes are aggregated, rationalized and then presented to the executive team for decision making. Usually, the chief executive officer presides over the launch meeting, acts as the overall arbitrator and takes decisions on how to move the launch forward. Hence, the executive team performs well as long as the company is in launch mode, but any departure from this model and the frailty of the PMO is swiftly exposed.

Many executives find themselves unable to step into the shoes of the project sponsor (previously performed by the CEO as the sponsor of launching the business) and take important decisions about projects under their stewardship. Furthermore, very few executives possess sound ideas about how a centralized PMO should function in a post launch environment. Therefore, it is only logical to find executive support lacking as the PMO transitions into its post launch life.

2.     It was never about the project methodology

During the launch phase, the consulting company pays very little attention to devising a project/programme methodology, standardizing project documents and templates, and mentoring PMO staff about performing roles other than reporting. Even the reporting suffers from the absence of a structured approach and sometimes there is too much dependency on ‘power point presentations’. Hence, post launch, the PMO armed only with colourful slides is ill-equipped to support or deliver projects and programmes. Rampant project failure usually follows and all attempts to rectify the dire situation are hopelessly unsuccessful. This is because the solutions employed to address the structural weaknesses are derived from the PMO’s launch experience. For instance, many executives assume that just because the PMO delivered during the launch phase, a similar approach (without tinkering too much) will yield positive results.

3.     Over reliance on launch centric roles and responsibilities

Another surprising discovery is that the roles and responsibilities, processes and governance structures executed by the PMO are based on its launch life. It is not uncommon to find ‘Launch PMO’, ‘Launch Manager’, ‘Launch Director’, ‘Launch Gate’, ‘Launch Project Life Cycle’, ‘Launch Check Lists’, etc. as part of  PMO’s lexicon. In some cases, only the prefix ‘Launch’ is removed from job descriptions and processes, but the essence remains unchanged. Subsequently, the PMO and its staff are unable to adapt to the pace of corporate life and find themselves on the periphery of project delivery. To remedy the situation, two typical solutions are applied. Firstly, ‘certified project managers’ are recruited and expected to deliver projects on time. However, in the absence of a sound project management methodology many are found floundering.

Secondly, expensive consultants with extensive experience in working with PMOs in launch mode are brought on board to rescue the struggling PMO. In some cases, consultants are hired from the same management consultancy that established the launch PMO and fail miserably when given the responsibility to turn around the fortunes of the ailing PMO. All of this, exacerbates the problem, and marginalises the PMO’s role in corporate life.

To be fair to management consultants, they are typically hired for their domain expertise and not for their PMO competencies. The PMO is a value-add that is thrown in as part of the consulting service and at no extra cost. This practice is wide spread across the MENA region, so much so that executives are often left wondering as to why there is an abundance of project failure  despite the successful launch (the launch of the company or business line is viewed as a ‘successful project’) of the company or the new business line. To avoid a repeat of such stories, executives would do well to scrutinise the PMO capabilities of their management consultancy, in addition to their domain expertise. Alternatively, they may hire a PMO specialist company that works alongside consultants in the launch phase and in the post launch phase ensures that a proper PMO, equipped with the right methodology and resources is established.

Executives would be wise to opt for a PMO company that specialises on a BOT (Build, Operate Transfer) model as opposed to a DBT (Design, Build, Transfer) model. As the BOT model is geared more towards ensuring that the concept solution works in practice and the project culture is imbued and transferred within the organisation.

Don’t forget to leave your comments below.


Abid Mustafa is a seasoned professional with 18 years’ experience in the IT and Telecommunications industry, specializing in enhancing corporate performance through the establishment and operation of executive PMOs and delivering tangible benefits through the management of complex transformation programmes and projects. Currently he is working as a director of corporate programmes for a leading telecoms operator in the MENA region.

Would You Hire a Project Manager or a Business Analyst?

Jan_25_Feature_Fotolia_28094822_XSIf You Had to Choose, Would You Add a Project Manager or a Business Analyst to Your Team?

This was one of several questions posed to a cross-functional panel of industry experts encompassing the product management, project management, and business analysis professions at Project Summit and Business Analyst World Chicago. The resulting dialog shed light on several topics that underlie current practices.

The panelists were George Bridges (GB), Director of Business Analysis at the International Institute of Learning, Greg Geracie (GG), President of Actuation Consulting, Frank Kowalkowski (FK), President of Knowledge Consultants, and Neal McWhorter (NM), President of Strategic Value Partners. The panel discussion was moderated by noted project management author Steven Starke.

Moderator (Steven Starke): Greg, let’s begin with you. If you had to choose between adding a project manager or a business analyst, which would you choose and why?

GG – As a product management professional and a frequent project sponsor, I tend to take a broader view of this decision. A good analogy might be an orchestra. Within the orchestra the business analyst would be a violinist creating wonderful music. However, the project manager would be the conductor. The business analyst is an important individual contributor while the project manager is in a leadership role within the context of the project team.

So, I’d lean toward selecting a project manager because project managers can ensure that whatever value is created by the team gets to market. The business analyst role can create a lot of value, but if the value never gets to market it’s like the proverbial tree falling in the woods – no one is around to hear it.

Moderator: George, which would you choose?

GB – I‘d choose the business analyst. This is a shift in the way I’ve traditionally thought about this issue. I’ve always believed that the project manager could manage the project and make sure they have subject matter experts and all the resources they need to complete the project. However, after listening to Dr. W. Edwards Deming’s presentation “Management’s Five Deadly Diseases,” my concept of the business analyst has changed.

I now believe that business analysis skills and assets reside in the analyst’s knowledge of the business. They need to be conversant about the business at every level of the organization, and this includes formal and informal communication with the executive management team. This is not to say that the project manager is not conversant; but the business analyst should know the strategic business objectives of the company. Business analysts with this knowledge create value for the organization and can justify those decisions to senior management. These are the main reasons I’d choose a business analyst.

FK – Steve, I’d like to add to George’s comments. I’d start with a business analyst because the first issue the team would face is problem solving. Once you get to a solution or a set of solutions, the project manager role comes into full play for effective planning and a cost/benefit analysis of alternatives. If the limit is one full-time person, I might consider having a contract business analyst followed by a contract project manager. Alternatively, one could hire the business analyst full time and add a contract project manager because they’re more readily available than a contract business analyst.

NM – As someone who has spent years helping organization build up their business analysis capabilities, I’m sorry to say that I’d have to choose a project manager. The rationale is pretty simple. With a project manager I have a pretty clear value proposition. I’m looking for an individual who knows how to identify and track issues and risks, can track resources and work dependencies to schedule effectively, and who can monitor time, cost, and quality to quickly identify when a project isn’t where it’s expected to be.

With a business analyst, I really don’t know what I’m getting. I might end up with someone who is little more than a scribe or someone who takes charge of delivering a holistic business solution. The skills and techniques could range from an expert facilitator to a subject matter expert to a process analyst to someone who is little more than a technical writer. While any particular individual could bring a valuable skill-set, the current grab-bag-like assortment of business analysts really makes it difficult to believe that the role means much as it stands right now.

Business analysts have the potential to deliver great value but right now they’re a pig in a poke.

Moderator: So it seems our panel is evenly split between adding a business analyst or a project manager. Since that’s the case, let’s find out what each of you perceive as the value of a business analyst.

NM – This question gets right to the root of the problem with the business analyst’s role. In many organizations, this role is considered that of a “translator,” “facilitator,” or “requirements document creator.” None of these terms has a direct link to business value. So the business analyst’s role is a hard sell. In some organizations Agile is a direct attack on the business analyst role because this kind of intermediary role is seen as overhead or – even worse –as a drag.

If I were a business analysis practice lead, I would be really working hard to define the specific business value that my group delivered and align my people to that. I think the best place to start is to focus on three roles for the business analyst: designing the technology-focused aspect of a product, creating technology-based capabilities that enable new products or significant changes to operational processes, and optimizing operational processes.

Unfortunately I don’t see a lot of organizations aligning their business analysis practices to this kind of value proposition.

GB –The business analyst should understand the business need, business capabilities, and range of available options and provide a robust justification for the proposed solutions. For me, there are several elements that define the business analyst’s value. First, they help define, manage, and control the scope of the product or solution. Second, as a dedicated resource, they communicate the urgency, value, benefit, and risk of the proposed solution. Third, they clearly elicit, analyze, document, and manage the project’s requirements. They also define the problem, get buy-in from stakeholders and the project team, and define and communicate the business solution.

GG – Like George, I believe the true value of a business analyst is their ability to correctly research business problems and develop solutions that address needs. When appropriately aligned with organizational goals, business analysts can create a tremendous amount of value. However, I think their full value gets diluted when they’re solely focused on internal initiatives. I believe business analysts could be aligned with product managers very effectively. This would further expand the scope of a business analyst’s responsibility outside of the organization and further increase the value of the role.

Moderator: Let’s move on to the project management role. I’m interested in hearing your thoughts about the value of a project manager. Who would like to go first?  

FK – I’ll go first. This one is pretty clear cut from my perspective. Project managers play the governance role of an asset steward. They’re responsible for keeping resource usage on track for a given initiative of the enterprise. As such, they take a proposed solution, develop the cost/benefit (or other type of value analysis), prepare a plan, monitor adherence to plan, take care of deviations, and minimize the impact of problems during implementation.

NM – I’d agree with the others and just add that the project manager can have a relatively wide range of value. There’s the traditional time, cost, and delivery tracking that is part of any project. But there’s a lot more to this role than simply tracking progress. A project manager adds real value when they can fully embrace their initiative’s goals. When this happens the project manager can help direct issue resolution towards outcomes that make well thought out trade-offs and prevent a project from being delayed and from straying from its objectives.

Moderator: George, what’s your take?

GB – The value of the project manager to the organization is their ability to effectively manage the competing demands of time, cost, scope, resources, risk, and quality. These six competing demands — along with customer satisfaction — are the basis for managing the success of any project. The project manager has to manage the inevitable tradeoffs associated with these competing demands throughout the project. Project managers coordinate all of the contributors to the project to deliver value to internal and external stakeholders.

PART 2 –

Moderator:  Now that we’ve framed how each of you perceives the value of project management, what is the biggest issue with the project management role today? Greg, how about going first?

GG – Sure, Steve. I think the greatest issue project managers face today is the possibility of being viewed as overhead. I’ve never felt this way, but I know that this is a risk in some organizations. This is particularly true of project managers that don’t effectively link the goals of the project to the company’s business objectives. Project managers really need to focus on correctly defining this linkage and ensuring that their projects demonstrate value to the organization.

Tied to this issue is the fact that too many projects don’t actually add value, are never cancelled, and sputter on consuming valuable resources when everyone involved in the project knows it’s a wild goose chase. It’s one of the most difficult aspects of a project manager’s job in my opinion – akin to telling the emperor that he has no clothes as the saying goes. But frankly, project managers must find creative ways to tackle these types of challenges.

Moderator: Frank, I take it you want to go next?

FK – Absolutely. I think the biggest issue relates to the type of problems project managers deal with. They’re more skilled at implementing a solution than solving business problems. This often depends on the industry. I’m actively involved with a lot of construction projects, and the project management role in these efforts is critical; construction projects require program offices with many project managers. In this setting, the central issues are consistency of project manager performance, skill level, and experience level. Many of the project managers that I see in that industry are Project Management Institute (PMI) certified.

In the computer applications systems space, I think project managers lack a good feel for the reality of gathering requirements and what’s needed to successfully manage product development projects. The technology field is less mature than the construction industry, and the skill level you’re managing is much higher than you typically find on a large construction project. So the issue is one of dealing with educated professionals.

NM – I’d add to Frank’s comments and say that the biggest issue for project managers today is that they are often little more than a project’s bookkeeper. For a project manager to create some larger value to organizations, they have to play a larger role in evaluating issues and risks. The project manager must evaluate issues for impact and resolve them, if possible. If this isn’t possible, the project manager must create a decision framework for quick resolution. If the issue is outside of the control of the project, then it’s a risk and the project manager needs to quickly identify and escalate this while they begin to develop risk mitigation plans. This is much more proactive role than most project managers are taking today.

Moderator: Let’s circle back to the business analyst. What’s the biggest issue with the role of the business analyst today?

GB – The biggest issue with this role is that it’s perceived as a new profession and isn’t as understood as it should be. The generally accepted practices are new to everyone and most of the enterprises see this role overlapping with the project manager and the system analyst. Business analysts are often not given enough time and resources to effectively do their job. The biggest challenge is simply gaining acceptance and anchoring the role effectively in the organization. Business analysts need the space to do their jobs effectively so they can contribute solutions that will meet company objectives and strategies.

GG – Although the International Institute of Business Analysis (IIBA) has done a good job of defining the skill set a business analyst needs, I think the biggest problem is that the role and responsibilities vary so widely among organizations. The act of business analysis is a component of almost any job inside an organization and I believe the roles of a business analyst should be more segmented. Thoughtful segmentation would give more clarity to all involved — from practitioners to hiring managers.

FK – Greg and I view this question similarly. I see the biggest issue as the definition of the role. The term business analyst is very general. There are many types of analysis, analysts, and analytics. The word analysis defines the domain or subject area that is of interest — like process analysis or financial ratio analysis. An analyst is the person who does the analysis — like the process analyst. And analytics are the algorithms you need to draw a conclusion from the analysis — like calculations. Our organization has listed more than 50 types of analysis that a business analyst might do and maybe 75 or 100 types of analysis. You can put the words analysis, analyst, or analytics after any one of the possible subject areas.

I also see another issue related to modeling. Many of today’s problems require different types of modeling such as decision structures, feedback models, dynamic models, management, and discipline models. I find that business analysts are good at interviewing and drawing diagrams, but not as effective at analyzing the problem. I think this reflects the current emphasis on business analysts doing application systems requirements and not really focusing on solving business problems.

Moderator: I’d like to conclude by asking each of you to look into the future. What does your crystal ball tell you about the business analysis or project management professions?

GG – I’m seeing greater emphasis on clarifying the role of business analysts. From the product management perspective, I can envision more emphasis on the product manager and business analyst relationship. I’ve always been a bit puzzled by the business analyst and project manager relationship, although I understand how it evolved. I think the common thread of creating value is a more natural linkage between the business analyst and the product manager, and I can envision a future where this becomes a preferred career path for a subset of the business analyst community.

GB – I see more project managers adding the business analyst skill set to their professional development by taking certification courses and training in business analysis. Some project managers may take on business analysis as a full-time profession. The same is true for senior business analysts. They may seek project management certification and take on project management full time. The roles will become more clearly defined and professionals will flock to the role that best meets their personal, professional, and organizational needs.

Some project managers will set aside their project management skills to learn the business and begin working in executive positions and provide business analysis to the organization. I see business analysis establishing their own department, where they’re not tied to IT or a particular business function. They will establish a business analyst Center of Excellence and offer independent objective solutions to the organization.

FK – The future business analyst must be much more versatile in applying problem-solving skills and techniques to the business. If they don’t, another discipline – like auditing – will take over the task. Auditing is already doing operational analysis because automation has decreased their role. And auditing can justify taking over the role because they have risk analysis experience related to process execution. So I see risk ahead for business analysts.

The future of project management may be a little brighter as the skills and methods seem to be better defined and I don’t see any other discipline interested in taking over.

NM – For the business analysis profession, I think the key will be whether it creates a single definition of business analysis. Business analysts must show a more direct relationship to value, or they face increasing marginalization.

Instead of the big tent approach to business analysis, I think it makes a lot more sense to break the role into different designer functions: process, product, business rule, content, etc. Successful organizations will find that moving the business analyst toward design roles that are aligned with concrete business value will yield real benefits. Organizations that don’t follow this path will likely view the business analyst role as overhead.

 Dont’ forget to leave your comments below.

Would You Like To Close Out The Year With Project Success?

FEATURENov30thfAs we close out the year, wouldn’t it be nice to achieve year-end results with critical projects?  As many companies and leaders get lost in the holidays, it is an opportunity for those who stay focused on the key priorities.  By no means should you forget the holidays and thanking your people for a good year; however, if you channel your efforts on the critical few, you could not only end the year on a positive note but also accelerate project results in time for year-end.

There are several keys to success in delivering project results; however, one simple yet secret weapon is follow-up.  The best plans are useless without follow through and follow-up. I’ve found it quite amazing the number of highly paid, intelligent leaders that do not value or do not make the time to follow-up. Why spend millions of dollars developing plans if you don’t plan to put in the work to make sure they occur?  So what are a few tips to ensure results occur?  1) Plan.  2) Prioritize.  3) Follow-up.

  1. Plan:  First, develop a simple plan.  What needs to be done?  By who?  When?  What support is required?  It doesn’t have to be fancy or use the latest technology (a scrap piece of paper with action items will likely suffice). This will provide the structure for your follow-up.  In my experience across hundreds of projects in multiple industries and geographies, working a simple list is the 80/20 of success
  2. Prioritize:  Prioritize your follow-up. It isn’t necessary to follow-up on everything. If there is one common mistake in today’s new normal business environment, it is getting caught in an endless sea of tasks in a survival mode.  Instead of going down that rabbit hole, think about what’s most important.  What can have the largest impact on your project between now and the end of the year? Next, follow up on only those priority tasks; for example, the critical path or the A priorities.  If you follow up on only the tasks that are key, the people related to those tasks will intuitively realize the implied importance and prioritize accordingly. Additionally, the more you are able to explain why the specific tasks are important, the more the people responsible for the tasks will understand and value them themselves. On the other hand, if you followed up on every task, it would just become a nuisance, and you’d likely be ignored.
  3. Follow up:  Think function & not form. It doesn’t matter whether you follow-up via email, phone, a fancy software or whatever. What matters is that you follow-up. You will achieve the best results if you change your follow-up style to the person you are following up with. For example, if you are following up with someone who reads email voraciously but doesn’t typically talk on the phone, send an urgent email. On the other hand, if you are following up with someone who enjoys talking with people (regardless of whether he/she has email), pick up the phone.

When you follow up, make sure to follow up in advance of the due date on critical tasks and critical path items. This gives the person an opportunity to remember and plan for the task. I’ve found that 99% of the people will complete the task with this type of follow-up, whereas, without the follow-up, I might receive a 50% completion ratio, mainly due to conflicting priorities and busy schedules.

It isn’t complex, expensive or requires capital investment to follow-up, it just requires a bit of energy, yet, it yields significant results. Why not close out the year with your project team celebrating a significant “win”?

Don’t forget to leave your comments below.

PMs and Hockey Players

My son’s hockey team won a tournament recently that included a series of hard-fought, well-earned victories.  As the athletes came into the lobby from the locker room, everyone cheered, recognizing each individual contribution.  Another mom made a comment out loud that many of us hockey parents think just about every time we see them come out of the locker room: “They’re so little!”

It’s truly amazing to see 9-year-olds play hockey at the level that this team plays.  They skate on the ice as though they’re dancing on pavement.  They handle a stick with astounding skill.  They move the puck up and down the ice with agility that sometimes takes my breath away. 

It’s not hard to get caught up in this level of play and start cheering, shouting…OK screaming:  “Hustle!”  “Pass!”  “Move your feet!”  They are so good and they make it look so easy.  Fans sitting on the bench start to wonder, “What’s your problem? Shoot the puck!” 

Then after the game they come out of the locker room and you see them as…little boys.  With height not augmented by skates, bodies not donned in pads and equipment, faces not covered by helmets and masks, they’re just the little kids who like Saturday morning cartoons and still sleep with a favorite toy.

If it doesn’t make you feel a bit silly for all the screaming you did, it sure does make you appreciate how good they really are.

Project managers don’t wear pads and helmets while managing projects and we don’t get a locker room from which to exit looking like a humbler version of ourselves to invoke appreciation for what we do.  

We do, however, get senior level folks to sponsor our projects and advocate for what we’re trying to accomplish.  We get access to resources, support to schedule and run meetings, and we may get training to help us do our jobs better.  We get teams of people and the wealth of organizational knowledge about what’s worked and what hasn’t on past projects.  So there may be stakeholders on the sidelines wondering, “What’s your problem? Deliver on time!”

Well, it’s tough out there on the project ice. Even when we get the sponsorship, resources, and skills we need to do our job, stakeholders are conflicted, organizations are in flux, and resources change.  While it may not look that hard from the bench, some days it’s amazing that we get consensus or momentum on anything. 

High expectations for project managers are a good thing.  But sometimes after a hard day, it would be nice to have a locker room where we could take off all the emotional and intellectual equipment we wear to get our job done and emerge for others to get a little different perspective for who we are:  someone just trying to get the project done for the benefit of the organization and everyone in it.

Don’t forget to leave your comments below.


Andrea Brockmeier is the Client Solutions Director for Project Management at Watermark Learning.  Andrea is a PMP® as well as Certified ScrumMaster.  She has 20+ years of experience in project management practice and training. She writes and teaches courses in project management, including PMP® certification, as well as influencing skills. She has long been involved with the PMI® chapter in Minnesota where she was a member of the certification team for over eight years. She has a master’s degree in cultural anthropology and is particularly interested in the impact of social media and new technologies on organizations and projects.

Root Cause Analysis and Corrective Action for Project Managers

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.

  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 contribute?
  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 out to 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.”

Don’t forget to leave your comments below.


Duke Okes 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.

Gareth Byatt 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. Gareth 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. He has presented on PMOs, portfolio and program and project management at international conferences in the UK, Australia, & Asia including PMI APAC in 2010.

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.

Jeff Hodgkinson is a 32 year veteran of Intel Corporation, where he continues on a progressive career as a program/project manager. Jeff is an 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: www.linkedin.com/in/jeffhodgkinson. 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, GPM™, IPMA-B®, ITIL-F, MPM™, PME™, PMOC, PMP®, PgMP®, PMI-RMP®, PMI-SP®, PMW, 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.