Use Cases · Deliverables & Information Delivery

Delivered on time is half the equation.
The other half is whether it conforms.

Every deliverable tracked against the brief, the EIR and the programme, with a named owner, a live status and a forecast. "Delivered" means reviewed and conformant rather than received, and the record of what was promised survives as long as the liability does.

  • Deliverables tracking
  • EIR and brief conformance
  • Information delivery status
  • Ownership

Structural calculations packDue 12 Sep

One deliverable, four states.

Due

12 Sep, per the programme

Received

11 Sep, a day early

Log stops here

Reviewed

Against 9 information requirements

Conformant

7 of 9. Two schedules missing

Current practice

The tracker says delivered. The programme finds out later.

A deliverables schedule records dates and ticks. It cannot say whether what arrived satisfies the brief, whether anyone reviewed it, or who is accountable for the half that is missing. So a package lands, gets marked complete, and the gap surfaces weeks later in whatever depended on it.

The tracker is also only as current as the last person who updated it, which is usually the week of a report.

  • Received and conformant are recorded as the same event
  • Status is re-keyed by hand from minutes, so it lags the project
  • Items shared between parties have no owner, so neither delivers them
  • Slippage is visible once it has happened, not while it can still be absorbed

Information required for the stage gate

W32W34W36W38W40W42

Structural calcs

Facade performance spec

Acoustic test report

Coordinated services model

Stage gate submission

Today
  • On plan
  • Overrunning
  • Knock-on

Tracked today across, for example

  • MIDP and TIDP
  • Design deliverable tracker
  • RFI and technical query logs
  • Contract deliverables
  • Responsibility matrix
  • BEP
  • Deliverables to payment milestones

With Tektome

Due, owned, delivered, and actually conformant.

Every deliverable is held against the brief, the Employer's Information Requirements and the programme, with an owner attached and a status that reflects the review rather than the receipt. Forecasts are carried alongside due dates, so slippage appears while there is still time to act on it, and the position stands up in front of a client or an auditor.

Delivery positionStage 4

Week 36 · 46 deliverables

Deliverable Due Forecast Owner Status

Structural calculations packEIR §3.2 · 9 requirements

12 Sep

11 Sep

JRJ. Reeve Partial, 7 of 9

Facade performance specificationBrief §7 · 14 requirements

29 Aug

19 Sep

?Unowned 21 days late

Acoustic test reportEIR §5.1 · 6 requirements

05 Sep

14 Sep

MKM. Kaur 9 days late

Coordinated services modelEIR §2.4 · 22 requirements

26 Sep

26 Sep

ATA. Toft Waiting on inputs

Fire strategy, revision 4Brief §4 · 11 requirements

22 Aug

21 Aug

SDS. Dahl Delivered, conformant

Status drawn from the latest issue and this week's minutes

1 – 5 of 46

Facade performance specificationBrief §7 · due 29 Aug

Promised three times and delivered none of them. No owner has ever been assigned, which is why nobody was chased.

Assign an owner 21 days late

This week46 deliverables

28

Delivered and conformant

7

Received but not conformant

4

No owner assigned

EIR

Employer's Information Requirements

Rev 2 · 46 deliverables drawn

What you get

The outputs, and the evidence behind each one.

Tracked against the brief, the EIR and the programme

What is due, what has been received, what has been reviewed and what remains outstanding, measured against the documents that define the obligation rather than against a list somebody typed at the start of the job.

Why it mattersA deliverables list drifts from the brief the moment either changes. Holding them together is what keeps the tracker true.

Outstanding against plan · by week

32
33
34
35
36
37
38
39
  • Outstanding, on plan
  • Received but not conformant

Ownership visible, including where there is none

Every requirement and every deliverable carries a named owner. Where an item sits between two parties and neither has claimed it, that is stated rather than left to be discovered when it fails to arrive.

Why it mattersAn unowned deliverable is not a tracking problem. It is the one nobody is going to produce.

Owners · stage 4 information

Structural calculationsJRJ. Reeve
Acoustic test reportMKM. Kaur
Facade performance specification?Unowned
Coordinated services modelATA. Toft
Fire strategy rev 4SDS. Dahl

Status that updates itself from the meeting

Minutes are read, and the actions, decisions and deliverable updates inside them are pulled straight into the tracker. Nobody re-keys a status the week before a report, and nothing said in a meeting quietly fails to reach the record.

Why it mattersMost trackers are accurate on the day they are updated and wrong every other day.

Minutes · week 36 progress meeting

As writtenItem 4.2. Facade spec now expected 19 Sep, delayed by the revised cladding build-up. MK confirmed the acoustic report will follow on 14 Sep. Client asked whether the gate date still holds.

