Client involvement in performance based briefing in Public Private Partnerships procurement and the use of ICT: Dutch best practice

Transcription

1 CIB Client involvement in performance based briefing in Public Private Partnerships procurement and the use of ICT: ANGELIA ZEEGERS GEORGE ANG ABSTRACT Due to the complexity of PPP-projects, and the key role of the Output specification in ensuring end-user satisfaction during the contract period, proper organisation and sound management of this process are critical success factors. For the National Treasury-project (first Dutch government PPPproject) the Rgd developed a performance based briefing approach, structured according to the Nordic Five Level approach as to secure the recognisability of the client s input and ensure client satisfaction with the end result. Because of the complexity of the Output specification a digital version was provided with support of the ICT-tool Product Knowledge Model. The structure of the digital model follows the chosen Nordic Five Level approach. The PK-model is a complex set of databases in which requirements can be linked by describing relations. The use of the PK- Model improves the consistency of the Output specification and the enormous amount of data is easier to handle. Keywords Performance based briefing, Output specification, Public Private Partnership (PPP), Nordic Five Level structure, Product Knowledge Model (PK-Model).

2 2 Client involvement in performance based briefing INTRODUCTION This paper is based on best practices in setting Output specifications for Dutch government PPP-projects and will describe performance-based briefing with special focus on client and end-user involvement. The content of the Output specification is described as an outline only. This paper specifically deals with performance based briefing and related subjects in PPP-projects and not with other important aspects of PPP-projects such as contract, finance etc. For the Rgd, acting as the national corporate real estate agency, the client is generally also the end-user. The term client in this paper therefore covers both the construction client and the end-user. Public Private Partnership (PPP) Procurement methods applied by the Rgd are mainly traditional (separate contracts for various parties in the supply chain while operational risks are left to the construction client. In the early nineties the Rgd started with more integrated procurement, Design and Build, methods. In 2003 the Rgd, together with the National Treasury, started with the first Public Private Partnership project for the renovation of the National Treasury (approx m 2, contract period 25 years). Design, Build, Maintain, Operations and also Finance were included in one contract (DBFMO-contract). In November 2006 the contract was signed with Safire, the tender winning consortium. The Rgd believes that PPP-projects will improve the price-quality ratio; cost efficiency versus the quality of the end result. Integration of design and exploitation stimulates innovation and added value for the client. Therefore, all projects of more then 25 million euro (investment-, interior- and user costs), requires a comparative study whether PPP will be given surplus value, prior to project initiation. So far PPP is used for three other projects namely: 1. Tax office Doetinchem (approx m 2, contract period 15 years) 2. Tax office / Informatie Beheer Groep (IBG) Groningen (approx m 2, contract period 20 years) 3. Detention centre Rotterdam (560 detainees, contract period 20 years) Performance based briefing Describing performance requirements (Output specifications) for PPPprojects has become an important impulse for the Rgd to develop an approach, which will increase the user satisfaction and faith in the end result. Especially for PPP-projects, with a long contract period, it is important that the client will recognize his input and has faith in the outcome and its flexibility over time. If the client is suspicious and/or dissatisfied, it is very hard to create a real partnership during the rest op the contract.

3 Client involvement in performance based briefing 3 The performance based briefing approach, which the Rgd, together with the client, developed for the National Treasury-project, is structured according the Nordic Five Level approach. Because of the complexity of PPP-projects it was necessary to use ICT-supported tools for the development of the Output specification. The tool can also be used for validation and verification purposes. This aspect is now under development and will be finished in April BUILDING PROCESS AND THE BRIEF / OUTPUT SPECIFICATION Domains of competences In order to ensure a proper process where risks are allocated with the right party, risk management may be organised according to best competence of demand and supply parties. Figure 1 shows the building process projected against the three domains of competence [Ang, Wyatt, Hermans, 2001]. 1. The domain of demand competence 2. The domain of production competence 3. The domain of use competence Figure 1 Building process: the domains to be distinguished In general the client competences are apparent in the domain of demand and the domain of use, while the competences of the supply chain players is manifest in the domain of production. In traditional contracts all supply parties are contracted separately, and the contract partners are individually responsible for their input in the domain of production. In an integrated Design Build (eventually extended with finance-maintenanceoperation) contract a consortium covers a single point responsibility within this domain of competence.

4 4 Client involvement in performance based briefing PPP-contracts Figure 1 was originally made for the more traditional procurement methods. However, this figure can also be used for DBFMO-contracts. The important differences between a more traditional contract and a DBFMO contract are the responsibility and liability of the contract partners within the different domains and the contract period. In PPP-projects (DBFMO-contracts) the client is still responsible for setting requirements (the Output specification) in the domain of demand but the consortium is responsible for performing in the domain of production and also in the domain of use (with regard to building-related aspects) during the whole contract period. The consortium will also be responsible for (an agreed part of) the operations. Because this paper will concentrate on building related aspects, this is beyond the scope of this paper. In PPP-projects the focus of brief changed: 1. The moments of risk still exist but are now a problem for the consortium. They must verify if they still meet the requirements of the Output specification. 2. The verification methods described with these requirements will also change. Most of the requirements will be checked in de domain of use, in practice, and at hand-over. 3. For long-term contracts the focus in the brief must also be on the long term. Possible changes in social-, technical-, economical- and political fields must be taken into account and need anticipation. Ad. 1 Moments of risk: Since the responsibility of the consortium covers performances in the domain of production and the domain of use, the moments of risk (does the building meets the requirements) are the responsibility of the consortium accordingly. They must verify if they meet the requirements in the Output specification. One of the important items of a consortium is total cost reduction (investment costs but also maintenance and operation costs, for example cleaning. So (design) aspects and selection of materials, which will influences the exploitation costs, will be given more attention during the design phase in PPP-projects. This is one of the outcomes of the evaluation of the Dutch National Treasury-project. Since quality such as architecture and design must not be overlooked, attention for this aspect in the requirements is necessary. Therefore it is important not only to look at the lowest price but also at the best quality by weighting quality and price in such a way that both aspects are considered in the best offer. Ad. 2 Verification: Performance requirements must be verifiable / measurable otherwise it is useless to demand for them. Traditionally the verification was focused on the design and construction phase; in PPPprojects the verification is focused on the domain of use, because this is the moment and period of truth. Verification during the design and construction

5 Client involvement in performance based briefing 5 phase will be minimised to those aspects, which can t be changed once the building is realised (for example architecture, lay-out etc.) and to so-called strategic integral performance requirements such as indoor climate comfort and energy consumption for example. In PPP-projects measurement methods for most of the performance requirements are described instead of calculation methods. Ad. 3 Contract period: The contract period in PPP-projects is relatively long. This means that possible changes in the future must be taken into account. Looking only to the needs for the short-term will make the building less fit for purpose in the future or will lead to enormous contract changes which will undo the financial profit of a PPP-project for the client (for the National Treasury this was 15%). A special issue is the flexibility over time within the contract and with regard to functional quality and fitness for use [Zeegers, Hermans, Ang 2001]. SETTING THE OUTPUT SPECIFICATIONS AND THE ROLE OF THE CLIENT Points of attention In PPP-projects the Output specification is a very important contractdocument. It is de basis of the whole project and requires major attention. Different parties are involved in making a brief and lots of documents are produced to describe what kind of building the client/end-user wants. This makes it a complex matter and lots of things can go wrong as a result of: language problems between several parties. The client will describe his functional needs. After that, experts will translate the functional needs into functional and technical performance requirements, necessary for verification of the outcome. Since the brief is still a written document it is very difficult to link the functional needs (input) with the translation result into performance requirements. The client may loose the feeling with the brief. He/she doesn t recognise the input and therefore becomes uncertain and may be very suspicious towards the outcome. the number of documents and the tuning of the different documents, which are made for the project. During the process various documents will be produced (input documents, functional requirements, technical requirements, design documents, specifications etc). Such a bunch of documents may not be unambiguous and consistent, and generate major risks, especially in PPP-projects because of the long-term contract period. It is also hard to gain an overview and see the relations between all those documents. verification between the requirements described in the brief, and the design and technical specifications / solutions made by the contract

6 6 Client involvement in performance based briefing partner. In order to allow enough space to the contract partner to comes up with innovative solutions the brief sticks to performances instead of prescribed solutions as much as possible. The contract partner will translate the required performances into a design and technical solutions or specifications. The match between requirements and specifications / solutions is sometimes hard to make. It requires expert skills to check whether the outcome matches the brief. The client must trust on the professionalism of the expert and hopes the expert understand the functional needs of the client. Systematic approach In the National Treasury-project the client wanted to be explicitly responsible for the Output specification. This imposes on the Rgd to structure the process in a systematic way that allows joint monitoring and assessment with the client in order to ensure sound matching of client needs and expectations. For the National Treasury-project, together with the client, the Rgd has developed a systematic approach based on the Nordic Five Level Structure [NKB 1978], as to structure the briefing process and to overcome the problems described above. Per level the input and the person responsible for the content of this input are described.(see figure 2). Figure 2 Systematic approach based on the Nordic Five Level structure 1. Objective of the organisation: The first step in the pyramid is a description of the goals and mission statements of an organisation. These are generally written documents made by the organisation to communicate the mission and vision of the organisation and their staff. The client will take the lead to analyse the documents and extract useful information for the brief. 2. Functional concepts: The next step in the pyramid is to translate those building related mission statements into the functional concepts. Goals and mission statements of an organisation will affect the way the primary process is organised and will influence many functional

7 Client involvement in performance based briefing 7 requirements. For example: the client wants a pleasant work environment for their employees, which stimulates communication. This requirement deals with aspects related to the building itself, the workplaces, logistics, communication etc. In this step one must clarify what the client really means and what he really wants and why he wants it (pursue the question behind the question ) and what will be the impact with regard to the building design. This is a very important part of the process. One must be aware to maintain the starting point to describe those concepts in a performance based way and not into a solution based way. 3. Performance requirements: In the next step the functional concepts must be translated into verifiable and measurable performance requirements (functional as well as technical). Especially the relation between the functional concepts and the performance requirements is very important in the communication between the client and the expert. 4. Verification methods: In step four verification methods for each requirement are described. To verify the requirements one can use national and/or international standards like the ISO standards for example. In the case of PPP-projects most verification methods must be applicable as a part of the monitoring system during the period of use and operation. It is contractually agreed that not meeting the requirements will lead to a discount in the payment to the consortium. 5. References: References can be added to facilitate communication for both the client and the expert. Sometimes it is hard to express what one really wants, for example when it comes to architecture. References can be added to the brief as to illustrate the views or images expressed by the client and/or to underpin a required performance, but one should carefully avoid interpretation of a reference as a hidden solution. In the National Treasury-project the client took the lead in the description of the objectives of the organisation and the functional concepts. The expert consultant (functional, technical and services) took the lead in the description of the performance requirements and verification methods. References were used by both client and expert in order to facilitate communication about various issues. An example of the above (this example is worked out in figure 3) One of the focus points of the Dutch National Policy is the reintegration of handicapped and partly disabled persons into the production process. Every ministry must take special effort into this matter. Objective An objective of an organisation regarding this matter will be that Special effort with regard to the handicapped and partly disabled persons must be taken into account Functional concepts With regard to the functional concepts one may discuss the impact of this statement. For

8 8 Client involvement in performance based briefing example what kind of handicapped persons are we talking about? What percentage of the workplaces must be suitable for handicapped persons? The end of the discussion can be translated as: The whole building and all workplaces must be suitable for handicapped persons (motor-, airway-, acoustic- and visual handicapped) Performance requirements When describing performance requirements regarding lighting levels for example, one will discuss the consequences of this concept. How far do we want to go? There are handicapped persons who like to have a lower lighting level than usual while others like to have a higher lighting level. Do we want to serve all possible visual handicapped persons or not. The outcome of the discussion can lead to the following performance requirement: artificial lighting: E (m) task area: adaptable between lux Verification methods Verification methods are related to the performance requirement itself, not to the value. The only point of discussion will be in which phase we want this requirement verified? With regard to the requirement concerning lighting levels verification will took place in the domain of use. The verification methods for this requirement will be described: cf. NEN 1891/NEN-EN In this documents the measuring methods of the lighting levels are described. References References can be used by experts and clients to express what they want but also to underpin the chosen requirements. In this case a research report with regard to adaptable lighting, the use and energy consequences, applied in another Rgd-project (Court House in Den Bosch) can be used as a reference by the expert to motivate his statement. Organisation of the process Brief making must not be seen as an event but as a process [Barrett and Stanley, 1999]. Therefore the organisation of the briefing process is very important. Every stakeholder involved must have a clear vision of the approach and the goal to be achieved by this approach. In the National Treasury-project a core group consistent of three persons, the Output specification team, worked on the Output specification. All three were responsible for a part of the Output specification: 1. The client (responsible for objectives and functional concepts). 2. An external consultant (responsible for the performance requirements in regard to the operations). 3. A consultant of the Rgd (responsible for the performance requirements in regard to building related aspects). When necessary the three leading persons could demand for (additional) expertise, but they were the ones who decide what will be in the Output specification. Because the team was very small and worked together in the same room, it was easy to share and discuss a lot of information and they had a clear view of the overlaps. Within ca. 11 months the whole Output specification was made (including monitoring).

9 Client involvement in performance based briefing 9 While setting the Output specification the core team built in several checkpoints. Outsiders were asked to check the produced data and to give their comments. These checks prevent the Output specification team from being blind to their own work and it makes the client feel more comfortable with the end result. THE USE OF ICT IN MAKING THE OUTPUT SPECIFICATIONS The approach described above was the basis of the Output specification for the National Treasury-project. However, documenting all the data in a written document was nearly impossible because the relations between the different levels must be visualised in the brief to get a better understanding of the brief and the requirements asked. In a written document this would be unreadable and/or lots of data would be lost. Also, in a written document, the same data must be described more than once. This increases the risk that the data would not be unambiguous and/or consistent. Therefore the Rgd, together with the client, decided to make a digital document instead of a written document. For the National Treasury project we used the ICT-tool Product Knowledge Model (PK-Model), developed by ICOP / PKM-Solutions, for the first time. The PK-model contains a complex set of databases in which every requirement and other piece of data are described only once. Links between objectives, and functional- and performance requirements are made visible by described relations. The used Nordic Five Level structure is also the basis of the PK-model (see figure 3). The model is web based. The advantages of a digital model are: the Output specification is unambiguous and the consistency is improved; the relations between objectives, functional concepts, performance requirements and verification are made visible; the enormous amount of data is well organized and easier to handle; changes can be made easily because data is described only once. all team members are working with the same version [Barrett and Stanley, 199]

10 10 Client involvement in performance based briefing Figure 3 Translation of the Nordic Five Level Structure into the PK-Model (source ICOP/PKM-Solutions) Since the model and the approach, used for making the Output specification, are tuned, recognisability of the end result is improved. However an ICT model for a brief requires a different way of working: it requires a more structured way of thinking. No complete (sometimes vague) prose, in which one can hide several requirements, but straight forward requirements; the structure of the model must be well-considered, because it can limit the possibilities how to represent the data; special attention must be paid to the organisation of the work. The ICT-model is a tool. It can help to improve the quality of the work but it is not a guarantee. Sound organisation of the process is urgent as to avoid chaotic processes, in particular because any project-stakeholder is allowed to work in the database. VERIFICATION During the domain of production several functional concepts and strategic requirements were, or will be, verified, only to ensure that the consortium is on the right track. For the National Treasury-project a financial proposal and a technical proposal, elaborated in a design and solutions, were delivered by the consortia as written and illustrated documents and were verified by several teams (technical, financial etc.) commissioned by the client and Rgd. Since a financial proposal was part of the assessment and since the design and production time was relatively short, the consortia produced a relatively large amount of data as to cover uncertainties that go with such a PPP-proposal. It took a lot of time to verify the relevant information and compare the information of the several consortia with each other. After the final selection of the consortium Safire, this consortium requested the client for access to the PK-model data, and took the initiative

11 Client involvement in performance based briefing 11 to develop a verification model in the PK-model for their own use. They wanted to be sure that every requirement in the Output specification would be met, due to the contractual agreement that mismatches will interrupt the flow of payments. Therefore they appointed a responsible person for each requirement and he/she was supposed to give a motivation how the requirement would be met. FUTURE DEVELOPMENTS The first experiences with the approach and the use of PK-Model in the National Treasury-project were very positive. The consortia working with the digital Output specification in the National Treasury project were very enthusiastic about it. It gave them sound information to work with. Therefore the department responsible for PPP-projects at the Rgd decided to use this model for all PPP-projects. For the purpose of project definition of other projects the Rgd will develop a library of requirements based on the Output specifications already made for the four projects. With regard to the digital Output specification a standard layout will be provided as to facilitate setting complete and sound specifications. A standard Output specification will also facilitate the consortia to work with it (by improving the recognisability). With regard to the test phase the Rgd together with the ICT-company will work out a verification model. The purpose of this model is to facilitate the verification process. This is also in the interest of the consortia. It will provide answers to all kinds of questions and make sure they don t miss a thing. The delivery of this model is foreseen in April The model can also be used for monitoring during the operational phase. Since the operational phase is the responsibility of the consortium this could be optional and it is up to the consortium itself. CONCLUSIONS Essential learning points from the Rgd PPP-projects with regard to the Output specification are: 1. The content of the brief, and the depth of the described performance requirements in the brief, are closely linked to the selected procurement method and the partner who carries responsibility for the outcome. 2. The allocation of risks is different in DBFMO-contracts compared to traditional contracts. Since the focus of the brief for DBFMO-contracts integral performance during the operational phase of the facility rather than on the quality of its parts and components. Verification methods

12 12 Client involvement in performance based briefing that go with the requirements must be suitable during the operational phase (measuring instead of calculation and simulating). 3. Describing performance requirements for a contract period of 25 years requires a special focus on the long term needs such as flexibility over time with regard to fitness for use, and with regard to financial agreements about the percentage of interest related to real risks. 4. The involvement of the client is very important. Make the client responsible for the brief; this is a driver to structure the process. The Nordic Five Level approach, which is used in the Dutch National Treasury-project, turns out to be most useful as a method to give structure to the process of describing output specifications. Don t use it too rigidly. 5. Developing the brief, setting requirements and output specifications, and managing the process of briefing, monitoring and assessment in small core teams has proven to be most effective.. 6. Have the outcome checked by outsiders. They will provide you with a fresh view on the results and prevent the team from being blind to their own work. 7. The Output specification for a PPP-project is very complex and there is an urge to ensure the end result is consistent and unambiguous. Making use of ICT related supporting tools helps to realise these needs. 8. In a PPP-project the Output specification is not a stand-alone product, but is part of the total contract related to financial agreements, such as the interrelation between mismatches and interruption of the payment flow. REFERENCES Ang, K.I., Wyatt, D.P., and Hermans, M., 2001, A Systematic Approach to Define Clients Expectations of Total Building Performance during the Pre- Design Stage, Proceedings CIB world Congress Performance in Product and Practice, Wellington, New Zealand 2-6 April Barrett, P., and Stanley, C., Better Construction Briefing, 1999, Blackwell Science Ltd., Oxford NKB (Nordic Committee on Building Regulations), 1978, Structure for Building Regulations. NKB Report No. 34. November. Stockholm, Sweden. NKB Zeegers, A, Hermans, M, Ang, K.I. 2001, In search for design criteria for the delivery of industrialised, flexible and dismountable buildings, a performance based model, CIB world Congress Performance in Product and Practice, Wellington, New Zealand 2-6 April 2001