Estimating Client Project Timelines: A Habit That Improved Accuracy

I’m Charles Liu, CEO and Marketing Director of Cubic Promote.

We supply promotional merchandise and uniforms across Australia, including large event orders where several people may need to sign off before production can begin. That can make timelines uncertain because we do not start production until the artwork mock-up has been approved.

The way we handle it is by making the dependency clear from the start. We do not set a final dispatch date while artwork is still awaiting approval. Instead, we explain that the production timeline officially starts once approval is received.

For standard production, that may be around seven days depending on the item and order. If the client needs a much faster turnaround, we also offer rush options, including 24-hour production on selected products at an additional cost.

The single habit that has improved our estimates most is not committing to a deadline before artwork approval. It sounds simple, but it prevents us from promising a date based on a stage we do not yet control.

Transparency is key. Clients are usually comfortable with the timeline when they understand exactly what needs to happen before production starts and how each approval affects the final delivery date.

Charles Liu

CEO and Marketing Director

Cubic Promote

My company, TKEG Expat, a corporate-services firm that manages 120 companies across 22 jurisdictions, commits a hard deadline on the part of a project that sits with us, and gives the part that waits on the client or a bank its own buffer. Of our 148 company-incorporation packages, 118 are gated on documents the client supplies, a median of six each. Bank accounts are the extreme case: 80 of our 82 bank-account-opening records carry no turnaround estimate. Moreover, under Article 14(1) of Directive (EU) 2015/849, the bank must verify the customer’s and beneficial owner’s identity before the business relationship is established. There is no buffer or lead-time field anywhere in our system, so the buffer is operating practice instead of a system field.

The single habit we rely on most for time estimates is reading the catalog quote against our own completed engagements. For example, our Poland incorporation quote is 5 business days and covers the registry step, whereas the five completed Polish engagements on our record, four of them linked to that 5-day catalog record, ran far longer, 46.0 to 114.6 calendar days from engagement start to registration (median 72.6, document collection included). However, as our record carries no registry-submission timestamp, it cannot show whether the registry step itself held.

I start with the riskiest unknown first, not the easiest task. That tells me fast if the timeline is realistic or if I’m lying to myself.

I build buffers around dependencies, not around effort. Most delays come from waiting on someone else, not from the work itself.

The habit that changed everything for me is a midpoint check-in, not a final review. I ask my team what’s behind schedule at the halfway mark, when there’s still time to fix it.

That single checkpoint has saved more launches than any planning document I’ve ever built. People are honest about being behind when there’s still room to recover.

I’d rather have an uncomfortable conversation on day five than a missed deadline on day thirty.

Eleven years running client services delivery, mostly on projects scoped before anyone understood them.

Buffers do not protect anything. A padded deadline gets treated as the real one and consumed by week three, because nobody works slower to preserve a cushion. What protects quality is committing to less when you know least.

Do not estimate the project. Estimate how long it takes to find out what the project is.

So the first commitment is small and specific: two weeks to produce a scope we will both hold to, and no date for anything beyond it. Clients accept this far more readily than they accept a confident number that moves twice.

The habit that improved my estimates most is recording what I originally guessed alongside what it took. Most people never look.

It requires a client who tolerates a staged commitment. Fixed-bid procurement often does not allow it.

Fire and security work taught me planning to deadlines of inspection dates, not final finish dates. I’ll build in buffers for the things that normally delay our inspections, typically things waiting on equipment. By phasing the build and not delaying until we had final installation on everything, we eliminated a good majority of what caused chain delays on those projects. Now I use real history from old jobs, not hunches, when I build those buffers so we always have the capacity not to cut any corners of quality for a client change.

Uncertainty at kickoff is not a reason to avoid committing. It is a reason to commit to a range and to be explicit about which parts of that range you actually control.

Four things I do at kickoff. Estimate in ranges rather than points, with the drivers named. A duration of six to nine weeks with the reasons stated is more useful to a client than seven weeks that everyone privately knows is fiction. Put the buffer in one place at the end, owned by the project, rather than distributing it into every task. Buffer spread across individual activities gets consumed silently, because work expands to fill whatever each person was handed. A single visible reserve gets managed. Size that reserve against the specific unknowns rather than as a flat percentage: three unresolved scope items and an approval chain with no named decision-maker deserve more reserve than a well-defined repeat of last year’s project. And write down the assumptions the date depends on in the kickoff document. “This date assumes approvals within five business days.” When an approval then takes three weeks, the conversation is about the assumption rather than about whether you are slow.

The habit that improved my estimates most is comparing estimate to actual at closeout on every project, and keeping the results where the next estimate can see them. Not a formal postmortem, just duration and effort logged against what was predicted. Within a handful of projects, you learn your own bias, and almost everyone has one running in the same direction. Mine was underestimating review and approval cycles, never the production work itself. Once it was written down, I stopped repeating it.

The checkpoint that protects quality is a midpoint review against the original assumptions rather than against percent complete. Percent complete tells you what has been spent. The assumption review tells you whether the date is still real.

