A client asks how long the design will take. The answer is ten to twelve weeks and everybody writes it down.
Nobody says that ten to twelve weeks assumes a survey booked immediately, information arriving from two other consultants, one statutory approval and three client decisions made without delay.
Five months later the consultancy is blamed for a programme that was never about them. The estimate was defensible and the dependencies were never stated, which is the same thing as being wrong.
1. Separate the work from the waiting
Design time and elapsed time are different numbers. Most of a programme is spent waiting for something external, and a client who understands this manages the project rather than blaming it.
2. Name the dependencies explicitly
Surveys, ground investigation, statutory approvals, utility responses and information from other parties. Each of these has its own timescale and none of them is yours to control.
3. Name the client's own dependencies
Decisions, approvals, access, information and sign offs, with the dates by which each is needed. This is the most commonly omitted part of any programme and the most common cause of slippage.
4. Break the programme into stages
Feasibility, concept, developed design, technical design and construction information. A single duration hides where the risk sits and prevents anybody managing it.
5. Identify the critical path honestly
Which single item, if delayed, moves everything. Naming it lets the client concentrate their effort where it actually matters.
6. Be realistic about statutory timescales
Approvals frequently take longer than the published period, particularly where additional information is requested, and building in an optimistic figure sets up a visible failure.
7. Explain the seasonal constraints
Ground investigation, ecology surveys and certain assessments have windows. Missing one can delay a project by months and it is invisible to a client.
8. Avoid the date everybody wants to hear
An optimistic programme wins an appointment and loses a reputation. Clients remember the first date they were given and measure everything against it.
9. Ask what is driving their deadline
A funding date, a lease expiry, a planning condition or a board commitment. A hard date changes the sequencing and it should be established at the first conversation.
10. Explain what could be run in parallel
Some things wait unnecessarily. Identifying what can start before something else finishes is frequently the single largest programme saving available.
11. Explain the coordination overhead
Multi discipline projects spend real time on coordination and review, which is the ground in multi discipline project questions from developers.
12. Update the programme rather than defending it
A programme revised openly when something changes preserves trust. One defended after it has clearly slipped destroys it.
13. Establish the scope before quoting a programme
An unscoped project cannot have a meaningful timescale, which is the groundwork in scoping and feasibility questions from new clients.
14. Give an honest range at the first enquiry
An assistant that asks about the project type, location, existing information, approvals needed and the client's own deadline can give a properly qualified range immediately instead of a number that will be quoted back in six months. The same honest timeline handling appears in how long a website takes and other timeline questions and the fit matching in ai shopping assistant product fit. See features, start at try, and the sector view sits under b2b.