Stakeholders or Clients?

When determining the requirements and the risks associated with your project, how do you regard and engage with each of the stakeholders you identify? How seriously are you treating the risks and concerns they raise?  I'd like to convince you that the way you think about and treat those stakeholders, and the value you place on their inputs, can have a significant impact on the outcomes of your project.

Stakeholders can fall into many categories, each having varying levels of impact and influence on your project, and it is arguable that some of them - particularly the most critically influential (often those most likely to be impacted by your project) - should be treated as clients, and their concerns as criteria which must be met.

In my last article, I reflected on the fact that project failure rates are extremely high, especially those which have high numbers of stakeholders, and for those that require environmental assessment approvals. In other words, failure is often high when the needs of stakeholders OTHER than the client need to be met within the scope of a project.

Studies on project failure causes often cite scope creep as a primary reason for cost overruns and schedule delays, and many studies clearly indicate that much of the scope creep is due to stakeholder issues. 

In the natural resources sector, this fact is well known, and many companies are very engaged with local communities at early stages of their projects. The industry seems to be learning from its past mistakes, and as a result, some progress has been made in terms of reducing the rates of failure, or at least minimizing the extents of the failure itself.

However, as more traction is made by protesting audiences, more projects are denied approvals, and as legal requirements increase in stringency, it is a question on how project performance stats will continue to roll out.

On the one hand, companies are learning (or for those laggards out there, being forced to improve by ongoing changes in approval processes and regulation). On the other hand, are they learning quickly enough, are they becoming proactive, and are they thinking about doing more than just what's required, as dictated by a regulator? Rather, are they doing what's best, what's expected, and what they would personally want if the development were being imposed upon themselves?

So, my stance is this - those project failure rates and causes did not come to fruition because of those external influences. The scope creeps and delays referred to were not caused by the stakeholders. No, they occurred because we didn't do our jobs. We didn't identify those risks and influences on our projects, we didn't hear the concerns and objections to the project from the stakeholders we did identify, and we didn't realistically consider the impact they might have on our success of gaining approval. We failed because we didn't consider what the entire scope of our project needed to entail.

We didn't think. 

We didn't listen.

We didn't place enough value on other's concerns. 

Let's step back to the identification of stakeholders. As mentioned, they can fall into many categories. Here are some off the top of my head (every project is unique and I know not all have been mentioned here!) I've categorized them based upon the example of a natural resources project:

  1. Project team - sponsor, planners, schedulers, estimators, designers, procurement, discipline managers, etc.
  2. Key internal business drivers (too often managed separately from the project team) - corporate strategic planning, legal, safety, health and environment, external communications and community engagement, etc.
  3. Key external business influencers - regulators and environmental assessment agencies, local communities, not so local communities, and other NGOs with concerns
  4. Other internal business influencers - finance, human resources, IT, etc.
  5. Future operational (and execution) stakeholders - construction roles / builders, suppliers, operators, maintenance personnel, etc.

Let's review the first and last groups first, then get to the key business drivers and influencers last.

1. Project team stakeholders

Note that, as part of a project team, we would expect to be fully engaged in every aspect of the project, as should be the case. In this respect, these 'stakeholders' are treated and engaged much differently than the rest. These people work together on a daily basis, with regular updates with respect to each others' progress. Issues regarding their discipline-focused and cross-discipline work are raised, options brainstormed, and concerns or risks resolved on a daily basis, through ongoing engagement and dialogue with their respective team members. One note of caution, particularly when there are many disciplines and specialists involved, is that conflicts can and often do arise between teams, and silo work is common - these issues can add significant risk to the project and must be closely managed.

4. & 5. Other internal influencers and future operational stakeholders

These are stakeholders that are often not engaged until late stages of a project, if at all. However, they can have a serious positive impact on your project success, if their input is sought out at early evaluation phases. They are experienced people who can point out significant risks, and tremendous opportunities to improve efficiencies and safety measures during construction and operation, they can indicate where designs are not practical to build or operate around, where secondary risks can develop, and more. Suppliers can indicate options to assess that might reduce transportation and equipment costs, operating and maintenance costs, or waste generation issues. The list goes on, and their feedback on the project scope should be sought out early and valued immensely.

2. & 3. Key internal and external business drivers and influencers

As I've suggested, it is often the case that those involved with key internal business drivers are managed separately from the project team, even if they are engaged for inputs to the project requirements. It is typical for the information from these groups to be used to indicate the business need for the project, and to help define constraints and boundaries of its scope, and sometimes they may be brought in to help in decision making or oversight stages of the project.

In regard to the external influencers, they are usually similarly managed separately from the project team, and although engaged for inputs to the project, are typically not included in decision making processes, but rather told what the resultant decisions were, (and sometimes why), to see if there is agreement. Unfortunately, this can have serious negative impacts on the schedule and cost of a project, since disagreements can easily arise around the reasons given for selections made, or the weighting of particular criteria. 

It's not my suggestion that where regulations come into play, those requirements aren't considered as design criteria, and strictly abided by. No, in fact these are taken very seriously by all industrial players - not doing so would result in a lot of wasted time and money, as approvals would never be granted!

However, often internal strategic targets and action plans, initiatives aimed at meeting or beating potential regulatory changes and increased stringency on environmental performance, and doing what is expected by an external community (or legally committed to by the corporate entity), are not brought into the scope of a project, or regarded as seriously as they should. In addition, opportunities for improvements are often treated merely as considerations.


Part of the reason for this is, in my opinion, because of standard project management training. While the well-renowned Project Management Body of Knowledge (PMBOK) guide includes details of stakeholder and risk management planning within its primary knowledge areas, it does not include management planning guidance for safety, health, environment, or external relationships - critical areas in developments within the natural resources sector.

In fact, in scanning the guide, there are very few references to these specialized knowledge areas - a couple of these are mentioned in the list of potential stakeholders to consider, others are indirectly referred to within 'other' or 'specialized' categories, and it is suggested that information regarding these topics might be found when reviewing 'Enterprise Environmental Factors' that might impact the project. Language around these topics are broad and vague throughout the guide. Of course, this is because it is a standard that needs to be applicable to ALL types of projects, without a focus on any one sector. So in this respect, these knowledge areas are rightfully left out. 

Recommended shifts in practices

Because the natural resources sector is so heavily influenced by the second and third categories of stakeholders above, and are so little referred to in the PMBOK standards, it is imperative that leaders and teams experienced in this sector be engaged to manage, and perform any work required for future developments.

Emphasis should be placed on the way we engage with and involve each of the key stakeholder groups through the duration of our project. As suggested, it is of utmost importance that the key internal stakeholders identified actually be integrated directly within the project team, and the concerns, requirements and processes that each of them identify, be added specifically to the criteria for the project deliverable. Not just added to a risk register to be managed.

In regard to the key influential external stakeholders, it may not be the preference of an organization to make them part of the 'project team', but again, their interests must be raised to the highest levels of significance. Their concerns, requirements and processes (i.e. EA & permitting processes, land owner development applications, etc.) must be fully integrated into the criteria, scope, schedule, and costs of the project.

Finally, it is recommended that not only should these key external players be invited to participate in making decisions involving the selection of alternatives to avoid or mitigate their concerns, but they should also become one of the clients listed within the project charter, to also approve project success.

Only these shifts will set up natural resource development projects for success.

While this may be a bit of a mindset adjustment for some, it really is common sense and shouldn't be so difficult. Just put yourselves in the shoes of those who live in the area where you want your development, those whose livelihoods depend upon the land in which you would like to inflict change, particularly long-standing change.

What would you want?