The Unwritten Project

The premise

The project everyone believes they agreed to.

A school board sees a building that will support the next generation of students. The facilities director sees equipment that must be serviced by a small team. The finance office sees a capital commitment. Teachers see the daily movement between classrooms, storage, shared space, and supervision.

All of them may support the same project. They may also be imagining different buildings.

The differences can remain invisible through an early presentation. Words such as flexible, durable, efficient, and ready for the future sound like agreement. Each person can hear a different promise inside them.

We call the collection of those unspoken expectations the unwritten project. It is the project people assume has been included, although its requirements have never been made explicit.

A design criteria package gives the owner a way to bring those expectations into the open. Its value lies in the quality of the decisions it enables: what competing teams understand, what the owner can compare, and what remains visible as the selected solution develops.

Similar proposals can contain different projects.

Consider an illustrative renovation of an occupied school. The owner asks three teams to improve classrooms and building systems, complete critical work over summer, and keep the school operating.

One team assumes the owner will empty the affected rooms and provide temporary teaching space. Another includes a phased sequence with temporary arrangements. A third proposes a faster approach that depends on access to areas the district has not yet agreed to release.

Each proposal can sincerely describe a workable solution. Each can also attach a different meaning to “keep the school operating.” A price comparison alone cannot establish which responsibilities, allowances, or operational compromises sit behind that phrase.

The immediate question is what each price represents. Before evaluating value, the owner needs to understand whether the teams are solving the same problem.

This example is hypothetical. It illustrates a review problem, rather than the outcome of a particular Savoie Studios project.

What a useful design criteria package makes explicit.

A criteria package translates organizational intent into requirements a team can respond to. The appropriate content depends on the facility, delivery method, procurement stage, and information available. The following six subjects provide a practical starting framework.

These subjects are connected. A required completion date has implications for phasing. A maintenance expectation has implications for equipment access. A program requirement has implications for space relationships. Developing each in isolation can leave contradictions that the project team must later interpret.

The criteria developer’s contribution includes finding those connections and helping the owner resolve them while there is still room to make deliberate choices.

Replace comfortable language with answerable questions.

“Easy to maintain” is a useful aspiration. A facilities team still needs to explain what it means in its setting. Does it concern access to equipment, the availability of replacement parts, staff skills, service interruptions, or all four?

A stronger brief records the underlying need and asks teams to demonstrate how their approach addresses it. Some requirements will support a numeric measure. Others need a drawing, a sequence, a maintenance explanation, or a clearly documented assumption. The form of evidence should fit the decision.

This example deliberately avoids supplying a universal technical specification. The right requirement must be developed with the people who understand the facility and its operation. The useful discipline is connecting the need, the requirement, the evidence, and the owner’s decision.

Make uncertainty visible before it becomes a commitment.

Early projects contain unknowns. Existing conditions may be incompletely documented. User groups may be considering different programs. Funding or access decisions may still be pending.

A brief does not become more credible by presenting those matters as settled. A practical approach separates information into three categories:

• Established requirements: Decisions the owner has made and expects teams to address.
• Working assumptions: A stated basis for planning that needs confirmation before a defined decision point.
• Open decisions: Questions with an identified decision-maker, information need, and target date.

For each significant unknown, ask who will investigate it, how the response will be communicated, and which commitments depend on the answer. The appropriate mechanism must fit the procurement process and the owner’s contractual arrangements.

This distinction helps a team understand what it may propose, what it must respect, and what it should flag. It also helps the owner avoid mistaking a planning assumption for a decision already made.

Leave room for design judgment.

There is a real tension in criteria development. Too little definition can make proposals difficult to compare. Too much prescription can close off useful approaches before teams have had an opportunity to develop them.

The owner should distinguish a necessary outcome from a preferred method. If a particular material, system, or arrangement is essential, record the reason. If the need can be met in more than one way, describe the performance expected and the evidence required to assess alternatives.

For example, a district may need spaces that accommodate different teaching arrangements. Prescribing one layout may be appropriate in a particular context. In another, it may be more useful to describe the activities, capacities, supervision needs, and changeover expectations, then ask teams to explain their proposed response.

The balance requires judgment. The objective is a brief detailed enough to support meaningful decisions while preserving appropriate opportunities for design and construction expertise.

Compare the requirement, the response, and the consequence.

Once proposals arrive, the owner needs a way to understand differences without losing the connection to the original brief. A working comparison record can use five columns:

1. The requirementIdentify the owner’s stated need and the relevant location in the criteria package.
2. The proposed responseRecord what the team has actually offered, with a reference to its proposal.
3. The assumption or exceptionIdentify where the response depends on owner action, leaves information unresolved, or departs from the requirement.
4. The implicationExplain what the difference may mean for scope, operations, timing, maintenance, or another owner priority. Mark implications that still require investigation.
5. The next decisionDocument the clarification, evaluation, or approval needed and who is responsible for it.

This is an organizing method, not a substitute for the owner’s published evaluation process. It does not assign universal scores or presume that every difference is a deficiency. It makes the information behind a decision easier to inspect.

For the school-renovation example, this record would expose the different assumptions about room access and temporary teaching space. The owner could then examine the implications through its established process instead of discovering the mismatch after selection.

Keep the brief alive after selection.

The original requirements remain useful as the design develops. A room relationship can change. A system can be substituted. A phasing plan can be revised. Each change deserves a clear account of what requirement it affects and what the owner is being asked to accept.

A useful change record answers four questions: What was required? What is proposed now? What are the relevant implications? Who has accepted the change, and on what basis?

This creates continuity between the project the owner defined and the solution taking shape. It also gives new participants a way to understand why an earlier decision was made.

Owner technical advisory can support that work through defined reviews, issue tracking, and decision documentation. Its scope should be explicit so the owner, adviser, designer, and builder understand their responsibilities.

Readiness is an owner responsibility.

Before asking teams to make substantial commitments, leadership should be able to explain who can decide, what information is reliable, what remains open, and how quickly questions can be resolved.

The Design-Build Institute of America pairs its owner-advisor guidance with an Owner Readiness Assessment, recognizing that an owner’s preparedness and the support it needs belong in the same conversation. Its resources address selecting an adviser and aligning that role with the owner’s needs. [1]

A practical readiness discussion can begin with three questions: Can our leadership resolve competing priorities? Can our facilities and user teams explain what acceptable operation looks like? Can we identify the next decision without pretending later decisions have already been made?

For a school district, municipality, or institutional owner, the answers should inform the scope and timing of design criteria development. The owner’s procurement and legal advisers should establish the applicable delivery process, requirements, and approvals.

The decision before the design.

Before approving a rendering or comparing a price, an owner has a quieter decision to make: what must remain true for this project to serve its purpose?

That question deserves input from the people who will use, operate, fund, and maintain the facility. Their answers need to be reconciled, documented, and carried into the brief.

A considered design criteria package cannot remove every uncertainty or guarantee an outcome. It can give the project a more explicit starting point and give the owner a consistent basis for the decisions that follow.

The unwritten project is worth finding while it can still become part of the brief.