In the architectural world, the practice of developing space requirements for a project is known as space programming. It is done during the pre-design phase and provides the baseline space requirements for a construction project. The programming process involves a combination of conducting client interviews to understand operations and defining office and support space sizes using design guidelines or proven industry standards. Programming often also involves suggesting space recommendations based upon best practices learned from projects of a similar type. The result of this programming effort is a Program of Requirements (POR).
A POR consists of a detailed list of space types and sizes required, the quantity of each space type, and a few multiplying factors that ultimately establish the overall project size. The POR also often includes a narrative description of each department within the organization and adjacency requirements for each department as well.
A POR is used in many ways. First and foremost, it gives the design architect a comprehensive list of spaces, sizes, and adjacency guidelines that must be provided in a building. But the POR can also be used by the client to search for the right amount of leased space or to find a suitable site to construct a new facility. It can even be used to establish a preliminary budget by estimating a cost per square foot for the project.
Although my primary focus has been facilitating programming efforts for courthouses, I have worked on PORs for several kinds of projects. No matter the type of project, the most valuable, yet challenging, part of the programming process is the interviews. Stakeholders often fear that we do not understand their operations and that we will dictate a space solution that does not support their operations. They may even worry that our goal is to try to reduce their space. It is important to gain their trust and to help them understand that we are there to learn about their needs and to work collaboratively to develop an optimal space solution.
Conducting a programming interview is part art and part science. I would like to share a few things I have found consistently contribute to a successful programming effort.
- As early as possible, collect information about the organization’s history, culture, and structure, as well as workload, staffing, space, and demographic data. It is important to convey to the client that you have sought to understand how they function and what makes them unique. Some of the information gathered will also be used to prepare forecasts for workload and staffing growth (or decline). Gathering the information early will help in developing a positive relationship with the client and will ultimately help justify the space needs.
- Work with the leadership team to determine the most critical people to be included in the space programming interviews. The day-to-day operational processes and deficiencies need to be understood by the programming team. I have found that these details are most accurately conveyed by a department head as opposed to administrative leadership. Not that administrators shouldn’t be present during the interviews – particularly to help establish policies and to remind the stakeholders of parameters. But those who work in the space every day are needed to provide critical insight into how processes and procedures may be affected by space constraints. Many times, they have very creative solutions that can be incorporated into the POR. In addition, the department head can assist administrators in projecting departmental growth, both in terms of staffing and operations.
- Conduct a kickoff meeting of all stakeholders to lay out the project goals, design process, and big-picture ideas. This helps establish a collaborative environment and signals that all stakeholders have a voice. This meeting often leads to preliminary discussions about shared opportunities and concerns. I have found that this initial meeting not only establishes expectations but helps set the stage for the collaborative nature of the entire process.
- Clearly define the design parameters at the outset. If an organization has a design guide, as many do, be sure the stakeholders understand the space types and sizes contained in the guide and that the guide will be consulted throughout the process. This helps avoid unrealistic expectations and establishes a sense of fairness and equity among stakeholders. It also helps the stakeholders understand that the programming team must follow the guidelines and does not have the latitude to make programming decisions outside of the guide’s specifications without administrative approval.
Clear Communication is Key in Space Planning
- If the design architect has already been selected, it is important that they sit in on the programming interviews. I have found that a rich discussion often occurs between the design architect and the stakeholders during these meetings. Innovative solutions regarding space needs tend to be hashed out at a very high level, helping to establish a collaborative relationship with the design team at an early stage.
- Provide as many visual aids as possible during the programming sessions. Many people I interview have difficulty understanding square footage. Since the programming phase is heavily focused on square footage, it is helpful to provide visual aids to describe space types and sizes. For example, displaying an image showing what can fit into a 250 SF office (i.e., an executive desk, credenza, two side chairs, two file cabinets, and seating area) can help people visualize the size of the space. Similarly, showing the difference between standard sizes of conference rooms can help people gain a sense of the type and quantity of collaborative spaces that may be needed.
While the POR itself is the foundational working tool of the planning process, its comprehensiveness and quality rely on a robust and thorough interview process. These key discussions, when handled correctly, help provide an accurate reflection of the client’s operations and space needs and form the foundation of a productive team relationship. The programming phase is one of the first interactions the client has with the design team and sets the stage for the overall success of the entire project. Take time to establish a successful relationship with the stakeholders from the very beginning, and the rewards will likely pay off throughout the entire design process.