Delivering What's Required by TFT Consultants

The Bartlett School of Construction and Project Management Faculty of the Built Environment, University College London MSc Project and Enterprise Management

Delivering What’s Required An investigation into the management of client requirements in the UK construction industry.

Supervisor: Dr Andrew Edkins Author: Robin Keates September 2012

Abstract This paper discusses how the UK construction industry focuses on developing the brief at the front‐ end of the project. It is suggested that this front‐end focus and drive to ‘fix the brief’ in the early stages of the project lifecycle does not enable the project to respond effectively to changes in client requirements as the project progresses. Building on the principals of Risk and Value Management in construction, and learning from Requirements Management in systems engineering, a recommended framework for Requirements Management in construction is developed. Opinions of experienced industry professionals are acquired and incorporated into these recommendations. Effective Requirements Management requires an ongoing process, supported by key‐stage reviews. Barriers to ongoing development of the brief will need to be overcome. To facilitate Requirements Management in construction, a tracking document is proposed which can be used in conjunction with workshops and other means of collaborative working, to ensure the client’s requirements are always current and relevant. This should mitigate client surprise and ensure that the completed product reflects the client’s latest needs, achieving the best possible customer satisfaction.

Contents Abstract

List of Figures

iii

Declaration of originality and word length

iii

Acknowledgements

iii

Introduction

Literature Review

Summary of Findings of Secondary Research

Primary Research Methodology

Interview Questions

Analysis of Primary Research

Summary of Findings of Primary Research

Conclusions

Recommendations

References

Appendices

Appendix A – RIBA Plan of Works 2007

Appendix B – Transcribed Interviews

Appendix C – Proposed Client Requirements Tracker

List of Figures Diagram 1

Sequential ‘Over the Wall Syndrome’ for building projects. Kamara

p.1

et al (2002). Diagram 2

‘Network’ of relationships between project actors, including wider

p.2

project environment. Adapted from Pryke & Smyth (2006). Diagram 3

Context for implementing the client requirements processing model.

p.7

Kamara et al (2002). Diagram 4

The continuous Risk Management process. Adapted from Winch

p.10

(2010). Diagram 5

The continuous Value Management process. Adapted from Jefferyes

p.10

(2011). Diagram 6

A proposed briefing process with key‐stage reviews.

p.30

Diagram 7

Extract from proposed ‘Client Requirements Tracker’.

p.32

Text box 1

Professional background & experience of research participants.

p.13

Text box 2

Questions posed to the architects and project managers.

p.16

Text Box 3

Questions posed to the clients of the construction industry.

p.16

Text Box 4

Suggested categories for Requirements Tracking Document.

p.31

Declaration of originality and word length I declare that this MSc Dissertation is my own work except for quotations and citations, which have been duly acknowledged and referenced. The word count of this MSc Dissertation is 10,297 words (counted from the Introduction through to the Recommendations, excluding diagrams, text boxes).

Acknowledgements I would like to take this opportunity to thank my friends, family, employer and professional peers for their support and interest. I would also like to thank my tutor and the staff at UCL for the well structured and diligent approach to teaching, throughout the MSc. Finally and most importantly, I would like to thank my wife Alex for her unfaltering support and understanding over the last two years of studying.

iii

Introduction Delivering what is required – a product that is ‘efficient with the intended purpose’ – is a critical factor in achieving client satisfaction (Chinyio et al, 1998). In order to deliver a finished product that fulfils the client’s wishes, some form of management of the client’s requirements is required (Hood et al, 2006). This study reviews the management of client requirements in UK construction projects. While the study is set in the context of commercial (office) projects in the private sector, with values ranging from £0.5million to £5million, the findings could also be applied to other project types and sectors. For the purposes of this study, client requirements are taken to be the high‐level strategic requirements of a construction client, rather than detailed technical needs. Construction has been described by Kamara et al (2002) as suffering from ‘Over the Wall Syndrome’, creating a fragmented approach to management of client requirements in construction projects. They suggest that client requirements are extracted and interpreted by the architects then passed down‐ stream to the engineers, then to the contractor and finally the product is delivered to the end user (Diagram 1). Kamara et al go on to propose that down‐stream project actors have little involvement in, or understanding of, up‐steam decision making – again contributing to the fragmented approach to the management of client requirements in construction projects.

Diagram 1 – Sequential ‘Over the Wall Syndrome’ for building projects. Kamara et al (2002). Adding to the issues with ‘Over the Wall Syndrome’, is the fact that the RIBA Outline Plan of Work (2007) suggests that the brief should be ‘completed’ early in the project lifecycle, before the detailed design is carried out. This fails to recognise the possibility that the brief may need to be developed or adapted if the project environment changes during the design and construction process. Pryke and Smyth (2006) propose a networked ‘relationship’ approach to the management of projects which aims to create project structures and systems which are less linear and are more responsive to the wider project environment (Diagram 2). A ‘networked’ approach to projects requires ongoing communications and systems which continuously re‐examine the project environment, responding accordingly. If the management of client requirements in construction can take on board the key aspects of a networked approach, it may be better suited to delivering what the client requires.

Diagram 2 – ‘Network’ of relationships between project actors, including wider project environment. Adapted from Pryke & Smyth (2006). There are examples of current project management processes (Risk and Value Management) which already respond to the wider project environment (Winch, 2010; Jefferyes, 2011). Risk Management and Value Management in construction both take into account the wider project environment throughout the entire project lifecycle (Loosemore et al, 2006; Kelly et al, 2002; Jefferyes, 2011). These systems could therefore be used as a basis for developing a Requirements Management system for construction projects. Whilst systems such as Client Requirements Processing developed by Kamara et al (2002) help to improve the identification and ranking of the client requirements, they are less concerned with the ongoing management of the brief as the project develops. Although Requirements Management is a relatively new concept in construction it has, along with Requirements Engineering, been applied successfully in the software and systems engineering industries since the 1970s (Hood et al, 2006).

The first section of this study details a review of existing literature in order to better understand current practice in construction project briefing, and review the legitimacy of the call to improve the management of client requirements. Next, current practice in the management of client requirements is critically reviewed. Then barriers to ongoing management of client requirements will be discussed, followed by a review of Risk and Value Management as examples of an ongoing networked approach to the management of project issues. The software engineering industry’s well established practice of Requirements Management is also reviewed. Primary research is undertaken in the form structured qualitative interviews with ten practising construction professionals: three architects, three project managers and four clients of the construction industry. The interviews establish the opinions of current practitioners on the themes raised in the secondary research, and establish the context for a better means of managing client requirements in UK construction projects. Conclusions are drawn and recommendations made. Whilst this study builds upon a number of academic theories, the recommendations for improved Requirements Management in construction aim to provide real‐world applications giving value to current practitioners and clients of the construction industry. The key objectives of the research are: 

To analyse and evaluate current practice in Requirements Management in construction projects, and compare to current practice in Risk Management and Value Management.



To investigate resistance to Requirements Management in construction.



To establish a process for implementing Requirements Management in construction, leading to improved management of strategic client requirements and increased client satisfaction.

Literature Review This literature review focuses on current practice in construction project briefing, in the context of UK private sector commercial refurbishment projects. The objective of the review is to evaluate the current industry approach to briefing and consider if this can be improved to better serve the client’s needs. First, existing literature will be considered, comparing a traditional front‐end focused briefing process against the contemporary paradigm of ‘networked’ project environments. Next, current practice will be analysed in terms of its strengths, weaknesses, opportunities and threats. Finally, barriers to an ongoing briefing process will be considered, along with two examples of successful ongoing management of project issues (Risk and Value Management) and an example of ‘Requirements Management’ practice in another industry. The terms ‘managing client requirements’ and ‘managing the brief’ are used in this study to refer to the process of obtaining strategic requirements from the client, recording this information and communicating it to the other project actors. Current Approaches to Managing the Brief in Construction Projects Before discussing current practice in managing the brief, it is important to understand the link between an effective understanding of the client requirements and client satisfaction. Chinyio et al (1998) carried out extensive research of UK construction clients and found that above the traditional need for projects to be delivered on time and on budget, there is the need for the building to be ‘efficient with the intended purpose’. Whilst timeliness, value, risk management were all highly rated (98%, 90% and 81% respectively), the only need to be called for by 100% of clients was for the building to match its intended purpose. On this basis, it could be argued that establishing, monitoring and communicating the client requirements is the most predominant factor in ensuring client satisfaction. Even though the paper may be considered simplistic in its attempt to create a ‘checklist’ of requirements for use in construction project briefing, the observations are relevant. It is also interesting to note that no reference is made to the idea of re‐visiting the brief as an ongoing process. Current approaches to construction project briefing are generally focused on early‐stage formulation of a client brief (Walker, 2008) and can lead to a fragmented process of passing client requirements from one project actor to the next (Kamara et al, 2002). The traditional view of the ‘establishing the brief’ can be epitomised by the conversation between an architect and a client, held at the start of a new commission, to establish a client’s needs (Luck & McDonnell, 2005). In line with this traditional approach, prior research tends to view the briefing process as a focus on the front‐end (early stages) of the project (Chinyio E. et al, 1998; Smith J. et al, 1998; Kelly J. et al, 2002; Tzortzopoulos P. et al, 2006).

Advocating fixing the brief at the front‐end of the project is the RIBA Outline Plan of Work (RIBA, 2008). Created by the Royal Institute of British Architect (RIBA), the Outline Plan of Work is taught in most UK architectural undergraduate courses and widely used as a project framework by architects and construction professionals throughout the UK. It breaks down the typical progression of a construction project from inception to completion. These 11 stages are labelled Stage A (Appraisal) through to Stage L (Post Practical Completion). The full plan of works can be found in Appendix A. The sections of the RIBA Outline Plan of Work (RIBA, 2008) relating to client requirements and the briefing process can be identified as follows: Stage A – Appraisal Identification of client’s needs and objectives, business case and possible constraints on development. Stage B – Design Brief Development of initial statement of requirements into the Design Brief by or on behalf of the client confirming key requirements and constraints. Stage C – Concept Implementation of Design Brief and preparation of additional data. Stage D – Design Development Completion of Project Brief. From Stage E onwards, the brief and client requirements are not mentioned. This reflects the traditional school of thought that projects have a linear structure with a brief at the start, followed by a period of design, followed by construction. Walker (2008) suggests that it is ‘rather idealistic’ for a client to be told that the brief (and therefore their requirements) must be frozen at a certain stage in the project. Walker advocates a systems approach to the structuring of construction project organisations which shares many traits with the ‘networked relationship’ approach discussed in the introduction (Pryke and Smyth, 2006) such as an ongoing responsiveness to a wider project environment. He suggests that a project should be viewed as a system – the system must have an objective, which must be continuously developed as further information is made available. Nutt (1988) also recognises that the linear nature of the RIBA plan of works poses a risk to the client, stating that once a brief and initial design is fixed at the early stages of the design process, it is assumed that any changes to requirements are to be accommodated post‐construction – an approach which has historically shown to be lacking. Nutt focuses on the importance of a strategic level of input in the planning, design and management of a building to ensure it meets the needs of the end user for the lifetime of the building. Whilst the paper has an academic focus and does not go far to offer practical day‐to‐day solutions, it does discuss the process of strategic requirements management

