Accountability Has a Name, a Date and a Time Stamp

Accountability is the most frequently stated and least frequently operationalised value in capital project delivery. Every entity's governance charter contains it. Every project kick-off presentation includes a slide on it. And on the majority of projects, when something goes wrong, establishing who decided what, when, and on what basis takes weeks of forensic effort and produces a contested answer.

This article is about how a Project Management Information System converts accountability from a stated intention into a structural property of every transaction.

What accountability actually requires

Strip away the language and accountability in a capital project requires four things to be knowable, permanently and without dispute.

Who was authorised to make this decision. Who actually made it. When they made it. What information was in front of them at the moment they made it.

The fourth is the one that is almost always lost. It is usually possible, with effort, to establish that an approval happened and who signed it. It is much harder to establish what the approver was looking at. Was the cost impact known at the time, or added later? Had the design been superseded? Was the risk already on the register? In disputes and in audits, this is where positions become unrecoverable.

A PMIS resolves this because approval is an action taken on a record, and the record has a version history. The system knows what the record contained at the moment of approval because it retained that state. This is not a reporting feature. It is a property of how the data is stored.

I raised this in the previous article and return to it because it is the single control that most changes an entity's exposure.

Every government, semi-government and PIF entity has a delegation of authority matrix. It defines financial thresholds, approval levels, and the conditions under which a decision escalates. It is typically a well-drafted document, approved at board level, and reviewed periodically.

The question is what enforces it between reviews.

In a manual environment, enforcement is individual knowledge plus retrospective audit. The project manager is expected to know the thresholds. The finance function is expected to catch errors at payment stage. Internal audit samples transactions after the fact. Each of these is a real control, and each of them operates either at the wrong time or on a fraction of the population.

When the DOA is configured as workflow logic in PMWEB, enforcement moves to the point of transaction and covers the entire population. A commitment above a threshold physically cannot reach approved status without the required authority acting on it. The control is preventive rather than detective — which is the distinction that matters most to an audit committee.

There is a secondary effect that entities often value more than the primary one. Because escalation is automatic, project teams stop managing approvals politically. Nobody has to decide whether to escalate. The system decides, and the decision is not a reflection on anyone.

The problem of silent delay

Accountability failures in capital projects are less often about wrong decisions than about absent ones.

A submittal sits with a reviewer for six weeks. An RFI is unanswered for a month. A payment application is neither certified nor rejected. A variation is neither approved nor refused. Nobody made a bad decision, because nobody made This category of failure is uniquely well addressed by a PMIS, because a system that holds the record knows exactly how long it has been held and by whom.

Configured properly, PMWEB tracks the elapsed time on every open item against contractual or policy review periods, escalates automatically when the limit is approached, and reports the aging of every pending action across the portfolio. The PMO no longer has to ask project teams what is stuck. It can see what is stuck, ranked by how long and by how much it matters.

Accountability across organisational boundaries

A capital project is delivered by an entity, one or more consultants, a main contractor, subcontractors and suppliers. The processes that most often fail are the ones that cross between these organisations, because each party keeps its own records and the boundary is bridged by email.

The consequence is that on many projects there are three parallel and non-identical records of the same events. The contractor's log of RFIs, the consultant's log, and the entity's log rarely reconcile. Each is maintained honestly. They differ because they were built from different sources.

When all parties transact in a single system, this class of dispute disappears. There is one RFI register. It contains the date the RFI was raised, because the contractor raised it in the system. It contains the date the response was issued, because the consultant issued it in the system. Neither party is relying on the other's word, and neither is exposed to the other's record-keeping quality.

Extending system access beyond the entity's own staff is often resisted at first, usually on security grounds. It is worth working through, because the value of a PMIS is roughly proportional to the completeness of the transaction

What accountability is not

Two clarifications, because this argument is sometimes heard as something it is not.

Accountability enforced through a system is not surveillance of individuals. The purpose of knowing that a submittal has been with a reviewer for six weeks is to unblock the project, not to build a case against the reviewer. In practice, teams working in a well-implemented PMIS report the opposite of the feared effect: because their own work is visible, they stop absorbing blame for delays that originated elsewhere. Visibility protects the diligent.

Nor is it a substitute for judgement. The system does not decide whether a variation is justified. It ensures the question reaches the person entitled to answer it, with the relevant evidence attached, within a period that does not damage the project.

The stakeholder's test

If you have an interest in the delivery of a capital project — as a board member, a funder, a regulator, an auditor or a citizen affected by its outcome — accountability is what allows you to rely on the assurances you are given.

The test is simple. Select any significant commitment made on the project in the past quarter. Ask to see who approved it, when, under what authority, and what supporting information was attached at the time of approval.

If that takes an hour, the entity has a governance system. If it takes a week and produces a reconstruction rather than a record, it has a governance policy.

Next in the series: why transparency is a question of access, not of reporting.