A thought exercise: “How long will it take you to get to work tomorrow? Can you guarantee it? To give us a guarantee, you’d probably put a buffer on your answer first. I guarantee a team working to put together software for the next two weeks is engaged in something a lot less well understood than a daily commute. We can put in a buffer - promise less - to give you a guarantee, or we can work from our estimates and do our best.”

A project manager reports that her project is “48 percent complete.” In terms of what, I wonder? Calendar time? Cost? Effort?

I know it’s not 48 percent complete in terms of functionality because there hasn’t been any working code delivered, just a bunch of documents.

One approach that makes sense to me is to express completion percentages in terms of implemented requirements.

For example, if you have 100 functional requirements, and 48 of them have been successfully implemented, then you’re 48 percent complete!

Actually, I oversimplified that a little . . .

All requirements are not created equal: Because some requirements cost more to implement than others, and some requirements have a greater business value than others, you could assign relative cost and relative value numbers to each requirement, and calculate completion percentages accordingly.

This is good both for measuring the value of work already completed, and for estimating time to completion on the work remaining.

Completion percentages continue to be one of the enduring fictions of our business. I wish I had a dollar for every time someone reported that work is 90 percent complete, it continued to be 90 percent complete until a week before the due date, at which time the date was pushed out another six months because nothing actually worked . . .

Thus spoke The Programmer.