Near-future project specifications

John Gelder, NBS Content Development Manager, looks at how near-future project specifications might differ from current project specifications. Generally, we'll see that project specifications will be much smarter than at present, able to work much harder, whilst requiring less effort to produce and use.

Briefing

The project specification will serve the entire project timeline. For example, it might commence service as a briefing tool. As such, it will have sections dealing with the technical description of the requirements for the project at high level, describing the facility as a whole (e.g. the hospital or housing estate) in terms of its component buildings ('facility outline'), and their component activities and spaces ('building outline – activities' and 'building outline – spaces'). These outline descriptions will be supplemented by facility and building performance specifications. There will also be sections dealing with the project context – physical, regulatory, commercial and so on.

These technical sections will be accompanied by appropriate administrative sections, e.g. on commissioning a brief, organising a design competition, or procuring a PFI project. These would cover time, cost and risk management, for example.

The client could complete this phase of the specification alone, or in collaboration with design consultants. Information entered at this stage won't need to be rekeyed for specification production, for facility management (FM), or for any future purpose.

Room data sheets (RDSs) will be created at this stage, linking component spaces to their activities and performance requirements, and to the corresponding spaces in the project's geometrical model (CAD files). The RDSs will start here as class-based (e.g. offices generally), to be adapted later in the timeline for specific spaces (e.g. Office 1.01). Systems and products will also be added later to the RDSs, linking to clauses describing them in the specification.

Survey

Each building can also be described in terms of its component systems (e.g. framing, roof covering, FF&E, lighting, foul drainage, planting), as a 'building outline – systems' specification. These systems in turn will be similarly described in terms of their component products ('system outline') and system-wide performance. For new-build projects, these outline clauses wouldn't usually appear until Stage D, say, but for work on existing sites and buildings, outlines for the existing buildings and systems can be created to support the pre-design surveys.

The geometric parts of the survey will be recorded in CAD, of course. Descriptive parts, such as type and condition of system components and recommended actions, can be recorded in the specification. One simply creates system outline clauses specifically to describe 'existing', and then adds columns against them for condition (poor, good etc) and actions (retain, repair, replace etc). With arithmetic columns for rates and quantities, we can generate an initial estimate for work-to-existing. The rates can be derived automatically from authoritative national sources or an office resource, or added manually. The quantities will be derived through links to corresponding systems in the CAD files.

This survey-based work can be followed up by creating work-to-existing clauses, and 'new work' clauses (where values might include 'match existing' for example), once the decision is made to proceed with the work.

Design

The specification will also work as a design tool. The building and system outlines will support a variety of design functionalities, such as tools for determining cost (capital and life cycle), waste, carbon and general environmental impact. We would again add columns, for quantity, rate (specific to the parameter) and sum. As one selects a component (clay, concrete or calcium silicate bricks), so one will see the impact the component has on these parameters. If not acceptable, one can test alternative components until the cost, waste and environmental impacts are all acceptable.

Being able to specify performance – for all buildings, systems and attributes – will support various flavours of design-build procurement, in which the design at tender is incomplete. These range from full PFI, to completing the design of a single system in an otherwise fully-designed project.

Integration of outline and performance specifications (typically 'elemental') with conventional full specifications (typically organised by CAWS – Common Arrangement of Work Sections) is a challenge, but well worth doing as it achieves continuity from pre-documentation to documentation phases of the project. To do it means that CAWS and elements (or systems) must be brought together – CAWS must be overhauled (see 'Reclassification', NBS Journal 08) and a new approach to section structure is required (see 'Standard section structure', NBS Journal 09). The functionalities using this content, some of which are outlined in this article, require it to be delivered in a rich digital information model to all those who might contribute to or use the specification. This will be the building information model (BIM – see NBS Report: Building Information Modelling, March 2011).

For example, external BIM-compliant design simulation softwares, for acoustics, fire and thermal performance and so on, will need to be able to interrogate the entire BIM, not just the geometric (CAD) component. This will save multiple entry of the same non-geometric data (of which the specification is a major part), ensure that identical data is used for all simulations, and allow alternative design solutions to be assessed with a minimum of effort. Currently, non-geometric data is entered manually into simulation softwares.

Approvals

The specification could assist with the approvals process in several ways. If it could be reported with a structure and content exactly parallel to the Approved Documents (ADs), for example, then the work of building control officers (BCOs) would be simpler. This structure should also simplify automated code checking – the software would just compare the AD and the specification side-by-side, ensuring that AD recommended minima (for example) have been met by the specification. Another option would be to submit a project-specific mapping between ADs and the specification and associated drawings (or BIM) such that the BCO can follow links digitally between the ADs and the project's compliance documents. Another is that the specification could support compliance-related simulations, such as SBEM, by feeding data into them directly.

