January 25, 2007
Milestones & ObjectivityMilestones are an important part of any project's lifecycle. They help us to know how far we've come and how much further we have to go. But they are often abused in the project management process. Many developers complain about project managers deciding arbitrarily that a milestone has been reached when, in reality, they still have far to go. Typically this abuse happens when deadlines arrive. "Well, we said it would take six weeks to get our initial use cases agreed, and that was six weeks ago, ergo we have reached that milestone." The fact that - in reality - you haven't agreed any use cases is neither here nor there. If the boss says you reached the milestone then you reached the milestone.
By far the most commonly abused milestone is when the software is supposed to be ready to be released to the end users. The deadline is looming, and the project is lagging way behind schedule (having bulldozered our way through several previous milestones so that we now have no clue where we really are in the lifecycle). In theory, the customer must acceptance test the software, and only when they're happy that it's good enough for release have we finally reached this critical milestone.
I've seen projects that were - on paper - supposed to be in the final stages of acceptance testing when not a single line of code had been written. That's an extreme case, but on average projects tend to be 40-60% further behind schedule than the customer's being told. When a 12-month project is due to be delivered, I know from experience that there'll be another 4-8 months of faffing about afterwards.
Imagine instead of building software, our goal is to climb a mountain. We commit - or rather, our project manager commits - to reaching the summit in 5 days. On the 5th day we are only half way to our goal, but we plant a flag and pretend we're at the top anyway, just so our sponsors know we didn't fail. Then we spend the next 5 days doing "maintenance climbing", while we pretend that we're actually climbing an even higher peak that our sponsors have asked us to conquer.
This is how project teams fall further behind with every "successful" delivery. Every time we pretend we've reached a real milestone, we raise the expectations of our customers, so in the next cycle we have to work twice as hard and pretend twice as convincingly when the next deadline arrives. This state of affairs is, of course, unsustainable. The software itself can't pretend. It either works or it doesn't. It's either maintainable or it isn't. Eventually the reality catches up with us and there's no escaping it. (Except, of course, that most of us will have moved on by then.)
Which is why it's critically important that we track our progress as objectively as we can. No matter how bad the reality looks, I can assure you it'll be ten times worse if you choose to ignore it and pretend all is rosy. By far the best source of progress information on a software project is test results. If it isn't tested, then it's 0% completed.
Posted 14 years, 6 months ago on January 25, 2007