Skip to content
Van Oosten Advies B.V.

Programme & project support

Risk and stakeholder analysis for an IT project

There is a risk log. Filled in at kick-off, a standing item on the steering group agenda, flicked through in two minutes. Meanwhile everyone knows in the corridors where this project is going to come apart, and that concern is not in the log. Nobody has yet spoken to the department whose work will have to change.

Risk analysis and stakeholder analysis are two halves of one question: what could make this project fail, and who has a say in that. I make both explicit and small enough to use. A short list of risks that genuinely matter, each with an owner and an agreed moment at which it is looked at again. Alongside it, a picture of whose support the project needs, who can hold it up, and what each of them needs to hear.

When this helps

Not every project needs a worked-through risk analysis. These situations do.

  • The project starts shortly and you would rather the first setback was not also the first time anyone thought about it.
  • There is a risk log, but nothing in it has changed since the kick-off.
  • The steering group asks for the risks and gets back a list of worries: no owner, no assessment, no decision.
  • A decision keeps slipping because somebody turns up each time who was not in the picture before.
  • A department whose work will have to change only hears about the project when it is nearly live.
  • You have to justify a go or no-go and want to know what risk is left standing at the end.

What the work covers

Small and usable. Ten risks the steering group genuinely knows beat eighty that nobody reads.

  • The difference between a risk and an issue. A risk has not happened yet and can still be influenced; an issue is here now and needs capacity. On one list the issues crowd out the risks, because what is burning is louder than what might catch fire.
  • Judging likelihood and impact without false precision: no scores to two decimal places, but what this costs in time, money or credibility.
  • An owner for every risk. A risk without an owner is a wish. Ownership follows the mandate to act, not the person who raised the point.
  • Responses that amount to a decision: avoid, reduce, transfer or knowingly accept. Accepting is a legitimate choice, provided it carries a name and a date.
  • The rhythm that keeps the log alive: when it is revisited, by whom, and what happens on the day a risk turns real. A log that has stood still is worse than no log, because it suggests someone has thought this through.
  • The stakeholder side: whose support the project needs, who supplies capacity, who can stop it without any formal authority to do so, and what each of them needs to hear. An action only works once somebody with an agenda of their own agrees to carry it.

What you get

Working documents, not a report. In a form your own people can keep maintaining.

  • A risk log of a few pages: per risk a description in plain language, the assessment, the response, the owner and the date it is next reviewed.
  • A stakeholder picture: who matters, with what interest and what influence, and who holds which conversation.
  • A short note for the steering group separating the risks that call for a decision from the risks that only need watching.
  • A working agreement on upkeep: who maintains the log once I am gone, and when it appears on the agenda.

What it is not

  • Not the introduction of a method or a tool. What you get fits inside what you already use.
  • Not an audit and not an assessment against a standard. No formal opinion comes out of it, but a reasoned picture does.
  • Not an information-security analysis or a DPIA. This is about project risk, not about your data processing.
  • Not an inventory of everything that could go wrong. Eighty lines is a way of prioritising nothing.
  • Not a substitute for your judgement. I map and advise; which risk you accept remains the organisation's call.

Common questions

What is the difference between a risk and an issue?

A risk has not occurred yet and can still be influenced by an action. An issue is happening now and needs people to resolve it. You steer a risk with a decision in advance, an issue with work today. On one list, the issue wins.

We already keep a risk log. What does this add?

The gain is not in more lines but in fewer. Out goes anything that is not a risk: assumptions, wishes, and items that became issues long ago. In come owners, and per line the decision sitting underneath it. Plus the stakeholder side, which a risk log does not cover.

Should scores and a risk matrix come into it?

A coarse scale helps you sort, and no more than that. Likelihood times impact to two decimal places yields a number that looks more accurate than the judgement beneath it, and a number like that takes on a life of its own in the reporting. I work with ranges and record what the estimate rests on.

What if nobody wants to own a risk?

Then that is the finding in itself. A risk nobody will carry falls between departments, or touches a decision above project level. Either way it belongs on the steering group table, not at the bottom of a log. The project manager keeps the log; ownership sits with whoever can take the action.

Isn't stakeholder analysis only for large programmes?

Size determines the form, not the need. On a small project it fits on one page and takes an afternoon. It is the same four questions: who has an interest, who has influence, who supplies the people, and who can bring it to a halt.

What does it cost and how long does it take?

A short engagement of a few days: reading the documents, a round of conversations, and a session in which the risk log and the stakeholder picture are sharpened with the people involved. The size depends on the scale of the project and the number of parties in it. The shape is agreed up front: time and materials with a ceiling, or a fixed price for a defined result. I name a rate in the first conversation.

Want to know where this project could come apart?

An introductory conversation is without obligation. Sketch what is at stake; I will say honestly whether this work helps you or whether something else would serve you better.