Your requirements come from everywhere.
An EIR (Employer's Information Requirement) that defines what the project must deliver. Design standards that specify how it must be built. Compliance criteria that must be met. Client expectations that aren't written down. Operational needs that emerge during delivery.
They're all requirements. They're all important. They're all supposed to guide your project.
Then they get filed away, scattered across documents, emails, and conversations.
Six months into delivery, someone asks: "Are we actually meeting requirement 4.2.1?" And nobody knows. Because requirements aren't tracked. They're stored. The project is being delivered. Your requirements are in a folder.
This isn't a compliance failure. This is a visibility failure.
And it's expensive.
Here's how most organisations actually manage requirements:
Project Start: Requirements are defined from multiple sources: an EIR (if you have one), design standards, compliance criteria, client briefs, operational needs. Detailed. Comprehensive. Supposed to guide everything.
They get approved. Signed off. Published.
Week 1-30: Your requirements sit in the CDE. Shared folders. Email attachments. Design tools. Compliance databases. Occasionally referenced when someone needs to check something. Mostly ignored or forgotten.
Design Phase: Designers create designs. They're supposed to meet the EIR requirements. But the EIR isn't integrated into their workflow. So they design. Then someone (maybe) checks: "Does this meet requirement X?"
Often the answer is: "Uh... I think so?"
Site Phase: Work starts on site. Teams follow designs. The EIR requirements that drove the design are now distant. Site teams don't check them daily. They check designs, schedules, specifications. Not the original requirements.
Compliance Phase: Compliance team wants proof that requirements are met. They hunt through:
The answers are scattered. Sometimes missing.
Handover: Questions emerge: "Which requirements were actually met? Which have gaps? Where's the evidence?"
Discovery during handover, not verification during delivery.
Post-Handover: Operations inherits assets that are supposed to meet requirements. But they're not sure which requirements apply. How to maintain them. How to verify ongoing compliance.
Your requirements are disconnected from delivery.
You've defined what you need (from EIRs, standards, compliance criteria, client briefs, operational needs). But you haven't connected them to:
So requirements become static documents scattered across systems. Not a live tracking system.
The gap between "what we specified" and "what we're actually delivering" grows throughout the project. By handover, there's no clear line of sight from any requirement to evidence of completion.
Requirement gaps discovered late are expensive:
During Design: Rework because design doesn't meet requirement. Redesign costs. Schedule delay.
During Delivery: Work done wrong because requirement wasn't clear. Rework on site. Cost and schedule impact.
At Handover: Information gaps. Missing compliance evidence. Handover delayed or conditional. Operations can't start.
During Operations: Assets maintained wrong. Compliance not maintained. Safety or performance risk.
Requirement gaps are expensive because they're discovered backwards—from outcome, not from plan.
ISO 19650 isn't just about documents. It's about the golden thread.
The golden thread: Requirements flow from briefing through design through delivery through operations. Every requirement (from whatever source) is addressed. Every decision is traceable back to a requirement. Every compliance criterion is verified. The entire thread is auditable.
Most organisations think ISO 19650 means: "Create an EIR and store it in the CDE."
That's not the golden thread. That's document storage.
The golden thread means requirements are active throughout the project. Every phase knows what requirements it's responsible for. Every deliverable is validated against the requirement it addresses. Every gap is surfaced early.
That requires visibility. Not spreadsheets or storage systems. Live, connected tracking of requirements from all sources.
Three reasons requirements management is becoming critical:
1. ISO 19650 compliance is non-negotiable. Clients demand it. Regulators expect it. If you can't demonstrate the golden thread, you're exposed to compliance risk. A static EIR won't pass an ISO 19650 audit.
2. Complexity is increasing. Modern projects have dozens of stakeholders. Multiple design disciplines. Long supply chains. Complex compliance requirements. Requirements don't manage themselves in this environment. You need active tracking.
3. Handover failures are expensive. Missing information. Compliance gaps. Operational surprises. These all trace back to requirements not being tracked throughout delivery. Early visibility prevents late cost.
Your requirements should be live, not static.
Instead of creating an EIR and filing it away, your requirements become a tracking system:
From Briefing:
To Design:
To Delivery:
To Handover:
The golden thread is live. Not a theoretical concept or an audit document. An actual traceability line from requirement through to operational compliance.
Scenario 1: Design Requirement
Your EIR says: "All structural steelwork must be designed to BS 5950, checked by an independent engineer, and documented with that check."
Old way: Designer creates design. Sometime later, someone checks: "Did we get independent check?" Maybe. Evidence is a signed email or a memo.
New way: Requirement is active in the design workflow. Designer links their design to the requirement. System automatically triggers: "Independent check required per requirement X.2." Checker signs off in the system. Compliance proof is recorded. Design phase closes with requirement verified.
Scenario 2: Compliance Requirement
Your EIR says: "All safety-critical installations must be inspected and certified before handover."
Old way: Installation happens. Weeks later, someone tries to compile inspection records and certifications. Some exist. Some are missing. Handover is delayed while you hunt for evidence.
New way: Requirement is tracked throughout delivery. Installation triggers automatic checklist: "Safety inspection required. Certification required." Site team completes inspection in the system. Uploads certification. Compliance status updates automatically. Handover proceeds because evidence was captured at point of work.
Scenario 3: Operational Requirement
Your EIR says: "Asset maintenance must follow manufacturer specifications. Maintenance schedule must be defined before handover."
Old way: Maintenance schedules are created late (or post-handover). Operations tries to match them to asset specs. Gaps emerge. Some assets don't have clear maintenance protocols.
New way: Requirement is tracked from design through to handover. Asset specifications are linked to maintenance requirements from the start. As design finalises, maintenance schedules are updated and validated against asset specs. Operations inherits a complete, verified protocol. Day one operations with clear maintenance requirements.
An EIR is a snapshot. A moment-in-time statement of what you need.
But projects change. Design evolves. Site conditions emerge. Scope adjusts. Compliance requirements shift.
A static EIR can't track how you've adapted to those changes. Which requirements you've adjusted. Which gaps you've accepted. How you've verified that everything still meets the original intent.
A live requirements system:
ISO 19650 requires the golden thread. But most organisations treat it as a compliance checkbox: "Create an EIR. Store it. Audit it."
The golden thread isn't about documents. It's about visibility.
Can you trace any asset in your project back to the original requirement? Can you show that it was designed to meet that requirement? Can you prove it was delivered to spec? Can you demonstrate that compliance is being maintained?
If those questions require hunting through emails and spreadsheets, you don't have a golden thread. You have documents.
If those questions can be answered in seconds from a live system, you've got ISO 19650 compliance. And you've got visibility that prevents handover failures.
Your requirements should be live, not static. They should flow from briefing through design through delivery through operations. They should be verified continuously, not discovered at handover.
Book a demo to see how active requirements management works on complex programmes.
Key Differentiators: