The invitation went out on Monday. By Thursday the ductwork subcontractor's office administrator has tried the link twice — once on her phone in the car park, once on the machine in the cabin — and both times it asked for a code that goes to a mailbox belonging to somebody who left the firm in March. She has not rung anybody, partly because she does not know who to ring and partly because there is a tender due Friday. Her supervisor, meanwhile, is installing from an A1 plotted three weeks ago and a zip that arrived in a messaging thread. On the adoption report, that trade is green.

This is where common data environment programmes actually fail. Not at the licence, not at procurement, not in the BEP, but at the point where a named person at an installing company is meant to start living in the environment and quietly does not. The standard response is another webinar: ninety minutes on a Tuesday afternoon, a recording nobody opens, and the same zip in the same thread by the end of the week.

Ten working days per trade, run by the document controller who already has the job, works better than any of that. Access first, on the machine they will use at seven in the morning. Then naming. Then the set they must build from. Then one upload. Then one numbered transmittal. If those five things have not happened by day ten, the firm has been shown a screen.

Decide what onboarded means before you invite anyone

Write the acceptance test first, in one sitting, before an invitation leaves anywhere. The trade is finished when a named person who was not in the kick-off can do four things without ringing the main contractor's document controller:

  1. Find the current published set for their package and say which revision of a named sheet is live.
  2. Name a container correctly — identity stable, revision in a field, suitability from the agreed list.
  3. Upload one container into work in progress rather than into Published.
  4. Issue one numbered transmittal: date, purpose, exact containers and revisions, named recipients.

A login gets you none of that. Neither does a green row in the user list, which is the thing most adoption reporting is actually counting. "They have access" is the sentence that lets an unofficial set stay live in a trailer for eight months.

Name the person, not the package and not the contractor. Somebody who can be asked, in November, which revision they plotted on a Thursday in July, and who can answer. If the honest answer to "who is this" is a role or a shared mailbox, you do not yet have anyone to onboard, and the whole ten days will end up being performed on your monitor rather than theirs.

Then name the document you will test against — the information standard, or the BEP, whichever actually publishes the status codes and naming fields. Read it before day three rather than during it. If no such list exists on your project, write that down; you have already found something, and day three is going to hurt.

Day one: a login that works on their machine

Access is a working session at their desk, or in their cabin, on the device that will be open at seven. It is not a demonstration.

Sit with the named person. Set the account up against their own company email if you possibly can, because shared inboxes turn every later receipt into a fiction — nobody can ask info@ what it understood. Walk the password, the multi-factor, the reset path. Write down the name and number they ring when the token fails on a site laptop at half six on a wet morning. If they cannot get back in without you, they will stop trying on day two, and you will not hear about it.

Then prove three things from their seat rather than yours:

  • They can sign in on the cabin machine and on a phone, outdoors, in daylight.
  • They can see the packages they are appointed to and cannot open the ones they have no business in.
  • They can open one published container for their trade and download it. If the download renames the file — and it often does, with a timestamp or the word "export" — write the new name down. You have just watched a second identity being minted, and it will follow you round the job.

Half an hour of a working login, a written reset path and one successful download is a better day one than any amount of screen-sharing. Webinars teach the toolbar to people who have not yet found the door.

If access fails outright — guest tenant, the wrong identity provider, a licence nobody assigned, a phone that cannot finish multi-factor on site wifi — stop the clock and fix it. Days two to ten cannot be run on screenshots of your own screen, though plenty of onboarding reports suggest otherwise.

Day two: the two places they will actually touch

Give somebody the run of a system and they will treat it as a drive. Teach two places instead, and one they must never write into.

Published is what they build from: read it, plot it, acknowledge it, do not overwrite it, and do not drop a helpfully named "use this" PDF alongside the current revision. If the permission model allows a trade to write into Published, go and fix the permission before you teach anything else. A CDE that a subcontractor can silently overwrite is a shared folder with a logo on it.