Production documentation

The hierarchical structure of facility outline, building outline and system outline enables automation of specification assembly. As one completes a building outline, selecting systems, so the corresponding system outline clauses will be brought into the specification, assuming that they exist in the master specification system being used. Likewise, as one selects products against a system outline clause, the corresponding product clauses will be assembled for editing. Only the clauses that are wanted will be included (the specification process is additive), making for a more concise specification, and all clauses that are wanted will be included, making for a safer project specification. Assembly will also be a much quicker process than it is now.

The links that have assembled the specification can also be used to navigate it. Right-clicking (say) on a product item such as 'Clay bricks' in a system outline clause will take you to the Clay bricks clause. Metadata attached to the Clay bricks clause will allow you to navigate back up to its parent system outline, or to other linked clauses, such as Installing clay bricks, or Spares – clay bricks.

Navigation will also be aided by the use of the standard section structure mentioned above (e.g. system performance clauses are always the 200s). It will also help specifiers to author sections from scratch, or add clauses of their own to a master specification, as it can serve as a check list for content.

Schedules are essential in mapping between types, defined in the specification (door type A, door type B etc), and instances, identified on the drawings (doors G.01, G.02 etc). In BIM, linkage between geometrical representations of objects such as systems, and the specification of the same objects, will be managed by a mapping schedule for each class of object, whether there are hundreds of instances and/or types, or just one instance and one type. Most of these schedules will exist behind the scenes in the model, but some will be published. The door schedule is a good example. It will draw information from the CAD files and the specification, and allow 'instance-variant' information to be added (e.g. signage, which varies from door to door). Current CAD systems can often generate these commonly-published schedules but, without the benefit of any linkage to the specification, a lot of information has to be entered manually. With the near-future specification, and its integration with the BIM, this will all change.

The specification will also support scheduling of types – if you have 10 fire door types, then rather than authoring 10 fire door clauses, you'll author one, with 10 columns, one for each type. This will save space and make type comparisons and rationalisations much easier.

Tendering

Generally only one specification is produced, and it has to be used by all users. As it happens it isn't ideal for any of them, not even contractors (even though these are regarded as the principal audience – see NBS Educator on this). In the future, specifications suited to different users, such as tenderers, will be able to be generated from the one source specification.

Time is tight during tendering. The specification will be able to help. For example, the building and system outlines already mentioned make it easy for tenderers to get their heads around the project's scope and quality without having to digest the entire specification. The quantity/rate/cost functionality already mentioned would be attached to these clauses, helping the tenderer to price the specification. The specification will also be easier to disassemble, e.g. by system (if an entire system is to be given to one subcontractor), and/or by subsection, e.g. Execution (if the supply and installation are to be split between two subcontractors). It will also be able to be split into a two-part report, comprising a 'general specification' on the one hand and 'project particulars' on the other. Tenderers would focus their attention on the 'project particulars'.

Columns for quantity/rate/cost mean that the specification can be used to create a priced bill of quantities directly, without the need for a separate document. The specification will be the core of this bill which will, of course, include links to corresponding geometrical information. The pre-tender priced bill can be used to assess priced tender bills to as much detail as required (e.g. just to 'building outline' level), and tender bills priced using this functionality can be readily compared. Because SMM7 is aligned to current CAWS, and the future specification will be aligned to a future CAWS, these bills will not be SMM7-compliant.

Mobilisation

The specification, like the building information model, will be available to all players, including contractors. The specification tool, outside the formal 'contract specification', will be able to hold descriptions of products and services contractors require, such as temporary power and scaffolding systems, benefitting from all the functionality already described. Indeed the specification, along with the rest of the BIM, should be able to be used right through the supply chain. Subcontractors, suppliers and manufacturers should be provided with mini-BIMs of their own, with functionality and content that will be of use to them.

Execution

Currently the contractor is given only dumb specifications, in paper or PDF. We can do much better than this. For example, the contractor will be able to generate reports on submittals and tests, and also for system performance (for contractor design), products (for ordering), execution (for installation), and so on. Some of these reports will also be of interest to the contract administrator (CA). As well as industry-standard reports, users will be able to generate their own (e.g. using key words), and at any level down to clause items. Reports can follow the structure of the original specification, or be given structures of their own. For example, though authored in a CAWS structure, the entire specification could be reported in the North American MasterFormat, for projects where this might be required (e.g. in the Middle East).

Disassembly of the specification for subcontracts, or for package contracts, will be much easier than at present, thanks largely to the data structures (e.g. revised CAWS, standard section structure). Sections will be able to be split by system if different trades are going to be responsible for different systems, for example. Management functionality attached to the specification will also help. For example, distribution of project content will be managed to ensure there are no gaps and no overlaps.

