Author: Gareth Byatt

Tips on Stakeholder Management

Written by Gareth Byatt on December 19, 2012. Posted in Articles. 4 Comments on Tips on Stakeholder Management

hamilton Featurearticle Dec19 In many cases, managing stakeholder expectations while managing projects or programs within their constraints is as much an art as a science. It takes a balance of knowledge, tools, and “soft skills” on the part of the Program/Project manager, and an environment that is conducive to success. With so many factors to take into account, what does it take to successfully work with the stakeholders on your program or project? All of us who work on programs and projects face this question.

A great deal of excellent guidance material, tips and techniques for working with stakeholders exists. In this brief article, we aim to provide you with a synopsis of things to consider, some “food for thought,” if you will, including some ideas and techniques that we have seen work well in our own experiences running programs and projects.

1. What or who is a stakeholder?

Let’s start by defining what a stakeholder is. The Project Management Institute’s A Guide to the Project Management Body of Knowledge (PMBOK® Guide) describes a stakeholder as a person or organization that:

Is actively involved in the project
Has interests that may be positively or negatively affected by the performance or completion of the project
May exert influence over the project, its deliverables or its team members

Within the context of a project, The UK’s Association of Project Management defines stakeholder management as follows:

“Stakeholder management is the systematic identification, analysis and planning of actions to communicate with, negotiate with and influence stakeholders. Stakeholders are all those who have an interest or role in the project or are impacted by the project.”

We shall use these definitions as our starting point.

2. Should you think of your stakeholders in groups or segments?

When considering whether to group stakeholders together, you are asking yourself: what “stake” does this stakeholder, or do these stakeholders, have in my program/project? Several dimensions can be used – choose what works for you (if it makes sense to do so). An example of one dimension is to break them into responsibility, such as the client, the project team, suppliers/contractors, the end consumer(s), activist groups, and so on. Another method is to categorize stakeholders by their level of influence and their level of support. Some people use “stakeholder maps” to graphically show who their stakeholders are, and who is most important or “closest” to the program / project.

3. What do your stakeholders think constitutes success on your program/project?

In a previous article on Project Success Planning, we posed the question “What does success mean?” to everyone on your program or project. In another article, The Nine Critical Steps for Project Success, we discussed documenting all stakeholder expectations early (step 2, for those of you who recall this article). As we mentioned at that time, small projects may collect stakeholder expectations through personal interviews or by email. Larger programs and projects, with stakeholders potentially numbering in the thousands, may need to employ more sophisticated/broader techniques such as sampling and extensive consultation. Different stakeholders (or groups of stakeholders) will view your program or project through different lenses, and this is something over which you will only have limited control. Some stakeholders will be against your program or project, and you will need to determine how to work with them.

The takeaway message is that it is important to understand your key stakeholders’ meaning of success (or why they oppose your initiative), work with them to understand why they think of the program/project in this particular way, and get on the same wavelength as them. Understanding their viewpoints is the first step to knowing how to respond and inform them appropriately.

4. How do you resolve conflicts between stakeholders?

One issue that is all too common is the lack of a defined process for resolving conflict amongst stakeholders. A stakeholder influence diagram is often used to prioritize stakeholders; however, less influential stakeholders can have ideas that are discounted. Balancing the influence on decision-making to add benefit to the program/project is vital to success.

5. Should you create a Stakeholder Management Plan?

In our experience, it can be useful to create this type of plan, as long as it is then used by your team. Creating a Stakeholder Management Plan just to satisfy a company procedure, and then putting it “on the shelf” or forgetting to carry out the actions it contains is a waste of valuable project resources.

6. Is it worth keeping a “CRM log” to track your stakeholder relationships?

CRM or Customer Relationship Management is a term widely used in marketing circles, and basically means to keep track of customers. This principle can be applied to your stakeholders. Do you have a list somewhere of all the stakeholders you deal with? If you don’t, think about creating one – you will probably be surprised by the number of people you liaise/work with. Whether you think keeping a register is or is not of value is up to you. You may find it a helpful process to review your stakeholders, say, once a month, to ensure you are keeping on top of things. Spending 30 minutes each month summarizing any key comments such as when you last contacted people, how helpful they are being to your initiative, and who you need to put more effort into speaking with next month could jog your memory and ensure that you have things covered.

7. How can you influence your stakeholders?

