In this article (10 sections)
Everybody knows software projects run long. What almost nobody explains is why, and without that the conversation ends up being about asking the vendor to commit harder, which has never worked.
Timelines don't stretch for lack of commitment. They stretch for identifiable reasons, and most of them aren't on the side of the person writing the code.
Typical timelines
For an order-of-magnitude reference:
- A contained internal tool —a CRUD, a form, a report—: 1 to 3 weeks.
- An MVP or first version of a product: 3 to 6 weeks.
- A business system for a small company: 2 to 4 months.
- A system with several integrations and roles: 4 to 8 months.
- Replacing a legacy system in production: 6 months to 2 years, and it depends more on the migration than on the development.
One fact that sets expectations straight: calendar time is not work time. A 200-hour project doesn't ship in five weeks if the team is working in parallel with two other clients, and it doesn't ship in one week if you put five people on it.
The five real causes of a project running long
1. The scope grew and nobody wrote it down
The number one cause, by far.
It doesn't arrive as one big request. It arrives as twenty small ones: "while you're in there, add the field", "it would be good if it also sent an email", "couldn't it filter by date?". Each one is half an hour. Twenty of those are two weeks.
The problem isn't asking for them. It's that they don't get recorded as what they are. A change that isn't written down turns into a delay with no visible cause, and at the end of the month nobody understands why things slipped.
2. The client's decisions take time
This is the one that surprises buyers most, and it's the easiest to fix.
Development stalls waiting: what's the discount logic, who authorizes what, how are documents numbered, which of the three workflows is the real one. Every unanswered question is a day standing still.
Put one person with authority to decide and with time set aside for it. Not somebody who has to go ask and come back in three days. It's the cheapest and most effective intervention there is on a timeline.
3. The old data was worse than anyone thought
Names spelled five different ways, dates stored as text, duplicate records, balances that don't add up. Cleaning that wasn't in the plan and it always takes longer than expected.
And you can't skip it: a new system with bad data is born distrusted and never recovers.
4. The other system didn't cooperate
If the project integrates with something owned by a third party, the timeline partly depends on a third party. Incomplete documentation, test environments that don't work, support that takes a week to answer.
It's the part of the plan with the most variance and the one neither side controls.
5. Testing happened too late
If the first time a real user touches the system is in the delivery week, that's when the cases nobody accounted for will show up. And they all show up at once, at the worst possible moment.
What doesn't speed a project up
Adding people. A late project with more developers gets later at first: they have to be brought up to speed and coordinated. It works for genuinely parallel work, not for rushing something already in motion.
Skipping discovery. You save two weeks at the start and pay them back with interest in the middle, when it turns out the workflow was something else.
Asking for weekend work. It buys days, not weeks, and it lowers the quality of whatever comes next.
Dropping the tests. It's the fastest way to hit the date and the surest way to never finish, because what gets delivered comes back.
What does speed it up
Defining things properly before starting. A scope document with screens and business rules is the investment that saves the most time.
A single point of contact with authority. See cause 2.
Partial deliveries every two weeks. Not to show progress: to find out early what's wrong. A mistake caught in week 2 costs hours; the same mistake caught in week 10 costs days.
Taking things out. The only lever that really works on a date. If the date doesn't move, the scope has to. Any other combination is a promise somebody is going to break.
How to read a timeline in a quote
Three signs the number is serious:
- It's tied to a written scope, not to a conversation.
- It says what it needs from you and when: decisions, data, access, people to test.
- It has intermediate deliveries, not a single final date.
And one sign that it isn't: an aggressive timeline offered without hardly a question asked. Someone promising speed before understanding the problem isn't being fast, they're estimating blind, and you're the one who pays for that difference in month three.