Work in progress, plus whichever shared area they are allowed to use, is where their own containers go. That is the only place a first upload belongs. Archive they may read, to work out what went out last month; it is not somewhere to grab something they intend to install from.

Walk one live container through the four states out loud, in sentences, rather than putting a slide up. Who may write in this state. What the state authorises somebody to do. Which gate moved it here, and who holds that gate. The published state exists in ISO 19650 because a file being on the disk and a file being authorised for a particular use are two different facts, and people conflate them constantly. If the person leaves day two thinking the folder names are the states, they will upload into whichever cupboard looks friendliest.

Then write their permission in one sentence they can keep: you may read Published for package X; you may write in WIP under your originator code; you may not authorise anything into Published. If that sentence is untrue of the system as configured, the system is wrong.

Day three: names, before anything gets uploaded

The first file a trade uploads is nearly always a collision. A long Windows name, a revision suffix, the word FINAL in capitals, and an originator code copied off the last job because it was sitting in the template. Fix the convention in their hands before they mint a bad identity.

Give them the short rule rather than the annex:

  • The identity is stable — project token, originator, type, and a number somebody can shout across a slab.
  • Revision lives in a field. A _RevC on the end of a filename mints a new container every time anybody touches it.
  • Suitability and state stay out of the filename. Renaming a file has never released it.
  • The download should keep the register identity. If the system bolts a timestamp on, that copy is not the working file.

Test it with no software in the room. Ask them to read out the number of yesterday's published sheet. Ask them to tell two neighbouring sheets apart on a phone screen wearing a glove, which is the condition the convention will actually be used in. Ask what they intend to call the first shop drawing they upload. If the answer contains FINAL, a date or somebody's initials, correct it on paper now, because day six is too late.

What they need from you is narrow: their originator code, the type codes they may use, and one worked example of a correct name for something they will genuinely produce. A twelve-field essay written for a folder tree is not that.

Day four: the set they are supposed to be building from

Before anything of theirs goes in, they need to be able to find what the site is building from. Most unofficial trailer folders exist because nobody ever walked this with the trade.

Pick the live package — the floor, the zone, the pour, the coordinated services they are installing against this week. Reconstruct it together from the published location, not from the zip somebody emailed in May. For each current title:

  1. There is exactly one current revision. Two rows claiming to be current is a fail, not a tidy-up.
  2. The previous revision is marked superseded, and there is a withdrawal fact behind it: a collected print, a stamped copy, a dated instruction that the old identity is dead.
  3. Suitability matches what they are about to do with it. A sheet still sitting at S2 while the programme treats it as issued for construction is optimism with a status code.
  4. Title block, register row and the file they would plot all name the same object.

Then walk to the hut, or ring whoever does the plotting. The A1 on the table is a fact too, and it outranks the register in the mind of the man cutting the duct. If it is last week's revision, day four is not finished. Issue without withdrawal leaves two live instructions in the building, and only one of them is in your system.

Write down the sheet numbers that failed. Not "they have access to the drawings."

Day five: receiving, before they issue anything

A firm that has never reconstructed a transmittal will not issue a good one, so spend day five on receipt.

Take a transmittal from the last fortnight that named their company, or should have. Reconstruct six facts from the system of record rather than from anybody's memory:

  1. the unique number and the date
  2. the purpose, or the action being asked for
  3. exact containers and revisions
  4. named recipients — a person, not "the contractor"
  5. dated evidence that it arrived at their company
  6. whether the previous workface copy was withdrawn

Whichever of the six is missing is the lesson for the day. Uploading is not issuing, and a download by a mailbox is not receipt at the workface. Then go and ask the supervisor three questions about one sheet in that pack: which revision are you working from, what changed, and what must you stop using. If the pack cannot answer the second and third, the firm was sent a file rather than an instruction.

This is also the day the cascade gets closed. If the named recipient was the main contractor, the installing package is still sitting outside the record. Write down the person at the trade who will acknowledge from now on.

Day six: one file, into work in progress

One container. Not a zip of forty. Not into Published.

