When it comes to progress, there are only two points where we can objectively (well, with high enough confidence) know where we are – 0% and 100%. Anything in between is just guesswork. And people have made very elaborate guesswork tools and systems over the years. Big tools, great methods. But none of that has taken away the fundamental problem – it’s still just guesswork.

The problem with most guesswork is that it’s based only on what we know or can think of. The most significant risks are typically the ones that catch us by surprise. So while some amount of guessing is useful, going too far is sometimes even dangerous (but at least usually futile and waste of time). And trust me, I’ve done my share of those guessworks :). I used to love MS Project.

But, since we can only know 0% and 100%, we should focus on our attention to those numbers. 0% is easy – we haven’t done anything yet. But in waterfall, we start everything (with requirements) very early. We invest some into everything, then invest some more (planning), and invest even more (desing, then coding), before getting to the point where we can evaluate whether it all works or makes sense to our customers. So if we want to know as much of 0% as possible, we should not any work on most of the stuff.

Also, once we start working on something, we should get it to 100% as quickly as possible, so that we get back to “know where we are”. So we should do requirements clarification, design, architecture, code, testing, integration, deployment and documentation as quickly as possible. If you check e.g. eXtreme Programming, it gives you a pretty good description to how to do all that in short time frames.

So, to me, the most important measure of progress is working software. I use user stories to describe the “vertical slices” of capability that our customers might need, have the team build a few of them from 0% to 100%, and then check what happened. When the product is developed this way, we pretty much know all the time what works (and has been done [and also, how much time it took us to do that]) and what is still not done. I do supplement that information with some guesswork about the overall scope to get some hunch about general timelines (e.g. are we moving fast enough or do we need to adjust things to hit our targets). I would also track money spent vs. money available, and compare that to estimated timelines.

If we can make the slices thin enough (a day or two per slice at most), we don’t really need much of anything else for progress management.