Stakeholder management

Stakeholder management2018-07-11T13:11:05+00:00

Overview

Stakeholder management is one of the basic tasks in successful delivery. After all:

“Unless a business truly engages its stakeholders, it will be paying some of its employees to initiate change and the rest to resist it.”

In a simple situation where there are few stakeholders, the product is mature and both Core Team and Extended Team are well established, stakeholder management is seldom a problem and no special measures may be required.

However, where any or all of these conditions are not met, some degree of active stakeholder management is desirable. In an Agile environment this can be complicated, because:

  • Agile in its core form tends to emphasise an inward-looking approach, focusing on the Core Team and seldom looking outwards. Agile training, for example, only rarely pay much attention to the wider organisation.
  • The stakeholders in question may not be operating in an Agile environment.
  • Many of an Agile team’s stakeholders will be more senior than anyone on the Agile team, so conflicts and disagreements will be harder to handle.

Why is stakeholder management important?

Engaging stakeholders is frequently cited as a key reason for success – and failure – of delivery.

It’s easy to see why:

  • Ultimately, it is your stakeholders who define the success of your work.
    • Business case, benefits, value of work as a whole.
    • How individual stories are interpreted.
    • Final satisfaction and acceptance of deliverables.
  • Stakeholders control many levers, including:
    • Many project preconditions.
    • Corporate policies, standards and procedures.
    • The corporate priorities, schedule and events.
    • Critical evaluations (especially Showcases).
    • Key information & decisions affecting successful delivery.
    • Key resources, facilities & materials.
    • Critical dependencies.
  • Stakeholders are key project contributors.
    • They make up both higher-level and (in organisations that are not yet fully Agile) local governance bodies.
    • They typically represent and manage your user groups.
    • … and also the resource pools from which your Core and Extended Teams are taken.
    • They provide many SMEs & project resources.
    • They are actively involved in accepting and implementing the solutions you deliver.

So failure to manage your stakeholders well raises a whole range of risks & issues.

The stakeholder management process

Stakeholder management consists of:

  • Identifying your stakeholders.
  • Creating an appropriate relationship with them.
  • Supporting your project through these relationships – and vice versa.

Note that this needs to include the whole of your relationship with them, including user stories, participation, communications, dependencies, governance, and so on.

The major steps in this process are:

Stakeholder management process

The details of this process are explained by the Manage Stakeholders practice.

Who are your stakeholders?

Hopefully, plenty of individuals and groups will be interested in your project. Generally speaking, a stakeholder is anyone who:

  • Will gain or lose from your project.
  • Can facilitate or obstruct its successful completion.
  • Will participate in your project (apart from the Core Team itself).
    • SMEs, support staff, etc.

In other words, they are only stakeholders if at least one of the following is true:

  • They play an active role in your project.
    • Governance, compliance, etc.
    • Execution, acceptance, implementation, deployment, support, etc.
    • As suppliers, regulators, etc.
  • Your project will change some aspect of their roles and responsibilities.
    • It may work to their benefit – or detriment.
    • It may require them to use up resources on your behalf.
    • They may need to provide information, advice or decisions.
  • They can potentially influence the success – or failure – of your project.
    • They manage a related or dependent project.
    • They control the strategy, portfolio or programme of which your project is part.
    • They are enterprise/business architects who define the solutions your project affects or relies on.
    • They are involved in higher-level or parallel governance.
    • They own other units competing for priority, resources, etc.

But who specifically does this mean? Well, it could mean any of the following:

  • Support functions
    • PMO.
    • Delivery Assurance.
    • Systems managers.
    • Architects.
    • Data managers.
    • Security.
    • External test teams.
  • Related (especially non-Agile) projects
    • Systems development.
    • Business re-engineering.
    • Operations engineering.
  • Implementation
    • DevOps.
    • Business operations.
    • IT operations.
  • Beneficiaries
    • Customers.
    • Technology Leads.
    • Internal users.
    • Business owners.
  • Governance
    • Sponsor/Champion.
    • Executive.
    • Business areas.
    • Vendor representatives.
  • Regulatory and supervisory
    • Board and senior management.
    • Internal audit and compliance.
    • Legal and regulatory.
  • External groups
    • Suppliers
    • Prospective customers.
    • Competitors.
    • Regulators.
    • Stock market analysts.
    • Media.
    • General public.

