In BriefBuilder, you cannot only define requirements concerning construction projects, but also concerning the related services, e.g. maintenance, security, catering, landscaping and cleaning services.

These services may be tendered separately or they can be part of the construction tender, e.g. in case of a DCM (Design, Construct & Maintain) or DBFM (Design, Build, Finance & Maintain) tender.

To define requirements for services, you can use the BriefBuilder services module. This module allows you to define the scope of the service contract and to capture requirements for each specific service (e.g. requirements concerning response times, operating hours, 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 to different types of performance failures which may come with requirements concerning repair times.

Essentially, you are then using BriefBuilder to make 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.

Important: to be able to define requirements for services, you must activate the services tree via the settings menu.

Object types

Just like all other BriefBuilder objects, services are defined in a ‘tree’ structure: a decomposition or breakdown structure of the requested services. This decomposition defines which services must be performed by the contract party.

To make this tree structure, ou 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. See example below.

In addition, you can use folders () to organize the requested services and service groups. Note that you can also add classifications and numberings to your services (see the TIP below).

TIP: there are classification systems that can help you with the naming and structuring of services.

For building projects, you may want to look into the EN 15221 Facility management- Part 4: Taxonomy, Classification and Structures in Facility Management.

For infrastructure projects, you may to look at the ISO 55000 – Asset management — Overview, principles and terminology, although this one is of a higher abstraction level than the aforementioned EN 15221.

Structure

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 the building’s technical systems and the facade. See example below.

Please note: services are sometimes mixed up with we call processes in BriefBuilder. The difference is as follows:

Processes are the activities/tasks that a party has to do in order to realize and complete the construction project (e.g. design activities, construction work).

Services are the activities/task that a party has to deliver once the facility is in use (e.g. maintenance, operation, cleaning, security).

Requirements

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 you can find the following tables:

• General
• Properties
• Standard properties
• Relation tables (various kinds)
• Uploads

Below we will explain the use of each of these tables.

General

In the table ‘general’, you can enter a description of the requested service, explaining its general purpose and you can add label or a classification, if relevant.

Note: 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. 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.

Properties

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.

Properties can have text values, but you can also define very exact requirements with comparators (<, >, =, etc) and units of measure (e.g. hours, euros, ) and references to documents. More info about properties can be found here.

See below for a simple example for the service reactive maintenance.

To create properties for a service (group), click on the Add property button.

TIP: If you have a long list of properties, you can easily insert a property between two existing ones by clicking on the plus icon that appears when you hoover with your mouse near the starting point of the table’s separation lines.

Note that each requirement has a unique requirement ID (a ‘REQ-ID’) which you can use to make cross-references between requirements.

Standard properties

If it is possible to standardize properties across all services, you may want to opt for standard properties, which can be defined via the requirements settings menu. These properties are then automatically shown on the detail view of each service (group).

Standard properties for services could be:

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?
Staffing	Are there requirements that apply to the involved staff (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?

In the settings menu, you can define for each property what kinds of values are allowed. Such as text, a number of specific options from a picklist, numericals, etc.

The advantage of using standard properties is that they can easily be viewed and edited in an Excel-like cross table.

Relations

The relation tables offer you the possibility to link specific services to other parts of the model. See below for an explanation of the most important relations.

TIP: The relations between different kinds of objects can easily be viewed and edited in (Excel-like) cross tables.

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.

Please note that you can define specific properties for these buildings and spaces which can be relevant for the services that have to be provided. For cleaning it will for example be relevant to know the sizes of spaces. More info about that here.

Systems/elements

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.

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

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).

Furthermore, 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.

All of the linked performance failures and quality measurements can obviously have their set of specifications. You can see these by simply clicking on the object.

Please note: the relation tables for spaces and locations, systems and elements, and monitoring are only available for services, and not for service groups; the latter are generally too generic to be linked to particular objects elsewhere in the model.

Uploads

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.