Chapter 5. Are We There Yet?[7]
Note
Several organizations I’ve encountered always meet their schedules for software projects. As the target date approaches and the project clearly won’t finish on time, the team enters a "rapid descoping phase." They defer much planned functionality and release on the appointed completion date a crippled system with serious quality problems that provides no value to anyone. Then they declare the project to be a success because they delivered on time. Yes, they delivered something on time, but that something bore scant resemblance to the expected product.
One important aspect of project initiation, of beginning with the end in mind, is to determine how to tell when you’re ready to release the product. Defining your product’s release criteria is one of the essential activities that lay the foundation for a successful project. "It’s June 30 so we must be done" isn’t usually the best reason to ship. The team’s key stakeholders are responsible for selecting release criteria, with input from the rest of the development team. Whatever criteria you choose need to be realistic, objectively measurable, documented, and aligned with what "quality" and "success" mean to your customers. Decide early on how you will tell when you’re done (and who will make the call), visibly track progress toward these goals, and make sure everyone understands the implications if they ship before the product is ready for prime time.
No one ever builds perfect software products that contain every imaginable function that behave flawlessly under all circumstances. Every project team needs to decide when its product is good enough to go out the door. Being "good enough" means the product possesses some acceptable blend of functionality, quality, timeliness, customer value, competitive positioning, and supporting infrastructure in place. You can always spend more time and money to make any product better but at some point you must draw the line. You need to balance the cost invested in the product against the value it will provide both to customers and to the organization building it.
There is no perfect, simple measure of software quality. The customer view of quality depends on factors such as reliability (how long they can expect to use it without encountering a failure) and performance (response time for various operations). Strive to obtain customer input to the release criteria. How would your customers judge whether the product was ready to be installed and used, whether they could cut over to a new system that replaces a legacy application, or whether they’d be willing to pay for the new product?
The internal or engineering view of quality is also important. Is the software written in such a way that it can be modified and maintained efficiently during its operational life? Is documentation in place so the help desk or field support staff can assist users? The project might end when you deliver the system, but the product will live on for years to come. Consider the long-term implications when choosing the conditions that dictate releasability.
[7] This chapter was originally published in Software Development, 2005, 13(6): 26-29. It is reprinted here, with modifications, with permission of CMP Media Inc.