In your organisation they may go under different titles. And of course, unless you are running a very large programme, most of these will not be among your stakeholders. The crucial thing is to know whether or not they are your stakeholders, and then to manage the ones who are effectively.

Critical success factors

Stakeholders can kill a thriving project and breathe life into a failing one. So it is crucial to understand the Critical Success Factors in building and maintaining stakeholder relationships.

  1. Be thorough. Take time to identify your real stakeholders. They aren’t always who you think. If in doubt, include.
  2. Review and redefine what success means to each stakeholder regularly, and build & rebuild your relationship with them accordingly.
  3. Stakeholder relationships are complicated. Make sure you:
    • Capture & reconcile your stakeholders wants, needs and expectations.
    • Allow for what your stakeholders can and must do.
  4. Start managing stakeholder relationships early & stick with them throughout.
    • If in doubt, be willing to ask dumb questions – they’re probably as mystified as you are.
    • Keep going till you really understand them.
    • And then expect change.
  5. Establish practical relationships – create transparent & reliable points of contact, give regular, solid briefings, make data absolutely reliable, run convincing showcases, manage issues visibly & to a proper conclusion, etc.
  6. Make sure the rest of your team also understand & act on your stakeholders’ interests, priorities & concerns.
    • Satisfying stakeholders is their job too.
    • So given them the motivation, the space & the resources to do it.
  7. Sell your project. Build your stakeholders into a coalition of mutually supporting enthusiasts, who are as eager for your success as you are for theirs.
  8. Set clear expectations.
    • Make sure they understand how the project will work, especially their roles and responsibilities.
    • Don’t be afraid to manage them too.
  9. Always be completely open & honest – especially when you’re in trouble.
    • Don’t promise anything you can’t deliver, and always try to deliver more than you promise.
    • Deal with negatives quickly, robustly & honestly.
  10. Never abdicate ownership of stakeholder relationships. This is their project, but it’s your job is to deliver success.

Analysing your stakeholders

Once you know who your stakeholders are, you need to know what their relationship to your project is, so you can manage it effectively. This analysis (explained in more detail below) will provide a solid basis for planning how to manage stakeholders.

Stakeholder focus

Of course, not all stakeholders have the same interest in your work. So what is each stakeholder’s primary focus within the project? Here are the main options, which will tell you what the key issues you need to manage actually are:

FocusInterest
BeneficiaryGain – or lose – from what the Core Team will deliver.
GovernanceAccountable for the Core Team’s strategy, direction and success.
StrategySet the context – business, technical, operational, etc. – for the Core Team’s work.
DeliveryCreate and deliver a working solution.
SupportProvide services that will enable the Core Team to complete delivery.
ComplianceEnsure and check that delivery process and solutions comply with required policies, standards and procedures.

Identify what each stakeholder expects

Each stakeholder’s expectations are unique. However, there are some things all stakeholders expect:

  • You will provide:
    • a complete definition of your/their project.
    • skilled resources.
    • accurate estimates of effort, cost and timecales.
  • Timely, accurate and relevant reporting.
    • anticipating all problems.
    • avoiding surprises.
  • You will identify and resolve all issues, ideally without involving them.
  • Mitigation of risks.
  • Delivery of what you promised:
    • Meeting or exceeding expectations,
    • Defect-free.
    • On-time and within budget.
  • To know what is expected of them.

Most importantly, they expect all this even if they don’t say so.

Understand the complexity of stakeholder attitudes

Stakeholder satisfaction can be very complex. It is extremely easy to imagine that you know your stakeholders. You have their stories, which tell you very clearly what they want. And over time you get to know them, of course. But unfortunately this is not enough. As things change for your stakeholders – and they will change, often very quickly – you may be the last to know.

So to understand how to satisfy each stakeholder, you need to discover, balance and respond to all 5 key dimensions of stakeholder satisfaction – even when they are not expressed explicitly. These dimensions can summarised in this diagram, and are expanded in the table below.

The dimensions of stakeholder satisfaction

DimensionSignificance
What they say they want.What stakeholders expect doesn’t always show us where you expect it to. Make sure you are aware of:

  • The wider programme or business strategy.
  • The business case for the stakeholder’s involvement.
  • The Release Charter.
  • The stakeholder’s stories – including ones you are not working one.
  • Any outstanding change requests that may help to define this stakeholder’s stories, interests and concerns.
