Development estimates rarely blow up on the hard features. They blow up on the parts you don't control

Every line in the estimate was filled in, and the lines that overrun are usually the same few: equipment integration, third-party system integration, vendor integration.

It isn’t that development is slow. These parts aren’t yours to manage. When the other side has time, when the interface arrives, when the equipment is tuned: none of that is your call. The fix is to list these three on their own, not mixed in with the functions, and to write into the plan what the other side has to deliver and by when.

This post covers four things: how requirements turn from a blueprint into development tasks, how the estimate is split, how many rounds of testing there are, and who takes new requests that come in during development.

1. Development requirements come from the business blueprint, and get explained before coding

A signed blueprint is written in the language of the business: flows, roles, documents. Developers don’t read that language, so someone has to translate.

This is how we do it:

1. The product manager designs the functional logic from the business blueprint: for each step in the flow, how the system decides and what it does
2. A product design document: the logic, screens, fields and rules of every function
3. Walk the developers through it: the product manager explains it in person until the developers understand and have asked their questions
4. Then development starts

Step 3 is the one most often skipped. The document is sent over and that counts as the handover, developers build to their own reading, the result doesn’t match the blueprint, nobody finds out until testing, and the rework takes far longer than one walkthrough would have.

2. The development estimate is split by function, then planned with the project manager

The dev lead does the split. Each function is broken down into front end, back end, interfaces and so on, and each part gets:

• Effort: how many days
• Finish date: which day it’s done
• Developer: who builds it

Once it’s split, the dev lead and the project manager agree the development plan and timeline together. The project manager holds the go-live milestones, the dev lead holds the people and the effort; only a plan both have checked can actually be run.

The post on project kickoff said every line in the function list is marked “reuse” or “modify.” Reuse is mostly configuration; only the modified functions need to be split down to front end, back end and interfaces like this.

What’s most often estimated wrong is the three parts you don’t control:

• Equipment integration: the equipment supplier’s on-site commissioning decides when you can integrate
• Third-party system integration: their schedule, their interface spec, their test environment are all in someone else’s hands
• Vendor integration: the vendor’s systems and people move at a pace you can’t set

However hard a function is, the people and the time are yours, so you can estimate it. These three depend on someone else, and they’re usually the lines that overrun. So list them on their own, not mixed in with the functions; write into the plan what the other side has to deliver and when, and ideally also into the “assumptions and constraints” chapter from the kickoff post.

3. System testing in four rounds: internal first, then business users

Our testing has four rounds:

1. Unit testing: developers test their own work, each function on its own
2. Integration testing: several functions and several systems run together
3. Equipment integration: running with the equipment, such as the automated storage and AGVs
4. User testing: business users run simulated business scenarios in the test environment

There’s one rule about the order: internal testers finish first, and only when nothing blocks do business users come in. Business users already have full jobs. If they make time to test and get stuck on the first screen, they won’t want to come back. Internal testing clears the path, so business users don’t get stuck when they arrive.

4. New requests during development: through the project manager first

Halfway through development, the business asks for something new. It happens all the time. What we do:

• The project manager assesses it first: accept it or not, and whether it counts as a change
• If it’s accepted, then schedule it: where it goes, what it pushes out, whether milestones move
• Developers don’t take requests from the business directly

The last one matters most. When developers take requests straight from the business, one “just add this while you’re at it” goes into the code with no assessment, no schedule and no record. Enough of those and the estimate stops meaning anything, and the milestones slip with it.

---

Do your developers take requests straight from the business?