Construction: Stop creating OIRs and project requirements in Word and Excel, your project depends on it
The quality and performance of any built asset are intrinsically linked to how good the requirements were at the start of the project. As part of Building Information Modelling (BIM) and various standards (such as BS EN ISO 19650, ISO 55001, etc.) that set forth high-level processes, construction project should follow a clearly defined process to create all requirements for a well-performing asset.
REMINDER: Types of requirements that must be created during the construction of an asset:
- Organisational Requirements (OIR): Data and information required to achieve the organisation’s objectives.
- Project Information Requirements (PIR): For a given project milestone, this defines what information the appointing party of a project needs from the design and construction team.
- Asset information requirements (AIR): Requirements to be met so that the OIR can be satisfied, together with the information exchanges by which information and data are transferred to, and from, the asset information model (AIM)
- Exchange Information Requirements (EIR): Pre-tender document setting out the information to be delivered and the standards and processes to be adopted by the design and construction team, including its supply chain, as part of the project delivery process.
Unfortunately, there are very few industry examples of client organisations successfully delivering these requirements as intended. The reality is that most clients, design teams and contractors have very little experience creating integrated requirements, and attempt this using Word and Excel. This often results in numerous unwieldy documents, that do not sufficiently link between requirements across stages, creating duplicated or incorrect information. Teams can spend more time looking for the latest version of a document than on the requirements themselves.
Furthermore, these requirements are created in an environment where stakeholders at opposite ends of the organisational spectrum are disconnected, using different lines of communication and generally focused on their own workstreams, objectives and outcomes. Too often, these factors lead to:
- Disconnect between stakeholders
- Information being recreated between stages and documents
- Higher-level requirements are not taken into consideration when creating lower-level requirements (i.e. OIRs not considered when creating AIRs)
- The operation of an asset not being considered during design and build
- Clients often do not understand the technical language used during build and construction
- Clients are left not knowing how to create required information e.g. an asset
Manage your requirements well, to save yourself a world of pain
We recently worked with a client that faced these problems on a complex restoration project in the UK. To help our client we developed Rockr, a requirements management platform that enables clients, design and construction teams and asset management to manage all requirements in one place, collaboratively.
At each stage of the project, the client answers several Plain Language Questions (PLQ), which the design and construction team then converts into requirements. Once a requirement is defined, it is never recreated, but simply refined in the next stage of the project.
In the example below, you can see how a single OIR is broken down into granular construction requirements which can be traced back to their origins at each phase in the construction cycle.
Each requirement has an accountable person, responsible for obtaining required information and sign-off(s), creating transparency and clear risk ownership which is traditionally challenging on medium and large projects.
Rockr enabled our client to manage their requirements using 6 mechanisms:
- PLQs: Simple questions for owners and stakeholder to answer from which information is extracted to form requirements;
- Clear requirements: Specific instructions that had to be considered for the asset;
- Case studies & lessons learned: Reference and adoption of learning from relevant examples from previous projects, where applicable;
- Confirmation: An acknowledgement that a given condition was met, typically phrased as a PLQ, answered as YES/NO;
- Evidence: Documentation giving physical or digital proof of a condition being met;
- Assessment: Objective evaluation to support decisions with significant impact.
A better way to create good requirements
In an example, to bring Rockr to life, we look at how our client assessed that their high-level needs, with regards to Environmental, Social, Security and Economic performance have been captured in the Strategy Definition.
In the Rockr workflow, we defined that we needed the design and construction team’s confirmation that the requirements for this section have been captured.
Once the team has acknowledged that the requirement has been met, they are now asked to provide the details of the requirement on Rockr to ensure it is centrally captured. In addition to their answer, they were also asked to provide supporting documents for context and auditability against the agreed targets.
When capturing the requirements, the PLQs that were put to the client were captured as well as the answers and any supporting documents. Any further requirements, e.g. for materials, conformed to the requirements given in this answer, and construction and design teams were required to evidence how they were met on Rockr.
Our client was able to significantly improve the collaboration between teams and will be able to deliver assets that deliver strategic objectives of the organisation.
Clients, design and construction teams alike have an opportunity to retire their dependency on requirements created in Word and Excel which are highly ineffective and lead to problems during all stages on the construction and asset management cycle.
While clients tend to stay away from prescribing specific approaches to be taken, moving forward, clients should mandate a more integrated approach to the creation and management of requirements that allows them to clearly understand how their strategic objectives translate into an asset.
This post was initially published on by us on Medium.