Systematic completion and commissioning: a practical guide

Systematic completion makes sure the technical systems work when a building or facility is put into use. This guide explains the method, the test hierarchy and the FMI levels, shows how systematic completion relates to commissioning, and who is responsible for what.

If you work with commissioning on data center projects, this guide shows how the Norwegian method complements the Level 1 to 5 approach, and where the two meet.

What is systematic completion?

Many construction projects are finished without the technical systems working as intended. Ventilation is not controlled correctly, access control does not talk to the fire alarm, and the faults are found only when the users move in. Systematic completion is the method designed to prevent this.

The Norwegian guideline for systematic completion, published by the industry program BA2015, defines systematic completion as an assurance that the project meets all functional requirements within the given limits for time, cost and quality, planned and verified through a structured, management-driven process from planning to handover.

The key word is process. Systematic completion is not only about the tests at the end of the project, but about the road there. The work starts at project kickoff, with a plan that describes how the building should work, and follows the project through design, construction, testing, handover and operation.

Systematic completion and commissioning

The terms are often used interchangeably. Commissioning is the international term, and is especially common in industry, oil and gas and data centers. Systematic completion is the Norwegian methodology, described in the guideline from BA2015.

The goal is the same: that the systems work, individually and together, when the facility goes into operation. Both start at project kickoff, with success criteria for what the facility must achieve. The difference lies in the role. The systems integration team and the project organization work throughout the project to make sure the criteria are met. Commissioning is often an independent third party that verifies in every phase that they actually are. The roles complement each other, they do not overlap.

On international projects, commissioning is often divided into levels from Level 1 to Level 5, with integrated systems testing as the final level. Some projects use an extended scale from Level 0 to Level 7, where Level 0 covers requirements and planning in the early phase, and Level 6 and 7 cover operational readiness and trial operation.

Why projects fail in the final phase

According to the guideline, the main reason for the many defects found during final testing is that systematic completion has not received enough attention during design, combined with too little control during construction. The guideline also points out that:

• Defects are signed off as quality assured. Self-inspection alone does not catch everything.
• Solutions are designed that do not work. This is often discovered only during full-scale functional tests.
• Contracts steer attention. Contractors focus on their own obligations, while integration between systems falls through the cracks.
• The industry builds first and checks afterwards. When the same solution is repeated many times, the first installation should be tested before it is rolled out.

Experience from projects also points to:

• Unclear interfaces. When interfaces are not defined, described functionality and components are missing when the systems are tested together.
• Late preparation. Activities that come later in the project are not planned in time. It is the same kind of waste that lean describes.
• Assumptions from earlier projects. “We did it this way there” becomes the plan, without checking the requirements on this project.
• Schedule ahead of quality. The schedule is pushed faster than quality can keep up. Data centers are especially exposed.
• Contracts that do not secure the expertise. The contracts do not make sure the right expertise comes into the project, for example a systems integrator.
• Information in silos. Data sits in different systems that are not synchronized and not maintained.

The three elements

The guideline describes three elements that must be in place for systematic completion to work:

• Leadership. The owner and project management must anchor the method from the start, set goals, assign roles and make the decisions that move the process forward.
• Subject matter expertise. The project needs people who understand functions, sound technical solutions and cross-disciplinary relationships, grounded in operation and maintenance.
• A systematic approach. A clear structure for plans, requirements, documents, tests and deviations, supported by a tool that is used from project kickoff.

The V-model

Systematic completion is based on the V-model, which is also used in IT projects. The left side describes the requirements, from the overall program down to detailed functional descriptions. The right side verifies the same requirements, level by level, as construction progresses.

The point is that every test must have a requirement to verify against. Without functional descriptions, the system function test has nothing to measure against, and without integrated functional descriptions, the integrated tests cannot tell whether the systems work correctly together.

How systematic completion is carried out

1. Create a plan for systematic completion

