©1999 Johanna Rothman
“Ship it!” Do you say these words with a feeling of pride? Or a feeling of desperation?
For any project, the big question is “when will the project be ready to ship?” When is the project complete? You can't know when the project is ready, unless you know what “complete” means. I use release criteria for helping to decide when a project is complete.
Release criteria can be any of these statements and others like them:
- Fewer than 10 major defects.
- Fewer than 30 minor defects and all defects are documented in release notes.
- Ship on May 31. (Your company might need the revenue. There might be a political reason. Whatever the reason, better to get the dates explicit, than to be surprised.)
- All tests run, > 90% pass.
- Installation and startup tested and pass.
I use release criteria to manage expectations, those of senior management, the project staff, and the customers. Here's how I develop criteria:
- Define what's special about this project. Every project has some overriding reason(s) for existence. When you define what those reasons are, you can define what special reasons would make you ship or not ship the project. Include your time to market, performance, usability, installation, compatibility, defects, and other requirements for this release of this product.
- Draft milestone criteria, at least for the release, additionally for other milestones. I like to have milestone criteria for every customer-visible milestone, such as ship and Beta. In addition, I like to set criteria for milestones such as system test, feature freeze, and code freeze. That way the project team can make a yes/no decision-did they meet the criteria for this milestone?
- Negotiate criteria with product development, marketing, and senior management. Although I might have the “big picture” vision, unless I'm part of senior management for this product line, I don't necessarily have enough information to know if my criteria are necessary and sufficient for this release. I like to draft the criteria with a small group from product development, and then present and negotiate the criteria with marketing and senior management. Senior management must understand what they will get for their investment.
Once the release criteria are defined, I publish them to the entire project team, so everyone knows what will make the project complete.
As a project manager or program manager, I use the criteria to continuously assess project state. I can use the milestone criteria as an early warning, to see if the project is meeting criteria early in the project.
If the project is not meeting the release criteria, it's time to observe what's really going on, and determine what actions to take, to get the project back on track. If you can't get the project back on track, don't just change the criteria or not meet the ship criteria. Either action is demoralizing to the project team, and doesn't help you ship the product any faster. If you realize partway through the project that the criteria are not correct or the project can never meet the criteria; renegotiate the criteria and republish them.
If the project starts to meet the criteria, then the project is progressing well.
Use release criteria to know when the project is complete, so that you can take pride in your projects.
Tags: project management, release criteria