Updated
Facade performance spec, forecast moved to 19 Sep
Updated
Acoustic test report, forecast 14 Sep, owner M. Kaur
Raised
Gate date at risk, flagged to the programme

Late and incomplete surfaced before it bites

A forecast sits alongside every due date, so a deliverable that is drifting is visible while there is still float to absorb it. Incompleteness counts as lateness here, because a package that arrives missing half its content has not really arrived.

Why it mattersThe window in which a slip is cheap to fix closes long before the slip shows up in a monthly report.

Due against forecast

Facade performance specification

Due 29 Aug21 days late

Acoustic test report

Due 05 Sep9 days late

Structural calculations pack

Received 11 Sep2 items outstanding

What was due, what was promised, what arrived

A linked record of the obligation and every promise made against it, with the meeting and the decision behind each one. If delivery is ever disputed, the sequence is already written down.

Why it mattersDelay claims turn on who promised what and when. That is a record you either kept at the time or reconstruct under pressure.

Facade performance specification

29 Aug

Due per the programme · original obligation

27 Aug

Promised for 05 Sep · week 34 meeting

04 Sep

Promised for 12 Sep · email, cladding build-up revised

11 Sep

Promised for 19 Sep · week 36 meeting

Three promises, no delivery, and every one of them recorded against the same obligation with its source attached.

Value

What the work produces, and the value it returns.

What the workflow produces What it prevents Value
Deliverables held against the brief, the EIR and the programme
A package marked complete that does not satisfy what was asked for
Downstream work that holds, because what it was built on was conformant
A named owner on every requirement and deliverable
An item between two parties that neither one produces
Programme protected, with nothing waiting on an unassigned item
A forecast beside every due date, updated from meetings
Discovering a slip after the float that would have absorbed it is gone
Gates met first time, with gaps closed while there is still float
A linked record of what was due, promised and delivered
Reconstructing a delivery history once it is already contested
A defensible record, answered from the trail rather than an archive

c.35%

of Gateway 2 applications turned back for missing information rather than bad design

Building Safety Regulator, reported statements

44.8%

of projects affected by inaccurate, incomplete or late design, the single largest causal cluster

HKA CRUX, 6th annual report, October 2023 · the design share has declined since

£10,000

per building per week cost of delay, so a 12 week slip is worth around £120,000

BSR Impact Assessment, cited by Centre for Cities · the size of the exposure, not a Tektome result

Why Tektome

A delivery log records arrival. A commitment rests on conformance.

Deliverables are tracked against the requirement register and the review status, not just a schedule of dates. That single difference is what lets "delivered" mean reviewed and conformant, which is the only version of delivered that a programme can safely be built on, and the only one that answers a delay claim years later.

On this A deliverables schedule Tektome
What it records That something arrived Whether the obligation was met
What "delivered" means Received and conformant are the same tick Reviewed against the requirements, and conformant
How status is kept Updated by hand, so it is current the week of a report and stale after Drawn from minutes and issues as they happen
Ownership Holds dates, not the requirements the deliverable has to satisfy Every item carries an owner, and unowned items are named as such
When slippage shows Once it has happened, not while it is forming Forecasts sit beside due dates, so drift is visible while it is cheap

Who this is relevant to

The date is the same. What a missed one costs is not.

A deliverable marked complete that does not satisfy the brief is not a tracking error. It is a programme commitment made on a tick, and the consequence lands well downstream of whoever entered it.

Legal and governance

General Counsel · Company SecretaryManaging Partner, Practice Director or Finance Director at design practices

A delivery record that holds up

What was due, what was promised, when it was re-promised and what finally arrived, each linked to the meeting or email behind it.

Insurance and risk

Whoever owns the PI programmeThe title varies by firm; the renewal obligation does not

Evidence against the information requirements

Deliverables measured against the EIR they exist to satisfy, not against a list that drifted from it months ago.

Information management

Information Manager · Head of Design ManagementBIM lead

Slippage while it is still cheap

A forecast beside every due date, updated from what was said in the meeting, so a drifting item surfaces while there is float to absorb it.

Delivery and packages

Project Manager · Package managerProgramme lead

Nothing unowned

A named owner on every deliverable, and an explicit flag on the ones sitting between two parties that neither has claimed.

In the project team

Architect · Engineer · BIM coordinator. See what a package still owes and what is blocked behind it, without re-keying a status into a fourth system.

Next step

Interested to learn more?

A 30-minute session: a deeper look at the platform, and a conversation about the information your firm owes and is owed. Nothing to set up, no project data needed.

  • A deliverable opened against the requirements it owes
  • A walkthrough on a project we have prepared
  • Live Q&A with our engineering team

Book a 30-minute intro

By submitting, you agree to be contacted about your intro session. We never share your details.