Decision and Accountability Log: Document Every Decision

It happens in month six. A feature ships, a stakeholder reviews it, and the question lands: "Who decided we'd build it like this?" Nobody can answer cleanly. The engineering lead remembers a Slack thread from sprint two. The product lead remembers a Zoom call. The client remembers it differently. Two weeks of velocity disappeared into the dispute. By the time everyone agrees on what probably happened — or stops trying — trust has frayed, and the project carries a quiet new tax: every future decision now needs a meeting because nobody trusts the informal channels anymore.

The pattern is recognisable. Most projects of any duration encounter it once. Many encounter it three or four times. Each instance burns calendar weeks that were budgeted to ship features.

A decision accountability log is the simplest delivery artefact that prevents this conversation, and it costs almost nothing to maintain. It exists for one reason: when a decision is questioned later, there is a written record of who made it, when, and why. That single piece of documentation transforms month-six scope conversations from adversarial to productive.

In Built to Last™ 2.0, the decision log sits inside the P04 Right Delivery pillar alongside the Scrum framework, change control register, and risk register. Each instrument serves a different purpose, but they share one operating principle: the project should never depend on anyone's memory. The log is the smallest, cheapest piece of that discipline — and the one with the highest defensive return per minute spent.

This article walks through what the log contains, how to run one without it becoming bureaucratic theatre, and where the failure modes hide even when a team technically has one.

What it costs when there's no record

When you can't find the record of a decision, you don't only lose the time spent litigating it. You lose three other things, and they compound.

The first is the calendar cost. A two-week dispute at month six is two weeks of zero velocity. The engineering team isn't shipping; the product team is in meetings reconstructing chronology; the account lead is mediating. On a fixed-price proposal, the cost falls on the agency. On time-and-materials, it falls on the client. Either way, both sides feel poorer at the end of it.

The second is the trust cost. Disputes about the past create scepticism about the future. Once a project has had one "who agreed to this?" conversation, subsequent decisions tend to be made in writing and reviewed by lawyers. The pace of decision-making slows. Calls that should take twenty minutes start taking three days because both sides want email trails. The lightweight, conversational mode that made the early sprints fast becomes impossible.

The third is the precedent cost. Whatever resolution the dispute reaches — the team absorbs the time, the client absorbs the cost, or it becomes a contract amendment — sets a pattern. If the team absorbs it, the team becomes defensive. If the client absorbs it, the client becomes suspicious. Neither outcome is conducive to the kind of partnership that ships well past launch.

None of these costs appear in the original proposal. They surface late, after both parties have already absorbed the budget assumption. The log is the instrument that prevents the original cause: a state where neither side can prove what was agreed.

What a decision accountability log actually contains

The log is a single, plain-language document that captures every project decision worth recording. The bar for "worth recording" is whether a future stakeholder might reasonably ask about it.

At minimum, each entry contains seven fields: the decision ID used to reference it later, the date the decision was made, a one-sentence summary in plain language, the options considered (including the rejected ones), the choice made, the rationale for choosing that option over the others, and the owner — the single accountable person who signed off.

Many teams add three optional fields: the stakeholders consulted, the impact area (scope, budget, timeline, architecture, design), and the status (proposed, approved, superseded, withdrawn). These make the log easier to filter later when someone is searching for "every architecture decision affecting the data model" or "every decision the client signed off on before sprint four."

The log can live in any tool that supports versioned, searchable, plain-text content. We've seen teams run it in a Confluence page, a Notion database, a Markdown file in the repo, or a row-per-decision spreadsheet. The tool matters less than the discipline of writing entries within forty-eight hours of the decision being made. Memory degrades quickly beyond that window.

A decision log entry that fails its purpose is one missing the rationale. "We chose Postgres" is not a useful entry. "We chose Postgres over MySQL because the read replica story is better-documented and the team's senior engineer has prior production experience with it. MongoDB was considered and rejected because our access patterns are relational. Owner: Engineering Lead. Stakeholders consulted: Client CTO." That is a useful entry. The rationale is what makes the entry defensible in six months when someone asks why.

The log is owned by the named account lead, written by whoever made the decision, and reviewed at every sprint demo as part of the standing agenda. The demo review serves two functions: it surfaces decisions the client hadn't realised were made, and it creates a forcing function for the team to keep the log current.

The most common failure mode for a log that exists is partial maintenance. A project starts with discipline, deadline pressure hits in sprint six, and entries stop being written for a few weeks. By sprint nine, half the recent decisions aren't recorded, the log isn't trusted, and people stop consulting it. The discipline matters more than the format. A weekly check by the account lead — five minutes asking "what decisions did we make this sprint that aren't in the log yet?" — keeps it honest.