What they actually expect.Whether or not they mention it, whether or not it’s realistic, your stakeholders expect that the final deliverable will:

  • Retain the current solution’s strengths.
  • … and remove its weaknesses.
  • Unlimited capacity & reliability.
  • Ergonomic design + usability.
  • Achieve 100% integrity, availability + accuracy.
What they must do. Almost all stakeholders have certain obligations – where or not they know it, and whether or not they mention them! These include:

  • Legal and regulatory requirements.
  • Contractual commitments.
  • Corporate policies.
  • Business plans.
  • Local and global business, operational and technical standards and procedures.
What in practice they can do.Regardless of their aspirations or desires, there are usually limits to what changes stakeholders are able to implement, absorb or benefit from:

  • Competing plans.
  • Available resources.
  • Functional expertise.
  • Technical competence.
  • Budgets.
  • Change fatigue.
What they really need.Stakeholders aren’t always the best judges of their real needs, especially in rapidly evolving environments. There are also aspects of systems development of which they are seldom very aware that also need to be addressed by any working solution, such as:

  • Manageable operating costs.
  • Maintenance and support.
  • Future-proofing.
  • Housekeeping requirements.

In this complex situation, it is important to recognise that satisfaction requires:

  • Making all five dimensions of stakeholder satisfaction completely explicit.
  • Reconciling all five into a single solution.
  • Making sure this single solution works for all stakeholders.

Assess stakeholder impact

The next question is, How much can this project affect – or be affected by – each stakeholder? To do this, you need to evaluate:

  • The power (positive and negative) each stakeholder has over your work.
  • The impact (positive and negative) your work will have on them.

From this you can use the following table to estimate the priority of managing your relationship with them.

Stakeholder relationship table

So, in this project…

  • Members:
    • cannot facilitate the project much but can obstruct it.
    • will be very positively benefited by this project, with little downside.
  • Users:
    • have no significant influence over the project either way.
    • though it will greatly improve their position.
  • Enterprise Architecture:
    • have great power over this project, but mostly like it.
    • … and are little affected by it.
  • The regulators:
    • are only involved in a routine way.

The final prioritisation score + ranking give you an initial idea of who matters, how much and why.

This then raises the question of how best to manage your stakeholders depends on their power and impact. In terms of overall strategy, the following matrix should indicate not only the general level of attention each stakeholder needs but also the kind of attention they are likely to require:

Stakeholder management matrix

In addition to the power, impact and priority scores, you need to analyse precisely how each stakeholder is involved in your project:

  • Which individual stories do they own or are they affected by?
  • How do they need to participate directly?
    • Providing users to participate direct in the Core Team.
    • Showcase participants.
    • Governance and accountability.
    • As experts and authorities.
  • Which dependencies do they control?
    • Information, decisions and deliverables.
    • Key events.
  • What additional communications do they need?
    • Points of contact.
    • Specific forums, channels, vehicles, content, tracking.
      • E.g., standard vs non-standard reports.
    • Approach:
      • E.g., full or by exception only.
      • Non-standard requirements.
    • Specific messages.
    • Inputs to project communications.

Once you think you understand a stakeholder, you can start to define your desired relationship with them:

  • What is their key interest in your project?
  • What specific powers do they exercise?
    • E.g., who do they influence (users, other stakeholders, senior management, etc.)?
    • E.g., what key decisions do they make (priorities, funding, acceptance, etc.)?
    • What authority do they have?
  • What specific impacts will they feel?
    • Positive and negative.
  • What is their current attitude to your project?
    • Advocate, supporter, follower, critic, blocker?
  • What is the desired attitude?
  • What motivates them?
  • How can you reconcile what they want, expect, can, must and need?
  • What issues, risks and triggers does this create?

Plan stakeholder management

Now that you understand the relationship you need with each stakeholder, how do you plan to manage them?

Mapping stakeholder attitudes

Here is an initial question: What is their current attitude to your work? Here is a useful classification:

Stakeholder attitudes

Using this table:

  1. Identify your stakeholders’ individual attitudes toward your work, and
  2. Decide where on this scale you need them to be for your work to succeed.
  3. Plan activities to migrate your stakeholders from their current to the ideal attitude and relationship.

This should give you a matrix somewhat like this:

Stakeholder planning matrix

As a couple of these examples suggest, although you would usually want stakeholders to be as positive as possible about your work, you may want some to become more neutral (i.e., less actively involved).

What motivates stakeholders?

