Management Consulting
Project Jump Start
Management Coaching
Workshops AYE Conference
Project Management
Management
Hiring
Requirements
Consulting
Process Improvement and Quality
Managing Product Development
Hiring Technical People
Manage It! Your Guide to Modern, Project Management
Behind Closed Doors: Secrets of Great Management
Hiring the Best Knowledge Workers, Techies & Nerds
Corrective Action for the Software Industry
Amplifying Your Effectivess
Speaking Calendar
Testimonials
Resume
Contact
Volume 1, Number 2
Managing Projects: Release Criteria, or "Is it Ready to Ship?"
©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.
To subscribe, print and send the order form, or contact me at 1-781-641-4046 or by email.