Project Control Records and Reporting Map

Control guidance

Think in evidence relationships, not document counts

A project-control record exists to authorise, communicate, verify or learn. The same control purpose can be satisfied by a concise document, a workflow item, a database record, a dashboard linked to controlled data or an integrated workspace. Counting templates therefore says little about control quality. The relevant questions are whether information is complete for its decision, current, owned, protected from unauthorised change and traceable to the products and authority it affects.

Records fall into four useful classes. Baselines are approved reference points such as the project brief, initiation documentation, plans and product descriptions. Dynamic records are continuously updated, including risk, issue, quality, lesson and configuration status. Reports are views prepared for a defined audience and time or event, such as checkpoints, highlights, stage-end, exception and end-project reports. Decisions are the approvals, conditions, concessions, directions and authorisations that change what the project may do.

These classes should remain linked. A report should not become an independent baseline. A decision should identify the plan or product version it approves. A register entry should link to its impact analysis and implementation evidence. A product approval should reference the tested configuration. When the links are absent, teams spend time reconciling status and may act on superseded information.

Control guidance

Lifecycle decision-to-evidence map

The most reliable way to design project information is to begin with decisions. For each gate or delegated action, list the authority, questions, evidence, recommendation, possible outcomes and record of decision. This avoids collecting data that no one uses while missing evidence that arrives too late. The level of detail should match the decision: governance needs integrated stage and investment evidence; delivery needs precise product and work instructions.

Each process both consumes and creates information. Startup converts a mandate into a brief and initiation request. Initiation creates the authoritative delivery baseline. Direction creates authorisations. Stage control and product delivery update actual and forecast evidence. Stage boundaries renew or replace authority. Closure confirms acceptance, transfer and evaluation. Risk, issue, quality, configuration, lesson and benefit records operate across those processes.

Control guidance

Foundation and baseline records

The mandate states the commissioning need. The project brief develops it into an initial product, scope, approach, governance and outline justification suitable for initiation. The initiation documentation then assembles or references the approved project plan, business case, benefit approach, management approaches, controls, roles and tailoring. It is an information baseline, not necessarily a single file. A contents map should identify which component and version is authoritative.

Plans exist at different decision horizons. The project plan supports whole-project viability and stage decisions; the stage plan authorises detailed management for one stage; optional team plans support accepted work packages; an exception plan replaces a plan forecast outside tolerance. Product descriptions define purpose, composition, derivation, quality, tolerance, method and approval. The final project-product description defines customer acceptance.

Baselines need formal status and change control. Draft, reviewed and approved should not be inferred from folder location. Identify approver, approval date, effective date and superseded version. A baseline may be updated through an approved change or stage decision; preserve the history and record what downstream work or evidence must be revised.

Control guidance

Registers and dynamic records

The risk register records uncertain threats and opportunities, cause-event-effect statements, probability, impact, proximity, owners, responses, residual exposure and status. The issue register records requests for change, off-specifications and problems or concerns, with impact, decision and implementation. The quality register schedules and records reviews, tests, results and evidence. The lessons log captures learning as it arises. The configuration system records product identifiers, versions, status, relationships, approvals and history.

A daily log can hold informal actions, observations and events that do not yet require formal control. It should not become a shadow issue register or the only evidence of significant decisions. Move an item into the appropriate formal record when it affects a baseline, needs sustained tracking, has wider impact or requires authority. Link the original observation if context matters.

Dynamic records need common status definitions and update rules. Every open item requires an owner, current action, due date or trigger, and escalation path. Closure status needs evidence and rationale; deleting or filtering closed items can destroy traceability. Use reference identifiers across systems so a risk response in the plan and an issue decision in a report can be traced back to the source entry.

Control guidance

Work, product and quality evidence

A work package connects the stage plan to delivery. It identifies products, descriptions, constraints, interfaces, resources, reporting, tolerance, quality methods, issue arrangements and handover. The accepted package is a commitment; checkpoint reports update its forecast; approved product versions and records support completion. A team plan may provide detailed execution information but cannot silently alter the package.

