Governance bodies RIDA: project log of information, decisions and actions
A project's RIDA, or log of information, decisions and actions, is the table that outlives its meetings. Its structure is simple and well known. What is less known is the detail that decides whether it is useful: in almost every log in circulation, the assigned person ticks their own line, and the requester never gets a say.
Log of information, decisions and actions, n.
Telling the three kinds apart is not a refinement of form. Information calls for no follow-up, a decision must be retrievable exactly as it was taken, an action must be closed. Mixing them in a single list produces a document you reread without knowing what it expects from you.
The acronym comes from organizations that formalized their governance bodies, and it circulates mostly in industry and large programs. Elsewhere, people simply say action log, action tracker or decision table. The name matters little; what matters is that a single table runs across the meetings, rather than ten lists that are born and die with each session.
It is also the first symptom of an arrangement that does not hold: when every meeting produces its own list, no one knows which one is authoritative, and each time you start over by reconstructing what is still open.
Seven columns, and not one more.
The minimal form that makes a log usable from one meeting to the next.
| Column | What goes in it | Why it is there |
|---|---|---|
| Kind | Information, decision or action. | Say what the line expects from the reader. |
| Date | That of the meeting where the line was born. | Establish since when the matter has been known. |
| Subject | One sentence, no jargon, understandable six months later. | Avoid lines that no one can interpret any more. |
| Owner | A named person, never a team. | An action owned by everyone is owned by no one. |
| Requester | The person who asked for the action, the client included. | That person is the one who can consider it done. |
| Due date | A date, not a month or an "as soon as possible". | Without a date, the line can be neither late nor closed. |
| Status | Open, in progress, closed, dropped with a reason. | Tell what is done apart from what we gave up doing. |
SOURCE Template drawn from orgatypik practice, tested on projects managed at an IT services company. It can be reused as is.
Dead actions, and how they die.
Ten to twenty actions are stated aloud at each committee. Three weeks later, no one knows who owned what.
It was never written down
It was said in the meeting, everyone nodded, and the minutes kept something else. It exists only in the memory of two people.
It has no named owner
"The technical team will look into it." No one feels targeted, and no one is at fault when nothing happens.
It has no due date
It stays open indefinitely without ever being late. It ends up disappearing out of weariness rather than by decision.
It is closed by the person who had to do it
They tick their line because they did something. The requester finds out three months later that it was not what they expected.
The requester closes, never the assignee alone.
In every log we have come across, closing belongs to the person who executes. That is logical from the tool's point of view, and wrong from the commitment's point of view: an action is done when the person who asked for it acknowledges it, not when the person who carried it out considers it finished.
Reversing this point has two effects. One-sided declaration disappears, since a closed line was closed by someone other than its owner. And above all, the delay of an action that falls to the client becomes as traceable as your own: if they are the requester, they close; if they are the owner, their delay shows.
Project governance describes the bodies and their artifacts. Operational commitment management describes what those artifacts hold: what was promised, by whom, by which date, and on what dated proof. One is the frame, the other is the substance. This is what we call operational commitment management.
An action log and minutes do not do the same job.
The minutes are a time-stamped record: they describe a meeting, they are dated, they are submitted for approval, and they freeze. They answer the question "what did we say and decide that day".
The action log is a flow: it runs across meetings, it grows and empties, it is never frozen. It answers "what is still open today".
Both are needed and they feed each other: the actions decided in a meeting enter the log, and the state of the log opens the next meeting. The minutes are covered on their own page, and the allocation of responsibilities on the RACI matrix.
In pylotik.
The log is not a separate document: it is a property of the project, fed by the meetings.
Closing belongs to the requester
An action is not closed by the person who carried it out. This is the structuring rule, and it is enforced by the tool, not by discipline.
The client is an owner like any other
An action that falls to them appears on their side, with its due date. Their delay is dated just like yours.
Actions are logged during the meeting
They are born during the meeting, in the tool where it is held. There is nothing to re-enter afterwards.
Nothing is rewritten
Dropping an action is a state with a reason, not a deletion. You can say what was given up, and when.
The overall frame is on project governance. The full tour is on the product page, and the contractual modes on the commitment levels.
What we are asked about the action log.
What does RIDA stand for?
Log of information, decisions and actions. The acronym is common in organizations that have adopted it and opaque everywhere else: better to spell it out at its first occurrence, then talk about an action log.
What is the difference between a RIDA and minutes?
The minutes describe a meeting and freeze; the log runs across meetings and stays alive. The first says what was decided on a given day, the second what is still open today.
Who should close an action?
The requester, never the assignee alone. This is the point that separates a log that holds from a declarative one: without it, an action is closed when its owner thinks they have done something, which is not the same as having answered the request.
How many open actions is reasonable?
There is no threshold, but there is a signal: if the log gets longer from one meeting to the next without ever emptying, these are no longer actions, they are wishes. It is better to explicitly drop a few than to let them age.
Do you need a log for every meeting?
One log per project, fed by all the meetings. A log per meeting recreates exactly the problem it was meant to solve: ten lists that no one consolidates.
How do you track an action owned by the client?
Like the others, with a named owner and a due date, and by making it visible on their side. That is the condition for their delay to be a dated fact rather than a reproach.
Going further.
- Project governance: bodies, roles and artifacts.
- The RACI matrix: who answers for what, on both sides.
- Steering committee minutes: the frozen artifact, and who approves it.
- Operational commitment management: the definition of the category.