Exerting influence in a subtle way without using formal authority (for the most part) is key to successfully working with your stakeholders. Whilst you will have formal authority bestowed on you with some stakeholders on your program or project, with many, you will not. Program and Project Managers should be conversant with the basics of what is known as Organization Change Management” to help them with this. Various approaches to managing change in an organization exist; the basics are about ensuring there is a level of understanding early, and then continuing this effort to communicate to ensure that this understanding turns into support and willingness to adopt change. Using a few simple techniques and approaches to get your stakeholders on board will go a long way toward helping your initiative to succeed. In particular:

Start the process early on; do not leave it until well into the Execution phase.
Be very clear with your communications.
Be open and honest with people.
Show a genuine interest in “what is happening in their world.”
Gain feedback and take it into account – do not make it “one way traffic.”
Keep up the “hard yards” of talking with people.

8. This is all great in theory, but I don’t have time!

We all know the old adage, that project management is 90% communication. A large proportion of communication is working with stakeholders. If you cannot devote quality time to working with your stakeholders using well-conceived strategies, you will probably be placing your program or project at risk in some way or another.

Don’t forget to leave your comments below.

The Virtual Project Team – Is it right for me?

Written by Gareth Byatt on December 5, 2012. Posted in Articles. 5 Comments on The Virtual Project Team – Is it right for me?

Gareth FeatureArticle Dec5 In today’s workplace, the use of virtual project teams and, for that matter, virtual workers in general, is increasingly common. There are many reasons for this: younger workers entering the workforce who bring new attitudes about virtual working patterns; a larger number of employees wanting to balance work and life; and companies seeking ways to save money, just to name a few. The emergence of the ‘virtual project team’ actually began more than 20 years ago; roughly 15 years ago, it started to gain ground as collaboration technology became more advanced. It could even be argued that industries such as construction have been using quasi-virtual teams for decades. Much has been written on this topic, including two articles that we authored in 2010 (Managing a Virtual Team and Communication Risk Within and Around a Virtual Team) discussing the communication risks associated with virtual teams and offering some advice on managing virtual teams. For this article, we choose not to further debate the advantages or risks of the virtual project team, but to ask the question, “Is a virtual project team right for me?”

To answer this question, let’s start with the definition of a virtual team. For the context of this article, we define the virtual project team as one that does at least 75% of their work without co-locating in the same physical location. A good example of a virtual team is our own article writing. The three of us have been a virtual team for three years, writing collaboratively without meeting face-to-face in order to produce our articles to an agreed ‘project plan’. With this definition in mind, let’s first approach the question from the individual viewpoint.

Employee attitudes have the appearance of becoming markedly shifted from the days of the 60’s and 70’s, when people’s goals were to work hard, be promoted, and aspire to one day ‘have the corner office’, a better parking bay and the other perks associated with lifelong employment at a single company. Or have they? Many employees maintain these same outwardly attitudes, and there is nothing wrong with rising through one or two organizations in your career. However, a growing number of employees, especially the younger generation, are entering the workplace without ever knowing of a world where data was not ‘real time’, who assume that online ways of working are the ‘norm’ and that ‘we are accessible from anywhere’. Upon further inspection, the perks these new age virtual employees seek are not that far removed from those of previous generations. They want to be recognized and valued for their contributions, but also have expectations of a better work balance, a continuous challenge and, often times, a well-defined career path. The “better corner office” of yesterday, is the “better online presence” today. The recognition of their value, regardless of the physical attributes, is the underlying common element that has been the common motivator of employees for centuries. Many of these new age youthful knowledge workers, as well as more mature workers (who may have reasons for seeking a change in work style) are likely to encounter situations in which virtual work is required. Will it suit them? We believe that one must consider five key questions:

How comfortable are you with modern technology? In order to be a successful virtual worker, one must be at ease with the collaborative technologies that enable it. Another question is – does your company have such technology?
How best do you work? Are you task oriented and able to work well with little supervision?
How do you balance priorities? Competing priorities arise very easily in a virtual setting.
What is the corporate culture and attitude toward virtual employees? Is it a novel concept, or is it an established and ingrained core?
Do you, or can you, honestly see yourself as a full member of an organization if you work remotely for a long period of time (e.g., for the entire duration of a project, or maybe longer)?

