Architectural programming is the work that happens before there is anything to design. A client hands over a set of ambitions and constraints, and the program turns that into a document precise enough to design against: a list of spaces, their sizes, how they need to relate to each other, and the budget they have to fit inside. Theme 1 tests whether you understand that this is a distinct, structured service — not a warm-up to schematic design — and whether you can read a program critically enough to catch one that's missing something.
Programming is a service, not a warm-up
The exam-critical fact sits in RAIC Document Six, the Canadian Standard Form of Contract for Architectural Services. It defines five phases of basic services: Schematic Design, Design Development, Construction Documents, Tender, and Construction Administration. Programming isn't on that list. It's a pre-design, additional service, billed under its own fee agreement.
Two consequences follow, and both show up as exam traps. First, completing a programming study creates no entitlement — contractual or implied — to the design commission that follows. A client can pay an architect to write the program and then hire a different firm to design the building. Second, because it's a separate service, the boundary between what the client supplies and what the architect develops matters. The client provides the functional program or design brief — the space list, adjacencies, and operating requirements — along with the budget and any specialist reports such as surveys or geotechnical data. The architect's pre-design deliverables sit alongside it as additional services too: the feasibility study, the site analysis, and an initial code overview.
The five-step programming process
The standard method for getting from a client's ambitions to a design problem statement comes from William Peña's Problem Seeking, and it runs through five steps in a fixed order. The names are easy to mix up under time pressure, so it's worth anchoring each one to what it actually produces.
- 1. Goals. Establish what the client wants to achieve. This is the client's philosophy, values, and the services the facility needs to provide — the "why" behind the project.
- 2. Facts. Gather the quantitative and qualitative data: activities, workload and throughput, staffing numbers, and major equipment. Facts are collected, not invented — they describe the world the building has to work in.
- 3. Concepts. Explore organizational ideas that address the goals — this is where space relationships get worked out, using the adjacency tools covered below.
- 4. Needs. Translate the goals and concepts into spatial and performance requirements — the detailed space list, with net areas, that a budget can actually be checked against.
- 5. Problem. Synthesize all four steps into the design problem statement the architect will solve. This is the handoff point into schematic design.
Notice the order does real work: Concepts (organizational ideas) comes before Needs (detailed requirements), because you can't size a space list sensibly until you know how the spaces are meant to relate to each other. A question that asks you to sequence these five steps is testing that logic, not just memorization.
What a functional program has to contain
A functional program is generally built from a core set of activities. Knowing them lets you evaluate a program you didn't write — which is exactly what a working architect has to do before agreeing to design against one.
- Describe the client's philosophy, vision, and goals
- Describe the services the facility will provide
- Identify delivery and operational characteristics
- Identify activities, workload, and throughput
- Identify the number of people and staff required
- Identify major equipment
- Identify relationships between spaces or groups of spaces
- Prepare detailed space requirements
A separate list covers what a program may additionally include, rather than what it's core to preparing one: the overall project implementation schedule, preliminary financial information and budgets, the project delivery method, and site evaluation. The distinction matters on the exam — a question that asks which item is "additional" rather than "core" is checking whether you know a program can be complete and adequate without a delivery method or a site already chosen.
Evaluating a program for adequacy
Before design starts, the architect reviews the completed program the same way a marker reviews an exam answer: against a checklist, not a gut feeling. A program is adequate when it states the client's philosophy, values, goals and services; defines the relationships between spaces; shows a reasonable correlation between the activities and occupancy described and the space actually listed; confirms the budget corresponds with the space requirements — net against gross, not net against net; and confirms the facility can physically fit the site.
Net area, gross area, and the grossing factor
The "Needs" step produces a tabulated space list, and the number everyone actually argues about is how that list becomes a building.
Net floor area is measured to the inside face of the walls of each assigned space. It excludes corridors, stairs, partitions, exterior walls, and mechanical, electrical, and telecommunications rooms. Gross floor area is the whole building — net area plus all of that circulation, service, and structural space. You get from one to the other with a grossing factor:
Example: 4,000 m² of net program area at a grossing factor of 1.35 gives a gross floor area of 5,400 m². A factor below 1.0 isn't possible — gross area can never be smaller than the net area it contains.
The factor itself isn't a fixed number. It depends on building type, use, size, and the number of spaces being served, because circulation and servicing scale differently for different programs.
| Building type | Typical grossing factor | Why |
|---|---|---|
| Single-storey warehouse | 1.10 – 1.25 | Largely open space, minimal servicing |
| Office building | ~1.35 | Standard corridors, core, and washrooms |
| Hospital / laboratory | 1.8+ | Wide public corridors, intensive mechanical/electrical service rooms |
Large, complex programs go a step further and split into components, each with its own grossing factor. A sample table drawn from Alberta Health and Wellness's Health Capital Planning Manual makes the logic visible inside a single building type:
| Functional component (hospital) | Component grossing factor |
|---|---|
| Intensive Care Unit — Adult | 1.60 |
| Emergency Department | 1.50 |
| Inpatient Unit (bedroom areas) | 1.50 |
| Administration Services | 1.30 |
| Gymnasium | 1.15 |
| Laundry & Linen Services | 1.10 |
The ICU carries the highest factor in the table because it needs the widest corridors and clearances to move beds and equipment around critical-care patients — the same logic that gives hospitals a higher overall grossing factor than a warehouse, just applied department by department.
From space list to adjacency diagram
The "Concepts" step is where the space list stops being a table and starts being a diagram. Problem Seeking describes this using a relationship matrix: every pair of spaces is rated for how close together they need to sit, using a small shorthand — commonly E for essential, D for desirable, and X for undesirable.
A small clinic program illustrates the technique:
| Reception | Waiting | Exam Room | Staff Office | |
|---|---|---|---|---|
| Reception | — | E | D | X |
| Waiting | E | — | D | X |
| Exam Room | D | D | — | D |
| Staff Office | X | X | D | — |
Reception and Waiting are rated essential — patients need to see one from the other on arrival. Staff Office is rated undesirable next to either, for privacy and noise. Once every pairing is rated, the matrix converts directly into a bubble diagram: circles sized roughly to area, pulled close together where the rating is essential and pushed apart where it's undesirable. That bubble diagram is the bridge between the program and the first schematic block plan.
Theme 1 is one of thirteen — and it sets up the rest
Programming decisions carry forward into every later phase. The ExAC Study Guide covers Theme 1 in full — programming, feasibility, cost planning, and the architect's work plan — cross-referenced to RAIC Document Six and the Canadian Handbook of Practice, alongside every other theme on the exam.
Get the ExAC Study Guide ($300 CAD)Sustainability decisions that start in the program
Some sustainable design choices have to be made in the program itself, before design begins, because they change the space list — not just the construction. If a client decides to promote cycling as an alternative to driving, that's an operational systems decision that adds bicycle storage and, usually, shower and change facilities to the space list. It reads like a design amenity, but it's really a programming decision, because it changes what has to be counted in net area before schematic design starts. For how sustainability decisions continue to shape the project after programming, see our guide to life cycle assessment and sustainability in architecture.
Business Case vs. Feasibility Study
Two more pre-design documents get confused with the program itself, and the exam likes to test the order they come in. A Business Case establishes the merits of a project and justifies committing organizational resources to it — it's strategic, and a single business case can spawn several possible projects. A Feasibility Study is narrower: it analyzes the economic, regulatory, and technical viability of one specific proposed project. The Business Case comes first. You confirm the project is worth pursuing before you test whether a particular approach to it is viable. Both are additional services under RAIC Document Six, billed separately from programming and from the five basic-service phases.
Quick reference for exam day
- Question asks about design entitlement after programming → none. Programming confers no claim on the design commission.
- Question asks you to sequence the programming steps → Goals, Facts, Concepts, Needs, Problem — in that order.
- Question mentions corridors, mechanical rooms, or structure → gross floor area, not net.
- Question asks why a hospital has a higher grossing factor than a warehouse → wider corridors and heavier mechanical/electrical servicing.
- Question lists "contractor's means and methods" as something the program should confirm → wrong. That's a construction-stage concern, not a program adequacy check.
- Question asks which comes first, Business Case or Feasibility Study → Business Case.
For how Theme 1 fits alongside the rest of Section 1, see our breakdown of all four ExAC sections and 13 themes, and work the programming and space-planning items in the free Section 1 practice questions under time.
Sources
- William Peña and Steven Parshall, Problem Seeking: An Architectural Programming Primer, 5th Edition, 2001. Wiley.
- RAIC Document Six, Canadian Standard Form of Contract for Architectural Services. Royal Architectural Institute of Canada.
- Canadian Handbook of Practice for Architects, 3rd Edition, 2020. Royal Architectural Institute of Canada.
- Functional Programming (Practice Bulletin), June 2010. Alberta Association of Architects.
- Health Capital Planning Manual, Table 1: Component Grossing Factors. Alberta Health and Wellness.