They prepare the file to day three's rule, fill in the metadata the project actually uses — identity, revision, suitability, status from the agreed list, package or location — and upload into work in progress. Discourage the reflex of ticking every workflow box to clear the dialogue.

Then check four things before anybody reviews it. The filename is the container identity, with no revision suffix and no USE_THIS. Revision and suitability in the metadata match the title block. The state is WIP, and if it landed in Shared or Published because a default folder looked plausible, pull it back and write down why the system allowed that. And they can find it again tomorrow without ringing you; if they cannot, the upload is your artefact rather than theirs.

A first upload that is a dump "for the record" teaches exactly the wrong habit. What you want is one identity, one revision, one state, one purpose. Forty files in a zip is how the unofficial set gets reborn inside the CDE, this time with permissions.

If the firm does not produce drawings at all — labour-only, install-only — day six still happens. A method statement, a temporary works sketch, a set of record photographs, whatever the BEP says they originate. The act is identical, and the container still needs a name and a state.

Day seven: what happens to that file next

The upload is not finished when the progress bar stops. Day seven is the first gate they see from the author's side of it.

Move the container to Shared only if the task-team check you described on day two has happened. They should see a comment, a rejection or an acceptance attached to this container, rather than a message in a chat thread saying it looks fine. If the project has no review step for their type of file, that is worth writing down; do not stage a theatre of approvals so the week looks complete.

Three things they should leave the day knowing. Shared is not Published, and coordination is not an instruction to build. A rejection is a recorded fact on a container rather than a mood in a meeting. And changing the file after a review without changing the revision is how two people end up reviewing different bytes under one identity, which is a tedious argument to have in front of a client.

If the first upload is rejected, it has been a good day; they have watched the gate work. An upload that sails into a published folder because nobody looked is a bad day that will report green.

Day eight: the first thing they issue

Issue is a dated, attributed release: these containers, these revisions, this purpose, these named recipients. A zip in a folder called Issued is storage.

They issue one numbered transmittal for the smallest honest pack — the container from days six and seven if it is ready to leave WIP, or received published information passed onward to a named installer on their own payroll if they are not originating design yet. Either way, the record carries a unique number and date, the purpose expressed as what the recipient must do, exact containers and revisions rather than "see attached", named recipients rather than a distribution group that means the usual crowd, and the previous identity this issue withdraws.

Do not let them substitute an email with a link in it. Sending is a mail event; it does not name the act, and in six months it will not reconstruct. If the CDE can produce a transmittal and they mail a zip anyway because that is how they have always done it, stop and redo the issue in the system of record. The unofficial channel is the thing most likely to undo days one to seven.

Then make them shrink the pack. Eighty drawings with "see clouds" will not be read by anybody. The sheets that changed, the revision withdrawn and the action required — that gets read.

Day nine: the first thing they receive and act on

Yesterday they issued. Today they are the recipient again, deliberately. Pick a live issue for work starting this week: from the designer, from the main contractor, or their own day-eight pack if it went to a named supervisor.

Then they do what the hut actually requires. Acknowledge as a named person rather than as a mailbox. Plot or place the current sheets if the workface runs on paper — and remember that the plotter does not withdraw the previous run, so somebody has to collect, stamp or take down last week's copy. Answer the three understanding questions for one changed sheet in writing, in the record or in a dated note beside it.

Receipt has a clock on it, which the record rarely shows. A transmittal issued at five to five for work that starts at seven has been issued. Whether it was received in time is a different question.

If they cannot withdraw the copy on the wall, in the rack, or rolled up in a bag in the van, they are not yet really a party to the CDE. Day nine exists to make withdrawal somebody's job rather than an article of faith.

Day ten: the Monday test

Sit down with the same named person and let them drive. They perform the four acts from the acceptance test, on their device, against a package the site is actually installing.

A pass is boring. They find the current published set, name a new container correctly, upload it to WIP, and raise or reconstruct one numbered transmittal and say who has to receive it. A fail is specific: a sheet number they could not find, a metadata field left blank, a write into Published, a zip sent to a mailbox. Resist averaging the four into a percentage, which would invent a precision the hour does not have.

