Developer Speak for Project Managers - Translating the Percent Done

As a developer, I've tried a variety of ways to convert my innate sense of 'doneness' into a percentage for the weekly status report: Wild Ass Guess, percent hours spent vs time estimated, re-estimating time to completion. In the end, I've decided that once the project is in development, time or percent estimates are ultimately useless. or as I read recently "Nobody will remember when a project started or finished, but they'll be reminded of every mistake you made, daily for the life of the product"

In my experience developers, by and large, do try to be truthful in their estimates. The problem is code is a human endeavor, there will be misses, there will be changes, there will be unforeseen problems. If you're a PM measured on success of the project outcome (rather than success at project process), what you need is a handy way to covert standard developer status speak into an objective measure of progress.

Developer Speak: "I'm 90-95% done with that feature"
Translation: "What's done is done, I'm not touching this code until QA finds a bug. That missing 5% is my notifying the PM that I expect them to find something, they always find something. I may also have taken a few shortcuts that will slow down development next cycle."

How to respond: Ask for a demo, today. Developers, by and large, take pride in their work, having them demo a job well done is not only a useful check, it's a chance to show interest and appreciation for all that hard work. If the demo fails to meet your expectations, isn't it better you know right now, and not weeks down the line?

Developer Speak: "I'm 75 - 85% done with that feature"
Translation: "I'm confident that the code I have works, for everything I know about. I'm putting this on the shelf to see if I missed anything."

How to respond: This as a request for help, assign someone for informal demo and code review. Ask to be informed of findings, and a revised estimate to complete the feature. This is where developers feel most uncertain, there's always more than one way to solve a problem, and they've still got some open questions if they're on the right one. A peer review can quickly help to clarify the options and may help them to save time by dropping attempts to over-engineer a solution.

Developer Speak: "I'm 25% - 35% done with that feature"
Translation: "I think I understand how this is going to work, and my first attempts at code compile"

How to respond: Ward off problems early. Ask for a test case review. The project crippling problems start here, and lack of a test plan or an inadequate test plan is your surest, best warning sign a developer is out of their depth and will benefit from guidance and support from the senior team members.

What gets measured gets done. You can reward your team for generating numbers that give a temporary false sense of success, or you can reward your team for producing quality code that meets business needs. It's all in how what you choose to hear.