Pre-Project Planning and Programming
From need to validated program
Pre-project planning converts a business need into a validated scope, budget, and schedule baseline before significant design money is spent. The candidate must know the sequence: needs assessment, feasibility, programming, then project definition and the basis of design.
Programming states what the facility must do: space types, adjacencies, capacities, performance criteria, and growth assumptions. It is functional, not prescriptive; the trap is letting a preferred architectural solution leak into the program. Feasibility tests the program against site, entitlement, market, and funding constraints. A charrette or visioning workshop is a tool, not a deliverable; exam questions often treat it as the programming output.
The traps
- Skipping a written program and jumping to concept design, then discovering scope gaps during construction.
- Treating a Class 5 parametric estimate as a budget baseline; early estimates carry wide ranges and must be reconciled as scope matures.
- Confusing the basis of design (owner requirements and assumptions) with the design narrative produced by the architect.
- Forgetting stakeholder and operations input; facilities maintenance, IT, and security requirements are notoriously omitted.
- Ignoring lifecycle cost: first cost decisions that raise operating cost for decades.
Worked example
A client wants a 40,000 sq ft office but has only programmed 32,000 sq ft of known functions. The CM should flag the 8,000 sq ft gap as unprogrammed growth allowance, price it with a range (not a point), and record the assumption in the basis of design. When design shows 38,000 sq ft, the variance is traceable to a documented assumption rather than a surprise change order. Rule of thumb: no design contract should be executed until the program is signed off and the budget carries an explicit contingency and escalation line.