Decision Log: The Forgotten Project Control
Projects keep risk registers, issue logs, change logs and lessons registers, and most of them keep no record at all of the decisions that shaped the work. Those decisions were taken in meetings, in corridors and in email threads, and they survive in the memories of whoever was present, which is a storage medium with a known failure rate.
Section 4 of the PMBOK® Guide Eighth Edition sets out the artefacts a project maintains, and a decision log is among the cheapest of them to keep and the most missed when it is absent.
Why decisions disappear
They are made in conversation. The significant ones rarely arrive as documents; they happen when two people work something out at a desk, or when a room agrees to a proposal in ninety seconds. Nothing in that moment produces a record unless somebody chooses to make one.
The outcome is recorded without the basis. A plan is updated, a design is changed, a supplier is chosen, and the artefact shows the result. What is missing is why: what the options were, what was assumed, what made this the answer. That is the part that matters later.
The people who hold them leave. On a two-year programme, a substantial proportion of the team changes, and every departure takes a set of unrecorded reasons with it. The remaining team then inherits arrangements nobody can explain, which is the beginning of re-litigation.
What an entry needs
The decision itself, in a sentence somebody outside the project could read. Not a reference to a paper, but what was actually decided.
Who took it, and when. A name and a date. Where it was a group, name the group and the person who chaired it. This is what makes the record usable in a dispute and what stops the decision being attributed, a year later, to whoever is least able to object.
The basis. The options considered, the assumptions relied on, and the reason this one was chosen. Two or three sentences. This is the part that converts a record into something useful, because it lets somebody later ask whether the reasoning still holds.
What would make it worth revisiting. The condition under which the decision should be reopened: a supplier withdrawing, a volume assumption failing, a regulatory change. Written at the time this costs a line; established retrospectively it is guesswork.
The same question, settled three times
A bank's change programme decided, in month three, to hold customer consent records in the existing document store instead of the new platform. It was a considered decision: the document store already carried the retention controls, the cost of building equivalents was significant, and the volumes were modest.
The decision was taken in a working session at a whiteboard, agreed by the programme manager and the data architect, and the board was wiped a few days later. The design documents showed the outcome and none of the reasoning.
In month nine, a new architect joined, saw a design that looked inconsistent, and proposed moving the records to the new platform. Nobody could explain the original decision, so the question was worked through again, at a cost of about three weeks and two workshops, and the same answer was reached.
In month sixteen it happened a third time, when a vendor's proposal included consent storage at no additional licence cost. That time it took two weeks, and the answer changed, because one of the original assumptions about volume had been overtaken. The change was correct and it was reached by accident, because nobody knew that a volume assumption had ever been part of the basis.
A decision log with four lines in month three would have saved five weeks of work and would have flagged, at the point the volumes rose, that a decision now needed revisiting. The ghost of the original working session stayed on the whiteboard for months, layered pale under everything written after it, which is about as much record as most decisions get.
Keeping it light
Log the decisions that would be expensive to revisit. Not every choice, which produces a document nobody maintains. Architectural choices, commercial commitments, scope exclusions, standards adopted, anything with a cost to reverse.
Write it in the meeting, not afterwards. Four fields take ninety seconds while everybody is present and remembers the reasoning, and take half an hour to reconstruct the following week, if anybody does it at all.
For a PMP® candidate, it helps to recognise that recording decisions with their basis is a control rather than administration, so a scenario about a settled question being reopened is describing a record that was never made. A response that reconvenes the discussion repeats the original cost. A structured PMP exam preparation course examines situations where a project is re-deciding what it decided eight months ago.
Start one this week with the last three significant decisions your project made. Write the decision, the name, the date and the reasoning, and see how much of the reasoning you can still reconstruct. Whatever proportion that is, it is the proportion that will still exist in a year.
Interested in going further?
The most expensive unrecorded thing on a project is rarely a risk or an issue; it is the reason somebody chose one option over another. Omega's PMP® Exam Preparation works through decision records as a working control.
Project records of this kind are described among the artefacts in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A169: Assumption Log vs Risk Register
A171: Change Log vs Issue Log
A155: Risk Register vs Risk Report vs Issue Log: What Goes Where?
A172: Lessons Learned Register: Use It Before the Project Ends
A167: Project Charter Explained: Purpose, Content and Common Misunderstandings
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
