Why We Should Wrong-Size Buildings
As we’re trying to finalize project requirements, our clients commonly ask:
“Are we unusual?”
What they mean is, “We feel dysfunctional; unable to bring you the requirements you’ve asked for in a timely fashion, and keep introducing new ideas that require vetting. Do you have other clients like us? Are we ruining the project?”
We need to start allaying their fears from the get-go, letting them know why this is not only normal, but necessary, and to build it into the project schedule.
Identifying space requirements optimally involves three tasks:
- identifying strategies that address uncertainty and changes over time;
- spot testing the sizes of the most significant and typical spaces;
- over-requesting and vetting.
The first two are subjects of other blog posts. The latter not only ensures the project is prioritized correctly, but also gets there the fastest, presents the opportunity for the best stakeholder buy-in, and consumes the least client and design team time.
On the surface, over-requesting and vetting seems inefficient, and consequently is rarely planned into the project schedule. Why not just identify the correct quantity of right-sized spaces from the outset? Client leadership is more than willing to read ground-rules to their users, letting them know that would-be-niceties are unaffordable and shouldn’t be requested. But this is a mistake. Good ideas and self-editing regrets continually creep in from the users despite the hope that they won’t. New requests can’t be tamped down because many of them are valid. The longer this process is drawn out, the more difficult and disruptive it is to address and incorporate these rightful changes. And since users are reluctant to identify colleague space as less important, the overall space request grows, either busting the budget or squeezing out any space that was banked for future uncertainty.
It turns out the most efficient process is a counterintuitive one: inject chaos as a planned step; really encourage the users to brainstorm and wish-list and blow the budget. This should go beyond just identifying “more”, but also include ideal ways of working together, and pondering the future. Why? Because:
- it spreads all the cards out on the table so users and leadership can consider, synthesize and vet together as a coherent and scheduled activity;
- it increases the likelihood that the highest priorities and best ideas will get identified in time to inform the earliest design and planning concepts;
- it ensures the lowest priority requests earn the attention they deserve to be weeded from the project or assimilated in less resource-consuming ways.
- even non-starters can be useful for spawning tenable ideas.
Conversely, if the project is within size and on budget, the appetite to rigorously evaluate the program is weak or non-existent.
And if the political will can be mustered, the vetting should over-prune; cutting more than what’s needed to get on budget. Over-pruning banks space savings that can be assigned to important needs that emerge during design or shortly after move-in. And why should we plan for that happening? Because it does so on every project. As one of my clients sagely said from a place of experience,
“You think you’re planning for one building, but it turns out you’re planning for another.”
It’s not only clients that fail to scrutinize on-budget projects, it’s also their design teams. Conversely, when a space problem is fabricated, it focuses the knowledge, experience and creativity of the broader team on the program…and makes it better. Though design teams can’t vet their client’s priorities for them, they can facilitate, bring ramifications to the table, and propose creative ways to do more with less - not an uncommon need. Design teams also have experience identifying inexpensive ways to plan for achieving long-term goals not initially affordable, like designing a building that seamlessly flows into a future wing, or are upgradable to more capable space.
These ideas apply to other aspects of buildings, like environmental and systems criteria, but if you find they also apply to a different industry, I'd be interested to hear from you.
Finally, the ramifications of getting the program right or wrong can be significantly diluted by designing for uncertainty and creating easily modifiable space and infrastructure. Read about that here…