from an end user perspective. This helps to extend the concept of requirements management beyond the typical early‐stage discussions. Developing the case for an ongoing briefing process, Winch G. (2010) argues that one of the key reasons for developing the brief is to avoid ‘client surprise’. He details a process of analysing and defining the brief but stops the process once the brief is ‘complete’. He goes on to suggest that there may be a gap between what the client required at the start of the project (before the design process has commenced) and what they receive (once the construction phase is completed) which could lead to client surprise. The suggested remedy is to ensure the client is involved and aware of the design process as the design changes. Blyth & Worthington (2010) develop the proposition that briefing should be managed throughout the project from inception through to end use. Whilst this is in line with the position of this dissertation, their work is still predominantly a front‐end focused discussion, with very little comment on the management of the brief at the later phases in a project, such as the construction stage. Continuing to build on the notion that the brief must be managed, Kamara et al (2002) propose a Client Requirements Processing Model (CRPM). The model takes a set of explicit and implicit client requirements and develops them into more industry‐friendly solution‐neutral design specifications that can be used by the project team. CPRM is an in‐depth briefing solution and has potential to add real value to large scale and/or complex projects. The focus on creating solution‐neutral specifications is key in differentiating between the strategic ‘client requirements’ document and the technical documentation created by the design consultants (used to convey construction information to the contractor). CRPM is however, a complex project management tool and relies on a high quality of input information in order to deliver meaningful results. It therefore requires time and effort from those using the system to a point where it may be considered unviable for smaller projects. One critical limitation of the model is the proposed method of implementation. Kamara et al recommend that the model is used only at one stage, before concept design has commenced, as represented in the black box in Diagram 3.

Diagram 3 – Context for implementing the client requirements processing model. Kamara et al (2002). In what could be seen as an attempt to extend the briefing process beyond the early project stages, Ryd (2004) puts forward the case for using the briefing document to convey information from the client to the contractor during construction. In practice however, it is important to differentiate briefing documents from technical/construction documents. The briefing documents should remain a solution‐neutral set of client needs (Kamara et al, 2002). Briefing documents require interpretation by a design team in order to turn solution‐neutral strategic needs into design drawings and specifications (construction information). It could therefore be argued that whilst the briefing document may not be suited to pass information to the contractor, is should be continually managed in parallel above the design process and be cross‐checked at regular intervals. Overtly supporting an ongoing briefing process, Othman et al (2004) investigate the drivers for ‘Dynamic Briefing’. They propose 30 key ‘drivers’ (reasons) why an ongoing briefing process would be beneficial. Whilst this list may not be definitive, it does offer a convincing argument for the need to extend the briefing process beyond the early project stages. The study proposes a system to manage the drivers of brief development. It could however be argued that the drivers are simply a means to an end, that monitoring the drivers and managing the outcome of changes is a more relevant approach. Having established the academic context of the briefing process in construction projects, this study will now move on to a critical analysis of current practice in managing the brief in construction. This will be followed by a review of possible barriers to continuous briefing, along with a review of

examples of continuous management of Risk and Value in construction, and finally, a discussion on the transferable aspects of Requirements Management from Systems Engineering to construction. Critical Analysis of Current Practice in Managing the Brief in Construction Following on from the initial review of academic literature regarding the briefing process, current practice in managing the client’s requirements in the UK construction industry must be considered. To identify areas for possible improvement, the strengths, weaknesses, opportunities and threats in current practice will be reviewed. A key strength of the construction industry’s current approach to managing the brief is the ability to quickly and accurately establish the initial client requirements. There is a consensus that understanding a clients requirements and delivering a project which satisfies them is a key factor in the success of a project (Chinyio et al, 1998; Tzortzopoulos P. et al, 2006). Methods range from an informal client meeting on small simple projects, right through to CRPM on large complex projects. It is generally recognised that a well documented brief is a critical component of the delivery of a project that meets or exceeds client expectations (Winch, 2010; Kamara et al, 2002). The majority of current approaches to briefing result in the production of a documented ‘brief’ which is used to capture or ‘freeze’ what has been asked for by the client. Whilst current practice is well adapted to identifying the client’s requirements at the start of the project, it is a front‐end‐focussed activity (as discussed in the preceding section). Given the typical duration of larger projects, especially those in the multi‐million pound budget range, a number of years can pass between the initial briefing process and starting on site. Even more time will pass during the construction phase. This introduces the risk that the project delivered meets the needs the client had three or four years ago, rather than what they need right now. There are no widely recognised mechanisms to allow for the client’s strategic requirements to be reviewed as the project environment develops. This has the potential to result in missed opportunities or, worse still, the delivery of a finished project which does not meet with the client’s latest requirements. According to Walker (2008) examples of factors in the wider project environment which may change or develop include: 

Developments in construction methods & technology



Fluctuations in raw material costs



Alternative procurement techniques

Other factors may include: 

Changes of key project personnel or stakeholders



Changing legislation (e.g. Building regulations, BREEAM)



Changing market expectations



Changes in the national financial/regulatory climate

As established earlier in the literature review, there is a great opportunity to optimise the management of client requirements and ensure the finished project delivers exactly what the client needs. This will lead to increased client satisfaction (Chinyio et al, 1998). A new management process would need to give the project team regular opportunities to review the original strategic requirements and take on board the latest developments. This will help ensure the delivered project meets current requirements, rather than what was required when the brief was established at the front‐end of the project. Building on Pryke & Smyth’s (2006) ‘relationships’ approach to projects could allow briefing to become an evolving networked conversation between all project actors throughout the project, rather than a one‐off, linear dialogue between client and design team. Treating the briefing process as a dynamic networked process could allow the project to achieve the following benefits: 

Respond and adjust to suit developments in the project environment.



Make best use of new information.



Ensure that the project design and construction team efforts are always correctly aligned with the client’s current goals.



Reducing or client surprises.



Add value by responding appropriately to unforeseen opportunities.



Reduce abortive work by acknowledging the expiry of redundant requirements.

A key threat to the improvement of the briefing process are barriers to the implementation of ongoing management of client requirements, which will now be discussed. Barriers to Continuous Requirements Management in Construction Whilst the case for ongoing development of the brief has been discussed, it is also necessary to consider barriers to implementation. Walker (2008) notes that one key document, used by current practitioners, actively discourages developing the brief: the RIBA Outline Plan of Works (2008). From the author’s own experience working on a design team as an architect, and managing a design team as a project manager, a culture exists whereby there is a rush to get the brief fixed, so that the client stops ‘changing their mind’ and designers are able to go and ‘get on with the job of designing’. Design has been described as a wicked problem (Winch G. 2010) meaning there are many possible solutions to each design problem (or client requirement). Design solutions are subjective, and whilst some designs are clearly better than others, there is often no right answer. Design is an iterative process often involving a number of options which get refining to arrive at the final design. This can create a blurred boundary between natural design iterations – ‘Design Development’, and additional time spent redesigning due to client changes. This blurring of boundaries can cause problems if the design team spends time redesigning due to a perceived change in requirements, whilst the client has taken the view that changes are a natural part of the design process. The design team expends their

resource allocation for the project and either ends up working at a loss during later stages (e.g. during construction) or surprising the client with additional fees. The RIBA’s proposal to fix the brief after Stage D would address this problem, but only from the design team’s perspective. It does not offer a satisfactory solution for the client, whose requirements may change after the project brief has been fixed. Risk and Value as Examples of Ongoing Management Processes in Construction Projects Whilst briefing has traditionally focused on the early stages of a project, other aspects of the management of construction projects have a much more integrated methodology. Two good examples are Risk Management and Value Management. Both operate a process of ongoing gateway reviews (Kelly J. et al, 2002; Loosemore M. et al, 2006) and facilitate open discussion between the client, design team, contractor and any other relevant project stakeholders. Both Value Management and Risk Management processes are started at early stage inception, and continue right through to post completion and occupation. In current practice, both processes can be subject to regular reviews at key project stages or ‘gateways’. Value Management and Risk Management both establish the key issues at an early stage (as with briefing) they go on through the project undergoing a process of continual development and refinement, with each stage building on the progress of the previous, as illustrated in Diagrams 4 and 5. It is this method of ongoing review which could be very beneficial to requirements management in construction projects.

Diagram 4 – The continuous Risk Management process. Adapted from Winch (2010).

Diagram 5 – The continuous Value Management process. Adapted from Jefferyes (2011). The tools and systems used to implement Value Management and Risk Management are suitable for ongoing use throughout the project lifecycle. Risk workshops or ‘brainstorming sessions’ and ‘Risk

Registers’ are common features in the management of UK construction projects (Winch, 2010). Likewise with Value management, there is a comprehensive framework of workshops, matrices and schedules all designed to establish, monitor and develop the value management process throughout the project’s lifecycle (Jefferyes, 2011) The systems used for briefing in construction tend to be focused on identifying, processing defining and recording the clients initial requirements, for example CRPM (Kamara J. et al, 2002), rather than managing them as an ongoing process. Example of Requirements Management in Other Industries The literature review has established that there is no widely established practice of ‘managing’ the client requirements throughout the project. In the software engineering and manufacturing industries, Requirements Management is a well established practice. In Requirements Management, Hood et al (2008) describe the process of defining and monitoring client requirements throughout the project lifecycle from concept design, through prototyping and technical analysis to build and implementation. The process even continues beyond implementation, in order to continually evaluate and refine the product and process. Hood et al draw a distinction between Requirements Engineering and Requirements Management. Requirements Engineering is concerned only with identifying all client requirements (i.e. establishing the brief). This is done with a high degree of detail and picks up on the smallest technical requirements. Requirements Management tracks changes to the established requirements throughout the project. One key advantage of tracking changes to client requirements is the ability to easily review past decisions and ensure the team does not revisit scenarios which have already been considered and discarded. Furthermore, a clear view of the impact of change on time, cost, quality gain be understood as each change is assessed and agreed. This will lead to reduced surprises for the client. Finally, the recorded common understanding of what’s changed that can be easily communicated to any new stakeholders joining the project.

Summary of Findings of Secondary Research It is clear that the academic research and industry practice of Requirements Management in construction is, to date, falling behind other aspects of construction project management such as Risk and Value Management. There is still an ingrained view of the brief as a static document to be fixed in place at the start of the project and used to communicate initial requirements to the design team. From an academic perspective, progress has been made by Kamara et al (2004) and Othman et al (2004) towards developing an ongoing briefing process; however, this has not yet translated into practical recommendations for implementation in industry. Turning Kamara’s one‐off CRPM system into an ongoing process could add much greater depth and value. As the design develops and new opportunities and limitations become apparent, the model can be re‐run to capture the clients latest response to what will be a changing project environment. This also offers an opportunity to gather input from new stakeholders to the project who may not have been involved at pre‐design stages (for example if an incoming tenant signs up to pre‐let an office building prior to completion). This responsiveness would ideally suit a networked approach to managing projects. A networked approach to construction projects requires new way of managing client requirements which allows the brief to respond to a changing project environment, using tools and systems to monitor, record and communicate the latest changes in client requirements. Risk Management and Value Management are good examples of how the construction industry has developed systems for monitoring, recording and communicating key project issues throughout the project lifecycle, from inception through to completion. Similarly, the systems engineering industry has demonstrated that Requirements Management can add value to projects. The culture of fixing the brief, propagated by the RIBA Outline Plan of Works, is a critical barrier to establishing Requirements Management in construction. In order to encourage the design team to embrace ongoing development of the brief, they will need to ‘buy into’ the notion that re‐evaluating the brief throughout the project lifecycle is key to ensuring client satisfaction, and ultimately of benefit to everyone working on the project. Concerns that late‐stage changes will result in wasted effort and abortive work could be tackled by ensuring that wasted time is adequately recompensed. The following section of this paper documents a series of qualitative interviews aimed at establishing the attitudes and experiences of practicing project professionals regarding Risk Management, Value Management and managing the brief. Their opinions and attitudes regarding various aspects of late‐ stage client changes are discussed. Clients are also interviewed regarding their experiences of managing and communicating their needs, as well as their experiences when making late‐stage changes on a project.