With custom orders, timelines get uncertain fast once you factor in artwork approval, proofing, and any back and forth on details. I build in buffer time around the proofing stage specifically, since that is where delays usually start, not because production takes longer than expected. If a customer takes a few extra days to approve a design or requests a change, that pushes everything else back even if the actual production time stays the same.

The habit that has helped our estimates most is treating proof approval as its own checkpoint with its own expected window, instead of lumping it into the overall production timeline. Once we started tracking that separately, our estimates got a lot more realistic because we were not blaming production for delays that actually happened earlier in the process.

I mitigate the risk of projects’ long-dated timelines by designing phase-gated delivery-point deadlines strictly based on vendors’ lead-time SLAs and client dependency sign-offs, with a mandatory 20% operational buffer in between instead of adding a single buffer point at the delivery deadline. Buffers should be designed after major deliverables, such as CAD drawing sign-offs, material allocations, and freight staging, not at the end of the project to avoid timeline inflation from intermediate delays. The practice that has proven to improve time estimation in our team for client services projects was introducing a mandatory technical audit checkpoint right after the initial discovery session. This way, our engineers and supply chain managers review all job-site measurements, material lead-time requirements, and fabrication limitations to establish the baseline project schedule with hard deadlines, which are then formally approved by clients. By designating hard client sign-off points for each project phase and formally reviewing actual supply-chain constraints during the technical audit, I mitigate time-related risks and ensure the delivery of high-complexity projects within the initially negotiated master schedule completion date.

I build the buffer around the riskiest dependency, not the whole project. On a launch with fourteen people, we estimated a third-party integration at two days, and it took eleven. By week three, the maths didn’t work, so I gave the client a real choice: launch on time broken, or three weeks late and working. They chose late and working. The habit that most changed my estimates is flagging the riskiest dependency at kickoff and checking it weekly.

I’d want to see some of the actual records before committing to a firm completion date. A client can quite reasonably say they’ve sent everything, but that doesn’t tell me whether the accounts reconcile or whether we can trace the figures back to supporting documents.

The checkpoint I’d use is an early walkthrough of a small selection of records with the person who’ll do the work. Can they follow a transaction from the ledger to the invoice and bank entry? Can they open the files and get into the accounting system? It won’t uncover every issue, but it gives us a better basis for estimating than a checklist showing that documents have arrived.

At kickoff, I’d give a provisional timetable and explain what it assumes. After that initial check, I’d confirm the dates with the team and client, including who will answer questions and how quickly they can respond.

I’d allow time for follow-up questions and review before the delivery date. If the records need substantial tidying up, I’d estimate that work separately so it doesn’t quietly use up the time meant for checking the finished work.

I’d also avoid promising that documents arriving two days late simply move delivery back by two days. We may have other work booked in by then. I’d check the remaining work and team availability before agreeing a revised date. That makes it easier to give the client a timetable we can actually work to without squeezing the review into whatever time is left.

Schedules become fragile when people feel compelled to report confidence they do not possess. At kickoff, create space to name uncertainty without penalty, then convert each concern into an owner, a test, and a decision date. This beats adding contingency because it reveals whether the risk belongs to capability, information, or governance. Risks need different buffers.

The checkpoint that improved estimates is the red-flag round after planning. We invite the least experienced person to speak first because hierarchy hides information that changes a forecast. Once concerns are heard, the plan is updated with the tradeoff needed if the deadline cannot move. That habit builds partnership. Clients see candor, and teams learn that protecting quality is a responsibility.

When the timeline’s uncertain at kickoff, break work into fixed quality gates first. Add time buffers only on variable discovery or revision phases. Never add them on core deliverables to protect quality without slipping. A mandatory mid-sprint scope freeze and re-estimate checkpoint with the client before final buffer lock most improves time estimates.

The thing that saved me was setting a hard check-in one week before every deadline. I review campaign progress, ad approvals, and content, then call clients immediately if we’re behind. This keeps us honest. On a recent launch, we spotted creative delays and reallocated resources fast. You have to build in this final check to find what your initial plan missed.

I don’t set hard deadlines for complex integrations. Not until we’ve mapped out the technical side and confirmed we can get into everything we need, like the insurer’s sandbox. We rushed a project once and missed a tiny API detail that set us back two weeks. Now I just keep a running list of past projects to ballpark the timing. If things feel uncertain on your end, start tracking what actually slows you down. Spotting the real problem early beats wishing for a perfect plan every time.

The best thing we do for Kunkune’s holiday launches is finish 20% early. I mean, 20% before the customer deadline. That date is locked; no one moves it. This gives us time to make sure we actually have the stock and test those bundles one more time before everything goes live. But the real game-changer is timing how long it actually takes to pull and pack orders after each big push. Our time estimates are finally getting good.

For campaigns with shaky schedules, I never send a timeline immediately. I make myself wait 24 hours and get a colleague who remembers our past messes to give it a look. We always underestimate how long things can get stuck, like influencer approvals or surprise edits. That quick review has saved me so many times. My trick is to build buffer time right into those specific problem spots, not just the whole project. That’s where everything actually falls apart.

