Most information management failures on a project are not failures of either document. They are failures of the handover between them — a requirement written loosely enough that the response can be vague, and nobody notices until the information arrives wrong.
Both are free, interactive, and run entirely in your browser. No signup and no gate: the report appears on the page, and asking for a copy by email is optional.
ISO 19650-2 puts a specific exchange at the centre of the delivery phase: the appointing party states what information it needs, and the prospective lead appointed party states how it will produce it. Everything downstream inherits the quality of that exchange.
What the appointing party needs delivered, when, in what form, and to what level of information need. Issued with the tender documentation, so it is the thing the supply chain prices against. An EIR that cannot be priced is an EIR that will be answered with a paragraph of intent.
EIR Manager
appointing party side · live demo, no account
How the delivery team will meet those requirements — method, standards, capability, and the people responsible for each information container. Submitted pre-appointment as a proposal, then confirmed after appointment with the TIDPs and MIDP that turn the promise into a schedule.
BEP Manager
lead appointed party side · live demo, no account
ISO 19650-2 breaks the delivery phase into eight numbered activities. The EIR is written at 5.2 and answered at 5.3; the appointment at 5.4 turns that answer into a schedule, and acceptance at 5.7 is where the whole exchange is finally tested. Pick an activity to see the standard’s own sub-activities, who is responsible, and what it produces.
Before anyone is asked to price anything, the appointing party works out what it needs and what will govern it: who manages information, which milestones it lands on, which standard it is written to, and which CDE it lives in.
The requirements become tender documentation. This is where the EIR is written and issued, alongside the reference information the supply chain needs in order to answer it — and it is the last moment a requirement can be added without a variation.
Score an EIR against thisThe prospective delivery team answers clause by clause: a pre-appointment BEP, evidenced capability and capacity behind it, a mobilization plan and a risk register. A response that reads like a brochure is a response nobody scored against the EIR.
Check a pre-appointment BEPThe promise becomes a schedule. The BEP is confirmed, responsibility is named container by container, and the task teams’ TIDPs aggregate into one MIDP the programme can actually be held to.
Check the confirmed BEPNothing is produced until the setup is proven: people in place, technology configured, and a live test of the information production methods and procedures against the project CDE.
Information is generated, quality-checked, reviewed and only then shared. The check → review → approve loop is the standard’s answer to the question nobody writes down: who says this container is fit to issue?
Submission, authorization, acceptance. The lead appointed party authorizes what the task teams produced; the appointing party accepts it against the EIR it issued back at 5.2. This is where a vague requirement finally becomes an argument.
The project information model is archived and what the operator needs passes into the asset information model. Lessons learned go back upstream, into the requirements of the next project.
None of these are exotic. They are the four that turn up on almost every programme, and every one of them is visible before appointment if somebody looks.
The EIR asks for models and drawings but never says how much detail, in whose format, or for which decision. The supply chain guesses, prices its guess, and delivers something defensible that nobody wanted.
Costs More rework than the other three combined
A pre-appointment BEP written from the last job’s document responds to requirements the client never issued, and stays silent on half the ones they did. Nobody scores it clause by clause, so it passes.
Costs A response nobody scored, accepted anyway
Both documents name a common data environment. Neither states the naming convention, the status codes, who approves a transition, or what happens to a container that fails one.
Costs A platform bought, a governance never written
Information delivery milestones sit on a separate list from the project programme, so they slip without anyone reporting a slip. The data that should have accumulated across the stages was never captured.
Costs An asset information model with gaps that cannot be backfilled
The document is not the deliverable. The decision somebody makes from it is.
Two separate tools, because they are two separate jobs at two different moments. Both run in the browser, both export a report, and neither asks for an email address.
You are writing or reviewing an EIR and need to know whether the supply chain can actually respond to it. Twelve questions across four sections, each rated 0–3 for clarity rather than simply ticked.
You have a BEP drafted and a submission deadline. Thirty-five evidence checks across nine sections, including a set flagged ISO-critical and a final go / no-go.
Whichever side of the appointment you sit on. If you are commissioning the work, you own the EIR. If you are bidding for it or delivering it, you own the BEP. Advisors working with both sides need to read each document as the other party will.
Both, and they are not the same document. The pre-appointment version is a proposal submitted with the tender. The confirmed version comes after appointment, carrying the mobilisation detail, the TIDPs and the MIDP that the proposal could only promise.
Upstream of the EIR. Organisational and asset information requirements describe what the business needs from its estate over the long run; project information requirements narrow that to one project. The EIR is where they become something a supplier can price.
No. Both run entirely in your browser and keep your answers in local storage so a refresh does not lose them, and there is no gate: the report appears whether or not you fill anything else in. Each tool ends with one optional field — ask for the report by email and I receive your address and the summary on screen, never a copy of your project.