Primary Research Methodology The literature review provides a base on which primary research can build. The aim of the primary research is to gather opinions from property and construction professionals currently working on live private sector commercial projects in the UK. The proposed methodology for the primary research element of this dissertation is a series of structured qualitative interviews. Individuals consulted for the primary research were selected for having extensive experience working on commercial (office) projects between £500,000 and £5million. Opinions were gathered from customers of the construction industry as well from practicing consultants employed to provide design and management services. As the focus of the research is on private sector commercial (office) projects, four clients have been selected from private sector property and real estate organisations, including asset managers and developers. Of the six consultants interviewed, three were project managers and three architects. Background details of each participant are outlined in Text Box 1.

Ref.

Profession

Years of experience

Company

Sector Experience

‘Practitioners’

Architect 1

Architect

Architect 2

Architect

Architect 3

Architect

Project Manager 1

Project Manager

Project Manager 2

Project Manager

Project Manager 3

Project Manager

Client 1

Asset Manager

Client 2

Asset Manager

Architectural Practice Architectural Practice Architectural Practice

Commercial; Residential; Public Sector. Commercial; High‐end residential. Commercial; Education; Private Residential.

Building Surveying Consultancy Building Surveying Consultancy Project Management Consultancy

Commercial; Residential. Commercial; Retail; Residential Commercial; Retail.

‘Clients’

Client 3 Client 4

Development Manager Development Manager

Pension Fund – Property Investment Property Investment Management Speculative Developer Speculative Developer

10 8

Commercial Offices; Retail. Mixed use ‐ commercial/residential; Retail. High‐end commercial; High‐end residential. Commercial; Student housing.

Text box 1 – Professional background & experience of research participants.

The primary research questions are structured around four key themes: 1.

Current practice of construction professionals in managing the brief.

Attitudes of construction professionals towards client changes.

Client practice in managing strategic requirements.

Client perception of design team responsiveness to changes in the brief.

The construction professionals were questioned on their use of Risk Management and Value Management along with their systems for managing the client brief. This was intended to provide an overall context to the way in which each individual applies tools and systems to manage a project. Questions on how time is allocated to Requirements, Risk & Value Management are intended to expose any discrepancies or biases in current practise. Finally, a qualitative assessment of the individual’s attitude towards late‐stage client‐driven project changes was established. Firstly, this was intended to ascertain if there is evidence of an inherent resistance within the design team to respond to late‐stage changes in the client requirements; secondly, whether and to what extent any resistance is driven by concerns over remuneration for additional time spent responding to client changes. In order to establish the context in which the clients review their own strategic requirements, they were first asked to describe how often and at what project stage they review their requirements. They were then asked to describe, in qualitative terms, their personal experience of communicating their needs to the design team. Next, the clients were asked to judge the quality of responsiveness from design teams in terms of speed and effectiveness, when responding to client changes in the brief throughout the project lifecycle. Finally, to establish how clients respond to feedback, the clients were asked if feedback from the design and construction team often leads to strategic aims to being reconsidered. An opportunity was given to the clients to suggest any ideas for improving the briefing process or the communication of strategic client requirements. Limited information was given to the participants, only to point out the following: 

The research is for an MSc investigation into current practice in the management of construction projects.



The questions should be answered in the context of private sector commercial projects, in the UK, with values of between £0.5m and £5m.



The questions should be answered as fully as possible, with full freedom to express personal opinions.



Identity of the participants will be kept anonymous.

The questions were asked in a specific order with a developing focus on detail, so that later questions did not influence the responses to earlier questions. If the participant misunderstood a question, the question was repeated with emboldened words emphasised. The interviews have been transcribed,

with only basic editing to focus on the answers and omit irrelevant connecting phrases. The interview questions posed to the participants are shown in Text Box 2 and Text Box 3. An analysis of the findings follows, with full transcripts contained within Appendix B.

Interview Questions Text Box 2 and 3 Detail the specific questions posed to each participant. Text Box 2 contains questions posed to the ‘Practitioners’ (Architects and Project Managers), while Text Box 3 contains the questions posed to the ‘Clients’. 1. Discuss what tools, systems and documents you use to manage risk on a project, and at which project stages this happens.

2. Discuss what tools, systems and documents you use to manage value on a project, and at which project stages this happens.

3. Discuss what tools, systems and documents you use to manage the brief on a project, and at which project stages this happens.

4. What proportion of your project are affected by late‐stage clients changes (i.e. RIBA Stages G‐K)?

5. Generally speaking, what effects do late‐stage client changes have on a project ?

6. On projects where clients have changed their minds in the later stages, what proportion have a positive, versus a negative, affect on the project?

7. What are your main concerns, if any, if a client’s needs change during the later stages of the design process?

8. Do you think it's difficult to claim additional fees to cover client changes. Text box 2 – Questions posed to the architects and project managers. 1. Describe the stages in a typical project which you review your high‐level 'strategic' project objectives.

2. Describe at which stages in a typical project you feel that you are most able to communicate your requirements to the design team.

3. How would you describe your experience of communicating changes in your requirements during later stages of a project? Would you say it is easy or difficult; simple or complicated?

4. On what proportion of your projects has it been necessary to alter the initial brief, in the later stages of the project?

5. How do you rate the performance of design teams in responding to changing client requirements mid‐ way through a project, for example, quickly or slowly; effectively or ineffectively?

6. How often does feedback from the design team or construction team affect the strategic decisions on your projects?

7. If you have any comments or suggestions regarding the improvement of the briefing process or communication of strategic client requirements, please them describe now. Text Box 3 – Questions posed to the clients of the construction industry.

Analysis of Primary Research The analysis of the primary research findings is structured around the four key themes identified in the Primary Research Methodology section: 1.

Current practice of construction professionals in managing the brief.

Attitudes of construction professionals towards client changes.

Client practice in managing strategic requirements.

Client perception of design team responsiveness to changes in the brief.

The following analysis is an interpretation by the author. It is noted that these findings are based on the author’s own subjective interpretation of the interviews. As such, the reader is invited to cross‐ examine this analysis using the transcripts located in Appendix B. 1. Current practice of construction professionals in managing the brief. The first collection of questions was asked to establish how practitioners currently approach the management of changing client requirements. This is compared with how the same practitioners manage value and risk on their projects. When asked to describe current practice in Value Management and Risk management, both the architects and project managers described a variety of tools, systems and documents. Statutory systems (CDM Regulations 2007, Building regulations) were described to assist with the management of project risk. “Risk workshops”, “Value engineering workshops” and “team meetings” were also mentioned, along with “risk registers” and “cost schedules”. When discussing the brief, participants mentioned “meeting with the client” and a “letter to the client” or “briefing document”. This demonstrates that there are a variety of provisions in place, in current practice, to establish and record the initial client requirements. The ongoing nature of risk management and value management was discussed: “[Risk management is] not a one‐off discussion, the list gets added to; things come off the list when the risk has gone, and new items are added on, so the document carries on changing.” “We normally look at costs at the start of the project at a high level, then do value engineering at [RIBA] Stages E & F… On more complex projects, we sometimes do more value engineering with the contractor on site.”

However, when it comes to construction project briefing, the construction professionals did not consider that the process should extend beyond the early project stages. Common themes coming from the practitioners can be represented by the following quotes: “We make sure the brief is all recorded and completed prior to detailed design.” “We send the letter to the client at the start of the job. It's a one‐off thing, so once it's sent [the brief] is fixed.” “Our time is generally spent in the first few weeks of a project. The brief is then fixed to avoid hundreds of variations." This falls in line with expectations based on the traditional approach to construction project briefing. As proposed in the secondary research, whilst risk and value have an established pattern of ongoing ‘continuous’ development throughout the project, management of the clients strategic requirements remains a static, one‐directional short lived activity, restricted to the front end of projects. 2. Attitudes of construction professionals towards client changes. The next collection of questions focuses on gauging the attitudes of the practitioners towards client‐ driven changes to the brief, especially at later project stages. These questions aim to highlight the possibility of a negative attitude towards client changes, which may in turn, lead to reluctance to embrace continuous management of the client’s requirements. The questions establish: if the practitioners feel that client changes rarely or commonly affect projects; the perceived effect late changes have on the project; and main concerns that come about as a result of these changes. When asked to comment on the frequency of client changes, answers ranged from: “We don't normally get major changes, as it's normally more of an evolving process.” to: “Pretty much all of our projects change as the project develops, especially the larger projects.” “The majority of projects are affected by changes at some stage. Most projects have one or two main changes and they all have numerous smaller changes.” It is apparent that in one form or another, the construction professionals have all experienced client change on projects. The definition of what constitutes a client change as opposed to design development is clearly subjective, and warrants further research.

Next the practitioners were asked to describe what effect late‐stage client changes have on a project. This question is intended to establish how the team view client changes – is the focus on meeting the latest client requirements, or is there a resistance to change? Typical responses were: "The completion date is the thing which is normally affected the most. The costs are also very likely to be impacted by late changes.” "Late changes don't enhance a project because they're rarely well thought through. You end up compromising the quality of the scheme.” “At a very late stage, changes are pretty detrimental and annoying, really.” “I try to put a client off the idea of making late changes, even if it's something they want ‐ because they have to understand the consequences. However two of the six practitioners did acknowledge the benefits that could be had by a client if the change is successfully implemented: "[Late changes] can lead to a much better project ‐ if the client allows more funds and makes last‐minute upgrades to scheme.” “It can be fine if the client is happy with the cost and programme implications ‐ you get a better product, and more work for the design team and contractor.” When pushed to specifically discuss if late changes have a positive or negative affect on projects, answers were mixed and all participants generally recognised that the final outcome could be positive or negative depending on the view point. It is accepted that if the client is pleased with the finished product, it must be good for the project: “If a client decides to have more money allocated on a reception area and finishes are upgraded, it could have a positive impact.” "If the client is happy then that reflects well on the project.” "[A negative outcome] is not always the case ‐ certain building types lend themselves to adaptation and changes.”

These positive comments are combined with descriptions of negative scenarios: “The trouble is, if [clients] make changes to save money, they can end up spending more in programme delays and other costs." “In terms of time and money, especially fees, the contractor tends to get paid for their changes, but the architect will carry the greatest loss due to client changes.” “I think late changes can be beneficial for aesthetics but not to cost or programme." The next question asks the practitioners to describe their concerns, if any, if the client’s needs change during the later design stages of a project. Concerns were regarding the management of changes and subsequent risks to the client e.g. of poor/rushed design coordination. “Things get rushed, especially services coordination and you end up with compromised designs. I worry that pressure will lead to things slipping through the net." Concerns regarding the ability to claim additional fees were noted on multiple occasions: “My main concern is normally the cost to the firm. By that I mean the time it will take to make the changes.” “If changes are not managed or recorded the client is at risk. It also puts the design team at risk of expending fees if the project strays from the original brief without clear documentation.” “If you get additional fees, the problem is much lessened, but generally architects don't ask for additional fees ‐ we try to be helpful and keep the client happy." Finally, and in anticipation of the potential concerns with claiming additional fees for late design changes, the practitioners were asked if they think it is difficult to claim for additional fees. The majority of responses recognise the importance of defining the brief at the start of the job, to be able to track changes and identify additional fees “Unless the brief is really clear at the start, it's hard to show the client what is ‘additional work’ and what is part of ‘design development’."

