Contract brief

The brief should be a concise summary of the client's requirements for the project. Although not an exhaustive list (and every brief will be different), a typical list of information within the brief may include the following:

• introduction/background;
• design and scope;
• budget information;
• programme;
• third-party stakeholders;
• legal issues;
• health and safety;
• sustainability; 
• procurement; and
• any other constraints.

The project brief is an organic document and should be reviewed and updated at the various stages of the project. Similarly, the level of detail of the brief will evolve as the project develops. Depending on the nature of the project, an outline brief may only be required at inception stage, which may simply include some of the high-level issues that need to be considered. As the project moves through feasibility to scheme design stage, a detailed project brief can be developed which add further detail. Typical information that might be provided for the relevant parts of the brief are discussed below.

Introduction/background

All too often a project is embarked on without understanding the client's business objectives behind the need for the project; for example, why is the client undertaking the project in the first place? These objectives should be understood at the outset as the client's need for the project should and will inform everything in the project. The objectives should be crystallised into a succinct list. Often these are called critical success factors (CSFs), or a statement of requirements (or objectives).

These can be used as a checklist of high-level deliverables to measure the delivery of the project against. Agreeing the critical success factors requires open dialogue with the client (or project sponsor) at the inception of the project. The project sponsor is a name often given to the person who is asking for the project to be undertaken and is usually from within the client organisation, though this is not always the case. The communication of the critical success factors may be undertaken with the project manager, the architect or the whole design team, either by a meeting or a workshop. Typical critical success factors are;

• the project is to be delivered with all construction costs, professional fees and all ancillary costs within the development budget;
• to deliver a BREEAM excellent building;
• completion of the contract works satisfactorily before commencement of the new school term;
• the project is to be delivered in accordance with the Construction (Design and Management) Regulations 2015;
• ensure all of the landlord's obligations under the proposed agreement for lease, which are related to the project, are discharged;
• planning approval is obtained prior to the target development agreement exchange date; and
• all works are to comply with the development authority's guidelines.

Critical success factors can also be emotional rather than technical such as 'produce a design that is commensurate with an expectant market in the City of London'.

The project sponsor may also (or instead of) include a financial justification for undertaking the project; i.e. a business plan.

Each project is unique and will have its own specific drivers. These have traditionally been illustrated with the cost, quality and programme triangle. The triangle's proportions can change depending on the particular needs of the project. For example, if the project demands a high quality then it may follow that the scheme will be costly (though cost certainty may be important). If there is also a need to deliver the project quickly then that may mean that there is an impact on cost (i.e. there may not be time for competitive tender). More contemporary thinking expands the traditional triangle to include other factors such as risk, scope, health and safety and resources.

Design and scope

Set out the parameters or expectations for the design depending on the project need. This should generally take the form of open, strategic requirements, in order to allow the team to fully explore all options and avoid rushing to predetermined design solutions.

The nature of the design and scope requirements should be project specific. For example, the scheme may be a landmark project making design quality paramount. Alternatively, a hospital could be more functional in appearance but would have its own very specific technical requirements. If known, the scope should be identified, which may be a simple bullet point list (as in the Scope of works within the forms section).

If the project sponsor can provide minimum space or accommodation requirements, these should be included. Depending on how advanced a project is, a development specification may be available which is a much more detailed list of requirements and would highlight design criteria for the project such as floor loadings or what set internal temperatures the heating and air conditioning can deliver for a given external temperature. An example of a development specification is included in the forms section.

Budget information

Depending on the project drivers, cost is likely to be a key consideration at the outset of a project. A budget should be included within the brief and there should be a clear understanding of what this includes. Depending on the nature of the project and the client's requirements, this will usually include the construction costs and may also include ancillary costs such as professional fees, statutory costs, VAT, inflation, etc.

The budget may have names such as cost plan or cost estimate. See an example of a project budget. There should also be an allowance for a contingency sum for unforeseen items. Generally, the view is there are more unknowns at the beginning of a project so the sum should start off relatively large at the outset (approximately 10%) and reduce as the unknowns reduce.

Programme

The project brief may include a bullet point list of key project milestones, as below, or a bar chart (also known as a GANTT chart) could be used:

The programme constraints must also be set out, i.e. when vacant possession will be available, when the scheme must be completed (such as before the commencement of a new school year) or possibly there may be a legal agreement to allow early access by a tenant for them to carry out their own building programme.

In any event, there are likely to be some programme constraints (even if these are 'as soon as possible' to reduce interest payments on a development loan). The particular requirements will therefore need to be indicated.

Third-party stakeholders

It is good discipline to carry out stakeholder analysis in order to produce a list of all, or at least the key stakeholders, who could potentially have an impact on the project. This could be a landlord whose approval is required for the works, or a local pressure group, who might object to the works, or an adjoining owner who might have compensation rights in respect of rights of light. It might even be existing tenants or occupiers who still have a need to access the building. If the stakeholders are listed out, together with their influence on the project, the team will be clear on the need to engage them (or not as the case may be) at the respective part of the project life cycle. It is important to also consider the requirements of the facilities managers who will be charged with managing and maintaining the building after the project team have handed over and moved on.