Quality evidence must identify the product and version, criterion, method, conditions, result, reviewer, date and disposition. Approval records show that a product satisfies its description. Acceptance records show that the integrated final product meets agreed customer criteria. Concessions identify the specific authorised deviation and residual conditions. Configuration status ties these records to the actual delivered item.

Evidence should be discoverable without copying it into every report. The quality register can link to detailed test results; a checkpoint can link to product status; a stage-end report can reference the approved configuration and outstanding concessions. Copies create version conflicts and increase the risk that governance sees an obsolete position.

Control guidance

Reports: time-driven and event-driven

Checkpoint and highlight reports are time-driven. Their frequency and detail follow the control need. A checkpoint communicates work-package products, achievements, remaining work, quality, issues, risks and forecast from delivery to the project manager. A highlight communicates integrated stage health and forecast to governance. Neither should wait for a forecast tolerance breach: the event-driven exception report is raised when the trigger occurs.

Event-driven reports include issue, exception, stage-end and end-project reports. An issue report contains baseline, impact, options and recommendation. An exception report identifies forecast breach, consequences and decision need. A stage-end report evaluates actual performance, products, exposure and lessons while supporting the next-stage decision. An end-project report evaluates the project against its authorised baseline and supports closure.

Every report should show the status date, baseline version, forecast assumptions, author, audience and decisions requested. Use consistent measures and accessible labels rather than colour alone. The report is current at a point in time; the underlying systems continue to update. Preserve the report version that supported a material decision.

Control guidance

Decision, assurance and communication records

A decision record states the question, authority, evidence considered, options, decision, conditions, dissent where relevant, effective date, actions and affected baselines. Meeting minutes can serve this purpose if they are timely and unambiguous. A long transcript without a clear decision is weak evidence. Advice and recommendation should remain distinguishable from approval.

Assurance records identify scope, criteria, evidence reviewed, findings, significance, recommendation, owner and follow-up. Assurance should report directly to the governing role that delegated it and preserve independence from the project manager or delivery work reviewed. Closure of an assurance finding requires evidence, not only a management response.

The communication approach maps stakeholder information needs, frequency, sender, medium, confidentiality and feedback. It should include how affected people can raise issues and how closure is communicated. External and contractual communications may have notice requirements and authorised senders; these must be integrated with project records without exposing information inappropriately.

Control guidance

Information governance and retention

Define one authoritative source for each information class and how data moves between tools. Access should match confidentiality and role, but decision-makers need sufficient visibility to fulfil accountability. Use naming, identifiers, metadata and search that allow retrieval by product, stage, issue or decision. Backups and audit history should follow organisational requirements and product criticality.

Retention depends on legal, contract, safety, financial, operational and learning needs. The project method does not create a universal retention period. At closure, identify records transferred to operations, records archived, records disposed of and the authority for each. Preserve evidence required for warranties, asset management, regulatory obligations, future changes and benefit reviews.

Privacy and security apply to project information. Collect only necessary personal data, restrict sensitive supplier or personnel information and use approved systems. Reports should avoid unnecessary identifiers. This package deliberately removes source company and personal examples; deployed project records should apply the same data-minimisation principle while retaining accountable role names where operationally required.

Control guidance

Tailoring and maturity diagnostic

A small project can combine the brief, initiation baseline, plan and approaches, and can use a combined risk-issue-action-decision log. It should still distinguish baselined from dynamic information and preserve approvals. A larger project can distribute records across specialist systems, but it needs an information map and identifiers to maintain one integrated control view. Tool sophistication does not compensate for unclear ownership or status.

Automate repetitive capture and roll-up where data definitions are stable. Avoid manually copying the same status into several presentations. Dashboards should allow users to trace a headline to its underlying product, plan, issue or risk. Human judgement remains necessary for forecast confidence, trade-offs and authorisation.