The biggest adjustment we’ve had on timelines was putting to bed my reliance on just *our* timelines. I was used to planning projects around what was possible for our team to produce, not considering response times on the client side at all! I remember the initial surprise when we’d ask clients about their typical approval time and suddenly we were right on the money with our estimates for approvals!

Setting expectations for their turnaround time has removed a massive portion of the guessing. If you deal with clients, this cannot be reiterated enough.

I always set a deadline backwards from the one real date my client cares about. Typically, there’s one real date for a project: the launch of a product, a board meeting, a lease signing, etc. All the other milestones are up for negotiation. And I’m very strict about that one date, and very flexible about the other dates that make up the rest of the project milestones, which are soft and subject to change.

As for buffers, I build in trust time, not just work time. In other words, the client needs time to decide, to get others involved (e.g. their manager, senior colleagues, etc.), and yes, there is even a chance they get cold feet and come back to you later. And it’s exactly at the moment of commitment that all momentum comes to a standstill. By rushing the client through this pause, you may get a yes only to have them change their mind later.

My best practice for estimating a project is to have one simple conversation at the beginning of the project. I ask the client to share their worst project experience and why it happened. Typically, this surfaces how a client behaves in crisis mode. Are they slow to approve things? Do they make last-minute changes? Do they “disappear” at the worst time? This one story typically gives me a much better sense of the true timeline of a project than any Gantt chart. I estimate people and then the work, and it’s the people that usually end up moving the date.

We started using two deadlines and it’s been a game-changer. One is an internal date for our team to finish drafts, and the other is the date we give the client, with a few days of buffer built in. It took a minute to get the hang of it, but now last-minute creative tweaks or compliance fixes don’t send us into a panic. I’d figure out where your projects usually snag and add extra time there. That simple trick has saved us so many times.

For manufacturing projects with shaky timelines, I learned to build a quality check into every major step. At Haizol, we started adding small time buffers for things like supplier qualification and prototype approval. This stopped the last-minute scrambles and kept our quality from slipping. Now we look at how much buffer time we used versus our defect rate every two weeks, which helps us plan the next project better.

The biggest lesson I have carried from agency work into product and project management at Slickplan is that uncertain projects need structure before they need precision. I start by breaking the work into smaller milestones, identifying technical unknowns and dependencies, and separating the scope we truly need from anything that can move if the project gets tighter.

Most estimate misses come from hidden technical complexity or work that depends on other people and systems. That is why I do not treat the kickoff estimate as fixed. Once discovery and planning are complete, I re-estimate with better information and tighten the schedule from there.

That checkpoint has done more for accuracy than simply adding generic padding. The first estimate should help you plan the work, not pretend uncertainty does not exist. Estimate what you know, isolate what you do not, and update the timeline when the unknowns become clearer.

When a restock or a dispatch timeline is fuzzy at kickoff, I publish a short checkpoint and a workaround, not a heroic Monday I cannot defend. Quality holds when the customer can still choose wait, swap, or refund before the carton moves.

The habit that improved estimates is naming the next update day in the first email, even when I do not yet have the ship date. Wash days sat 4.8 days apart. Someone waiting on Oyin Hair Dew planned that hour around a bottle. Buffers sit in the open as a Thursday write-back, not as silent padding. A fuzzy supplier promise becomes a clear customer promise, or it does not leave this desk.

If I can see the deadline is dodgy, I break tasks down a little – and throw in an extra 25% for each element. This also helps – I now let clients know specifically when something should land back with them – and then the final product feels a bit tighter. My own game changer?

Taking out old templates and slotting my errors in where necessary. With a team, identify your perennial choke-points and work around them.

Every project we do needs to have some kind of timeline so that we can structure our goals and speed around it. So, if the timeline is uncertain at the start, what we will likely do is just create a timeline estimate. We’ll think about factors like how long similar projects typically take, how fast we think we’re able to get it done, what expectations are among those we’re doing the project for, and things along those lines. With an estimated timeline, we’ll then communicate what we are currently aiming for while also explaining that it is just an estimate and that the actual outcome might be slightly different.

At kickoff, we treat an estimate as conditional. It states the proposed stack, expected team shape, third-party services, and the scope questions still open. We pair the hours range with the risks and a mitigation for each, so the client can see what may move the estimate.

We also define success before treating any date as a commitment. At Ronas IT, the project manager confirms the success criteria with the client, and the tech lead checks whether those criteria are technically feasible or contradictory. The kickoff plan connects them to milestones and constraints. If an assumption changes, we can show exactly which milestone moved and why. The team can adjust scope or sequencing before testing and review time get squeezed, which protects quality.

The checkpoint that improved our estimates most was putting the estimate’s conditions inside the estimate itself. An estimate can look precise while everyone is carrying a different version of the proposed stack or team setup in their head. Writing those conditions next to the range exposes disagreement before delivery starts. Revisit them when an assumption changes and tighten the range as unknowns close.

Ask for a date together with its assumptions and the next checkpoint for revising the range. If the assumptions aren’t visible, the buffer can’t protect the schedule because nobody knows what event is consuming it.