Building Program as the name so aptly suggests, might be a boring 100-page building planning document. The investor jots down there everything that he expects from the function and the building. However, quite a significant part of the building program might be placed in the database. Then we can create functional relations and we can export them to IFC. Sounds promising, doesn’t it? How to do it? Well, let me take you for a ride!
In the previous entry, we dealt with specifying general requirements that might be implemented to a portfolio of designs. The present entry discusses creating databases apportioned to specific building investment. Not only will we define a so-called Project Program, but also we will plan equipment. At the end, I will show you different ways of passing information to other members of the design team.
Table of Contents
- Creating a Building Program
- Planned items
- Information Handover
- Building planning in a nutshell
1. Creating a Building Program
Building Program (also referred to as a Functional Program) is the result of the planning phase, which constitutes an annexe to a bidding document and a basis to design a building. Functional programs usually consist of:
- Descriptions of the purpose and functions of the building (architecture, location and its impact on the environment, functional requirements, etc),
- List of rooms net,
- General technical and esthetic requirements regarding the building planned and its surroundings,
- Specific requirements regarding rooms,
- List of equipment that forms a part of the deliverables (e.g. kitchen installation)
Rooms in functions
Part 1 dealt with allocating departments and the total area in accordance with the requirements of the building functions. The aim of this step is to check the feasibility of the execution of that task with reference to the available area. The aim of this step is to form a proper number of rooms in accordance with the investment requirements and mandatory provisions of law (e.g. number of lavatories per number of employees).
Let me explain it to you by an example:
We are planning an office building satisfying the need for 60 employees. The investor apportioned 1300 m2 for this function, which is to accommodate ‘open space’ rooms, single offices and auditoriums. We create rooms in a manner to meet the requirements for 60 workplaces. Then we compare it with the requirements for the whole department:
The screenshot above displays the layout of single offices with their programmed area, which has taken 1020 m2. It ultimately means we have satisfied the requirements, which sounds better than anticipated before.
In the screenshot above we can see columns with different statuses. I hasten to explain.
Do you happen to remember how much attention have I paid to describe the exact requirements for standard rooms? Assuming it has been done well, it suffices to link types of rooms with their occurrences and we will get ready-made requirements for most of the rooms in the design.
If in our Building Program we plan four identical ‘open-space’ rooms, we link them with a proper Room Template (caption “From RT” in the screenshot). Relative database collects information from the template and inserts it in the planned room. The link is preserved and it mirrors any changes made in the standard itself.
I can hear you say:
“Well, Konrad, it’s nothing new… In Excel, I can also link a spreadsheet with a room template data to a line of a room”
Of course, you can do that as long as the number of different types of rooms is small enough to grasp in an Excel flat structure. But what is going to happen if the rooms are only slightly different? How would you deal with it without using a database?
Let us assume in one of the aforementioned open-space rooms is planned a coffee corner with a dishwasher. It means additional installation. If that is the case we employ the concept of ‘derivative’. The requirements that deviate from the standard are ‘detached’ from the standard while having other information follow the template. It lets us add new requirements while keeping other common features intact (e.g. amount of fresh air or number of workplaces).
How does the concept of the links within database work is put forth in the flowchart below:
Further relations between rooms
Having information about rooms we can find further relations between them, be they common technical or location requirements. By creating relations between rooms in a database we gain the following advantages:
- We make navigation easier- filtering and sorting of values,
- We add further layer of the structure and the relations to the data files,
Relations are created by simply adding further information common for a number of rooms. Here are additional examples of further relations:
- Investment project comprises several buildings,
- Project consists of many phases while we have a single shared database,
- Investor makes use of the classification that divides rooms according to their nomenclature (e.g. Uniclass),
- Only some rooms have specific requirements regarding furnishings while others are to remain empty,
- At this stage we know which rooms are set apart to form a firewall or be located on a specific floor or be adjacent in accordance with the design.
Creating relations, models and their derivatives between rooms and standards constitutes one of the key features of a database as it immensely makes it easier to create and manage huge data files.
2. Planned Equipment
Equipment planning inside rooms is the stage that is so often neglected during the planning phase. Any employee responsible for equipment procurement surely tells you that. More often than not, the budget allocated to the finishing of the investment grossly exceeds initial assumptions.
More precise planning will let us keep better control at this important stage. Having compiled the schedules of all planned items in a project, we will be able to make use of multiple advantages during later stages of designing or building:
- Acknowledge the whole budget allocated for furnishings,
- Equipment schedules serve as a basis for purchasing equipment during the building phase,
- Control over planned, determined and purchased items,
- Comparison between requirements for particular items and the rooms they are ascribed to,
- Items schedules which later during the development stages might be updated more specifically.
Budgeting and scheduling
The first step to create a summary list is adding information that will be used in further stages of designing or building:
- Party responsible for the item- who is responsible for determining the specification of this item,
- The budget allocated to this particular item,
- Purchasing group – which other items will we buy it with?
- Is it the item that requires special planning during the installation (ASI – Architecturally Significant Item),
- Additionally, we can get it classified (Uniclass, Omniclass, TFM, etc.).
Assuming our list of equipment for the project is ready, then it is the planner’s job to assign a proper item to each room. That enriches the Building Program with:
- Item category (finishing & furnishing, electric, etc)
- Furniture, Fixtures and Equipment for each room in the project,
- Particular structures that might be then modelled.
Irrespective of bid documents, we might also generate information that will help with a decision making process on the project development. Furthermore, having created the list of items in all rooms we get the quantitative analysis, so once we have set the price of an item and different budget groups, we can have a cost report. As a result of precise planning of items in our database, we can, even at an early stage, look at definite cost and the number of planned equipment, therefore, conduct an optimization of the project.
Items specifications and comparison with the room requirements
Items that are technologically advanced, or sensitive to the surrounding atmosphere or just quite expensive must be thoroughly described so as not to leave any doubt about the place or the way of having it installed. There should be a specialist responsible for specifying that particular item category.
Here is an example of the required temperature and humidity for a tomograph:
If it has been planned in the room, then we check whether those particular room requirements conform to these of the equipment:
Both screenshots evidently prove that a tomograph can be installed in the room. Of course, please bear in mind that the shot presents only one of many requirements that need to be completed should such a piece of equipment be installed.
3. Information Handover
The result of our effort is the ‘practical’ part of the Building Program in the form of many linked tables in the database. Let me remind one more time what it entails:
- Functional structure,
- Rooms and their programmed area,
- Room technical requirements,
- Room furnishings
And what is going to happen next?
The easiest way would be to just hand over the access to the database to each interested party. It might as well be to call for bids or to further develop a design. Due to possibilities of parameters mapping, design work might be much easier and more pleasant (this idea was brought up in this entry: Data Driven Design Explained In One Guide).
But what may happen if a designer/bidder does not know how to use the database? In other words – how to convey information in an open format, which is known to the whole industry? Well, we can export reports in PDF, XLS or IFC formats, however, each such export might look different and have different applications.
Non-editable format - PDF
Exports generate statistical reports predesigned by the software development team. This format works best as:
- Annexe to the contract
- Equipment budget reports
- Room Data Sheet reports to the investor
Editable Format - XLS
This format makes it possible to generate dynamic and highly configurable reports. Both Excel and database have columns and lines, which enables us to produce unrestricted schedules and reports. This format serves best as:
- Request for additional information. For instance to a sanitary specialist to have him complete the requirements for rooms, which then are imported to the database,
- Request for Proposal. For example to a medical equipment supplier
- Tables of parameters to import into modelling programs
Modelling format - IFC
Some database programs make it possible to export rooms with information to IFC schema. It generates rows of IfcSpace hexahedrons with the attributes defined during its export. This schema is most beneficial as:
- An annexe to the request for proposal to design offices. A contracting party might request export setup options, which may come handy when revising designs provided to them (IFC GUID and other parameters are preserved).
- An aid for designers to import requirements and room areas to modelling programs. Then, architects can arrange spaces into a project like puzzles.
4. Building planning in a nutshell
The aim of this two-part entry is to help you, my dear reader, go through the initial stage of planning an investment. We commenced from defining the needs and mulling over which functions we lack to meet them. As a result, we got a database full of valuable information that might be transferred to designers as a part of the Building Program. It constitutes the client’s requirements that are set forth before designers. In the traditional design model, it, more often than not, hits a drawer. However, in the process I suggest, the requirements remain updated with additional information that pops up during a design phase.
Further entries are going to show how to deal and not lose control over the new or updated information that always arises in the design. That all to avoid a surprise during building handover: “That’s not what we’ve had in mind”.
Here is the moment fun begins and in which the real strength of Data-Driven Design appears. Don’t miss further entries!