If you do not match the traits needed, particularly those mentioned in the first three questions, then seeking virtual working opportunities at this time is probably not right for you.
Regardless of the size of the organization, virtual workers exist in today’s marketplace and all trending information available indicates they will remain for many years to come. Virtual working options have provided both the small and large organization alike access to a wealth of talent that otherwise may not have been available to them. With the value associated with tapping into a virtual workforce, one must ask when it is best to utilize this option for carrying out a piece of work such as a project. If you are considering searching for ‘virtual talent’ or looking at ‘virtual presence’ technology to enable virtual working, we suggest it will be worthwhile to consider the following:

What is your general attitude towards “work”? Is work an activity undertaken, or is it an output produced, or both? Obviously, some work cannot be performed virtually. Bridges need building, and physicians need to treat patients in person. Knowledge workers, such as those who produce written material, build websites, or support customers, may have the option of virtual working.
What is the dominant management style of your organization? Make no mistake about it – a virtual workforce (all or partial) is not right for every organization. If the dominant attitude of the organization is that performance requires employees to be closely managed in person, virtual working options are probably not appropriate.
Do you have the technical infrastructure to support the virtual working option? Are you equipped to provide the necessary technical infrastructure and workforce support that is required to enable the virtual presence of workers? This will be a key success factor in establishing the virtual worker.
Have you set up the right structure to work virtually without impacting others in your team or community of practice who are back at the office whilst you are working in a virtual environment?

We hope that we have provided some ‘food for thought’ on the virtual workplace. Whether you are an employee or an employer, the key is to determine whether the virtual presence is right for you and your environment. Don’t be too quickly drawn to the option and assume ‘of course it will work out’ if your work style or culture does not support it. This will only be a recipe for problems that could more than outweigh any of the benefits associated with virtual workplace.

Don’t forget to leave your comments below.

Realizing Benefits – It’s What Projects Are For!

Written by Gareth Byatt on May 16, 2012. Posted in Articles. 4 Comments on Realizing Benefits – It’s What Projects Are For!

Co-authored by Jeff Hodgkinson

Realizingbenefits4_main We believe a simple methodology can be applied to attain Benefits Realization. You can achieve true project success by ensuring that:

Project benefits are clear, concise and relevant in ‘value creation’ terms from the Business Case onwards, and that they directly relate to your organisational strategy
People are held accountable for achieving these benefits
Benefits stated in a Business Case are actively measured throughout the entire initiative, ie:
- During the project lifecycle (particularly if it is released in phases)
- After the project is closed
- When the product/output starts to be used
Appropriate action is taken if required to alter direction (i.e. the organization changes course and the intended project benefits are no longer relevant)

Simple Process Flow for Project Benefits Realization

Realizingbenefits1

It Starts with a Good Business Case!

In the project management community, it is generally accepted that a project starts in earnest once a business case has been agreed to and various other initiation tasks are complete. The question now is, “Does your business case remain a core reference document throughout the project’s lifecycle?” or does it go into the project files, to be reviewed only if, say, key stakeholders request a change order or when project auditors visit?

Business cases vary in size and complexity. A business case, and the process to agree to it, should include the following elements relating to benefits realization:

Clearly show how the initiative contributes to the organizational strategy including the core reason for the initiative. There must be measurable benefits that specifically relate to the organization’s goals and objectives
People must be named as accountable for ensuring the benefits are achieved (and they must know and accept this accountability)
People must agree to these benefits being monitored over time, with appropriate adjustments made when necessary

Our Three Main Points

1. Contributing to the Organizational Strategy

Circulate your proposed business case benefits with all key stakeholders to ensure they “stack up”, and a ‘governance’ control group should oversee and approve key project decisions regarding agreed benefits, including business case approval. Remember, it can be all too easy to inadvertently omit certain stakeholders from the loop. From the beginning, ensure benefits monitoring is built into your project – it will keep you on track to deliver what your cstomer needs. It is most useful to include the strategy for tracking benefits in the business case. This can be high-level or it can be a detailed explanation, depending on the circumstances. One word of warning: benefits tracking can mean many things, and can be subject to lack of clarity without the right level of rigor being applied. The sample extract from a business case below shows benefits, accountabilities, metrics (if applicable) and the proposed timeframe for realization:

Realizingbenefits2