“We try to work on an hourly rate at RIBA Stages A&B help to focus the client's mind and encourage them to fix brief and stop looking at options." "Often the client finds it hard to understand why they should pay for additional fees. The client doesn't know where the boundary of design development ends, and when they are making changes which will require additional time.” “You need a clear definition of what is deemed a change vs. design development… It is very difficult to judge, that's why it's always good to try to limit or minimise change.” Clearly the practitioners have concerns regarding likelihood of being reimbursed for additional time spent responding to late changes in the clients requirements. This, combined with the other comments from this theme, supports the notion that architects and project managers are reluctant to promote the possibility of re‐evaluating the clients strategic requirements at later project stages. 3. Client practice in managing strategic requirements. This collection of questions is aimed at establishing when clients might typically review the strategic requirements for a project, and how easy it is to communicate changing requirements to the design team. The focus then turns specifically to later stages of projects, looking at the experience of communicating changes in the later stages of a project (detailed design/construction stages) and asking how often this might happen. The first question asks in which stages of a project the client typically reviews the strategic requirements. It is interesting to see that there is a definite push to establish the project requirements at the front end (prior to committing to the project): "A lot of work goes in to the proposed financing of a project, before it is even started ‐ establishing the viability of the scheme. Even so, there is also an ongoing (commercially driven) requirement to respond to the latest market conditions. Gateway reviews are carried out upon acquisition of a property, and again upon securing planning permission. “Gaining planning permission is a major hurdle as it takes a lot of risk out of the scheme. At this stage we decide whether to proceed with the scheme or to sell 'with permission'.” It seems that a certain degree of flexibility is required to ensure the finished product is perfectly positioned when delivered to the market for sale or letting:

“I would say it's an ongoing process, with a front‐end focus." “We are surprisingly happy to meander and make changes based on the latest market conditions.” “We need to be quite fluid in order to ensure we meet market expectations. These changes frequently lead to wasted time, money and materials but the short‐term losses should be covered by the long‐term commercial gains.” The need for this type of flexibility continues even when the project is on site: “At the construction stage we are delivering a product to the market, so we have to be constantly looking at the market ‐ balancing the specification ‐ we don't want to over specify or under specify.” It’s also apparent that the latest costs are reviewed as a key component of the overall project strategy: "At the pre‐acquisition phase we have an initial appraisal where we set up what we're trying to achieve, looking at projected costs and values, loan equity ratios, sources of equity and that sort of thing ‐ early stage stuff.” “A financial plan is drawn up and reviewed at key stages to ensure the numbers still stack up…. At pre‐construction stages, we ensure the scheme is still viable in current market conditions. At this point, maximum cost certainty is critical." Next, the clients are asked to describe when they feel most able to communicate their requirements to the project team. Perhaps unsurprisingly, there is a general consensus that the start of the project is the time when communicating with the team is easiest: "It's definitely easier to communicate to the team early on at concept stage.” "It's easier to discuss the project with the team at the beginning of the project because once things get very technical, it becomes harder to communicate with the team.” "At the beginning, when the team are asking for a brief of what is needed.”

“By the later stages the brief is pinned down and they're off ‐ the team want to know why you’re changing your mind and there can be some resistance.” It is also noted that the presentations held during earlier design stages also offer a good opportunity for discussing the client’s requirements: “Design reviews for the key stage reports like the [RIBA] Stage C and Stage D reports are a good opportunity to review each element of the project against the brief.” Focusing on the same theme, the clients were then asked to describe their experiences of communicating changes in their requirements at later stages in the project. Two clients reported meeting resistance when asking for late‐stage changes: “Sometimes you get resistance from the design team… But if we make a change, we're doing it for a commercial reason ‐ spending a pound now to make ten pounds in the future.” "Quite often there's a lack of effort from the design team at later stages if you need them to look at changes. There's the usual issue of additional fees, and a reluctance to spend time on 'options'.” “Project managers especially don't like changes because they're aiming to deliver the project on time and on budget, which they can often get fixated on." One client pointed out that the communication of the changes is not always the problem, but rather the execution: “It's usually OK communicating the need for the changes, but getting everything agreed and following through on the changes can be difficult." The clients were then questioned on the proportion of their projects where it has been necessary to make changes in their requirements in the later stages of the project lifecycle. The client responses were certainly less definitive than those given by the practitioners (that all projects experience changes). The client responses were generally more measured and suggested that changes were only made if essential (normally linked to a financial appraisal). They also implied that even if small changes occur on many projects, few projects are affected by wholesale change.

"Unless it's absolutely essential for the success of the scheme, we try to avoid the disruption of making too many changes.” "The initial brief is not normally changed. We try to stick with the original plans… in order to avoid additional costs." "To a degree [change] can happen on every project, but it's usually something relatively minor. We don't enjoy making changes for the sake of it, only if there's a valid commercial justification.” As mentioned previously the definition of what constitutes a change is highly subjective, but regardless of this there is a divergence in opinion between the clients and practitioners. 4. Client perception of design team responsiveness to changes in the brief. The final theme of questions investigates client perceptions of the design team’s responsiveness to changes made mid‐way through a project. The clients were generally positive about the performance of the design team in terms of speed of response. "A good design team will normally respond quickly and effectively because they want to get the change sorted and carry on to maintain programme.” "The Architects and Structural Engineers are generally quick to respond.” There is further evidence that the later stages of the project present a greater challenge in effecting change: “The later stages may take longer to get a change completed, maybe because the team is focusing on details and so the drawings take longer to change, compared to quick sketches at the start of the job." Concerns are also raised about the quality of response if rushed during later project stages: “[The design team] probably want to make sure they minimise additional time spent. However, this rushing can lead to missed communications.” One client emphasised that the ability of the team to respond effectively is reliant on a good management system.

“The performance of the team depends on systems in place to support them… we believe that you have to help them do the job they've been appointed to do.” In order to establish if there is a clear case for a collaborative approach to Requirements Management in construction, the clients were asked if feedback from the design team affects the strategic decisions on projects. Responses spanned from very collaborative: "You take feedback all the time. We always like to hear new ideas and we're looking for the best products out there." To fairly dismissive: "Consultants don't look at the jobs in terms of options for adding value. They sometimes come up with innovative technical solutions, but these don't really affect our commercial strategy for the project." "Feedback from the team generally is considered on a cost basis. It would have to be very major news to change the strategic brief." Finally, the clients were asked if they have any suggestions for the improvement of the briefing process and the management of the strategic requirements. Some focused on closer interaction between the various members of the project team: “I would like more involvement and a closer interaction between the client team and the project team.” "Making more effort to have meetings with all members of the team might help ‐ including all client stakeholders, especially at the start of the project to develop personal relationships.” There were also suggestions of systems and documents which could help to improve the briefing process: “We often have one or two key goals for a project, recorded in a statement ‐ making sure the team are always aware of this might help.” “Recording the key decisions would help to pin‐down the project stakeholders as well as the design team and show the stakeholders how they've changed the scheme."

"A system called BIM [Building Information Modelling] can help on larger projects as well as web‐based online resources which can help to communicate ideas.” One client suggested that the team should take a more proactive approach in questioning the brief: “You need a team of consultants who will help to test the brief, and recognise when it's appropriate to change it ‐ like adding an extra floor.” This approach would complement a networked project environment where the focus is on two way conversations, rather than passing information ‘Over the Wall’.

Summary of Findings of Primary Research The primary research has established opinions of practitioners in relation to current practice in managing the brief, along with Risk and Value Management in construction projects. It has also ascertained attitudes of the practitioners towards late‐stage client changes. Clients discussed their approach to reviewing their own strategic objectives, before going on to explain their perceptions of the responsiveness to requests for changes in later project stages. The interviews have highlighted that the architects and project managers all have a bias towards Risk Management when it comes to a ‘continuous’ development of a subject throughout a project’s lifecycle. Value Management is also practised as an ongoing element of project management albeit at less frequent intervals than Risk Management. It is interesting to note that in current practice Value Management, whilst well established in an academic environment, is much less widely used in it’s fullest sense. Whilst Value Engineering is often used around RIBA Stages F‐J, true whole‐life Value Management as defined by Jefferyes (2011) appears to be overlooked. When asked about their perception of late‐stage changes to the client brief, the most common concerns related to cost and programme implications, along with design coordination issues. The practitioners also generally concurred that the brief should be fixed or completed at an early stage. Problems agreeing supplementary fees for additional work were a key concern and an overt cause of reluctance to discuss changes to the brief in later project stages. Clients have suggested that whilst they try to keep away from making strategic changes (to avoid abortive costs), it is necessary to have the flexibility to respond to variations in the wider project environment, notably market demands. It was mentioned that abortive costs may be justifiable in the face of greater long‐term gains. Clients agreed that it is easier to communicate their needs to the design team at the start of the project; by the later project stages, the team were less open to discussing changes to strategic requirements. Most of the clients were generally happy with the responsiveness of the design team in terms of speed, however, questions were raised regarding the quality of coordination of late‐stage changes. When asked if feedback from the design team influences strategic decision making, the response was generally indifferent. This may be due to a historically reticent culture from the design team in relation to proposing ideas to the client which could materially impact the scheme after the detailed design has commenced.

Closer team integration was suggested by clients as a possible way to improve the briefing process. There was a suggestion that briefing discussions and subsequent amendments should be recorded to allow clear communication to all project stakeholders of historic decisions. Doing so would correlate closely with the processes of Requirements Management described by Hood et al (2008). One client also suggested that having an overt project goal would also help to communicate the highest level underlying purpose of the project, to everyone involved in the project. Having a ‘Mission Statement’ is common practice in enterprise and certainly has the potential to add value in construction projects.

Conclusions The following conclusions are drawn from the primary and secondary research, examining the management of client requirements in the UK construction industry. In current practice, communicating information relating to the client brief is a fragmented process, which normally ceases to evolve beyond the early design stages (RIBA Stage D). Clients need projects to be flexible and responsive to the latest market conditions, even during the later detailed design and construction stages. In this sense, it could be said that it more is important to ensure the brief is current than it is complete. Ensuring the end product meets with the most recent client requirements is critical to ensuring client satisfaction and therefore, it can be argued, project success. Establishing an ongoing review process of client requirements can help the clients to communicate changes in their requirements and improve the chance of completed projects delivering what is required. Viewing projects as a ‘network’ of relationships leads to better responsiveness to the wider project environment. It creates a project which is more conducive to the ongoing review of client requirements. The construction industry has proven that it can already deal with continuous management of key issues throughout the project lifecycle, as demonstrated in Risk Management and to a lesser extent, Value Management. If the construction industry can learn from the core principles of Requirements Management in systems engineering, it will gain benefits such as improved transparency, more structured change management and improved stakeholder engagement. Uncertainty regarding fee reimbursement leads design and management consultants to resist change. This is a barrier inherent to the industry, reinforced by the RIBA Outline plan of works, and needs to be overcome to achieve successful Requirements Management. A collaborative, well organised approach to Requirements Management would help to meet client needs whilst ensuring the design team can better define client changes and justify additional fees where appropriate. Removing ambiguity regarding additional fees should result in a more effective, conscientious response from the design team when tackling late‐stage changes.

