Programming: Turning a Demand Number Into a Building Program

Between the demand study's number and the first drawing sits programming: the research and decision-making process that defines the project's objectives and how they will be achieved. Its product is the program, a written and illustrated document that gathers, organizes, analyzes, and evaluates the project's information and formulates conclusions, and the manuscript's placement rule applies before its method does: programming and conceptual design are best performed by experienced parking consultants, not junior staff or firms unfamiliar with parking's peculiarities, because these first steps encode every planning concept the rest of the corpus carries, and errors here compound through every subsequent phase.

The four sections. The program runs on a four-part structure. Goals answer three questions: the project's purpose, the client's and users' objectives, and the project's characteristics. Facts are the evidence base, deliberately split into quantitative (site, climate, utilities, traffic, zoning and building codes, design criteria, building quality, mechanical and electrical systems, schedule, budget) and qualitative (aesthetics, views, vegetation and wildlife, sensory character, cultural implications, sustainability concerns), with some available at the outset and others requiring research; the split matters because the qualitative facts are the ones rushed programs skip and finished buildings regret. Precepts are the planning commitments that take the goals and facts and set the design's overall direction, from simple space-relationship diagrams to detailed functional requirements. Concepts are the general planning directions the goals, facts, and precepts suggest: not the design itself, but graphic representations of opportunity and constraint (the allowed envelope, the "box," and where the project might productively step outside it), with the programmer generating alternatives and indicating which best achieve the goals. When the programmer is the experienced consultant the manuscript requires, concepts sometimes become the conceptual design, and the phases merge.

Where the information comes from. The inputs are the owner, the users, zoning, building codes, and the design team's experience, gathered in owner-designer meetings and, where warranted, user groups and public forums; a programming checklist disciplines the collection so nothing necessary is missed. The programming phase is also where the corpus's earlier work cashes in: the study (Module 1), the demand fieldwork (Module 2), the shared-parking analysis (Module 3), and the feasibility gate (Module 6) all enter the program as facts and constraints.

The program statement. Programming culminates in a written statement, and the manuscript's minimal example is a small masterpiece of compression: the structure will provide 600 spaces for visitors and staff at the existing lot site, functionally efficient, attractive against the surrounding architecture, open by Thanksgiving, under $35,000 per space. Count, users, site, function, appearance, schedule, budget: seven commitments in three sentences. The manuscript's preference, though, is for the more detailed statement, for the reason that matters politically as much as technically: detail is what produces genuine shared understanding among owner, users, public, and design team, and stakeholder buy-in is a deliverable, not a byproduct.

Source crosswalk -- Module 15