Of course, the goal of stakeholder management planning is to identify an approach that will allow you to meet as many of these requirements as possible. So, before planning how to optimise your stakeholders’ attitudes towards your work, it is crucial to understand what it is that actually motivates stakeholders. Here is a basic model:

Stakeholder motivation

Refer back to this model regularly, but especially whenever:

  • The overall Product changes.
  • A Release or Iteration begins or ends.
  • During Backlog Refinement.
  • For each risk and issue:
    • Which of these items does the risks/issue affect? Does your propose remedy address this too?
    • On closing a risk or issue, has this item been restored to an acceptable level?

Once you understand what kind of relationship you need with each stakeholder, you can plan how to manage them better. Your plans should cover all of these issues:

  • Story and deliverable tracking.
  • Communications:
    • Regular Showcases, forums and other events.
    • Non-standard reporting.
  • User participation.
    • Special requirements.
    • Setting stakeholder and user expectations.
  • Direct relationship management:
    • Points of contact.
    • Involvement in standard Agile events (Showcases, etc.).
    • Regular schedule of meetings.
    • Issue and risk management.
  • Direct stakeholder participation:
    • Resources, dependency management, etc.
  • Measuring satisfaction:
    • Informal discussion, one-to-one reviews, formal surveys.

Implement your plan

A stakeholder management plan is implemented like any other plan.

  1. Set up initial stakeholder meeting.
    1. Critical and prioritised epics, stories and outcomes.
    2. Participation and collaboration.
    3. Communications.
    4. Capture any other stakeholder-specific expectations and needs.
  2. Diarise stakeholder events.
    1. Map relevant (i.e., stakeholder-specific) Releases, Iterations.
    2. Identify stakeholder participation in delivery events (Showcases, workshops, etc.).
  3. Schedule stakeholders into communications & event cycles.
  4. Brief the Core Team.
    1. Individual stakeholder wants, needs, expectations, etc.
    2. Stakeholder-specific issues & risks.
    3. Special engagement points.
    4. Mapping of each stakeholder to team events (workshops, Showcases, etc.).
    5. Other stakeholder-specific activities, tasks, etc.
  5. Track and manage progress & outcomes regularly.
    1. Activity & deliveries.
    2. Changes in stakeholder attitude, expectations, etc.
    3. Stakeholder comments & requests.
  6. Communicate results.
    1. To Core Team, governance bodies & wider stakeholder community.
  7. Review and adapt as appropriate.

Maintain your relationship

Stakeholders are key to delivery but not always a direct part of it. This creates critical problems:

  • You are always competing for their attention, priority and resources.
  • But you have no authority over them.
  • You aren’t the top priority for most of them.
  • Your most influential stakeholders aren’t always the most positive about your project.
  • Their interests change independently of your project’s.
  • Different stakeholders may have – or develop – conflicting interests in your project.

So maintaining your relationship is an on-going task. This creates a natural agenda for regular review:

  • Do both sides have the right level of overall awareness, commitment, involvement?
    • Is this as they or they desire?
    • Is this as the Core Team and delivery process needs?
  • Are we achieving success or failure?
    • What are success and failure from their point of view?
    • Has this changed since the last review?
    • How is the Core Team doing by these criteria?
  • How are stakeholder concerns, expectations and constraints evolving?
    • What are the emerging issues and risks?
    • What are the competing priorities and events?
  • In summary, what is the impact of your work on them so far?
  • Are reporting & communications still appropriate?
    • E.g., frequency, content, positive reports vs exception, etc.
  • Is stakeholder management itself working to their satisfaction?

Whatever the outcome of this review, don’t underestimate the complexity of managing a group of disparate stakeholders. You can expect to see all of these to change as the work proceeds:

This happens……which means that …To manage this you should…
Endowment effectPeople attach a higher value to things they own.Be sure of positively proving the superior value you are offering.
Confirmation biasPeople will search for or interpret information confirming their preconceptions.Understand and manage audience/ stakeholder biases and pre-conceptions.
Bandwagon effectDoing things because others do them.Show or create social approval/permission for desired outcomes from influential stakeholders.
Framing effectsPresentation method affects conclusions.Differentiate audiences and play to their priorities and concerns.
Consensus assumptionWe assume other people see things like us.Identify differences explicitly and reconcile around project-level consensus.

So always be careful to close any gaps between your understanding our your relationship and your stakeholders’ – make sure they know what you think they want!

 

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?