Recommendations Based on the findings of the primary and secondary research, and on the conclusions drawn, five recommendations are suggested. The recommendations focus on implementing Requirements Management in construction to suit a ‘networked’ approach to the management of projects. They address the issues raised in this paper with an aim to improve the management of client requirements, with the ultimate goal of improving client satisfaction. The recommendations should be considered in the context of the poor economic climate, which is affecting the wider project environment of many UK construction developments. The market is highly competitive with lower profit margins, more competitive fee bidding and a greater focus on value. Clients need to ensure the projects they commission maximise profits by delivering precisely what the market requires. Consultants have reduced fee contingency for unforeseen circumstances. These environmental conditions create an even greater need for accurate and up‐to‐date management of client requirements throughout the project lifecycle. 1. Continuous review. A process of continuous review of client requirements should be established, starting with the initial brief and then continuing throughout the project lifecycle. The process should run in parallel with the detailed design development, but remain distinct in so far as it is focused on ‘strategic’ requirements rather than technical design details. Workshops or team meetings should be carried out at key project ‘gateways’ as illustrated in Diagram 6. The traditional project structure outlined in the RIBA Outline Plan of Works should be amended to include ongoing reviews of Risk, Value and Requirements.

Diagram 6 – A proposed briefing process with key‐stage reviews. 2. A structure for tracking changes to client requirements. A system for recording and monitoring client requirements is needed. A list of eight categories of client requirements is proposed by Chinyio et al (1998): Aesthetics; Economy; Functionality; Quality; Working relationships; Safety; Surprises (i.e. Lack of); and Time. Reducing surprises is implicit in the process of Requirements Management and relates to all categories. By absorbing Quality into Form and Function, and combining working relationships with safety under the term ‘Stewarding’, the categories can be simplified into the five headings shown in Text Box 4. The categories proposed are

a suggested framework and could be adapted to suit each project. The subheadings are intended to be changed as required to suit specific projects. Focus should be on solution‐neutral strategic requirements (Karama et al, 2002) rather than technical details. As was suggested during the interview research, a mission statement should be incorporated along with the above, allowing the team to track the overarching strategic objectives of the project. Also, as established by Chinyio et al (1998), each client will have their view as to which requirements are key priorities, so a ranking system is required. This can be subjective, as the main purpose is to aid communication to the team as to which items are critical to the success of the project. Category

Example sub‐headings

Economy

Initial (project) budget Lifetime (management) costs Requirements/conditions of funding

Programme

Design & Procurement deadlines Stakeholder dates (e.g. tenants) Whole life timescale (e.g. required lifespan of services installations)

Function

Accommodation requirements Scope and functionality Services and IT connections

Form

External image (corporate appearance) Quality of key spaces (e.g. board‐room)

Stewarding

Environmental responsibility (e.g. BREEAM, Low carbon technologies) Social

responsibility

(e.g.

working

relationships,

stakeholder

involvement, Health & Safety)

Text Box 4 – Suggested categories for Requirements Tracking Document. 3. A client requirement tracking document Using the categories of client requirements in Text Box 4, a tracking document is proposed with which to record and review the ongoing development of client strategic requirements throughout the project lifecycle. This tracker will focus specifically on the high‐level strategic needs of the client. It is not intended to be a comprehensive stand‐alone briefing document and should be developed in conjunction with more detailed project briefing documentation. The tracker should be used in conjunction with ‘strategy workshops’ at regular stages throughout the project lifecycle (Diagram 6), and be used to record the client’s strategic decision making and communicate this to the wider project team. Diagram 7 shows an extract from the proposed tracking document, a full version of which is located in Appendix C.

Diagram 7 – Extract from Proposed ‘Client Requirements Tracker’. Full version in Appendix C. 4. Collaborative relationships and close teamwork In order to promote a collaborative ongoing approach to Requirements Management in construction, periodic workshops should be attended by the client team, the project team and any other key stakeholders. The purpose of the workshops is to create a forum for the discussion of the original brief and ensure that the strategic requirements and proposed project deliverables are still aligned. The project team will be given the opportunity to report latest information to the client and key stakeholders. The client will be encouraged to review the strategic requirements recorded at the start of the project on the ‘Client Strategic Requirements Tracker’, and consider if each requirement is still current and applicable. Building on suggestions from the clients that the teams should be more closely integrated, ‘digital networks’ could be used to complement the workshops. These generally take the form of discussion forums, social networks (e.g. Linkedin) and digital messaging (e.g. Twitter). If implemented properly, these new forms of digital communication could offer a supplementary environment for ongoing discussion of the Client Strategic Requirements. 5. Reducing resistance to Requirements Management It has been established that a key barrier to Requirements Management in construction is the professional team’s belief that client changes result in additional work without adequate recourse to additional fees. To mitigate this problem, the tracking of changes in client requirements can be used to identify significant developments in scope which justify additional fees. In addition, definitions of Design Development versus Client Change should be established at the initial stages of a project. If

this increased transparency is combined with suitably quantified provisions within appointment documents and a clear and flexible fee pricing schedule, the design team will have increased reassurance that any additional work resulting from client change will be adequately reimbursed. This should result in less reluctance from the team to open‐up the briefing process into a collaborative discussion running for the full life of the project. It will also allow the client to take into account the cost of additional fees when making critical project decisions. Further research Those interested in pursuing further research into Requirements Management in construction could build on the findings of this study by investigating the following areas: 

Systems for analysing whether a change should be made in the client requirements, i.e. quantifying the decision.



Quantified research to establish a link between the successful implementation of Requirements Management and client satisfaction.



Defining what constitutes a client change vs. design development.

To commence the refinement of the Client Requirements Tracker, the example document in Appendix C was presented to a small focus group of professionally qualified practising project managers. Initial feedback is as follows: “You need to consider the cost and programme impact of each change – it would be nice to have a ‘value’ column and ‘number of weeks column’ next to each key stage review.” “It would be useful to see a diagram or process‐map, showing how this document fits into a project lifecycle along with the other documents like the Risk Register.” “I think this would be useful on larger projects, especially if you have multiple stakeholders. Although, it might be difficult getting a consensus from various stakeholders as to how the items are ranked.” Further progress could be achieved by completing case studies on the implementation of the Client Requirements Tracker. Also development of the weighting system used in the tracker, could allow quantitative ranking of the importance of each item, as per CRPM by Kamara et al (2002). Using a Requirements Management tracker in conjunction with regular workshops, effective digital communication, and appropriately structured appointment documents, a continuous process of Requirements Management can be achieved. This ongoing process will help to ensure that the brief is always current and responsive to the latest project environment. In turn, this will ensure that the

project delivers a product to the client with fewer surprises and with a greater alignment to the client’s latest strategic goals. The author proposes that this will increase the chances of client satisfaction, resulting in a greater chance of project success for all parties involved.

References Blyth, A. & Worthington, J. (2010) Managing the Brief for Better Design (Second Edition). Routledge, Oxon. Chinyio, E., Olomolaiye, P., Corbett, P. (1998) An evaluation of the project needs of UK building clients. International Journal of Project Management, 1998 pp 385‐391. Hood, C., Wiedemann, S., Fichtinger, S., Pautz, U. (2008) Requirements Management. Springer‐Verlag. Berlin. Jefferyes, M. (2011) Value Management, BENVGPM2. [Handout]. Handout for Value Management Session. Owner‐based Management of Projects. UCL, The Bartlett School of Construction & Project Management, London, 08 December 2011. Kelly, J., Morledge, R., Wilkinson, S. (2002) Best Value in Construction. Blackwell Publishing, Oxford. Kamara, J., Anumba C., Evbuomwan, N. (2002) Capturing client requirements in construction projects. Thomas Telford Publishing, London. Loosemoore M., Raftery, J., Reilly, C., Higgon, D. (2006) Risk Management in Projects. Taylor & Francis, Oxon. Luck, R. & McDonnell, J. (2006) Architect and user interaction: the spoken representation of form and functional meaning in early design conversations. Design Studies. 27, pp. 141‐146. Nutt, B. (1988) The Strategic Design of Buildings. Long Range Planning, 1988 Vol.21, No. 4, pp.130‐ 140. Othman, A., Hassan, T., Pasquire, C. (2004) Drivers for dynamic brief development in construction. Engineering, Construction and Architectural Management, Vol. 11 Iss: 4 pp. 248 – 258. Pryke, S. and Smyth, H. (2006) The Management of Complex Projects – a relationship approach. Blackwell Publishing Ltd. Oxford. RIBA (2007) Outline Plan of Work 2007 (Amended 2008). Royal Institute of British Architects, London.

Ryd, N. (2004) The design brief as carrier of client information during the construction process. Design Studies, 2004 pp. 231‐249. Smith, J., Kenley, R., Wyatt, R. (1998) Evaluating the client briefing problem: An exploratory study. Engineering, Construction and Architectural Management 1998 pp387‐398. Tzortzopoulos, P., Cooper, R., Chan, P., Kagiolou, M., (2006) Clients’ activities at the design front‐end. Design Studies, 2006 pp. 657‐683 Walker, A. (2008) Project Management in Construction (Fifth Edition). Blackwell. Oxford. Winch, G. (2010) Managing Construction Projects. Wiley‐Blackwell, Chichester.

AppendicesÂ

Appendix A – RIBA Plan of Works 2007

Amended November 2008

Outline Plan of Work 2007 The Outline Plan of Work organises the process of managing, and designing building projects and administering building contracts into a number of key Work Stages. The sequence or content of Work Stages may vary or they may overlap to suit the procurement method (see pages 2 and 3).

Preparation

RIBA Work Stages

Description of key tasks Identification of clientâ&#x20AC;&#x2122;s needs and objectives, business case and possible constraints on development.

Appraisal

Preparation of feasibility studies and assessment of options to enable the client to decide whether to proceed. Development of initial statement of requirements into the Design Brief by or on behalf of the client confirming key requirements and constraints. Identification of procurement method, procedures, organisational structure and range of consultants and others to be engaged for the project.

Design Brief

Implementation of Design Brief and preparation of additional data. C

Design

1 Business justification

2 Procurement strategy

Preparation of Concept Design including outline proposals for structural and building services systems, outline specifications and preliminary cost plan.

Concept

Review of procurement route.

OGC Gateways

Development of concept design to include structural and building services systems, updated outline specifications and cost plan.

Design Development

3A Design Brief and Concept Approval

Completion of Project Brief. Application for detailed planning permission.

Technical Design

Production Information

Preparation of technical design(s) and specifications, sufficient to co-ordinate components and elements of the project and information for statutory standards and construction safety.

Pre-Construction

Application for statutory approvals. F2

Tender Documentation

Tender Action

Preparation of production information in sufficient detail to enable a tender or tenders to be obtained. Preparation of further information for construction required under the building contract. Preparation and/or collation of tender documentation in sufficient detail to enable a tender or tenders to be obtained for the project. Identification and evaluation of potential contractors and/or specialists for the project. Obtaining and appraising tenders; submission of recommendations to the client.

Construction

Letting the building contract, appointing the contractor. J

Mobilisation

3C Investment decision

