I work with a company that has the following set of milestones in its standard project methodology:
- Vision/Scope Complete
- Requirements Complete
- Design Complete
- Definition Complete
- Build Complete
- Test Complete
- Rollout Complete
I’ve noticed an interesting pattern at the weekly enterprise status meetings: a significant number of projects report being exactly on schedule for each milestone — not one single day ahead or behind! — until they get to rollout, at which point they suddenly go several months late.
Some things can be faked and some things can’t. As long as you have milestones that can be met simply by declaring them done, or by signing off on a document, you can always hit them on time.
But when it comes to putting actual working software in front of a customer, that’s when you really have to deliver the goods, and that’s when the milestones start getting missed.
This is a very high-risk approach to software projects. Deferring testing to the end of a project guarantees that if your project fails for any reason — and if your testing is honest, there’s always some non-zero probability that it will fail — you will have already invested in the entire cost of construction.
That’s why the history of software engineering is littered with big-ticket disasters. You never really know what you’ve got until the end, after you’ve spent all the money.
It’s also a good argument for iterative, incremental development. If you have to deliver working software early and often, you can’t fake it.
Thus spoke The Programmer.