Every project brief is different because every project comes with its own particularities due to the chosen site, the available budget, and the specific needs of the project’s stakeholders. Yet, project briefs are also incredibly similar in terms of their structure and content. This offers a lot of potential for standardization.

Standardization is most obvious for projects of the same type. For school projects, for example, the brief’s indoor climate requirements will not differ much from one school project to another. The same goes for hygiene requirements for hospitals or safety requirements for tunnels. But even in the briefs for ‘one-off’ projects, such as museum buildings or opera houses, you will see a lot of similar requirements regarding practical matters like accessibility, cleaning, and maintenance.

In particular for professional construction clients, there is a lot to be gained from the standardization of requirements. Standardization makes it easier and faster to develop project briefs. It also helps to create consistency across projects, which is relevant for repeat-clients who have to build (or renovate) many of the same kind of facilities. Moreover, standardization helps to reduce the risk of budget overruns and delays as projects become more predictable.

Requirement tools, like BriefBuilder, help clients to work with standardized requirements as they offer a centralized and systematic approach to capturing and managing requirements. Relevant features are version control, the ability to track changes, and uniform requirements formats. Online accessibility is an essential feature too because it ensures that everyone is working with the latest version.

In general, there are two options for the standardization of requirements.

The first one is to create a requirements template for a particular project type that can be copied in its entirety for new projects. With each new project, this template is then first copied and subsequently adapted to the project’s specifics, e.g. by changing room quantities, finetuning the formulated design principles, and adding site-specific requirements.

The second approach is to work with a requirements library: a model that contains standardized space types (e.g. common spaces such as toilets and meeting rooms) and technical objects (e.g. generic elements such as access systems and power sockets). From such a library, it is then possible to pick and choose the spaces and objects that are relevant for the project and, thereby, to configure a tailor-made project brief.

Which option works best depends on the degree of similarity between projects. If 80% of the project requirements are always the same, the template approach will work best. If it is less than 80%, you might want to opt for a library approach.

In either case it is important to have an ‘owner’ of the standardized requirements who is responsible for quality control (you don’t want an erroneous requirement to be replicated across projects). This owner is usually referred to as a ‘requirements manager’, ‘requirements engineer’. It is a critical role because this person, or team, helps to ensure that requirements are up-to-date, accurate, and aligned with industry standards.

So, when you want to reap the benefits of requirements standardization, you have to look at both content, tooling and organizational aspects.

Want to know more? Don’t hesitate to contact us—we are experts in this.

RECOMMENDATIONS CONCERNING PROCESS & ORGANIZATION

• Ownership: make sure that there is a ‘requirements owner’ who is responsible for the standards.
• Scope: do not overstandardize. It is mostly technical requirements that lend themselves to standardization.
• Evaluate: evaluate how standards are being used in projects: are they understood and perceived as relevant?
• Change: develop a procedure for dealing with change requests concerning requirements.
• Improve: make sure that requirements are continuously improved on the basis of user feedback and project evaluations.
• Applicability: clearly communicate the standards’ applicability: do they e.g. apply to both new buildings and renovation projects?
• Status: Be clear about the standards’ status: can they be adjusted in projects or are they ‘fixed’?

RECOMMENDATIONS CONCERNING STRUCTURE

• Requirement naming: create consistency in terminology. E.g. don’t use the term “slip resistance” in one project, and “anti-slip grading” in another.
• Units of measure: ensure that the same requirements have the same UoM. So, don’t use millimetres for ceiling heights in one project and metres in another.
• Value options: where possible, create picklists for values. E.g. for the impact resistance of ceilings, you can easily work with predefined classes (1A, 2A and 3A) on the basis of a norm like EN 13964:2014.
• Structure: make sure that requirements are always located in the same model part. E.g. created a dedicated model part for the project’s electrotechnical systems (e.g. the folder ‘EF_70 Electrical power and lighting functions’ when using Uniclass).
• Classification: add classification IDs (e.g. Uniclass, SfB or Omniclass) to all technical objects. E.g. add the Uniclass code ‘Pr_40_20_87_84’ to the requirement object ‘sink tap’ and then make sure that the same is being done in the BIM model so that data can easily be compared.
• Norms and standards: Do not try to re-invent the wheel. There are lots of norms and standard available for requirements. Where possible, follow and refer to industry standards from e.g. ISO, DIN, EN, BuildingSmart etc, for naming conventions, values, verification methods and UoMs.
• Verification: do not just standardize requirements but also their verification by defining standardized verification methods (e.g. simulations, calculations, document review, …) and verification phases.