Stakeholders, Risk and Communication

Who the stakeholders are

A stakeholder is any person or group with an interest in the work or affected by it. On a project that is more people than you would think: not only the sponsor who pays and the users who will use the result, but also the support teams who will run it, the departments whose processes change, suppliers, regulators and sometimes the works council or the press.

Two distinctions help:

• Internal and external. Internal stakeholders work in the organization (the sponsor, finance, the service desk, operations). External ones do not (customers, suppliers, regulators, partners). External stakeholders are often harder to reach and you cannot simply invite them to a meeting.
• Supportive, neutral and resistant. Some people want the change, some do not care yet, and some will lose something — a familiar tool, a budget, influence. Resistance is information, not a character flaw: a team leader who objects to a new portal may know about a workflow the project has missed.

In the running example, the Portal team at Kestrel Energy is relaunching the customer portal and app: a new design, a new login and online meter readings. Product Owner Isabel Santos works with the Developers on the product; around them sit the chief financial officer (CFO) Margriet de Wit, who sponsors the budget; Sanne de Vries, owner of the portal service; Ingrid Berg from communications; the head of customer service and the service desk; the network operations team (Tomasz Nowak, Emeka Obi); the data protection officer; the payment provider; and about 400,000 customers.

Stakeholder analysis

Stakeholder analysis is the structured way of answering three questions early, and again whenever things change: who is affected or has influence, what do they care about, and how should we involve them? The result is a simple list — a stakeholder register — with per person or group their interest, their influence, their current attitude and the attitude you need.

A short analysis has four steps:

1. Identify. Brainstorm with the team and ask the people you find: "Who else should know about this?" Look at process flows and the value stream to find groups whose work changes.
2. Understand. Talk to them. What do they gain or lose, what worries them, what do they know that you do not?
3. Prioritize. Place them on a power-interest grid (below) to decide how much attention each needs.
4. Plan engagement. Decide how you will involve or inform each group — the communication plan.

The power-interest grid

A power-interest grid places each stakeholder on two axes: how much power they have over the work (budget, decisions, the ability to stop it) and how much interest they have in it (how much it affects them). The four quadrants suggest a strategy.

• Manage closely (high power, high interest): involve them in decisions, meet regularly, invite them to every Sprint Review.
• Keep satisfied (high power, low interest): give them short, relevant updates and ask for decisions only when needed. Overloading them with detail turns them against you.
• Keep informed (low power, high interest): keep them up to date and listen — they often see the practical problems first. The service desk will answer every customer question after go-live.
• Monitor (low power, low interest): check now and then whether that has changed.

The RACI matrix

A RACI matrix (also called a RACI chart or responsibility assignment matrix) lists tasks or decisions in rows and people or groups in columns, with one letter in each cell:

• R — Responsible: does the work. There can be several.
• A — Accountable: owns the outcome, approves it and answers for it. Exactly one per row, so it is always clear who decides.
• C — Consulted: asked for input before the work or decision; two-way communication.
• I — Informed: told about the result afterward; one-way communication.

One person can be both A and R for a row. For the portal relaunch, the parts that cross team boundaries look like this:

Notice what is not in the table: who picks up which task inside the Sprint. In Scrum the Developers are a self-managing team and decide that themselves, and the accountabilities of the Product Owner, Scrum Master and Developers are already defined by the Scrum Guide. A RACI is useful at the edges of the team — where other departments, suppliers and decision makers come in — not as a way to assign work inside it. The Scrum Master, Lars de Boer, does not appear either: he is accountable for the team's effectiveness, not for delivering these tasks.

Common RACI mistakes

• Two A's in one row. "Shared accountability" usually means nobody decides. If two people really must agree, make one Accountable and the other Consulted.
• No A at all, or an A who has no authority over the outcome (a project coordinator "accountable" for a budget she cannot approve).
• Everyone Consulted. Each C is a conversation that has to happen before work can continue; ten of them per row make every decision slow. Move people to I when their input is not needed.
• Made once, never used. A RACI only helps if people read it when a question comes up — keep it short and next to the work.

Variants exist: RASCI adds S for Support (helps the Responsible), and some organizations use DACI (Driver, Approver, Contributors, Informed) for decisions. The idea is the same.

The communication plan

A communication plan records, per stakeholder group, what they need to hear, when, through which channel and from whom. It turns the stakeholder analysis into actions, and it makes sure nobody depends on someone "remembering to mention it".

Prefer two-way channels for the people you must manage closely: a conversation in front of the working product reveals more than a report. Use one-way channels (email, a dashboard, a wiki) for those you keep informed — and make them pull-based where possible, so people can find the current state without asking.

Reporting status honestly

Many organizations ask for a regular status report with a traffic light (RAG: red, amber, green) per topic — scope, schedule, budget, risks. Traffic lights are quick to read, which is also their weakness: they hide why, and people under pressure keep them green until the last moment. The result is the project version of the watermelon effect: green on the outside, red on the inside. A project that reports green for months and then turns red the week before go-live was never green.

A status report that helps decision makers:

• shows trends and a forecast (a range, not a single date), not only the current color;
• says what has changed since the last report and what the main risks and issues are;
• names the decisions needed, from whom and by when;
• defines the colors in advance (for example, amber = the forecast is outside the agreed date but the team has a plan to recover; red = it cannot recover without a decision from the sponsor).

Portal relaunch — status after Sprint 9                    Overall: AMBER

