Waiting on the architect, again
The structural engineer cannot finalise the ground floor transfer beams until the architect confirms the shopfront openings. The drainage design is waiting for a CCTV survey the client has not commissioned. The building services engineer needs the kitchen equipment loads from a specialist nobody has appointed yet. Each is mentioned at the design team meeting, noted in the minutes, and forgotten until the next meeting.
When the programme slips, the conversation turns to why the engineering is late. The honest answer, that you have been waiting for information, is hard to prove without digging through minutes and emails.
Why information requests drift
- Requests are made in meetings, emails and phone calls, with no single list.
- The information required schedule is updated only before meetings, if at all.
- Required-by dates are not linked to your programme, so urgency is unclear.
- Chasing depends on the engineer remembering and feeling comfortable doing it.
- When information arrives, nobody closes the item or checks it was complete.
It is also a question of tone. Engineers do not want to look like they are nagging the architect, who is often the client's lead consultant and a source of future work. So requests are made politely once, then left, and the missing information becomes a problem that nobody raises until it is urgent.
What waiting costs
| Gap | Consequence |
|---|---|
| Requests not tracked | Engineers wait without anyone noticing |
| No link to programme | Late information discovered too late to recover |
| No record of dates | Delay blamed on the engineering |
| Rework when information arrives | Fee spent twice, often unrecovered |
Late information is one of the main reasons engineering stages overrun. A clear record is also what supports a request for additional fees when it does.
How we build a live information schedule
- Engineers log a request in seconds: what, from whom, needed by when, and which design element it holds up.
- Requests can also be created from a design team meeting's action list or from an email, with a forwarding address.
- Each item has a status: requested, chased, received, received but incomplete, closed.
- Reminders go to the responsible party on the dates you set, from the engineer's name or a project address, with the engineer copied.
- When information arrives, the engineer confirms it is complete, and the item closes with the date.
- The schedule is produced in your format for design team meetings, sorted by urgency.
- Late items link to your fee and programme records, so the effect of waiting is visible when it matters.
The schedule belongs to your practice, but you can share it with the lead designer or project manager, which often helps more than any chaser email.
We usually load the current information required schedule from your existing spreadsheet for each live project, so nothing is lost at the switch. The chasers are worded with you, so they sound like your practice and suit the relationships you have with each design team.
Design team meetings afterwards
The schedule is current before anyone walks into the meeting. Discussion focuses on the few items that are holding things up. Chasing happens between meetings without anyone having to remember.
When a programme question comes up, you can show exactly when each piece of information was requested and received.
Are your engineers stuck like this?
- Engineers are regularly waiting on information from others.
- Your information required schedule is updated only before meetings.
- Chasing is inconsistent.
- Nobody links late information to programme or fee.
- Delays get blamed on the engineering.