RAID Log Example for Engineering Projects

A RAID log is one project record of Risks, Assumptions, Issues and Dependencies. A risk may happen, an issue already has, an assumption is accepted as true until checked, and a dependency is something you need from someone outside the team. This guide fills one in for an invented engineering project, with owners, dates and a sorting rule.

One fact about our own offer, so you can judge this fairly. The EDWartens project coordinator job simulation is a training project at a simulated company, done day by day with project documents, emails and tickets. It is not employment, an internship or a work placement. The first week is free and every ticket is checked as you hand it in. A graded, verifiable certificate is optional, and the longer Premium version is paid; prices show in your own currency before you pay. It shows on your EDWartens profile under Work experience, marked as a job simulation.

RAID in one table

The four letters differ by one question each. Ask the question and the entry sorts itself.

A fifth thing sometimes sneaks in: a fact. “The wet well is six metres deep” is information, not an entry. If nothing can change it and nobody needs to act, it belongs in the project brief.

How it differs from other project records

A RAID log is not a risk register, an action log or a change log, although it touches all three. The APM guidance on risk management treats the risk register as its own tool, and many teams keep the two side by side, with the RAID log as the weekly working view. The UK Government project delivery standard is a useful reference for how public-sector projects expect risks, issues and dependencies to be controlled.

The invented project

The example is an invented refurbishment of the Marlow Down pumping station for a made-up client, Dunmere Water. The work: replace two duty pumps and a standby, fit new actuated valves, replace the motor starters and install a new flow meter. The baseline finishes on the 12th of March, with an agreed shutdown window of three Sundays in January and February. The project coordinator, a role and not a person, keeps the log.

A filled RAID log

Ten entries as they might stand at the end of week six. Each has an ID, a type, a plain description, a named role as owner, a rating or due date, a response and a status. P means probability and I means impact, each scored low, medium or high.

Three habits make this log useful. Every entry has one owner, not a team. Every entry has a date, either a rating date or a date by which the thing is needed. And the status line is updated every week, even if it only says “no change, chased 9 Nov”.

A worked example: sort twelve raw comments

At a kick-off workshop twelve comments come up. Try sorting them yourself before reading the answers. They are written as people really talk, which means several fit two boxes until you use the question test.

1. “The old starter room might not cope with the heat from new drives.”
2. “We are assuming the existing supply can carry the new pumps.”
3. “The valve supplier emailed to say delivery is three weeks late.”
4. “We can't start commissioning until the utility approves the connection.”
5. “The operator said they might want a second flow meter.”
6. “We might not get the road closure permit from the council in time.”
7. “Survey drawings from 2009 are assumed to be accurate.”
8. “The crane hire company has double-booked the lift.”
9. “The wet well is six metres deep.”
10. “Operators say shutdowns can only be on Sundays.”
11. “We still have no cable pull schedule from the electrical contractor.”
12. “If the second pump fails its test, the handover could move.”

Number 6 is the useful one. The word “might” does not make something a risk. Ask who decides. If the answer is someone outside the team, it is a dependency, and the response is to chase, not to mitigate.

When an entry changes type

The log is alive, so entries move. This is the order to follow when one does:

1. A risk happens: change its type to Issue, keep its ID history, set an owner and a date for the fix.
2. An assumption is proved wrong: log it as an issue, then ask what else rested on it.
3. A dependency slips: log an issue for the slip and check the schedule; if it sits on the critical path, tell the project manager that day.
4. A dependency arrives on time: close it with the date, never delete it.
5. A risk can no longer happen: close it with the reason and the date.
6. A scope request arrives: do not do it; record it and raise a change request.

Where an informal scope request goes

The most common leak in an engineering project is a friendly email. A client's operator writes: “Could you also label the old bypass valve while you are there?” It is small, and it is a change. The coordinator's reply is courteous and specific: thank them, state that the request is outside the agreed scope, say it has been logged as a change request with a cost and time estimate to follow, and confirm that nothing will be done until it is approved. Then add a line to the change log and to R03 or a new entry. The kindness is in the speed and the clarity, not in doing the work for free.

From the log to the weekly status report

Once a week the log turns into a one-page report. The key is to write the colour rule before the week starts, so nobody can argue for green under pressure. Here is an example rule for the project above:

Apply it to I01. The valves are 15 working days late, but the schedule shows 8 working days of float on that path, so the net slip to the finish is 7 working days. By the rule that is Amber, not Red and not Green. The report says so, shows the response (part shipments) and names the decision the sponsor may need to make. Reporting green because “we will probably catch it up” is the habit that turns a manageable slip into a surprise.

Eight checks before the status report goes out

• Every open entry has an owner and a date, and none is older than its date without a note.
• Each issue says what is being done, not only what is wrong.
• Each dependency says who was chased and when.
• The colour matches the written rule, not a feeling.
• Forecast finish is recalculated, not copied from last week.
• Changes requested this week are listed, with their status.
• Anything needing a decision names who must decide and by when.
• Numbers in the report match the log and the schedule.

Practise it in a job simulation

A log like this only becomes natural after you have kept one under pressure. The project coordinator job simulation gives you a project at a simulated company with meetings, emails, a document register and a change request, and each ticket is checked as you hand it in. You can compare it with the site-based roles, such as the substation and motor control centre engineer simulation and the commissioning engineer simulation, to see the same problems from the other side, and the quality engineer simulation shows deviations and changes from a quality view. All are on the job simulation hub.

A finished simulation shows on your EDWartens profile under Work experience, marked as a job simulation, and the optional certificate has a public page where anyone can verify it. For AI in the same job, see our guides on how to use AI in project management and the AI project management internship roadmap, and the matching project management internship track. You can also check current openings on the jobs board.

Last updated 19 October 2026. The project, company and figures in this post are invented. Use your own organisation's templates and scoring scales where they exist.

Take the free course

Free

Industrial networks · Intermediate · Free

Industrial Communication: Serial, Fieldbus, Ethernet, Modbus, PROFINET and OPC UA

Free

Instrumentation · Beginner · Free

Industrial Instrumentation and Process Control