How similar is building planning to the project planning? How to set project requirements? What are the goals? Everybody heard about SMART rule or Gantt chart. But who heard about building planning in reference to the requirements set for the building? This is a domain of building owners, planners, data managers and architects that in this post I want to put a light onto. I will focus on what we firstly would like to be modelled and then built.
The process of the initial stage of planning a project is quite complex. We assume that our database reflects the building we are about to design. Furthermore, it also performs the role of a contract attachment with designers. High-quality information gathered in that stage will serve to model the building, then as a handover to the designers. The roles, as well as the responsibilities of a contract provider and a project designer, are intertwined during the process of planning.
To make this article as clear as possible I have divided it into two parts, the first of which deals with the tasks of a building owner, whereas the other focuses on planners. That entry bases on my knowledge of the subject inferred from the experience of cooperating with both private and public investors in Norway.
The following article is included in the Data in BIM series. In case it’s the first post you came across, I encourage you to read the introduction "Data-Driven Design Explained in One Guide". I describe there the series, it’s table of content and describe the concept of Data-Driven Design. All that to make sure you can get the most out of the series. Have a good read.
Table Of Contents
1. Goal and deliverables at the stage project requirements planning
Way too often does the building requirements planning come down to just attaching the company’s documents “General requirements of the investment set by XYZ” and attachments putting forth specific requirements to be met for this particular project. Although it is supposed to protect the appointing party, it is cumbersome and time-consuming to analyse and implement during the designing process. That results in constant alterations in the project, often done at the last moment. More often than not, a situation arises when one of the designers notices an important requirement that has been so far omitted.
What is the goal of project requirements planning
While planning project requirements in the database we should aim to minimize documents and sheets with unnecessary data. The ideal situation would be to have each information about the building noted down as a Metadata. Such information is going to be used in further stages of the project. What we would like to avoid is writing the requirements e.g. “15 mm interior wall panelling in auditoriums and corridors”. Instead, we aim to have it as an occurrence in the database as shown below in the screenshot.
Should you require more information about the terminology and the structure of the database, visit earlier entry: How to present building information in a database?
What are the advantages of such a method? Well, we create metadata and assign them to the particular object in the database. A designer models this object and his metadata becomes the parameters. This makes it possible to send both the data and the handover results flawlessly among appointed parties in the subsequent stages of the project.
Another advantage is the centralized information repository (so-called single source of truth, mentioned in the introductory to the series Data-Driven Design Explained In One Guide). The outcome is that each designer can find requirements easily in one place instead of looking for it in multiple documents or arrangements from coordinating meetings.
What does the end result of the building planning look like?
While crossing over to bidding, we strive to create a database that contains the following:
Part 1 (this entry):
- Functional structure of the building (which departments and functions do we need our building to meet?)
- The area of departments (how many sqm is set for administration, surgery and patient rooms).
- The list of standard functional rooms (without technical & communication space) as well as the list of unique rooms (for instance foyer, lecture halls),
- Requirements & specification set for each room in every discipline,
- The list of standard items with their specifications and budget,
Part 2:
- Occurrences of objects in standard rooms,
- The full list of rooms assigned to particular functions with their area,
- Relations between rooms in the building (for example grouped into buildings, fire zones or placement requirements),
- Assigning rooms occurrences to standard rooms,
- Occurrences of required objects in each room,
- Budget reports regarding Furniture, Fixtures, Equipment and Finishes.
To achieve the project deliverable in the form of a well-prepared database, we need the cooperation of a building owner and planners. Below I will put forth the basis and requirements that should be determined by an appointing party to make it easier for planners. Needless to say, such a matrix should not be composed in the investor’s office only. A whole design team has to constantly coordinate it.
2. Process of the project requirements planning
I will try to describe step by step how to bundle the aforementioned information into one coherent database. Let me illustrate it with an exemplary design of a hospital and dRofus software I have been working with. Other programs or database might, of course, work as well (I have put forth other possibilities in this entry: Data-Driven Design Explained In One Guide).
Please be forewarned! In those articles, you are going to notice very few models and little graphical BIM. Although, there will be a lot of tables, columns and numbers as well as plenty of questions that must be answered during a planning process. However, this stage is particularly important and gives numerous advantages in following modelling phase when we can make use of a well-prepared database.
What do I want to build? Planning the building and it's functions
It is the most important question and it may be seen as too obvious to ask 🙂
Well, a statement like “let’s build a hospital” does not suffice. We need to define the functions it is going to serve. What kind of hospital? Which specializations should be taken into account? How many patients should it cater for? Having answered the above questions we create a basic functional division of the project.
What is the size of the project? Planning the building area
Information about the total area is usually available at this stage of planning, so we divide the whole area and ascribe them to the functions that have already been established. It might be a good idea to determine the gross/net ratio of the area. It indicates what percentage of the area can be arranged for utility rooms.
So, now we have a whole programmed area requirements at our disposal. We might take a look at a data sheet with the area of particular departments. Other columns will be filled in accordingly with the progress of work.
What kind of rooms do I want in this project?
Each larger building has typical rooms that are similar and used for the same purpose. Listing of room templates in our database makes it considerably easier for planners to carry on as they will know what the room program will consist of. Patient rooms – how big? Lavatories – how many different types? Offices, utility rooms, storage rooms, etc.
What is important, standards might be kept and copied among different databases. Therefore, hospital developers might use room templates for various projects. These types are always improved and need only a tiny adjustments from one project to another.
What project requirements do the room templates need to meet?
Only at this point do we reach the requirements the rooms have to meet. It is precisely here where we spend most of our time processing general requirements from documents into standard room metadata.
If there is an operating room with heavy equipment that requires a stronger ceiling, then we create or choose a suitable entry in the Room Data Sheet. If the walls around meeting rooms require specific acoustic absorption – it is also jotted down at this stage. Other examples might include the amount of fresh air, range of temperature, power and type of voltage connection, ICT systems. All aforementioned requirements need to be included in the database.
I need to stress it once more, it is the most important stage of planning project requirements. Not only do we make it easier for designers to carry on but also the appointing party gains the possibility of requirements control.
Let me show you a brief example of the requirement that we transferred from documents onto the database within one of the implementations:
“Glass doors and glass surfaces used by pupils should be tempered and/or laminated in the class F1/P2A. The design of the door and glass surfaces should prevent any danger of collision.”
Requirements apply in any rooms used by pupils e.g. classrooms. Therefore, in the lines referring to those conditions, we tick boxes and write down precise requirements (e.g. the class or type of glass surface).
Thinking over room templates and their requirements in the early planning phase greatly helps to control the later project stages.
Which items should be incorporated into the project?
At this stage, we know a lot about the rooms and functions of the planned building. The next step is placing different objects.
We might omit this step if only the investor gives a contractor absolutely freehand with the choice of equipment. Or if responsibility lies with the company managing the facility (e.g. an office building). However, while building a hospital with pre-arranged & delegated functions we tend to have control over each item, therefore, we need to create a database with the specific requirements.
As it is in technical descriptions and requirements we do not write down particular products (it is forbidden by the act of public procurement). However, we put down the properties of the items as well as the requirements to be met by the tangible product delivered to the building site.
At the hospital, we need an MRI, which is a massive and technologically advanced object working in a specified environment. It is, therefore, worth determining the object’s requirements and the room designated to house it.
3. Summary
Preparing properly structured databases for the first time is time-consuming – no question about it! However, the defined standards on the one finished project, might be reused in the next one. First projects are time and money consuming (as we have to learn and change our style of work), but as we move on, we save more money as the latest technology is more efficient and cost-cutting.
At times, building owners complain they can not write down their requirements precisely as they might forget about a condition that might result in a designer or a contractor evasion of their responsibility for delivering that element. However, I prefer to look at it from a different angle – a detailed database leads to precise quantity take-off and budgeting. That leads to better contractors and designers proposals with lower margin for unpredicted risks. In the end, it leads to the lower total cost of the building project.
This is a great guide for someone working on the investor/owner side, to see own to do the prework.
Yes, this article is created especially for them!