Regardless of what release criteria the team selects, you also need to know who will monitor progress toward satisfying the release criteria and who will make the final release decisions. I say "decisions" because you’ll probably have several types of product releases. You might deliver a late-stage build to quality assurance as a release candidate for final system testing. After the product passes its QA checks, you might release it to a beta testing site for user acceptance testing, deliver it to manufacturing, or approve it for general availability release. Information systems being developed for internal corporate use typically go through a sequence of quality verification, beta test in a staging environment, and release to the production environment. Different stakeholders might make these various release decisions and different release criteria will pertain to each decision point.

As you select release criteria, think about how they can be measured and who will do the measuring. Keep these questions in mind:

Monitoring progress toward satisfying release criteria provides visibility into project status, showing whether the project is on track to meet its goals. Write and track release criteria in a binary fashion: each one is either completely satisfied or it is not. You might create a color-coded tracking chart for your release criteria:

Avoid using yellow as an indicator for partial satisfaction of the release criterion. The temptation would then be to base a release decision on how many yellow indicators you can tolerate. If the board isn’t all green, you aren’t ready to ship.

Both the project manager’s and senior management’s commitment to the release criteria are essential if the criteria are to mean anything. Make sure the project’s senior management sponsor agrees that the release criteria are appropriate indicators of likely business success. Also obtain the sponsor’s commitment to rely on these criteria to make the ultimate release decisions. If management elects to override the objective release indicators, the team will question whether it’s even worth the effort to devise the criteria and work toward them. Inappropriate decisions to release a product prematurely undermine the team’s commitment to building high-quality products. They won’t take release criteria seriously on future projects.

As the scheduled delivery date fast approaches you might conclude that some release criteria won’t be satisfied. To anticipate this possibility, establish a process for reevaluating those criteria to determine if it makes sense to modify them. Maybe marketing is concerned about missing the optimum marketplace time to release. But is it in the company’s best interest to release an incomplete or deeply flawed product on schedule? The release criteria you select early on should reflect the appropriate balance of product features, quality, timeliness, and other factors that are aligned with business success. If you develop these criteria thoughtfully, you shouldn’t have to change them unless business objectives or other key project realities change. Identify the risks of failing to satisfy each release criterion so the stakeholders understand the implications of ignoring or finessing them.

When I was a software engineer at a large corporation, customers used to approach me frequently with a request for some program they wanted me to write. Some of those people didn’t want to spend time exploring their requirements; I was supposed to just dive in and get started. My question to those customers was, "If you don’t have any requirements, how will we know when we’re done?" None of them ever provided a satisfactory answer, but this conversation made them more agreeable to the idea of exploring requirements. "How will we know when we’re done?" is a vital question to ask in the early stages of any project. Release criteria provide a valuable answer.