Documentation occupies an uncomfortable position in the project management conversation. On one side sits the practitioner who has spent time on a programme buried under templates, approval chains, and document registers that nobody consults once filed. On the other sits the one who has watched a project unravel because a critical assumption was never written down, a decision was never recorded, and the person who made it left the organisation six months before the consequences arrived. Both experiences are real. Both reflect failures of calibration rather than failures of the discipline itself. The question for any delivery professional, and for any organisation that depends on effective project outcomes, is not whether to document but how much, what kind, and for whom.

The gap between what was said and what was written is exactly where disputes, delays, and delivery failures find their space to grow. Documentation is not the bureaucracy of project management. It is its institutional memory.

Why It Matters Across the Full Lifecycle

Across the lifecycle of a project, from initiation through delivery to close and benefit realisation, documentation performs functions that no other mechanism replaces. At initiation, a well-constructed business case and project initiation document create the shared baseline against which scope, cost, and benefit are measured throughout. Without them, the question of whether a project has succeeded becomes a matter of interpretation rather than evidence. During delivery, the risk register, decision log, and change control record provide the live institutional memory that holds the project together when team members change, when assumptions are revisited, or when a senior stakeholder asks why a particular direction was taken. At close, the lessons learned register and benefits realisation framework are the mechanisms through which an organisation extracts transferable value from the investment of delivery. Where these documents exist in name only, updated infrequently and consulted rarely, the value they represent is lost as completely as if they had never been produced.

Too Little: When the Project Lives in People's Heads

The most common documentation failure in project delivery is not over-documentation but under-documentation of the things that matter most. Requirements discussed but never written down. Decisions made in meetings and captured nowhere. Risk assessments that exist as a mental model in the project manager's understanding and nowhere else in the organisation. The consequence of this pattern is rarely immediate. Projects can operate for months on shared understanding, informal alignment, and the continuity of a stable team before the gap becomes visible. It becomes visible when a key team member leaves and their institutional knowledge leaves with them. It becomes visible when a stakeholder disputes a decision that was never recorded. It becomes visible when the scope of a change request is contested because the original requirement was never baselined. In each case, the cost of the missing document far exceeds the cost of producing it at the time it was needed.

Too Much: When the Library Becomes a Labyrinth

The failure in the opposite direction is less often discussed but equally damaging. Organisations that impose comprehensive documentation frameworks without calibrating them to the scale, complexity, or risk profile of the project create a different kind of problem: a documentation burden that absorbs delivery capacity without generating proportionate value. When the team spends more time producing governance artefacts than it does on the work those artefacts are meant to govern, the framework has consumed the function it was designed to support. When the risk register carries three hundred entries and nobody can identify the five that actually threaten the programme, the register has become noise rather than a management tool. When the project library contains forty documents of which six are ever consulted, the remaining thirty-four are not a safety net. They are a maintenance liability. Proportionality is the discipline that separates documentation that serves delivery from documentation that substitutes for it.

The Project Document Library: Enablement and Risk

The table below maps the core documents of the project lifecycle to what they enable when maintained with discipline and what their absence or neglect costs in practice.

DocumentWhat it enables when well-maintainedWhat its absence costs
Business CaseA baseline for scope, budget, and benefit against which the project can be measured at every stage of delivery.Scope creep with no agreed reference point; benefit realisation unmeasured and undefendable at close.
Project Initiation DocumentShared understanding of objectives, ownership, constraints, and decision-making authority from day one.Conflicting assumptions about what the project is and who is responsible for what, surfacing late and expensively.
Risk RegisterLive visibility of the threats being managed and the decisions being made in response.Surprises that were predictable; no record of the choices that preceded them when accountability is questioned.
Decision LogAn audit trail of why choices were made, by whom, and on what basis.Re-litigated decisions; institutional memory lost when key people leave before delivery is complete.
Change Control LogA structured record of scope, cost, and schedule variations and the approvals that authorised them.Scope disputes with no agreed baseline; contested changes that consume governance time rather than advancing delivery.
Lessons Learned RegisterReal-time capture of what is working and what needs adjusting, available to the organisation beyond this programme.Repeated mistakes across programme boundaries; no transferable learning from the investment in delivery.

Getting the Balance Right

The calibration question has no universal answer, but it has reliable principles. Documentation should be proportionate to the risk and complexity of the project: a programme with a multi-year timeline, significant capital investment, and cross-organisational dependencies demands a more rigorous library than a three-month internal improvement initiative. Documentation should be live rather than filed: a risk register updated once at initiation and never revisited is a compliance artefact, not a management tool. Documentation should be written for its reader: the executive summary exists to inform a decision, not to demonstrate the writer's thoroughness. And most critically, documentation should capture decisions, not just descriptions. The most valuable record in any project library is the one that explains why a direction was taken and not just what direction was taken. That is the document that protects the project when the person who made the decision is no longer in the room.

The most valuable document in any project library is the one that explains why, not just what. That is the record that protects the programme when the person who made the decision is no longer in the room.

Library Configuration: The Infrastructure Behind the Documents

The discipline of library configuration, how a project's documentation is named, versioned, accessed, and maintained, is treated as an administrative concern in many organisations. It is not. A document library with inconsistent naming conventions, no version control discipline, and no clear ownership of each record is a library that will fail the project at exactly the moment it is needed most: under pressure, when time is short, when the team has changed, and when the question of what was agreed and by whom has become urgent. Configuration standards are the infrastructure that determines whether a project's institutional memory is accessible or effectively lost. Clear version history, defined ownership, a distinction between live working documents and archived reference material, and access controls that keep the right people in the right records are not overhead. They are the conditions under which documentation does the job it was produced to do.

The Hervey Dickens Perspective

At Hervey Dickens Consulting, we see the documentation question play out at both ends of the spectrum across the organisations we work with. Programmes that are under-documented lose continuity, repeat decisions, and carry disputes that a written record would have resolved quickly. Programmes that are over-documented accumulate governance theatre that consumes delivery capacity without supporting it. Our approach to programme delivery and governance helps organisations find the calibrated position: documentation that is proportionate, live, and genuinely used, underpinned by library configuration that makes the right information findable at the right moment.

Getting this balance right is not a minor efficiency gain. It is a fundamental condition of delivery that holds under pressure and produces outcomes that can be evidenced, defended, and learned from.