When assessing benefits, and following through in the post-delivery phase, one should talk to people across the organization vs. taking one person’s opinion as the complete story. Ensure that the focus is on creating value, and that it is realistic. For example, drawing up “use cases” of real-life scenarios of how people will perform activities with the new deliverables in place can help to define the realistic benefits. This is what may be termed “active planning” for change, rather than “passive planning” as it means you will understand the true value creation process. It can help ratify the scope and intentions of your project, which should mean the people nominated as accountable for achieving the benefits are confident of their delivery (and hence they should be comfortable in signing up to them).

A business case may not always state specific financial benefits. Projects can be charted to contribute to a strategic objective of an organization where:

Clear-cut financial returns are not directly evident.
Are Implemented as control measures in response to statutory requirements or legislation.

It is wise to include financial metrics in a Business Case only if they can be substantiated; financial justifications should not be included if you cannot justify and measure them (but track financial improvement in future if possible).

2. Assign Accountable People for the Benefits in your Business Case

The governance group you establish for your project plays an important part in ensuring benefits are measured once the project is closed and the operations or sustaining teams start to use the deliverable.

Assigning key people as accountable for realizing stated benefits should give a business case the importance it needs to ensure those benefits are traceable. The key to success is to make sure the benefits are realistic and measurable.

To link business case benefits with ongoing benefits realisation, we have found it useful to clearly state in the business case that a benefits realisation plan will be implemented to track the proposed benefits over the initiative’s total lifecycle. We have found it can be helpful to include the proposed benefits realisation plan tracking mechanism as an addendum to the business case.

One example format (many exist) is shown below:

View Larger

3. Monitor Project Benefits Over Time

Successful project delivery is an important first step to achieving business benefits – completing a project on time, budget and to expected quality levels sets the platform for ongoing success. However, what we are most concerned about in benefits realization is to ensure the deliverable that the project provides generates benefits as intended (or perhaps new, unforeseen ones) over its lifecycle.

Sometimes project deliverables need to be adjusted before the project is complete or at a point in time after project closure. For example, as circumstances change, unexpected external impacts arise, or new opportunities result in a change of organisational strategy. This is often true for long duration projects. Such changes need to be fed into the benefits realisation plan, so that it is kept up to date and is ready to be used as soon as the project closes.

We have found that benefits realisation plans can be structured in “layers” – that is, specific project benefits can be measured regularly and aggregated at a program and/or portfolio level for overall benefits assessment and tracking.

Our Conclusions

The realisation of project benefits can be considered to be dependent on the following five principle factors:

Business case benefits should to be clear and concise, and relate to the organisational strategy
Give your business case importance by assigning the people who will be accountable for achieving stated benefits in your business case (after obtaining authority to do so). Make sure the business case signatories agree and understand that benefits will be tracked and corrective actions will be taken in the event of a change or direction, or failure to realise the stated benefits
The benefits stated in a business case should be actively measured through continuous participative engagement after project closure in a benefits realization plan
Action should be taken if a benefit is not being realised (for example, if the organisation changes course or the project deliverables are no longer relevant)
Lastly, giving people a continued focus on benefits throughout a project helps keep it on track, and for the “big picture” to be maintained. It is from this vantage point that we can ensure projects deliver the benefits they were intended for.

Summary Extract

Today, more than ever, project benefits need to be achievable, then realized and then sustained (maintaining relevance) when your project is complete and its output goes into use. Adopting a simple ‘project benefits realization tracking method’ starting from the project’s business case onwards can help you achieve this…

Mini Glossary:

Terms Used	Brief Description
Benefits Realization	What the project intends to deliver to the customer/stakeholder upon completion.
Business Case	Why the project is being done and what justifies the resources being used.
Project Lifecycle	The phases a project goes through between start to finish. Typically 3 to 5.
Project Benefits	What will be the long term results or gain derived after completion of the project.
Governance	Management group that approves the project charter and subsequent phases if needed.
Strategic Objective	High level business objective which the project has inclusion to achieving it.
Deliverable	A result gained either during or at the completion of a project.

Don’t forget to leave your comments below

Gareth Byatt is Head of the IT Global Program Management Office for Lend Lease Corporation He’s a PgMP and PRINCE2 practitioner, and holds an MBA and first-class undergraduate management degree. Gareth has worked in several countries, and is currently located in Sydney, Australia. Gareth has 13 years of project and program management experience in IT and construction. Gareth can be contacted through LinkedIn.

