A four-week delivery date is easy to write down and hard to believe, and the disbelief is well earned. Most buyers of software have been told a date, watched it move, and then been given a reason for the move that was true and also not their problem.
So this article does not argue that four weeks is achievable. It describes the shape of the weeks: what exists at the end of each one, what has to be true for the next one to start, where the work goes wrong, and what happens to the date when it does. If the shape is wrong for you, that should be visible from reading it rather than discovered in week three.
The scope this describes is one workflow. One process, with a defined beginning and a defined end, running against systems that already exist. It is not a platform, not a data warehouse, and not a program of several connected builds. Most of the credibility of a four-week delivery date comes from that boundary rather than from working faster.
Week One: The Process Becomes A Written Specification
The first week produces no software, and it decides whether the other three work.
Two or three sessions walk the process with the people who perform it, not with those who describe it in a management report. Those are different processes, and the difference is where builds usually fail. The steps that never appear in the documented version — the check somebody added after an incident two years ago, the message sent before the batch runs, the case where the rule does not apply — come out here or in week four.
Then the exception census. For one recent period, every item that did not follow the main path is listed with what happened to it. This is normally a surprise for everyone in the room. The exception rate is either much lower than believed, in which case the build is simpler, or much higher, in which case the exceptions are the product and the main path is trivial.
The week ends with a written specification: the records the workflow must produce, the order the steps run in, the identities involved, the systems it reads from and writes to, the acceptance targets, and an explicit list of what is out of scope. That last list is the one that makes the date possible, and it is agreed before any work begins. The reasoning behind it is in what it takes to get from clear requirements to something running in production.
Week Two: A Release You Can Open
By the end of week two there is a running version, in a real environment, that you can open and use. It handles the main path end to end on data shaped like yours.
It is deliberately not a demonstration. A demonstration is designed to be shown; this is built to be used badly by the person who performs the step, so the specification meets reality while it can still change. It will be wrong in specific ways, and those are the point.
What almost always changes after that first session is not the logic. It is the shape of the work: a screen that asks for things in the wrong order, a field that should default from the previous item, a status that means two different things to two teams. These are cheap corrections to make in week two and expensive ones to make in week four.
The purpose of week two is not to impress you. It is to be wrong in front of you, early, while correcting it still costs nothing.
Week Three: Integrations And The Record
Week three is the week with the risk in it, and there are two reasons for it.
The first is that integrations are where other people's systems set the pace. Credentials, a sandbox that differs from production, a rate limit nobody documented, a field that is free text in one system and a fixed list in the other, a date without a time zone. None of it is difficult. All of it depends on access, and access depends on somebody outside the project.
The second is the record. This is the part that is easy to defer and expensive to add later: who performed each step, when, on which version of the input, who reviewed it, what was rejected and on what basis, and where all of that is retained. When the workflow exists because of a disclosed control finding, the record is not a feature — it is the deliverable, and the rest of the software is the mechanism by which it is produced.
By week's end the workflow runs on the real systems, with real credentials and a real trail.
Week Four: A Release In Use
The last week is narrower than people expect, which is intentional.
The release is put into use alongside the existing process for a defined period of time, so that both of them produce results, and those results are compared. Each difference is investigated rather than being assumed to be a defect in the new system; a meaningful share of those differences turn out to be undocumented behaviour in the old system.
Then week one's acceptance targets are run in front of you, the production rollout is agreed from what that use showed, and what you have paid for transfers: the repository, its history, the documentation, a run guide. It is kept running by the person who built it, which matters because the failures that appear in week five are not ones anyone predicted in week one.
Where It Goes Wrong, And What It Does
Estimation research is not encouraging about optimism. The systematic review of software development cost estimation studies (Jørgensen & Shepperd, IEEE Transactions on Software Engineering, 2007) and the review of expert estimation of development effort (Jørgensen, Journal of Systems and Software, 2004) both document persistent underestimation across decades of practice, and find little support for the idea that better estimation technique fixes it. The response here is not a padded estimate. It is a bounded scope and a written boundary, so the date is protecting something small enough to be defended.
Five things go wrong regularly. Here is what each one does to the schedule and the release.
| What goes wrong | Frequency | Effect | On the release |
|---|---|---|---|
| Access or credentials arrive late | Most common by far | Elapsed days, not work | The date moves by the delay |
| An exception class nobody mentioned | Common | More logic than planned | Fits the agreed release, or goes into the next |
| Source data is worse than described | Common | Cleaning and matching work | Part of the work; finding it is the job |
| The required approver is unavailable | Occasional | A week-four acceptance slips | The date moves; the work is already done |
| A requirement changes after week two | Occasional | Rework | Fits the agreed release, or goes into the next |
The honest version of a written scope is not that nothing can change. It is, instead, that the release is agreed before work starts, what it covers is put down in writing, and a change to it is agreed before it is built. Changes outside that scope go into the next release, in writing, rather than being added quietly to a schedule, which then slips without explanation.
There is one failure no scope survives, and it is worth saying plainly. If system access does not arrive, no engineering effort produces a working integration. That is why access is asked for in week one, tested in week one, and escalated in week one rather than week three.
How The Work Stays Visible
Every engagement runs in TopDo, our own system for work that people and AI do together. The specification and the tasks are the same items, so the plan and the work cannot drift apart, and every change is on the record with a time and an author. You have access to it from the first day, and the workspace stays yours after the work ends.
This is not a reporting convenience. What it does is remove the weekly status call as the only window that you have into the work, which is the mechanism by which a schedule will normally slip for three weeks before anyone outside the project finds out.
First Steps
- Write the scope boundary yourself before anyone quotes you. One paragraph: where the workflow starts and where it ends, and three things that it explicitly does not do. If you cannot write it yourself, then that paragraph is the scoping conversation.
- Find out today how long credentials take at your company. Ask the person who grants the credentials, not the person who requests them. That waiting time is the most common reason that a four-week release turns into a release of six weeks.
- List the exceptions for one recent period. Not the volume — the list. It determines whether the build is simple or complex, and it takes an afternoon.
Buy The Shape, Not The Promise
A four-week date is credible when the scope is one workflow, the specification is written before the work starts, and something usable exists in week two rather than week four. It is not credible when the scope is a whole platform, when the requirements are being discovered during the build, or when the first thing you see is the final delivery.
A fifteen-minute call — nothing paid, nothing signed — tells you whether the workflow fits this shape. Where it does, one workflow becomes working software, with each release agreed before work starts. Targets are written first, and the repository transfers to you as it is paid for. Afterwards, $10,000 a month puts one accountable person on keeping it running.
If a piece does not fit, the useful outcome is knowing which piece, in week one.
References
- Jørgensen, M., & Shepperd, M. A Systematic Review of Software Development Cost Estimation Studies. IEEE Transactions on Software Engineering, 2007.
- Jørgensen, M. A Review of Studies on Expert Estimation of Software Development Effort. Journal of Systems and Software, 2004.