Issuing of information to the contractor. Arranging site hand over to the contractor.

Administration of the building contract to Practical Completion.

Construction to Practical Completion

Provision to the contractor of further Information as and when reasonably required. Review of information provided by contractors and specialists. L1

Use

3B Detailed Design Approval

Post Practical Completion

Administration of the building contract after Practical Completion and making final inspections.

4 Readiness for Service

L2 Assisting building user during initial occupation period. L3

Review of project performance in use.

The activities in italics may be moved to suit project requirements, ie: D Application for detailed planning approval; E Statutory standards and construction safety; F1 Application for statutory approvals; and F2 Further information for construction. G+H Invitation and appraisal of tenders

Royal Institute of British Architects

Page 1 of 3

5 Benefits evaluation

ÂŠ RIBA 2007

Appendix B – Transcribed Interviews

Consultant Interviews

Architect 1 Discuss what tools, systems and documents you use to manage risk on a project, and at which project stages. "We have an internal design risk register on every project. There is also usually a project risk register set up by the project manager, which tracks planning issues etc. This is normally the client's risk register as well showing things like client risks. Once we reach tender /contract stages, we normally add construction and contract issues." "In terms of timing, we get the risk register set up at the start of the project. It's developed through to planning. Once planning permission is received, it is removed from the register, although we might keep the discharge of conditions on it. The register stays in use then through to construction and going through site works." Discuss what tools, systems and documents you use to manage value on a project, and at which project stages. "Value Engineering is normally lead by the Project Manager. They hold workshops, or sometimes include a section for value engineering in the regular team meetings. We draw up a list of VE items for the quantity surveyor or contractor to price up." "We normally look at costs a the start of the project at a high level, then do value engineering at [RIBA] Stages E & F, after we have obtained planning permission. It depends on the complexity of the project. On more complex projects, we sometimes do more value engineering with the contractor on site, where they suggest cheaper or better materials or better ways of getting it built." Discuss what tools, systems and documents you use to manage the brief on a project, and at which project stages. "Getting the brief can be a bit of trial and error, a bit of a shot in the dark. We normally send one or two letters to the client. I think our office is in a rush to start work on the design and we don't spend that much time on the brief. I think a better way would be to sit down with the client and really define the scope of the at the start of the job. This would help to establish an accurate fee basis as well, so we can claim additional fees if the brief changes." "We send the letter to the client at the start of the job. It's a one‐off thing, so once it's sent it's fixed. Sometimes we need to change the brief and if we do we send an email to the client to record the change." What proportion of your project are affected by late‐stage clients changes? "Pretty much all of our projects change as the project develops, especially the larger projects. Although the changes can often be driven by the architects suggesting alternative options to the client." Generally speaking, what effects do late‐stage (i.e. RIBA Stages G‐K) client changes have on a project ? "A massive effect. [Late changes] can lead to a much better project ‐ if the client allows more funds and makes last‐minute upgrades to scheme. However, if the client cannot make decisions at a later stages, It can have a massive impact on programme (negative) and associated costs." On projects where clients have changed their minds in later stages, what proportion have a negative/positive affect on the project? "Overall it can often be a positive change. It depends on reasons for change. It can be caused by a commercial decision. The trouble is, if they make changes to save money, they can end up spending more in programme delays and other costs."

What are your main concerns, if any, if a client’s needs change during the later stages of the design process? "Changes without proper decisions are cause for concern. If changes are not managed or recorded the client is at risk. It also put's the design team at risk of expending fees if the project strays from the original brief without clear documentation. There is a blurry boundary between the natural development of the scheme and a client's changes to the project. It's something that's difficult to manage due to the subjective nature of design." Do you think it's difficult to claim additional fees to cover client changes. "We normally don't try to claim fees for changes unless it’s a really big change, like it needs a whole new planning application. Unless the brief is really clear at the start, it's hard to show the client what is additional work and what is part of design development."

Architect 2 Discuss what tools, systems and documents you use to manage risk on a project, and at which project stages. "Statutory regulations help to take the risk out of a project ‐ building control, health & safety. For other risks, we tend to use a basic risk register to track the risks. Client commercial risk is managed by design drawings and specifications." "Risk management is generally low priority for us, especially on smaller projects. Ongoing correspondence is used to communicate information on risks to the client throughout the project. We do have quite a large reliance on direct team communications, person‐to‐person, which is at design stage and also when we're on site." Discuss what tools, systems and documents you use to manage value on a project, and at which project stages. "The QS [Quantity Surveyor] often manages costs. We supplement the QS's work with value engineering by suggesting cheaper design options or products, which he will add to a cost schedule to allow the client to make a decision on which options to accept and which to reject. We get all project team members to sit around table and have a discussion. It can lead to a complete redesign. Once you've gone through the design and tendering process, you can work on the cost management with the contractor. A competitive tendering process helps to ensure costs are market rate and your NBS specifications and contract docs help to manage costs of variations on site." "Timing depends on the client. The budget is discussed at very early stages to manage expectations. The budget should be fixed and tends to go up only if the client starts making changes. The later the change is made, the more risk of additional costs." Discuss what tools, systems and documents you use to manage the brief on a project, and at which project stages. "I meet with the client and discuss the project. I then give the information back to them in a letter. It helps to do this because it lets the client know that 'this is what we're sticking to'. If the client changes the brief then the costs will go up. Communication is key ‐ if the client doesn't have enough money, everyone, especially the contractor, needs to know." "In terms of the stages we work on the brief, it's the Initial meeting at the start of the project. Our time generally spent in the first few weeks of a project. The brief is then fixed to avoid hundreds of variations." What proportion of your project are affected by late‐stage clients changes? "The majority of projects are affected by changes at some stage. Most projects have one or two main changes and they all have numerous smaller changes."

Generally speaking, what effects do late‐stage (i.e. RIBA Stages G‐K) client changes have on a project ? "The completion date is the thing which is normally affected the most. The costs are also very likely to be impacted by late changes ‐ contractors tend to charge a premium for late‐stage project changes. Late changes often seem to work out having a negative impact on the project." On projects where clients have changed their minds in later stages, what proportion have a negative/positive affect on the project? "If the client is happy then that reflects well on the project. In terms of time and money, especially fees, the contractor tends to get paid for their changes, but the architect will carry the greatest loss due to client changes. The hope is, that any loss is offset by future projects from a satisfied customer." What are your main concerns, if any, if a client’s needs change during the later stages of the design process? "My main concern is normally the cost to the firm. By that I mean the time it will take to make the changes. It can involve additional coordination with other team members, which of course uses up more of our time. If you get additional fees, the problem is much lessened, but generally architects don't like to ask for additional fees if it can be avoided ‐ we try to be helpful and keep the client happy." Do you think it's difficult to claim additional fees to cover client changes. "Yes, I think so. Especially with one‐off clients. They feel that they've already paid for your services. Some firms try to use a very tight spec at an early stage to 'sign the client up' at an early stage, then change for every change thereafter. Which is a nice idea in theory, but in practice, it's hard to define a design brief so specifically at such an early stage."

Architect 3 Discuss what tools, systems and documents you use to manage risk on a project, and at which project stages. "It depends on whether a project is notifiable or not, which they generally are so we normally end up following CDM regs. We don't always carry out formal risk management especially on smaller projects, but we do ensure that the client is aware of any big risks as they arise. Our clients are normally most concerned with risks against the finance of a scheme, so we use a spreadsheet with each risk main risk listed with a possible cost impact against it." "If we are formalising the risks, like on a bigger project, the spreadsheet is given to client as soon as possible. It's not a one‐off discussion, the list gets added to; things come off the list when the risk has gone, and new items are added on, so the document carries on changing ‐it grows with the project. We add risks from the contractor once we have reached the construction stage." Discuss what tools, systems and documents you use to manage value on a project, and at which project stages. "We normally appoint a QS [Quantity Surveyor] to deal with cost control and value engineering. The QS will be asked to prepare a detailed spreadsheet of costs. We then use it to analyse the overall cost breakdown and we look for highs and lows. When the project is design is completed, we sometimes look at the costs in more detail. Once a contractor is on board, we look [at costs] with the contractor. At that stage we look for cheaper alternatives products." "The timing of value engineering normally depends on how important cost is to client, and the complexity of design. We might have a one‐to‐one meeting during detailed design, discussing where to best spend the money. We often have an internal post‐completion review of the costs to help understand what the latest costs are like to benefit future projects. "

Discuss what tools, systems and documents you use to manage the brief on a project, and at which project stages. "Well, first off we normally have an initial meeting with client, with us taking notes. When we get back to the office, the notes are formalised into a into a written brief which takes the form of a letter to client, confirming requirements. This doesn't show serious amounts of detail, but it does outline their general requirements, like confirming what accommodation is needed. Sometimes, on more complex projects, we produce an outline scope of work which accompanies the letter, adding supplemental detail. The letter is used to record client decisions and it's important to include all requirements at the start. We make sure the brief is all recorded and completed prior detailed design and construction. I think when the specifications and design work are presented to the client it confirms the brief back to them, but really that's to focus on the details of how we're going to build it and how it will look." What proportion of your project are affected by late‐stage clients changes? "It's not something that happens too often. We don't normally get major changes, as it's normally more of an evolving process, which we call 'Scope creep'. It's easy for the client to add to scope without realising what the cost increases will be." Generally speaking, what effects do late‐stage (i.e. RIBA Stages G‐K) client changes have on a project ? "It's the programme that goes out the window first, especially on large changes. We try to ensure the client is made aware of any likely serious budget and programme implications before making any decisions, so that we know the client's sure this is what he wants. We have these discussions about cost & programme with contractor as well as the client. Then we try to work out how long it will take to make a change and see if additional fees can be charged to cover out additional work. At a very late stage, changes are pretty detrimental and annoying, really. I try to put a client off the idea of making late changes, even if it's something they want ‐ because they have to understand the consequences." On projects where clients have changed their minds in later stages, what proportion have a negative/positive affect on the project? "It's hard to say in a if it's positive or negative, it could go either way. I mean, if a client has made a late addition of an extra room, and the services are exposed and it can look bad. Or, if a client decides to have more money allocated on a reception area and finishes are upgraded, it could have a positive impact. I think late changes can be beneficial for aesthetics but not to cost or programme." What are your main concerns, if any, if a client’s needs change during the later stages of the design process? "My concerns are to do with coordination ‐ if changes are made on site, there is a pressure to get revised information out, and high pressure to minimise the impact on programme. Things get rushed, especially services coordination and you end up with compromised designs. I worry that pressure will lead to things slipping through the net." Do you think it's difficult to claim additional fees to cover client changes. "Often the client finds it hard to understand why they should pay for additional fees. The client doesn't know where the boundary of design development ends, and when they are making changes which will require additional time. We try to work on an hourly rate at RIBA Stages A&B help to focus the client's mind and encourage them to fix brief and stop looking at options."

Project Manager 1 Discuss what tools, systems and documents you use to manage risk on a project, and at which project stages. "I guess it’s a case of using a risk register properly and constantly reviewing. You do this with an outline programme, keeping it up to date. Also holding regular meetings helps. I look at project risks

