Spotting Risks and Dependencies Early

The risk you could not see

The risk that sinks a project is rarely exotic. It is usually something obvious in hindsight: the approval that needed a committee that only meets quarterly, the key person booked on another project, the supplier contract that assumed a different start date. Somebody would have spotted it if they had looked. Nobody looked, because everybody was busy and the plan looked fine.

You cannot see your own blind spots, by definition. That is why reviews exist. The trouble is that a proper review needs a colleague with time, and colleagues with time are rare. AI will not replace that colleague, but it is available at eleven at night, it does not get bored on page nine, and it has no stake in the plan being right.

What it is good at here

An AI assistant has read an enormous amount about how projects go wrong in general. It has no knowledge of how your projects go wrong in particular. That shapes what you should ask it for.

Generic failure patterns. Hand it a plan and it will notice that there is no time for user testing, that go-live is the week before a holiday, or that three milestones depend on one team. Common problems, reliably spotted.

Missing dependencies. It is good at asking "what has to be true before this can start?" for every task, which is a question people stop asking by around task twelve.

Gaps in the logic. A milestone with no owner. A task that depends on something that happens later. A risk listed with no response. Tedious to check by hand, easy for a model.

What it cannot know is everything specific to your organisation: the politics, the history, the sponsor who says yes and means maybe, the team that is quietly overloaded. It suggests. You judge.

The pre-mortem

The single most useful risk exercise is also the simplest. Instead of asking what might go wrong, you imagine the project has already failed and ask why. It sounds like a trick, and it is one, but it works: people find it much easier to explain a failure than to predict one, and it gives everyone permission to say the uncomfortable thing.

It works with AI for the same reason. "What are the risks?" produces a generic list. "It failed, tell me the story" produces specific, connected chains of events, which are much closer to how projects actually fail.

The reusable prompts

Below is my project plan. Imagine it is [six months] from now and the
project has clearly failed.
Write five short failure stories. Each must:

Be tied to something specific in this plan, and quote or name it.
Describe a chain of events, not a single category like "scope creep".
Name the earliest warning sign I could watch for.
Then list any dependencies the plan relies on but does not state
(approvals, people, systems, suppliers, other projects).
Rules:

Do not invent facts about my organisation. If a story depends on
something you are guessing, say "assuming..." so I can check it.
Do not rewrite the plan.
PLAN:
[paste your plan, milestones and dependencies]

For each milestone in the plan below, list what must already be true
before it can start and before it can finish. Mark anything that depends
on a team, supplier or decision outside the project as EXTERNAL.
Flag any milestone that depends on something scheduled after it.
Flag any single person or team that appears in more than two dependencies.

The last line catches one of the most common failure patterns there is: the one person everything routes through.

Run both prompts again whenever the plan changes shape, not on a fixed schedule. A new supplier, a moved milestone or a team member leaving all create dependencies that were not there last month, and the cheapest time to find them is the week they appear rather than the week they bite.

Now you do the judging

You will get back more risks than you can manage. That is the point. Go through the list and sort each item into one of three piles: already covered, genuinely new and worth adding, or wrong for your organisation. The third pile is not a failure of the tool. It is you applying the knowledge it does not have.

For anything you add, write the response yourself, with an owner. A risk without an owner and a response is just a worry written down.

Finally, take the best two or three stories to your team and ask them the same question. They know things neither you nor the model knows, and a pre-mortem story is a far easier way to start that conversation than asking "any risks?" in a meeting.