How Long Do Things Really Take?
February 2026 - Estimated reading time: 6 minutes.
Introduction:
One of the most common questions clients ask is how long a project will take. It’s a fair question — but it’s also one of the hardest to answer with certainty. That isn’t because architects are evasive or because the process is poorly managed. It’s because construction is complex, involves many moving parts, and depends on factors that sit well beyond any one person’s control. Understanding that early helps set realistic expectations and reduces frustration later on.
Construction is inherently complex:
Even relatively modest projects involve multiple stages, consultants, statutory approvals, and decision points. Information is developed progressively rather than all at once, and each stage builds on the last. Design, planning, technical approvals, procurement, and construction all move at different speeds — and often overlap. A delay or change at one stage can have a knock-on effect elsewhere. This complexity isn’t a flaw in the system. It’s the reality of turning ideas into something that can be safely, legally, and responsibly built.
It will likely take longer than you think:
Most people underestimate programme at the outset. That’s not unreasonable — much of the work happens before anything physical appears on site. Time is spent developing design, coordinating information, responding to feedback, and securing approvals. None of that is particularly visible, but all of it is essential. Rushing through these stages rarely saves time overall. More often, it simply shifts problems further down the line, where they are harder and more expensive to resolve.
Delays are common — and not always avoidable:
Almost every project encounters some form of delay. Planning authorities may take longer than anticipated. Building standards may request additional information. Surveys can uncover unexpected conditions. Third-party consultees may introduce new requirements. Contractor availability can change. Many of these factors sit outside the direct control of both the client and the architect. A good architect can manage the process, coordinate responses, and advise on next steps, but they can’t eliminate uncertainty altogether. What matters isn’t whether delays occur, but how they are anticipated, communicated, and responded to.
Decisions influence programme more than drawings:
One of the biggest drivers of time on a project is decision-making. When key decisions are clear and timely, information can progress. When decisions are deferred, progress slows. That often leads to compressed programmes later on, where pressure increases and mistakes become more likely. Taking time to resolve issues properly when they arise usually saves time overall, even if it feels slower in the moment.
Why rushing and cutting corners rarely helps:
Pressure to move quickly often leads to corners being cut. That might mean progressing with incomplete information, making assumptions that haven’t been properly tested, or pushing work forward before it’s ready. Those decisions tend to resurface later as redesign, rework, or dispute, all of which cost time. The same applies to attempts to “save time” by reducing design input or skipping steps. What is saved early is often lost several times over during construction.
How this is managed in practice:
While not every delay can be avoided, the way a project is managed has a significant impact on how those delays are experienced. A key part of my role is to help clients understand where time is being spent, what information is still outstanding, and what decisions are needed to allow the project to progress. That means communicating clearly, flagging risks early, and being honest about what is known, what isn’t, and what needs to happen next.
Due diligence is central to this approach. Time is invested early in gathering the right information, coordinating with consultants, and testing assumptions so decisions are made deliberately rather than reactively. When issues arise, as they often do, the focus is on understanding their implications before rushing to a solution. Just as importantly, it means advising when it is sensible to pause, clarify, or rethink aspects of the proposal, rather than pressing on for the sake of programme alone. That can feel slower in the moment, but it usually avoids far greater disruption later.
The aim isn’t to promise a smooth or delay-free process - that wouldn’t be realistic. It’s to guide projects through complexity with clarity and proportion, so time is spent where it adds value rather than correcting avoidable mistakes.
In summary:
Building projects take time because they involve complexity, coordination, and uncertainty. Delays are common, and not all of them can be controlled. What can be controlled is how decisions are made, how information is managed, and how clearly the process is communicated. Rushing rarely leads to better outcomes. Cutting corners almost always leads to additional time and cost later on. Understanding this from the outset helps projects move forward more calmly, more deliberately, and with far fewer regrets.