The plan is prepared at project kickoff and revised at each phase transition. It describes the process, the roles and the deliverables, and should be part of the project's basis documents. The plan can also be used as the basis for requirements for consultants and contractors. The choice of contract model does not determine whether the method can be used.

2. Establish the system register

The system register is the overview of all technical systems in the project. Each system gets a unique number, and the register shows where the system is located and which area it serves. This is what makes it possible to link the systems to the test plan and to the completion of each area.

3. Write functional descriptions

Integrated functional descriptions show how systems and spaces work together. Functional descriptions describe each individual system. Both must be in place before the solutions are detailed too far in the model. The FMI guideline recommends that the functional description is complete, FMI200, before the model reaches MMI200 on the model maturity index.

4. Prepare test procedures, the test plan and acceptance criteria

Tests are described in test procedures during design, with clear acceptance criteria. Milestones can then be stated as “test completed and accepted” rather than just “test completed”, and it becomes measurable whether the requirements are met.

5. Track status during construction

Contractors report completion of their own work on defined tasks. The guideline gives examples of such statuses: installed, connected, balanced, O&M documentation uploaded, ready for system function test, system function test accepted, training held, ready for integrated tests and integrated tests accepted. Construction management then only inspects work the contractor has declared complete.

6. Test the first installation before rollout

When the same solution is built many times, the first installation is built and tested before the rest. Defects in the first installation are corrected before the solution is rolled out across the building.

7. Send a notice of readiness for test

Before each test, the contractor confirms that what is to be tested is complete and self-inspected. The notice makes the preparations clear and places responsibility if the test is not approved.

8. Carry out the tests and close the deviations

Tests are carried out according to the test procedure and documented in test reports. Defects and deficiencies are recorded in one shared list for all disciplines and contracts, and the project does not move on to the next level until the acceptance criteria are met.

The test hierarchy

Systematic completion is based on step-by-step testing. Components are tested first, then systems, and finally how the systems work together. This keeps all the defects from showing up at the same time at the end.

• System function test. Tests one system on site with the relevant equipment connected, and documents that performance meets the specification.
• Integrated tests. Test how two or more systems work together across system and contract boundaries.
• Full-scale test. Documents that the building works as intended with all relevant subsystems connected.
• Operational test. Like the full-scale test, but with the occupant's own equipment in normal use.
• Stability and performance test. Documents that the systems work reliably over time with the intended performance.

FMI: maturity per system

It is hard to explain how far a technical system has come, and even harder for a whole project with hundreds of systems. FMI, the Function Maturity Index (Funksjons Modenhets Index in Norwegian), solves this with fixed levels that are set per system and can be rolled up to areas or the whole project.

The main levels are fixed and should be used the same way by everyone, while each project can add intermediate levels. A simple system without interfaces can skip levels that are not relevant, such as the tabletop test. Read more in the article on the FMI guideline.

FMI and the Level scale

On international projects, especially data centers, commissioning is often divided into five levels: inspection on delivery, installation and mechanical completion, equipment startup, functional testing of systems and integrated systems testing (IST). The two scales were made for different purposes and cannot be translated one to one, but they overlap:

• FMI100 to FMI300 cover planning and design, before there is anything physical to test. Level 1 to 5 starts only when the equipment arrives. Level 0 in the extended scale covers the early phase.
• Level 1 to 3 cover delivery, installation and startup. In FMI, this is often tracked with intermediate levels between FMI300 and FMI400.
• FMI400, system function test accepted, is close to Level 4.
• FMI500, integrated tests and full-scale tests accepted, is close to Level 5 and IST.
• FMI600 and FMI700, operational test and operation, go further than Level 1 to 5. The extended scale covers operational readiness and trial operation in Level 6 and 7.

Roles and responsibilities

