Designing Around Constraints You Have Not Met Yet

The worst kind of redesign is the one where nothing was done badly. The drawings are coordinated. The disciplines agree. The client has approved it. And then a constraint arrives that nobody had established, and a month of good work has to be undone, not because it was wrong but because it was premature.

Every project carries constraints that are not yet known at the moment the design begins. Some are physical, some commercial, some come from the wider framework any building has to sit inside. The design cannot wait for all of them. But it can be sequenced so that the decisions most expensive to reverse are not the ones taken first on the least information.

Two things advance at once, at different speeds

A project always has two kinds of progress running in parallel, and they are easy to confuse because both look like forward motion.

The first is how developed the design is: how much has been resolved, coordinated and drawn. The second is how much has actually been agreed, by everyone whose agreement the project eventually needs. Those two do not advance at the same rate, and neither waits for the other.

Design maturity is the one a project team can feel. It produces drawings, it fills a programme, and it is satisfying. Agreement is slower, less visible and largely outside the team's control. A project that measures only the first is measuring the half of its progress it can influence, and reporting it as though it were the whole.

The failure that follows is not dramatic. The design simply arrives somewhere ahead of its permissions, and has to wait, or worse, does not wait.

Developed past a decision that had not been made

This is the specific mechanism worth recognising, because it looks like competence right up until it does not.

A stage completes. The architecture is resolved, the structure is reconciled with it, the services are routed and the façade principle is settled. Everyone has done their job well. Then something is established that was always going to be established, and it moves a dimension the whole coordination rests on.

The design was not wrong. It was developed past a point it had no basis to pass. And because the disciplines are coordinated with each other, the change does not stay local: moving a slab edge moves the façade, the services and the units above and below it. Coordination, which is the thing that makes a design robust, is also what makes late change expensive. A well-coordinated design is harder to alter than a loosely coordinated one, which is an argument for making sure it is coordinated around the right things.

Some constraints depend on other constraints

A second pattern is subtler. A team assumes several unknowns can be resolved in parallel, and some can. Others turn out to be sequential, where one cannot be settled until another has been.

Discovering that late does not merely delay one item. It converts what the programme showed as parallel into a chain, and a chain is as long as the sum of its parts. The programme did not slip because anything took longer than expected. It slipped because two things that were drawn side by side turned out to be end to end.

Mapping those dependencies at the beginning is unglamorous work and it is usually done by whoever is least busy, which is the wrong instinct. It is the piece of thinking that determines whether the programme is a plan or a hope.

Some things take the time they take

There is a category of project input that is not compressible by effort, enthusiasm or seniority. It takes a certain amount of time because somebody outside the project has to consider it, and no amount of energy from inside the project shortens that.

Teams under pressure tend to treat these as elastic, because every other part of the programme has some give in it. They do not. And the slippage compounds, because whatever was queued behind the first item is now queued behind its delay as well.

The honest response is to treat those durations as fixed at the moment the programme is written, and to design the sequence around them rather than assuming they will bend. A programme built on optimistic assumptions is not an ambitious programme. It is a programme that will be rewritten, at a point when rewriting it is a conversation with a client rather than a spreadsheet.

Constraints are not the opposite of design

It is worth saying plainly, because the language around this subject tends to be defensive: a constraint established early is not an obstacle. It is information, and it is the most useful kind, because it arrives while the design still has the freedom to respond to it.

A height limit known at the outset shapes a massing study. The same limit discovered after the massing is approved deletes one. A ground condition understood before the structural strategy is set is a design input. Understood afterwards, it is a redesign. The constraint has not changed in either case. What changed is whether the architecture had the chance to make something of it.

Most buildings anybody admires were shaped by something they could not do. The constraints that damage projects are not the demanding ones. They are the late ones.

Common misconceptions

"A constraint discovered late is just bad luck"

Some unknowns are genuinely sequential rather than parallel. Mapping which is which at the outset is what determines whether the programme is a plan or a hope.

"A well-coordinated design is safer from late change"

It is actually harder to alter, because a change does not stay local. Coordination is what makes a design robust, and it is also what makes late change expensive.

"Constraints are the opposite of good design"

A constraint established early is information, arriving while the design still has the freedom to respond to it. Most buildings anybody admires were shaped by something they could not do.

"If a duration feels too long, it can usually be compressed with more effort"

Some project inputs depend on somebody outside the project. No amount of energy from inside it shortens that.

What good project planning actually does

The practical discipline is to establish, at inception, what the project must satisfy and in what order, and to hold that against the design programme as a live document rather than a one-off exercise.

• What does this project need agreement on, from whom, and by when?
• Which of those depend on each other?
• Which have durations we do not control?
• Which design decisions rest on answers we do not yet have, and so should be deferred rather than assumed?

None of these questions requires design work to answer. All of them are harder to answer once design work has been done, because by then each answer has a cost attached to it.

Holding those two sequences against each other is a large part of what design management and project management exist to do, and it is why we hold them as capabilities in their own right rather than as administrative overhead attached to design.

The question worth asking at inception

Not "how long will approval take", which is the question most programmes ask and the least useful one. The better question is: which decisions is this design about to depend on, and have they been made?

A project that can answer that at the start will still meet surprises. It will simply meet them while it can still afford them.

For the design sequence these decisions sit within, see the RIBA stages, which sets out what each phase decides and locks. For how appointments should be structured so that somebody owns this work, see choosing an architecture firm in the UAE. If you are planning a project and want to think through the sequence before committing to a programme, talk to us.