The specification can also be used to track progress (using percent-complete columns against the building and system outline clauses) and, if linked to contract administration software, help manage progress certificates. Through CAD links, progress can also be recorded in the geometrical part of the model. Indeed, because the specification has the timeline embedded in it, from section sequence down to clause item sequence, project sequences and durations can be attached to it, and the specification can help with construction programming. That is, a time-line view of key phases, perhaps even to clause level (e.g. preparation and finishing on site), could be generated for each system.

If the specification that is handed to the contractor has an incomplete description of the project, as it does in design-build procurement for example, then the contractor can be required to complete the specification and submit it (e.g. for client approval). Providing that the contract specification and the contractor's response specification are interoperable in software terms, then the building information model can continue to develop unbroken. This is likely to be very desirable to the client.

Preparation of conventional contract documents such as the specification and a standard set of drawings might only be needed for contractual purposes, because the contractor will be given access to the entire project BIM (with appropriate permissions). For practical purposes, the contractor will be able to create all sorts of non-standard outputs, such as drawings of just one system, with the specification clauses for that system included (perhaps with arrows pointing to the relevant objects). When looking at a geometric representation such as an axonometric, clicking on an object of interest will reveal its contract specification, and other textual data. And vice versa – when reading about an object in the specification, a right-click should show every instance of that object in a geometrical representation of his choice. Following this sort of linkage one would expect that, if an object is changed in the geometry, it should also be changed in the specification, or at least flagged for attention. And vice versa, again!

One side effect of this digital linkage is that old-style Coordinated Project Information (CPI) cross referencing is no longer needed. Natural language will be used for annotation instead (i.e. once objects are linked, then that object's specification title – clay bricks – will be reported against that object in any geometrical representations), with hyperlinks. The section and clause numbers have less meaning than at present since these identifiers will vary with how one chooses to report the 'clay bricks' clause – by CAWS, by AD, by system, and so on. The 'standard specification' is just one possible report of many.

System completion

This is the phase when testing and commissioning of complete systems is carried out, spares and tools are supplied, and operation and maintenance (O&M) manuals are prepared. The specification will assist by providing reports on all these topics, to ensure that neither the contractor nor the CA miss any of them out! This is also when record drawings would be submitted, to form a core part of the O&M manual. The specification will allow the contractor to prepare a record specification too – equally useful for O&M. He will, for example, replace generic and proprietary product clauses in the contract specification with proprietary clauses describing the actual products used, with supplementary information on contact details, dates of installation and testing, and the like. The record specification should also have (progressively) incorporated any authorized variations. This can be automated, if variations functionality is interoperable with specification functionality. The original contract specification still exists, of course, to be recalled from the model whenever needed.

Occupancy

The client will want a building information model (geometry plus properties) of the completed project, to use as an analogue building management tool during the occupancy phase. Because the model can drive simulations, proposed changes can be thoroughly tested before being implemented.

The specification will also describe occupancy-phase facility management requirements, both hard (for operation and maintenance of systems) and soft (for services provided by the consortium under PFI contracts, or hired in by ordinary occupants, such as catering and cleaning). The specification of 'hard FM' requirements will serve as the source for several other key reports – including the O&M manual, the health and safety file, an occupancy-phase site waste management report, the conservation of fuel and power report to AD L (or its regional equivalent), and a BS 9999 fire management report. Currently these documents are neither standardised nor integrated in the project model.

An interesting aspect of the hard-FM provision in the specification is its use of building and system level performance requirements as the criteria for maintenance. For example, an FM clause might state: 'If the lighting level falls below the briefed level of 500 lux, then replace all lamps in that room'. These performance requirements may not have been included in the contract specification, but will have been retained in the model from the briefing phase, precisely so they can be recalled and put to use during subsequent phases such as occupancy.

Conclusion

When is this near-future? Some of what is described here could be available in a couple of years (see my forthcoming article in NBS Journal 18); some within five, and some will take longer. None of it depends on specifiers being expert in building information modelling. Provided the content and software developers get it right, you'll be using BIM without even knowing it!

At present, material is added in the creation of project specifications, by a variety of specifiers, but this material is rarely extracted, even by the simple process of reading, after tender. It's a one-way process. During construction project specifications are often stashed away on site in a bottom drawer, only to be referred to if something goes awry. Once the project is completed, they are retained in hard copy form in a storeroom, if at all, and are often never referred to again! This is clearly not productive after all the effort that has gone into their creation, and is the antithesis of BIM.

The near-future project specification will be a different animal entirely.

John Gelder
Head of content development and sustainability
A shorter version of this article was published in NBS Journal 17.

Related NBS information:

Articles:

• Building Information Modelling: the holy grail?
• BIM and building properties
• The benefits of master specifications

March 2011

ViewAllArticles

BackToTop