from the very first stage. We start with risks like making sure the brief is agreed and that professional appointments terms are agreed. Then we move on to agreeing finishes with agents. The process carries on going through out the project onto site." Discuss what tools, systems and documents you use to manage value on a project, and at which project stages. "I tend to look at costs and value from as soon as you've done an initial budget cost plan. We then use cost options in the specification so that we can value engineer the costs down once the tenders are back if we need to. Value engineering updates are picked up in the regular project reports. We continue to look and costs closely all the way through on site, look ing at getting best value for the client." Discuss what tools, systems and documents you use to manage the brief on a project, and at which project stages. "I try to meet with the client on site, and walk the site, discussing what's required. Then the cost plan is prepared and agreed and the brief gets made rock‐solid, well, 99% fixed, before the design starts. It comes down to managing the clients expectations and learning what each client wants. I'm a believer that once the brief is set, you should be able to change it if the design team or client wants to change it. The down‐side with changing the brief is that the client has to 'put their hand in their pocket'. I don't think you can ever have a 100% fixed brief because things always turn up that you don't expect." What proportion of your project are affected by late‐stage clients changes? "Probably only 25% or so of projects ‐ it's fairly low in terms of changes from the client. I think changes often come from the project team, through things like a lack of investigations, or finding unforeseen problems on site." Generally speaking, what effects do late‐stage (i.e. RIBA Stages G‐K) client changes have on a project ? "It depends on the change. It can have huge implications or it can be quite easy to accommodate. If it can be accommodated in programme and budget then there's often very little effect on the project. Quite often there's a big impact on cost, especially because it costs more to put things in at a late stage than at an early stage. It can be fine if the client is happy with the cost and programme implications ‐ you get a better product, and more work for the design team and contractor." On projects where clients have changed their minds in later stages, what proportion have a negative/positive affect on the project? "It's mostly positive for the design team, if they get paid. Sometimes clients make changes and expect the designers to pick up the bill. Client's are happy if the change doesn't cost too much, if they're given realistic timescales. If there are no surprises, its mostly a positive effect on the project." What are your main concerns, if any, if a client’s needs change during the later stages of the design process? "I guess, it's external factors. The changes might have a knock‐on effect on programme which causes a problem for someone beyond the project team, like a long‐stop date for lease. Clients need to understand all of the knock‐on consequences. The client has to know the costs and timescales and make an informed, coordinated decision. As long as the client is happy with the additional costs, it doesn't really matter." Do you think it's difficult to claim additional fees to cover client changes. "I think it is difficult in this market, a few years ago it was easier. Now the client expects you to work for nothing. Smaller companies tend to do additional work for free. Larger firms trade on their names and have fixed policies on additional fees which clients have to accept. At the moment you just want to keep existing clients happy. I try to resist sub‐consultant requests for additional fees where possible. It comes up a lot on projects. It's never clear cut as to what should have additional fees, some changes are due to mistakes by the professional team ‐ like the architect makes a mistake which leads to additional fees for the M&E engineer."

Project Manager 2 Discuss what tools, systems and documents you use to manage risk on a project, and at which project stages. "There's the project risk register, which everyone has to input into at the first stage, and a CDM register. They're circulated by email at each key design stage and carry on onto site with any live risks. We update the register and rate the risks in terms of probability and impact." Discuss what tools, systems and documents you use to manage value on a project, and at which project stages. "Very important as part of the briefing process that the architect understands the value of the items they design with. Value engineering is a it of a nightmare, so we try to get it right at the start. Cost plan at stage C, reviewing costs begins. Very much an ongoing checking‐process, looking back at the bench‐mark original cost plan. Procurement method affects later stages of cost management." Discuss what tools, systems and documents you use to manage the brief on a project, and at which project stages. "We use a written document and a schedule document, the two documents are developed together, with the written document giving an overview, and the schedule adding detail. Lots of things get forgotten about so we check design work back against the original schedule." What proportion of your project are affected by late‐stage clients changes? "All of them. I cant remember a project that I've worked on that hasn't changed. They aren't all major changes, but most projects end up slightly different to how we had initially planned. They also quite often end up taking longer and costing more than anticipated due to client changes." Generally speaking, what effects do late‐stage (i.e. RIBA Stages G‐K) client changes have on a project ? "Nearly always changes will increase the programme and budget. Many of our less experienced clients don't understand change. If it's not on site, they don’t understand why changes have such an impact on programme and they can't always see why they should pay additional fees for changes in the design. Once on site, if you're not careful, late changes to save money like going to plastic fittings from stainless steel could end up costing more due to redundant purchases and re‐stocking charges." On projects where clients have changed their minds in later stages, what proportion have a negative/positive affect on the project? "Probably negative. There's increased costs; delays; stress, hassle and logistical problems for the team. Although if the client is happy and you can secure repeat business it can be OK." What are your main concerns, if any, if a client’s needs change during the later stages of the design process? "My main concerns are about the 'unknowns'. We can redesign and recost late changes but there could be unforeseen design coordination issues ‐ hidden problems. Quality checking goes out the window if changes get rushed through." Do you think it's difficult to claim additional fees to cover client changes. "Yes ‐ very. Which is why it's so important to always negotiate good appointment terms that at the start. You need a mechanism for managing changing scope and fees ‐ like applying an agreed percentage to the scheme and agreeing hourly rates to cover time spent on client changes."

Project Manager 3 Discuss what tools, systems and documents you use to manage risk on a project, and at which project stages. "We look at design responsibility and scope of services. We sit down at appointment stage, work up a clear scope of services, and look at where risks are. We tend to focus on design risks, with the client picking up financial risks. We're constantly reviewing, responsibilities, and appointment terms." Discuss what tools, systems and documents you use to manage value on a project, and at which project stages. "We normally put together a design intent drawing and get feedback from the QS. We tend to start quite late on in a project, which can be frustrating. , focus on value gets worried about at a late stage when the detailed design is nearly completed. We then update drawings with VE." Discuss what tools, systems and documents you use to manage the brief on a project, and at which project stages. "We normally prepare a written brief with the client at an early stage. Sometimes we have Employers Requirements on some D&B projects. Less experienced clients require a lot more handholding and consulting ‐ exploring what they need." What proportion of your project are affected by late‐stage clients changes? "Quite a lot. It tends to be a long period through design and planning processes so you do tend to get changes over this time. Which costs money but it has to be fit for purpose ‐ we quite often get asked to add more accommodation." Generally speaking, what effects do late‐stage (i.e. RIBA Stages G‐K) client changes have on a project ? "Late‐changes don't enhance a project because they're rarely well thought through. You end up compromising the quality of the scheme. This may be OK with the client but there will be compromise to the design." On projects where clients have changed their minds in later stages, what proportion have a negative/positive affect on the project? "A high proportion are negative because it's an after‐thought. Having said that, it's not always the case ‐ certain building types lend themselves to adaptation and changes ‐ when you've got large sprawling footprints with plenty of space, there's room to bolt on additional bits." What are your main concerns, if any, if a client’s needs change during the later stages of the design process? "Planning is always an issue. Certainly programme is always a concern but financial impact is less of a concern, because if it’s a change to the brief you can charge additional fees which means more money coming into the office ‐ as long as it’s clearly a change to the original scope." Do you think it's difficult to claim additional fees to cover client changes. "Not if you set it out very early on, on what basis change will be defined. You need a clear definition of what is deemed a change vs. design development. There's always a grey area between the two. Design is subjective, but we try to define change as: if you have already produced design information and you're then asked to change, then it counts; if you haven't produced information, it can be design development. It is very difficult to judge, that's why it's always good to try to limit or minimise change. The change procedure has to be quite vigorous with fees agreed before the change is carried out."

Client Interviews

Client 1 Describe the stages in a typical project which you review the high‐level 'strategic' project objectives: "Management of our strategic decisions on a project is less process driven than you might expect. As an organisation, we spend less time on actively managing strategic objectives and we are surprisingly happy to meander and make changes based on the latest market conditions. Some changes be frustrating for some members of our internal team and also, I think, for our consultant teams. We need to be quite fluid in order to ensure we meet market expectations. These changes frequently lead to wasted time, money and materials but the short‐term losses should be covered by the long‐term commercial gains." Describe at which stages in a typical project you feel that you are most able to communicate your requirements to the design team: "It's definitely easier to communicate to the team early on at concept stage. I used to think that one‐ stop D&B contracts should make it easier to communicate with the contractor at later stages, but in reality they are the same as traditional contracts." How would you describe your experience of communicating changes in your requirements during later stages of a project? Would you say its easy/simple or difficult/ complicated? "You can get the feeling that their heart's not in it. Quite often there's a lack of effort from the design team at later stages if you need them to look at changes. There's the usual issue of additional fees, and a reluctance to spend time on 'options'. I think it's probably to do with a lack of resourcing. At the start of the project you get the partners and lots of time spent on the design. Once you're in construction the fees run low due to front loading and the partners attend meetings less, meaning your left dealing with more junior less experienced staff." On what proportion of your projects has it been necessary to alter the initial brief, in the later stages of the project? "Unless it's absolutely essential for the success of the scheme, we try to avoid the disruption of making too many changes, so It more often that we make more small changes. We rarely make whole‐sale changes." How do you rate the performance of design teams in responding to changing client requirements mid‐way through a project, for example, Quickly/slowly Effectively/ineffectively? "Consultants are more responsive than contractors. Contractors will agree to make changes but they are reluctant and they add disproportionate costs." How often does feedback from the design team or construction team affect the strategic decisions on a project? "Consultants don't look at the jobs in terms of options for adding value. They sometimes come up with innovative technical solutions, but these don't really affect our commercial strategy for the project." If you have any comments or suggestions regarding the improvement of the briefing process or communication of strategic client requirements, please describe now. "As a client, I would like more involvement and a closer interaction between the client team and the project team. It's currently quite disjointed because the client team changes their mind, which is fine, but the design team struggle to keep up. Ongoing, closer communication with the design team would help. We often have one or two key goals for a project, recorded in a statement ‐ making sure the team are always aware of this might help. Recording the key decisions would help to pin‐down the project stakeholders as well as the design team and show the stakeholders how they've changed the scheme."

Client 2 Describe the stages in a typical project which you review the high‐level 'strategic' project objectives: "It's mainly at the early stages, with an ongoing review process looking at design and costs, so I would say it's an ongoing process, with a front‐end focus." Describe at which stages in a typical project you feel that you are most able to communicate your requirements to the design team: "It's easier to discuss the project with the team at the beginning of the project because once things get very technical, it becomes harder to communicate with the team. They get focused on details and they can get bogged down with lots of technical jargon. The seem less interested in re‐visiting the high level principals once they've started focusing on detailed design. Once on site it gets too expensive to make any big changes on our projects. We would carry in house cost based analysis before making any decisions." How would you describe your experience of communicating changes in your requirements during later stages of a project? Would you say its easy/simple or difficult/ complicated? "We normally talk things through with the design team. Small changes should be absorbed into the design development process. Although, it can lead to fee discussions if we need the design team to look at options at the later stages. They get committed to their designs and are normally reluctant to change them." On what proportion of your projects has it been necessary to alter the initial brief, in the later stages of the project? "The initial brief is not normally changed. We try to stick with the original plans (especially after planning approvals) in order to avoid additional costs." How do you rate the performance of design teams in responding to changing client requirements mid‐way through a project, for example, Quickly/slowly Effectively/ineffectively? "The Architects and Structural Engineers are generally quick to respond. Not so much with the mechanical engineers! The later stages may take longer to get a change completed, maybe because the team is focusing on details and so the drawings take longer to change, compared to quick sketches at the start of the job." How often does feedback from the design team or construction team affect the strategic decisions on a project? "Feedback from the team generally is considered on a cost basis. It would have to be very major news to change the strategic brief." If you have any comments or suggestions regarding the improvement of the briefing process or communication of strategic client requirements, please describe now. "Making more effort to have meetings with all members of the team might help ‐ including all client stakeholders. Especially at the start of the project to develop personal relationships and encourage effective teamwork, allowing the team to understand the client dynamic and visa versa."