There are things they still should not be doing unless the appointment says so — authorising into Published, editing another originator's identity, treating Archive as the place to grab the latest. Those gates stay with the lead appointed party. Onboarding a trade does not deputise them as the project's information manager.

Write the result on one page and carry the failures forward. A trade that fails day ten and is left on the system anyway is how a project reports full adoption while two live instructions sit on the wall of the same room.

  1. 01
    1
    FocusA login that works on their machine
    What must be true by end of daySigns in on the cabin machine and a phonesees only their packagesdownloads one published container
  2. 02
    2
    FocusThe two places they will touch
    What must be true by end of dayReads Publishedwrites only in WIPcan state their own permission in one sentence
  3. 03
    3
    FocusNamesbefore anything is uploaded
    What must be true by end of dayIdentity stablerevision in a fieldno FINAL/date/initials in a filename
  4. 04
    4
    FocusThe set they are building from
    What must be true by end of dayOne current revision per titlesuperseded marked and withdrawnsuitability matches use
  5. 05
    5
    FocusReceivingbefore they issue
    What must be true by end of dayCan reconstruct a transmittal's six facts from the system, not memory
  6. 06
    6
    FocusOne fileinto work in progress
    What must be true by end of dayOne containercorrect metadatacorrect statefindable again tomorrow
  7. 07
    7
    FocusWhat happens to that file next
    What must be true by end of daySees a real review outcome — commentrejection or acceptance — not a chat message
  8. 08
    8
    FocusThe first thing they issue
    What must be true by end of dayOne numbered transmittal: containersrevisionspurposenamed recipientswithdrawn identity
  9. 09
    9
    FocusThe first thing they receive and act on
    What must be true by end of dayAcknowledges as a named personwithdraws the superseded copy on the wall
  10. 10
    10
    FocusThe Monday test
    What must be true by end of dayPerforms all four acceptance-test actsunaidedon a live package

Running it for real

One firm at a time for the first month. Onboarding twenty trades in parallel produces twenty logins and no transmittals, which looks excellent on a dashboard. The document controller owns the clock. The package manager names the person and turns up on days four, five, eight and ten, because those are the days that need authority rather than patience. Hold the webinar afterwards if you still want one, for people who have already issued something and will therefore have questions worth answering.

If a day blocks, do not skip it. Access that failed on day one is not cured by a naming session on day three, and a file dumped into Published on day six is not cured by a tidy transmittal cover on day eight. The order is the point.

Ten days will not certify anybody, and it is worth saying so to the trade. ISO 19650, CDM, the Building Safety Act and the standard forms all assume appointed parties can find issued information and submit their own under control. None of them tells you whether the firm that started on site last Thursday has ever completed a transmittal. Ten days tells you that — a smaller claim, and a more useful one.

The cost is real, and somebody has to carry it: roughly two hours a day of a document controller's attention per trade, plus a few hours of a package manager's time on the days that need a decision. Across thirty subcontractors that is a genuine line in the preliminaries, and at the moment it is usually nobody's line, which is exactly why it does not happen.

So put it somewhere. Main contractors can give document control the headcount to run this and the standing to hold a package that fails day ten, and can move the ten days into the mobilisation programme alongside inductions instead of leaving it with IT. Clients and lead appointed parties can stop asking how many licences a tender includes and start asking who runs adoption for each new trade, and what happens when a firm cannot issue — then, at month three, ask a named person at two trades to reconstruct a transmittal while you watch. Trades can send somebody who will still be there in six months and say so loudly when they cannot log in, because nobody is coming to check. And whoever holds the permissions could go and look, this week, at whether a subcontractor can write into Published. If they can, that is the first day's work, and it will not wait for the next firm.

Read next: The transmittal nobody read, Naming information containers so the convention survives contact with site, The four CDE states: work in progress, shared, published, archive.