Jeff Hodgkinson is the IT Hosting Transformation Program Manager. He is a 29-year veteran of Intel Corporation with a progressive career as a Program/Project Manager. Jeff holds numerous certifications and credentials in project and program management including PMI’s PgMP (Program Management Professional) credential. He obtained his PMP (#713) in 1991. He is located in Chandler, Arizona, and also volunteers in various support positions for the Phoenix PMI Chapter. Due to simply helping people, ‘Hodge’ as referred to by his many friends is one of the most well networked and recommended persons on LinkedIn.

Gareth and Jeff met through LinkedIn and share a common passion for program and project management theory and practices. Though they live half a world away from each other collaborate and co-author articles. Together they bring over 40 years of experience into their subject writing for the benefit of their colleagues worldwide.

Project Success Plans – Planning for Success

Written by Gareth Byatt on May 16, 2012. Posted in Articles. 2 Comments on Project Success Plans – Planning for Success

Co-authored by Jeff Hodgkinson and Gary Hamilton

“A Project Success Plan can be a platform for ensuring all project stakeholders start off, and continue on, the right footing.”

Setting up projects to succeed in the view of the customer/stakeholder is a critical part of the Project Manager’s role. We suggest that, as part of project planning activities in the early stages of your project, you should hold a Project Success Plan (PSP) meeting with all key team members to agree on the project’s goals, and to discuss the emotional success factors that will ensure the team gels successfully to deliver the required outcomes.

A Project Success Plan (PSP) is different from a Project Management Plan (PMP), sometimes referred to as a Project Execution Plan (or PEP). A PMP is a typically produced by the Project Manager to describe how the project will be managed and controlled in its delivery/execution phase, whereas the PSP is a documented meeting convened by the Project Manager to discuss and agree “what success means” to all key stakeholders. The PSP (like a PMP/PEP) should draw from project artefacts such as the Project Charter and the Customer Brief.

Project Success Plans can Help the Team to “Gel”

Have you ever managed or been involved in a project where, at one point or another, you felt that you were not on the “same page” as other team members? Ensuring everyone on a project team is continually pulling in the same direction can be a challenge. A Project Success Plan can help you to set a solid foundation for stakeholder interactions throughout the project, and to ensure you can detect and rectify any occurrences where stakeholder views and actions start to deviate off plan. In order to ensure everyone starts off on the right foot, it is important to kick off your project communications strategy properly. By this we mean, ensuring that everyone’s interpretation of success and their assumptions about the project are aired and discussed in an open group forum, which can be documented and evaluated in a Pareto-type chart format to indicate importance. This is the essence of the Project Success Plan.

The Project Success Plan is a communications planning tool in the project manager’s toolkit to get all key project stakeholders on the same page, and understanding each other’s prerogatives and drivers for success. This is not always an easy task, since there are likely to be a range of drivers and interpretations of project success amongst your stakeholders. For example, team members who are recipients of the end solution/product may have very different views and expectations of what project success means to those who are focused on delivering the product. It is also likely that some (or maybe all) team members in your project will be working together to achieve a specific objective for the first time. Indeed, the number of stakeholders who have worked together on projects before is an interesting statistic for the project manager to take note of at a project’s start. A Project Success Plan meeting should aim to achieve the following outcomes:

serve as an ice breaker for team members to get to know a little about each other
discuss and agree the basis for setting the criteria for achieving success;
team members agree and commit to their roles and responsibilities for the project;
everyone should understand each other’s personality and modus operandi;
everyone’s assumptions about the project and their drivers should be aired, discussed and documented;
a win/win philosophy and a collaborative approach throughout the project needs to be fostered,
the team should discuss their collective lessons learned from previous projects/experiences.

The points above are all about communication and common understanding. By understanding how to handle your key/extended teams’ communications with each other, stakeholders can avoid accidental and sometimes costly mistakes in communicating information and decisions during the project’s life. For example, ensuring that people discuss how meetings, reports and controls should be conducted will help set reporting expectations (e.g. if one person thinks project status reports are “a waste of time”, find out why and talk it through).

Because of the emotional focus of a Project Success Plan meeting, it should be held face-to-face whenever possible, however this may not be possible for smaller projects – particularly those that involve geographically disperse stakeholders. In such situations, a virtual conference meeting may be the most practical option. This requires special emphasis from the Project Manager in facilitating the meeting to validate everyone’s opinions frequently, ensure good feedback, and level set expectations for the project, since the important signs of body language will be missing.

The Timing of a Project Success Plan.

A Project Success Plan should be completed early in the project’s life, as soon as all key members of the project team are in place. Key members are those with a material interest and/or delivery focus in the project. The timing for holding a Project Success Plan meeting can typically be after initial set-up works are complete and the project reaches the start of its detailed planning phase. If stakeholders change during the course of the project, the project manager should include reviewing and updating the PSP with the new stakeholders as part of the Resource Planning.

A Project Success Plan can also be a tool the project manager uses to keep the team focused and engaged. When stakeholders are suffering from project fatigue, the project manager can refer back to the Project Success Plan and use it to motivate the team by reviewing the reasons for the project and what success means to each person.

How should a Project Success Plan be structured; Do All Projects Need One?

All projects will benefit from a Project Success Plan meeting, because it is a mechanism to ensure the following aspects are agreed to:

Do we all agree on the core reasons for the project’s existence?
Are we all on the same page? Can we agree how to work together (including our roles and responsibilities, team meetings and communication protocols, team member working styles, governance processes and expectations)?
Are our assumptions about the technical aspects of the project (such as the design, scope, build methodology, work breakdown structure, schedule, budget and method of managing change) clear?

Large, complex projects have many different stakeholders, often spread across many geographic locations. A Project Success Plan for a large project may benefit from being led by a skilled facilitator, and it may need to last several days. Small projects with less complexity will typically not require the same level of detail.

The structure of a Project Success Plan meeting should ensure the emotional success factors are fully aired. It needs to bear relevance to the core Deliverables of the project regarding scope, budget, schedule and quality. An example of a Project Success Plan meeting agenda is shown below (the nature of your project’s Project Success Plan agenda will be tailored to the project):

Agenda Item

1. Project Introductions and Executive Summary

2. What is the definition of “project success”?

3. Our Project Methodology

4. Project Fundamentals, Principles & Key Drivers

5. Project Assumptions by us all, and how we all work

6. Project Scope, WBS, Schedule, Quality and Budget

7. Project meeting, governance and review strategy

8. Project Organisation and Role Definitions

9. Communications Management strategy

10. Tracking Benefits after Go Live

Conclusions

A Project Success Plan is a mechanism to achieve the following positive outcomes for your project:

Ensure all assumptions about the project, and the meaning of success, are aired and discussed, and any misunderstandings and/or disagreements are resolved early in the project’s lifecycle.
Ensure project team members get to know how to work with each other so that communications throughout the project are efficient and productive
Assist the project manager in keeping the team focused and engaged, especially on projects of long durations.

Done well, a Project Success Plan meeting can help project managers and the entire team understand how to work together successfully, communicate well with each other, and be a tool to keep the team focused and engaged for the duration of the project.

Planning for success increases your likelihood of a successful project outcome. It is always important to ensure the “facts” of project scope, schedule, design, quality and budget are given due consideration. It is equally important to ensure the emotional aspects of project teamwork – team member expectations, their way of working, their personal aspirations for the project and their assumptions on how the project will unfold – are managed. A Project Success Plan is a method to bring out these emotional aspects. It can be a good platform to ensure the whole team continually pulls in the same direction to make your project a success.

Don’t forget to leave your comments below

Gareth Byatt is Head of the IT Global Program Management Office for Lend Lease Corporation. He’s a PgMP® and PRINCE2 practitioner, and holds an MBA and first-class undergraduate management degree. Gareth has 13 years of project and program management experience in IT and construction. He can be contacted through LinkedIn.

Jeff Hodgkinson is the IT Cloud Program Manager for Intel Corporation. He is a 30-year veteran of Intel with a progressive career as a Program/Project Manager. Jeff’s credentials include PMI’s PgMP® and PMI-RMP® (Risk Management Professional) Jeff was 2^nd place finalist for the 2009 Kerzner International Project Manager of the Year Award. He can be reached through LinkedIn.

Gary Hamilton is the Manager of the PMO and Governance within Bank of America’s Learning and Leadership Development Products organization. Gary has 14 years of project and program management experience in IT, Finance and HR. He holds an advanced MBA degree in Finance and several certifications and credentials program management including PMI’s PgMP® (and PMP®.. Gary can be contacted through LinkedIn.

Root Cause Analysis and Corrective Action for Project Managers

Written by Gareth Byatt on November 9, 2011. Posted in Articles. 3 Comments on 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.

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?
Analyze 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?
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.