• Owner and project management. Own the process. Anchor the method, appoint someone responsible for the test process, approve test results and decide whether the project can move on.
• Consultants. Prepare functional descriptions and test procedures, and approve the contractors' revisions once products are selected.
• Contractors. Responsible for self-inspection, revise functional descriptions and test procedures after selecting suppliers, report status on their own work and send notices of readiness for test.
• Operations and maintenance team. Takes part in the tests and uses them for training. This gives them ownership of the facility they will take over.

Handover and O&M documentation

Handover between the contracting parties is a legal process. Handover to the operations team is something else, and the guideline points to four key factors for it to succeed:

• Clear expectations. What the owner expects to receive must match what the project actually delivers.
• Transparent defect and punch lists. With deadlines that are kept, at a level where both the foreman and the owner can follow the status.
• Complete O&M documentation. O&M documentation is delivered continuously and should be ready before testing starts.
• Training. Planned well in advance and carried out as part of the tests.

Trial operation is described in the Norwegian standard NS 6450, and the acceptance criteria for starting and ending trial operation should be defined in the contracts.

Project examples

E39 Herdal to Røyskår, Norway: road project with JVIS

The joint venture Implenia Stangeland uses TaskCtrl through the entire process on the E39 in Lyngdal, from planning roads, tunnels and bridges to completion. Read the E39 case.

Kuben, Bergen, Norway: residential project with COWI and Stoltz

COWI and Stoltz used TaskCtrl for design and systematic completion, with test records updated on site while the tests were running. Read the Kuben case.

Project Lightning, El Paso, Texas: data center

On a 1 GW data center, checklists and systematic completion are linked to the activities in the takt plan, so construction and the test plan stay connected. Read the case on takt planning for data centers.

Common mistakes

• Test planning starts at the end of construction. By then it is too late to influence the solutions.
• Tests without acceptance criteria. Without clear criteria, it is unclear when a test is approved, and the milestones become unclear.
• The model comes before the function. Systems are fully designed in BIM before the function is clarified, and have to be redesigned.
• O&M documentation is collected at the end. Documentation should be delivered continuously and be ready before testing.
• No shared deviation list. When each discipline has its own list, the project loses track of what must be closed before handover.

Systematic completion in TaskCtrl

The guideline from 2016 pointed out that no tool could support the whole process, from project kickoff to fully tested and handed over. TaskCtrl is built on the guideline to cover exactly that.

The systematic completion module brings together the system register, the test hierarchy, test procedures and test records. Tests are carried out and signed on mobile, deviations are logged with photos against the right system, and O&M documentation is collected along the way. The module is linked to the construction module, so status from the takt plan flows into the test plan.

The system register is the starting point. Each row is a system with a unique number, and the columns follow the system through the whole process:

• System. System status, MMI, FMI and open deviations.
• Documents. Functional description, system diagram, controls drawings and requirement specification.
• Mechanical completion. Started, complete and energized, with status from construction.
• Tests. Tabletop test, system function test, I/O test, integrated test, area test and scenario test.
• Disciplines. Which disciplines are involved in the system, from the owner and design manager to architecture, structural, HVAC and plumbing, electrical and the others.

The example shows how FMI follows the work. Systems with a completed functional description are at FMI200. Systems where the tabletop test is accepted and the system function test is planned are at FMI350. When the system function test is accepted, the system moves to FMI400. MMI shows the maturity of the model alongside: 400 for construction documents and 450 when the system is built.

The test hierarchy is set up to match the project's own structure. A data center can, for example, have tabletop test, FAT, mechanical completion, functional tests, IST and full-scale test as separate columns.

Expert contribution: Ove Kjærgård, Brisq.

This guide is based on the Norwegian guideline for systematic completion (“Veileder: Systematisk ferdigstillelse”) from BA2015, written by Per Roger Johansen and Tor I. Hoel (2016), and the FMI guideline (“FMI-veilederen”) from Prosjekt Norge at NTNU.

Frequently asked questions

Read also

• Systematic Completion: A Key to Successful Construction Projects
• FMI: Function Maturity Index
• Takt planning for data center construction: daily takt with control of construction and completion