Estimates, Milestones and Change Requests: Keeping a Build Predictable

Estimates, Milestones and Change Requests: Keeping a Build Predictable

Predictability in software projects does not come from accuracy at the start. It comes from three mechanics that keep everyone looking at the same picture as the work proceeds.

Estimate in ranges, with assumptions

A single number implies a precision that does not exist at the beginning. A range with its assumptions attached is more honest and more useful: "two to four weeks, assuming the payment provider is already chosen". When the assumption breaks, both sides know which part of the estimate moved. Written assumptions are also how disagreements surface early instead of at delivery.

Slice into milestones that mean something

Milestones should be verifiable: a person can log in, an order can be placed end to end, a report can be generated. Time-based milestones ("week three") tell you nothing about progress, because a late week cannot be caught up. Vertical slices that include interface, backend and data are what allow real evaluation.

Make change a written event

Every project changes once real software meets real users. The mechanism matters more than the rule: a short written description of the change, its effect on scope, cost and date, and a decision made explicitly rather than absorbed silently. Small changes are absorbed; material ones are decided. What destroys trust is the third category, where work is done informally and the surprise appears on the invoice.

Review the forecast regularly

Re-plan from what is known now, not from what was hoped in the first week. A forecast that is re-checked every milestone is rarely a shock by the end.

The part clients control

Availability of the person who decides, speed of feedback on working increments, and access to the systems involved. These three move dates more than any technique on our side.

How we run it

Every project at Black Origin IT moves through discovery and planning with estimates written down, then through development with reviewable increments and agreed handling for change.

Want a build you can predict? Send us a project description and we will start with the assumptions.