In DBFM (Design, Build, Finance & Maintain) projects, and other kinds of integrated delivery projects, requirements do not only concern the facility itself, but also services related to the facility’s operation — these are often maintenance services, but sometimes also security, catering and cleaning services.
In BriefBuilder, there is a specific ‘service tree’ (a decomposition or breakdown structure of the requested services) available for such requirements. You can use that tree to define the scope of the service contract and to capture requirements for each specific service (e.g. requirements concerning response times, staff competences, applicable standards, …)
For monitoring purposes, you can also link services to specific types of quality measurements that have to be executed (e.g. condition measurements or satisfaction surveys) and/or to possible performance failures and how these should be dealt with.
Essentially, you are then making a service level specification (SLS) or service level agreement (SLA) that can you use for tendering, verification/compliance management and contract management — all within the BriefBuilder application.
In this article, we will explain how you can define requirements for services in BriefBuilder.
In the services tree, you can define which services must be performed by the contract party. For this, you can use two kinds of objects:
Service group: a generic group of services that must be provided by the contractor / service provider (e.g. cleaning or maintenance).
Service: a specific service task or activity that must be delivered by the contractor / service provider (e.g. cleaning of internal areas or plant maintenance).
The services are typically part of a service group. E.g. the service façade cleaning is part the service group cleaning.
In addition, you can use folders () to organize and order the requested services and service groups.
The services tree is typically built up according to what is called an assembly structure: you start with groups of services and then add specific services that are part of that group.
For example: The service group maintenance may consist of the services reactive maintenance, planned maintenance of building systems and planned maintenance of terrain/grounds. See example below.
For each service(group), you can define requirements concerning how or when they need to be executed and to which part of a facility they apply. This can be done on the detail view where can find the following tables:
- Standard properties
- Relation tables (various kinds)
Below we will explain the use of each of these tables.
This is where you can enter a general description of the requested service, explaining its general purpose or meaning.
Please note that it is not always necessary to add a description, but it will be relevant when using terms that are rather technical. See below for an example.
Labels are not really requirements, but categorizations. You can use them to classify or categorize services/service groups.
The good thing about labels is that you can filter on them in overviews and tables, which makes it easier to define and manage requirements for services of the same kind.
For services, labels are often used to distinguish between:
- Standard service: should always be provided, part of the standard service fee.
- Variable service: only needs to be performed at the client’s specific request.
See example of a label above (under Description).
The property table is where you can define specific requirements. The term property should be understood as a required attribute, capability, characteristic or quality of a service. Examples of properties are frequency, method and scope.
See below for a simple example for the service reactive maintenance.
To create properties for a service (group), click on the Add property button.
If it is possible to standardize properties across all services, you can do so by defining standard properties via the requirements settings menu. These properties are then shown on the detail view of each service (group).
Examples of standard properties for services are:
|Timing||Does a service need to be performed at particular hours/days?|
|Response time||How fast does a service need to be performed after it has been requested?|
|Standards||Are there specific norms or regulations that have to be complied with?|
|Method||Is there a particular protocol or method that needs be applied when executing the service?|
|Staffing||Are there requirements that apply to the people that will deliver the service (e.g. certification)?|
|Approval||Is there a particular approval process or approval period?|
|Reporting||How does the service provider need to report to the client about the provided service?|
In the settings menu, you can define for each property what kinds of values are allowed. E.g. text, a number of specific options from a picklist (which helps to create consistency and it speeds up the specification process).
Relation tables offer you the possibility to link specific services to other parts of the model, for example to a specific set of spaces or systems.
The number of relation tables that you get to a see on a detail view is dependent on the chosen number of modules. There are the following possibilities:
Relevant spaces and locations
You can use this table to link a service to a specific spatial part of the facility.
For example: you may want to link the activity daily indoor cleaning to the particular spaces that need to be cleaned on a daily basis. Or, perhaps you want to specify which buildings from your portfolio are part of the maintenance scope.
You can use this table to link a service to a specific technical system or element of the facility. For example: you may want to link the activity technical maintenance to the specific systems that have to be maintained.
Relevant design principles
You can use this table to link a service to a particular design principle. In a DBM project, there may for example be design principles concerning sustainability that are also relevant for the project’s maintenance.
Monitoring – possible performance failures
This table can be used to link a service to specific type of performance failure (e.g. performance failures of different degrees of severity), which you can then use to specify the related actions or consequences (e.g. penalties).
Monitoring – applicable quality measurements
You can use this table to link a service to a specific quality measurement activity or method that has to be used to measure the delivered performance. E.g. a condition measurement or satisfaction survey. See example above.
Relevant user equipment
You can use this table to link a service to a particular equipment item. In a lab project, you may for example want to link the activity equipment maintenance to the specific equipment items that have to be maintained.
The last table on the detail page is the one for Uploads, where can add files that you feel are relevant for a service(group). For example, particular standards or reporting formats. Be careful, however, not to ‘hide’ any requirements in these files.
You can also add a note for a file, which you can you to explain its relevance, or to explain which part of the file is of particular importance.