A concrete example. In sprint three of a fintech build, the team decides to defer a multi-currency feature to phase two. The decision is made in a planning meeting between the product lead, engineering lead, and the client's head of product. The reasoning: the launch market doesn't require it, the architecture can be extended to support it later without rework, and pulling it forward would delay launch by four weeks. The conversation produces a decision log entry the same day, marked approved, owner = client head of product, rationale documented in two sentences. Five months later, when a new stakeholder asks why multi-currency wasn't included, the entry opens in under a minute and the question takes ninety seconds to resolve. With no entry, the same question costs a week.

How to start running a decision log this week

Implementing the log is a forty-minute task on day one and a five-minute task every sprint thereafter. It is the cheapest piece of delivery discipline in the framework.

What to avoid. Don't log trivia. An entry per ticket is unmaintainable and dilutes the signal. The bar is "would a future stakeholder reasonably ask about this?" Most sprint-level ticket decisions don't pass that bar. Architecture decisions, scope decisions, timeline decisions, design decisions affecting user experience, and any decision involving a trade-off the client wasn't in the room for — those pass the bar.

Don't make the log private. The whole point is that the client can open it whenever they want. A private log is a backside-covering document, not a working artefact. Shared logs build trust; private ones erode it.

Don't retrofit a log that's been missing for six months and treat it as authoritative. Backfill what's recoverable, start fresh from the current sprint, and accept that decisions made in the first half of the project are weaker evidence than decisions made under the log.

The log depends on, and reinforces, the named account lead. Without one accountable person across the engagement, the log has no natural owner and tends to become orphaned. If the project doesn't have a named account lead, fix that first.

What this looks like in practice

A mid-sized Australian SaaS client we worked with — an engineering team of around fifteen, building a customer-facing reporting product on a fixed-scope engagement — reached month six of an eight-month build and hit exactly the failure pattern this article opens with.

A stakeholder reviewed the demo and questioned whether the team had been authorised to drop a white-label theming feature. The team's recollection was that white-label had been removed in sprint two when the client decided to simplify launch scope. The client's recollection was that white-label had been "parked, not removed." With no written record, both versions were defensible. The next two weeks of project velocity disappeared into chronology reconstruction. The team trawled Slack history. The client checked their internal meeting notes. The account lead arranged a steering committee call. By the time everyone agreed on what had probably happened, two sprints had been lost and the launch date had moved.

A single log entry from sprint two, with the rationale recorded and the client's head of product as the owner, would have ended the conversation in five minutes. The entry would have said: "Decision 11: De-scope white-label theming from launch. Options considered: (a) build as designed, (b) defer to phase 2, (c) cut entirely. Decision: cut entirely. Rationale: complexity incompatible with launch deadline; only one signed customer requires it; phase 2 build agreed if a second customer materialises. Owner: Client Head of Product. Date: [sprint 2]."

That entry would have cost the team about three minutes to write. It would have saved the project two weeks. The cost-benefit ratio is the kind of asymmetry that justifies the entire delivery discipline.

The team adopted the log retroactively from that point and shipped the remaining two sprints without further dispute. The pattern they kept: every decision that involves dropping, deferring, or substantially changing scope gets an entry the same day, reviewed at the next sprint demo with the client in attendance.

When the log is critical, and when it can wait

The log is non-negotiable on fixed-price engagements, on engagements over twelve weeks, and on engagements with more than two stakeholders on the client side. Each of those conditions on its own raises the probability of a month-six dispute high enough to justify the log. All three together makes it structurally required.

It's highly recommended on regulated builds — fintech, healthtech, government — where decisions may need to be defended to an auditor years later. The same applies to any build where the original sponsor might move on before launch and a successor stakeholder might inherit a half-built product. In those situations the log isn't only defending against disputes; it's the mechanism preserving the build's intent.

The log is genuinely deferrable on short engagements with one client-side stakeholder and no fixed price. A four-week sprint with a solo founder pre-revenue, where the founder is in every meeting and the engineering team is two people, doesn't materially benefit from a formal log. Conversations are recoverable from memory, and the cost of dispute is low. Adopting a heavyweight artefact here is the kind of process theatre that erodes credibility for the rest of the framework.

Most engagements that look short are actually long. If there's any chance the project will extend, get a second phase, or hand off to a different team, the log earns its keep from sprint one.

Where to start this week

If your project doesn't have a decision log yet, do this today: open a new document, write down the three most consequential decisions of the last sprint with rationale and owner, and share the link with the client. The exercise takes thirty minutes and changes the trajectory of every subsequent scope conversation.

For more on the delivery discipline this sits inside, see how we deliver custom software. The decision accountability log is one of several P04 Right Delivery instruments — the others are worth knowing about before your next engagement.

Frequently asked questions