Chapter 2: Creating the Project Brief
1.1 A project brief formally defines the client/user's requirements and objectives, in sufficient detail to enable the proposed facility to be designed and specified. Creating a project brief is one of the most important responsibilities of a client. It is developed over a period of time, starting as a statement of need which develops into a strategic brief and finally into the project brief. A good brief ensures clarity for the design team, other consultants and the contractors and creates a sound foundation for the successful delivery of the construction element of the project. The brief is separate from the business case, but is developed in parallel to it and is both informed by and informs the business case development.
2.1 There are three stages to the creation of the project brief - these are shown below and coincide loosely with the four stages of the development of the Full Business Case. The relationship between the development of the project brief and the evolution of the business case varies according to the complexity and scale of the project. Figure 1, below, illustrates the typical relationship when developing both the project brief and business case.
Figure 1: Project Brief and Business Case Development
3.1 The brief, regardless of stage, belongs to the client and is the specific responsibility of the Project Sponsor. It is likely that the project sponsor will be assisted in this work by the client adviser and the design team as they come on-board. However, it is imperative that the brief sets out the client's requirements and not the design team or client adviser's view or interpretation of the client's requirements.
4.1 Whilst the process of developing the brief is important, it must be proportionate to the scale and complexity of the project. Some small, low risk and low value projects will not require the same degree of briefing as others. In these cases, a brief may be based on an established design or perhaps performance specifications. For major and more complex construction projects, the briefing process is likely to be more detailed and will be developed and tested through various iterations until it is finalised.
4.2 It must be understood that the Project Brief is not simply for use at the inception of the project, but is a live document that should be referred to throughout, as it provides a benchmark against which project delivery and success can be measured.
5.1 The strategic brief or statement of need/requirement is the first stage in the development of the project brief, although at this stage there may not actually be a project which has been formally approved. It provides sufficient information to assist the appointment of the early client team and to obtain agreement and buy in from key stakeholders, not least the end users. It is developed loosely in parallel to the Strategic Outline Business Case and is a high level statement which may include the following key pieces of information:
- A description of the need identified by the client
- How the need contributes to the client's corporate strategy
- High level options for satisfying the need
- Specific requirements
- A description of the client and its business
- How the need relates to existing and future provision
- Assumed budgets
- Assumed programme
- Likelihood of change
6.1 The initial brief takes the briefing process a step further, building on the strategic brief and begins to shape the detail of exactly what the project will deliver and how it will be delivered. It will involve wide engagement of stakeholders and research of similar facilities and lessons learned from other projects and will include an analysis of the options available unless a separate options appraisal is to be undertaken. The following sets out some of the areas which the strategic brief may cover:
- The client organisation and context, vision and aims of the project
- Project philosophy including quality standards and management
- Stakeholders and relationships
- Existing facilities
- Information about site or options for site
- Design approach
- Functional requirements
- Technical requirements
- Statutory requirements
- Relevant policy statements and guidance, for example: Scottish Government, Creating Places: A policy Statement on architecture and place for Scotland
- Sizes, outline room data and adjacencies
- Building Information Modelling, quality standards and design quality indicators
- Environmental and sustainability standards including British Research Establishment Environmental Assessment Method (BREEAM)
- Known constraints including physical, operational and planning
- Whole life costing and management
- Procurement strategy assumptions
- Security and information handling
- Health and safety and the Construction (Design and Management Regulations) 2015
- Transport planning
- Programme including phasing, milestones and critical activities
- Related projects
- Project management procedures
- As built quality assurance procedures
6.2 This list is not exhaustive, neither is it prescriptive. What is included will depend on the project at hand. Neither will it necessarily be the case that all this information will be available at one fell swoop. Therefore, it is likely that each brief will be built up in layers. It is important that the brief identifies all areas where the design advisor and the client want to set the standards of performance, appearance and design quality or specify particular items which must be provided. Early briefing and project definition take time and should not be rushed, as they are an early and essential investment in the assurance of successful project delivery.
7.1 This is the final iteration and follows on from the strategic brief. Whilst it can be revised as appropriate, revision should be minimised as the brief is used by the design team to develop the detailed design. The full project brief may cover the following areas as appropriate (these are indicative rather than definitive and are not comprehensive):
- The Client - organisational and project management structures, vision, mission and purpose, relevant policies, other allied projects and programmes, assurance and audit, client requirements such as sustainability, design quality and principles etc.
- Site Information - any constraints or requirements associated with the site.
- Functional requirements - adjacencies, accommodation schedules, user numbers and breakdown, specialist areas.
- Technical requirements - flexibility, Information and Communication Technology (ICT), services, performance, whole life management, facilities management, security, sustainability and energy use targets, waste and water management.
- Project requirements - information handling and security, project execution, procurement strategy, consultation, budget, risk, programme, change control, commissioning, quality control and inspection, use of clerks of works or resident engineers, handover and post occupation evaluation.
7.2 The project brief will become increasingly detailed throughout its life and the concept design stages and may ultimately include very specific information, such as room data information. The project brief should always reflect the requirements of the client, not what the design team has assumed or taken it upon itself to decide what the client wants. It should be frozen at the end of the concept design stage and a change control system introduced to prevent unjustified change without authorisation.
Building Information Modelling
8.1 On projects which utilise Building Information Modelling (BIM), the employer's information requirements may be set out in a parallel document to the project brief. Whilst the project brief notes the requirements for the physical built asset, the employer's requirements define the information the employer needs to procure to enable them to develop and operate the built asset.
9.1 The brief is a critical document which develops as the project grows and sets out clearly the client's philosophy and requirements for their project. It must be a real live document and not simply an exercise in box ticking.