Skip to content
BIMpedia
Chapter 4 · Lesson 3 of 4Topic: ISO 19650 basics

Review, authorisation and acceptance

Between a task team finishing its work and the client relying on it there are three separate decisions, made by three different parties. Name who makes each one, and what they check, before the first delivery.

3 min read3 quiz questions
Skip to the quiz
  • Watch out
  • What it costs
  • Experienced readers
  • Remember
  • In BIMpedia
Mayainformation manager
Even if you do this every day, watch for this: Acceptance needs criteria written in advance. If the EIR doesn't say what 'acceptable' means for each deliverable, the client can only accept on impression, and rejecting later becomes an argument instead of a check.

Information goes through three hands before a client relies on it, and each hand makes a different decision. ISO 19650-2 keeps them apart on purpose: the team that produced the work checks it, the party responsible for the whole delivery authorises it, and the party that asked for it accepts it.

Three decisions before information is accepted
Task teamProduces the information
Lead appointed partyResponsible for the delivery
Appointing partyThe client
Shared Submitted↺ not ready↺ rejected
1CheckResult: Names, codes, standard met
2Review the contentResult: Approved to share
3Review the whole setResult: Coordinated, complete
4AuthoriseResult: Submitted to the client
5Review and acceptResult: Against the EIR criteria

The task team checks and reviews, the lead appointed party authorises the set, the appointing party accepts it against the requirements. Dashed: sent back.

1. Check and review, by the task team

Before anything leaves work in progress, the task team checks the form (container name, status and revision, the information standard, the methods agreed for the project) and reviews the content (is it what the task plan said, at the right level of information need, coordinated within the team?). Only then is it shared.

2. Review and authorise, by the lead appointed party

The lead appointed party looks at the set: every team's containers for that delivery, together. Are they coordinated with each other? Is everything in the MIDP for this milestone there? Is it complete against the requirements? If so, the person named in the BEP authorises it, and it is submitted to the appointing party. If not, it goes back to the task teams with what needs fixing.

3. Review and accept, by the appointing party

The appointing party reviews the submission against its acceptance criteria: the measurable conditions written in the EIR for each deliverable (for example "every maintainable asset has a tag, a type and a maintenance regime"). It accepts, and the information becomes published and part of the project record, or rejects it with reasons.

Story · Approved by everyone, checked by no one
How it goes wrong

At each stage the design team shares its models, the lead designer clicks "approve" in the CDE, and the client's project manager replies "looks good". At handover the facilities team finds that a third of the plant has no tag and no maintenance data. Nobody can say who approved what against which requirement.

How it goes right

The EIR lists acceptance criteria per milestone. The lead designer's authorisation step includes an IDS check and a COBie test import; the client's information manager checks the same criteria on a sample and records acceptance in the delivery tracker. The missing tags are found at stage 4, when adding them is an afternoon's work.

Mayainformation manager
Your turn. Give it about 15 min and work it out on your own before you open the model answer: that is where it sticks.
Exercise: Who decides, and on what 15 min

A stage 4 delivery is due: architecture, structure and MEP models, a door schedule and a COBie file. For each of the three decisions, write who makes it and three things they check.

Key takeaways

  • The task team checks and reviews its own information before sharing it: names, codes, standard, then content.
  • The lead appointed party reviews the whole set across teams and authorises it before submitting it to the client.
  • The appointing party reviews the submission against the acceptance criteria in its requirements and accepts or rejects it.
  • Each decision is made by a person named in the BEP or the responsibility matrix, and recorded; a rejection goes back with reasons.

Your notes

Related tool

A one-page weekly delivery report from your MIDP, issues, RFIs and model QA, with a trend.

Open Delivery Tracker →

Check yourself

3 questions · 2 right to complete
  1. 1. The client finds at handover that half the asset data is missing, although every model was 'approved'. What most likely went wrong?
  2. 2. Who authorises a federated stage 4 model set before it goes to the client?
  3. 3. A task team shares a model with wrong container names. At which point should that have been caught?
0 of 3 answered
PreviousContainer metadata: status, revision and classificationNextMobilisation

Discussion

Open on the forum ↗