Progress   Meter readings and new login done and released to 5% of customers.
           Payments not started.
Forecast   Go-live between 3 and 24 November (was: 3–10 November).
Why amber  Payment provider delivered its test environment two weeks late
           (issue I-04). Team works on account migration first.
Top risks  R-03 login problems after migration (score 16, mitigating)
           R-07 overlap with annual billing week (score 15, see decision)
Decision   Margriet de Wit: move go-live out of billing week (week 47)?
           Needed by 10 October.

In agile work the most honest status report is the product itself. Stakeholders who see and try the working Increment at every Sprint Review need far fewer colored boxes — they have seen what is done and what is not. Forecasting with ranges is covered in Estimation and Forecasting.

Risks and issues

A risk is an uncertain event that, if it happens, affects the objectives — it has a likelihood and an impact. An issue is something that has already happened or is happening now and needs action. A risk that occurs becomes an issue. Project management also counts positive risks — opportunities — that would help if they happened.

A good risk description names a cause, an event and an effect: "Because customer accounts are migrated to a new login system, some customers may be unable to log in on launch day, which would flood the service desk." That makes it clear what you can act on (the cause) and what you are protecting (the effect).

A project risk register

Projects keep their risks in a risk register, the same tool security teams use. Each risk gets a likelihood and an impact (here on a 1–5 scale), a score, an owner and a response, and the register is reviewed regularly — on an agile project, at least once per Sprint.

How likelihood and impact are scored, and why the score is a tool for comparing rather than a precise number, is explained on the Security page Threats, Vulnerabilities and Risk.

Risk responses

There are four classic responses to a threat — the same four that security calls risk treatment:

• Avoid: change the plan so the risk cannot happen — move the go-live date, drop the risky feature.
• Mitigate (reduce): lower the likelihood or the impact — a pilot with 5% of customers, extra testing, a fallback.
• Transfer (share): move the financial consequences to someone else — a fixed-price contract, insurance. The consequences for customers do not move: if the payment integration fails, Kestrel's customers still cannot pay.
• Accept: consciously do nothing because the risk is small or acting costs more than it saves. Accepting can be passive, or active with a contingency plan or a time and budget reserve.

For opportunities the mirror images are exploit (make sure it happens), enhance (make it more likely or bigger), share (partner with someone who can realize it) and accept (take it if it comes). PMI's guidance also lists escalate for risks that are outside the project's authority — see escalation below.

The risk owner

Every risk has one risk owner: the person who is accountable for watching it, making sure the response is carried out and deciding when it needs more attention. The owner is not necessarily the person who does the work: Sanne de Vries owns R-03 because the consequences land on her service, while the Developers do much of the mitigation. Choose an owner who has the authority to act — a risk "owned by the project" is owned by nobody.

The issue log

An issue log (PRINCE2 calls it an issue register) records the problems, change requests and concerns that need action now: what happened, its effect, who is handling it, what was decided and its status. It keeps issues from living only in someone's inbox, and it shows patterns — four late deliveries from the same supplier are a conversation, not four separate surprises.

In Scrum, an issue that blocks the Developers is called an impediment, and the Scrum Master helps get it removed — see The Scrum Master in Practice. Not every team needs a separate issue log; on a small team the board and the Daily Scrum may be enough. Once other departments and suppliers are involved, a written log pays off.

Risk in agile work

Agile approaches do not have fewer risks; they handle them differently. Several features of Scrum and similar frameworks are risk management built into the way of working:

• Short cycles. The Scrum Guide notes that shorter Sprints limit the risk of cost and effort to a smaller time frame. If a direction is wrong, you lose two weeks, not two years.
• Risky items early. A Product Owner can order the Product Backlog so that the most uncertain work — the account migration, the new payment API — is done first, while there is still time to change course. Many teams use a short timeboxed experiment for this, often called a spike (a practice from Extreme Programming, not part of Scrum).
• A Definition of Done. Every Increment meets the same quality standard, so problems do not pile up for a test phase at the end.
• Transparency. Stakeholders see real, working product at every Sprint Review; the forecast is updated as evidence comes in.
• Releasing early. Releasing to 5% of customers first turns a big, uncertain launch into small, observable steps.

What agile does not remove: risks outside the team (suppliers, regulators, budget cycles, other teams' dependencies) still need an owner and a response. Many agile teams keep a lightweight risk list next to the Product Backlog, or turn risk responses into Product Backlog items, and look at it briefly in Sprint Planning or the Sprint Review.

Escalation

To escalate is to take a problem to someone with more authority because it is outside your own: a decision about budget, date or scope beyond what was agreed, a conflict between departments, or a risk that only management can respond to. Escalating is not failing or complaining — it is getting the right person to decide in time. (Escalating a support ticket to another team works in a similar way; see The Service Desk.)

A good escalation is short and makes deciding easy:

1. the situation, in facts (what happened, since when);
2. the impact if nothing is decided;
3. two or three options with their consequences;
4. your recommendation;
5. the decision needed, from whom and by when.

Predictive methods formalize this. PRINCE2's principle "manage by exception" gives each level of management tolerances (for example ±10% on cost); as long as the forecast stays within them, the level below gets on with the work, and when a forecast exceeds a tolerance the problem goes up a level. Agile teams escalate in the same spirit: the Developers decide how to do the work, the Product Owner decides on the product, and what neither can decide — more budget, a regulatory question, a blocked dependency on another department — goes to the sponsor or management, early and with options.