Client 3 Describe the stages in a typical project which you review the high‐level 'strategic' project objectives: "A lot of work goes in to the proposed financing of a project, before it is even started ‐ establishing the viability of the scheme. A financial plan is drawn up and reviewed at key stages to ensure the numbers still stack up. Once a project is up and running, we review our budgets against the QS's

[quantity surveyor's] cost plan. Then, at pre‐construction stages, we ensure the scheme is still viable in current market conditions. At this point, maximum cost certainty is critical." Describe at which stages in a typical project you feel that you are most able to communicate your requirements to the design team: "At the beginning, when the team are asking for a brief of what is needed. Also, design reviews for the key stage reports like the stage C and stage D reports are a good opportunity to review each element of the project against the brief. Although, these tend to be focused on detail rather than any strategic goals. Making changes becomes harder work at later stages, Architects like to wind‐down design reviews, but I like to keep and active involvement." How would you describe your experience of communicating changes in your requirements during later stages of a project? Would you say its easy/simple or difficult/ complicated? "If new information feeds into a scheme, like market expectations change, and requires late changes, it can be challenging. It depends on the depends on the team I've had some good experiences and some that were not so good. It's usually OK communicating the need for the changes, but getting everything agreed and following through on the changes can be difficult." On what proportion of your projects has it been necessary to alter the initial brief, in the later stages of the project? "I guess around 10‐15% require a change in strategy. It depends: if you have very changeable market conditions and longer projects, things are more likely to change. It's dependant on individual projects. We sometimes have an in‐house review meeting to confirm if a change in strategy is necessary before discussing with design team." How do you rate the performance of design teams in responding to changing client requirements mid‐way through a project, for example, Quickly/slowly Effectively/ineffectively? "A good design team will normally respond quickly and effectively because they want to get the change sorted and carry on to maintain programme. They Probably want to make sure they minimise additional time spent. However, this rushing can lead to missed communications and stuff. So we quite often have additional reviews to check that we're all singing off the same hymn sheet. How often does feedback from the design team or construction team affect the strategic decisions on a project? "The contractors should feedback information, but they often don’t. Design and Build contractors seem to be more willing to come up with new products and stuff, if it can save some money. Traditional contractors prefer to stick to 'tried and tested methods' and avoid feeding back information which may lead to changes. If you have any comments or suggestions regarding the improvement of the briefing process or communication of strategic client requirements, please describe now. "A system called BIM can help on larger projects as well as web‐based online resources which can help to communicate ideas. Although I think these tend to be used for more detailed requirements rather than strategic."

Client 4 Describe the stages in a typical project which you review the high‐level 'strategic' project objectives: "At the Pre‐acquisition phase we have an initial appraisal where we set up what we're trying to achieve, looking at projected costs and values, loan equity ratios, sources of equity and that sort of thing ‐ early state stuff. We re‐assess on acquisition because then the fixed costs are known ‐ the purchase price and buying costs. Gaining planning permission is a major hurdle as it takes a lot of risk out of the scheme. At his stage we decide whether to proceed with the scheme or to sell 'with

permission'. We narrow down our options. At the construction stage we are delivering a product to the market, so we have to be constantly looking at the market ‐ balancing the specification ‐ we don't want to over specify or under specify. Speaking to the agents at the start is important and they continue to have input throughout the design stages." Describe at which stages in a typical project you feel that you are most able to communicate your requirements to the design team: "Often initial concepts designs are done in house, so it's very simple to discuss with them what we need. On many projects, they already know what we're going to need. On the smallest projects, we only appoint an architect to get us to Stage C‐D. At the early stages ideas are up in the air, it's easy to pick them. By the later stages the brief is pinned down and they're off ‐ the team want to know why your changing your mind and there can be some resistance." How would you describe your experience of communicating changes in your requirements during later stages of a project? Would you say its easy/simple or difficult/ complicated? "If something needs changing it has to be done. Sometimes you get resistance from the design team. You also get resistance from the supply chain and contractor, like if samples have already been made up. But if we make a change, we're doing it for a commercial reason ‐ spending a pound now to make ten pounds in the future. Project managers especially don't like changes because they're aiming to deliver the project on time and on budget, which they can often get fixated on." On what proportion of your projects has it been necessary to alter the initial brief, in the later stages of the project? "To a degree it [change] can happen on every project, but it's usually something relatively minor. We don't enjoy making changes for the sake of it, only if there's a valid commercial justification. We try to maximise delay in making decisions on things like finishes to as late as possible ‐this maximises the chance of matching to market. Bigger changes are normally due to pre‐lets & selling off‐plan for example, not finishing a scheme, stopping at shell & core." How do you rate the performance of design teams in responding to changing client requirements mid‐way through a project, for example, Quickly/slowly Effectively/ineffectively? "The big difference can be made in how the team is structured and managed. You need a good change control system run by the architect. We had a recent project on site with no change control, and it was utter chaos ‐ with a big affect on finishes and design. The performance of the team depends on systems in place to support them ‐ If there's no system, it doesn't help the design team to respond. We believe that you have to help them do the job they've been appointed to do. Get the right team of consultants and the right systems, if you do this, they perform very well." How often does feedback from the design team or construction team affect the strategic decisions on a project? "You take feedback all the time. We always like to hear new ideas and we're looking for the best products out there." If you have any comments or suggestions regarding the improvement of the briefing process or communication of strategic client requirements, please describe now. "We don't always know what we want at the point of appointing designers. You a team of consultants who will help to test the brief, and recognise when it's appropriate to change it ‐ like adding an extra floor. Some people just want to take a fixed brief and design to it, rather than challenge the brief and work with us to develop it."

Appendix C – Proposed Client Requirements Tracker

Client Requirements Tracker Project:

Example CAT‐A Office Refurbishment. Insert address, City, Postcode

Importance as of

Stage 1 Review

Revision/Date:

Revision 4, 12/5/2012

14/02/2012

05/05/2011

12/07/2011

10/11/2011

14/02/2012

tbc

Pre‐Design RIBA Stage A/B

Concept Design RIBA Stage C

Design Development RIBA Stage D

Detailed Design RIBA Stage E

Construction Information RIBA Stage F/G/H

Construction RIBA Stage J/K

Post Construction RIBA Stage L

Occupation

High

Renovate 15,000sqft of central London office space and return to market with full occupancy. Rental at £45/sqft.

Renovate 15,000sqft of central London office space and return to market in 2018 with full occupancy. Rental at £55/sqft.

Renovate 15,000sqft of central London office space incorporating requirements of incoming tenants Smith & Long LLP, where financially viable.

High

£3‐4million achieved.

Document Date:

05/05/2011

Mission

Project mission statement

Economy

Initial (project) budget Lifetime (management) costs

Low

subject

Stage 2 Review

NIA £3‐4 million achieved.

Funding secured with Capital as JV partners.

Medium

Programme

Stakeholder dates (e.g. tenants)

Function

50 years on building fabric. 25 years on services.

Medium

50 years on building fabric. 25 years on services.

Quality of key spaces (e.g. board‐room) Medium

Medium

Social responsibility (e.g. stakeholder involvement)

Min. 15,500 sqft NIA of newly refurbished office space. Refitted reception & WCs. Funding partners have requested additional floor space and roof terrace to be added at roof level. Pre‐let tenants requires Gym facilities in basement.

Future‐proof communications. Future‐proof communications. Future‐proof communications. Full air conditioning required. Full air conditioning required. Full air conditioning required. Pre‐let tenant requires fibre‐optic connections for video conferencing with New York & Boston offices.

Future‐proof communications. Full air conditioning required. Pre‐let tenant requires fibre‐optic connections for video conferencing with New York & Boston offices.

Office space

Pre‐let secured with Smith & Long Pre‐let secured with Smith & Long LLP law‐firm. LLP law‐firm.

Exterior to be updated to Exterior to be updated to Exterior to be updated to Exterior to be updated to compete with new‐build office compete with new‐build office compete with new‐build office compete with new‐build office spaces within the area. Pre‐let spaces within the area. spaces within the area. spaces within the area. tenants require external signage.

Reception & WCs to be clean & Reception & WCs to be high‐end Reception & WCs to be high‐end bright. Mid‐high range quality. with a sense of permanence with a sense of permanence. White and navy‐blue colour scheme desirable for pre‐let tenants.

Medium

Reception & WCs to be high‐end with a sense of permanence. White and navy‐blue colour scheme desirable for pre‐let tenants.

Project to be designed to be safe Project to be designed to be safe Project to be designed to be safe Project to be designed to be safe to construct & maintain. to construct & maintain. to construct & maintain. to construct & maintain. No external stakeholders.

Funding partners stakeholders.

Improved EPC desirable. SKA assessment desirable but not essential. One or two items of obvious 'green' elements would be beneficial for marketing.

Improved EPC desirable. SKA SKA assessment essential. EPC 'B' SKA assessment essential. EPC 'B' assessment desirable but not rating minimum desirable. Cycle rating minimum desirable. Cycle storage & showers required. essential. One or two items of storage & showers required. obvious 'green' elements would be beneficial for marketing.

Medium Environmental responsibility (e.g. BREEAM, Low carbon technologies)

date

Min. 15,500 sqft NIA of newly Min. 15,500 sqft NIA of newly refurbished office space. Refitted refurbished office space. Refitted reception & WCs. Funding reception & WCs. partners have requested additional floor space and roof terrace to be added at roof level.

Office space

High

50 years on building fabric. 25 years on services.

Pre‐let tenants required move‐in Pre‐let tenant move‐in date is end‐June 2013. confirmed as 27/06/2013.

Medium

External image (corporate appearance)

Health & Safety (CDM‐C)

50 years on building fabric. 25 years on services.

High

Services and IT connections

Stewarding

Jones JV Partners require 2‐stage D&B JV Partners require 2‐stage D&B contract with 80% cost certainty contract with 80% cost certainty prior to start on site. prior to start on site.

Low

High

Form

NIA £4‐4.5million project budget £4‐4.5million project budget including contingency & fees. including contingency & fees.

Project to start on site by mid Project to start on site by mid Planning application for roof Planning application for roof 2012 & complete early 2013. 2012 & complete early 2013. terrace required. Start on site late terrace required. Start on site late 2012, complete May 2013. 2012, complete May 2013.

Accommodation requirements

Function of building occupants

Stage 5 Review

High

Key Design & Procurement deadlines

Whole life timescale (e.g. required lifespan of services installations)

Stage 4 Review

Asset to be sold on completion, New strategy agreed with equity Pre‐let tenant requires evidence Pre‐let tenant requires evidence lifetime costs low priority but partner to let property for 5 years of steps taken to reduce life‐time of steps taken to reduce life‐time costs. costs. must past purchasers due before selling. diligence. To be confirmed.

Requirements/conditions of funding

subject

Stage 3 Review

are

key Funding partners and pre‐let Funding partners and pre‐let tenants are key stakeholders. tenants are key stakeholders.

Stage 6 Review

Stage 7 Review

Stage 8 Review