Module 2 of 2 · 40 minutes
Risk, dependencies and the people problem
By the end of this module you will be able to
- Write a risk that can be acted on rather than logged
- Manage dependencies you do not control
- Run a stakeholder map that changes what you do
- Close a project properly, including the benefits nobody checks
Work through it
1 interactive for this module, built on the WAJD Teach engine. Nothing moves until you ask it to, and every one has a written version if you would rather read it.
Amara Our risk register has eleven items and none of them have moved in four months.
Nadia Then it is furniture, and it is doing nothing except making somebody feel governed. What do the entries look like?
Amara Things like resource availability, with a red dot.
Nadia Which cannot be acted on by anybody. A usable risk has three parts: a cause, an event and an effect.
Amara Rewrite that one for me.
Nadia Because the migration depends on one person who is also running month end, there is a risk that migration testing slips, which would delay go live by two to three weeks.
Amara That one I could actually do something about.
Nadia And you immediately know what: get a second person trained, or move the testing window away from month end. The rewrite generated the action by itself.
Amara Is there a test I can apply?
Nadia One question. What would you do differently tomorrow if you believed this? If the answer is nothing, it is not a risk, it is a worry, and it should not be on the register clogging it up.
Amara What about accepting risks? That feels like giving up.
Nadia It is a legitimate answer and it is badly underused. Avoid, reduce, transfer, accept. What matters is that accept is a recorded decision with a name against it, rather than a silence that later looks like nobody noticed.
Amara You said dependencies are where projects actually fail.
Nadia Almost always. Your own work is the part you control, and it is rarely what sinks you. It is the other team's deliverable, the approval sitting in an inbox, the supplier who was always going to be four weeks.
Amara So what do I record?
Nadia Three things for every dependency. Who owns it. What date you need it. And what you will do if it does not arrive.
Amara That third one is unusual.
Nadia And it is the one that turns a dependency log into something useful rather than a list of hopes. If you cannot answer it, you have not got a plan, you have got an expectation.
Amara Anything else?
Nadia Re confirm as the date approaches. Somebody agreed in a meeting three months ago, and since then they have had two reorganisations and a new priority. That dependency is not confirmed, it is remembered, and those are very different things.
Amara Stakeholders. We have a list.
Nadia A list achieves nothing. Sort them by how much the project affects them against how much influence they have, and then say what you will do differently for each group.
Amara Where do people go wrong?
Nadia They spend all their time with the enthusiastic people, because that is pleasant, and none with the person who can stop it. And then they are stopped, usually late, usually publicly.
Amara Who gets ignored?
Nadia Low influence, high interest. Which is very often the people who will actually use the thing you are building. They cannot stop you, so they get overlooked, and then adoption fails and everybody is surprised.
Amara Last thing. Closing down.
Nadia Closure is not the go live date. It is handover to whoever runs it now, documentation somewhere findable, outstanding issues transferred with owners, and your resources released.
Amara And you said there is a bit nobody does.
Nadia Checking whether the benefits happened. Projects get justified with a benefits case and closed at delivery, so nobody ever asks whether any of it materialised.
Amara Which means?
Nadia Which means organisations repeat expensive mistakes indefinitely, because nothing ever taught them it was a mistake. Set a benefits review date at the start, three or six months after go live, in the calendar of somebody who will still be there. Measure the thing you said would change. And publish the answer even when it is uncomfortable.
Amara Especially then, presumably.
Nadia Especially then. An organisation that only publishes the successes is training itself to believe everything works.
The written material
A risk register that is not furniture
Most risk registers are written once, reviewed never, and contain entries like 'resource availability' with a red dot beside them. Nothing in that sentence can be acted on.
A usable risk has a cause, an event and an effect. 'Because the data migration depends on one person who is also running month end, there is a risk that migration testing slips, which would delay go live by two to three weeks.' Now there is something to do.
Then decide what you are doing about it: avoid, reduce, transfer or accept. Accept is a legitimate and underused answer, provided it is a decision recorded with a name against it rather than a silence.
Give every risk an owner who is a person, and a review date. A register without owners is a list of anxieties.
Dependencies, which are where projects actually fail
Your own work is the part you can control, and it is rarely what sinks you. It is the thing another team was going to deliver, the approval that sat in somebody's inbox, the supplier who was always going to be four weeks.
Name every dependency explicitly with three things: who owns it, what date you need it, and what you will do if it does not arrive. That third one is what separates a dependency log from a list of hopes.
Confirm dependencies in writing with the person who owns them, and re confirm as the date approaches. A dependency somebody agreed to in a meeting three months ago, who has since had two reorganisations and a new priority, is not confirmed. It is remembered.
Stakeholders are a plan, not a list
A stakeholder map that lists names achieves nothing. A useful one sorts people by how much the project affects them and how much influence they have, and then says what you will do differently for each group.
High influence and high interest: involve them in decisions, and expect to spend real time. High influence and low interest: keep them satisfied and informed briefly, because they will surface late and loudly if surprised. Low influence and high interest: these are usually the people who will actually use the thing, and they are the group most often ignored. Low both: inform.
The failure mode is spending all your time with the people who are enthusiastic and none with the person who can stop it, and then being stopped.
Closing properly, including the bit nobody does
Closure is not the go live date. It is handover to whoever runs it now, documentation that exists somewhere findable, outstanding issues transferred with owners, and the project's resources released.
Then the part almost nobody does: check whether the benefits happened. Projects are justified with a benefits case and then closed at delivery, so the question of whether any of it materialised is never asked. That is why organisations repeat expensive mistakes: nothing ever taught them it was a mistake.
Set a benefits review date at the start, three or six months after go live, and put it in somebody's calendar who will still be there. Measure the thing you said would change. Publish the answer even when it is uncomfortable, particularly when it is uncomfortable.
Knowledge check
The knowledge check and your certificate need a free account, so that your progress and results can be saved as evidence.
The learning itself stays free and open. You are reading all of it right now without an account.