You can’t judge whether a product satisfies all of its business goals and objectives until some time after delivery. However, each business objective should imply technical success criteria you can monitor prior to release. The development team can’t directly meet a business goal of "Capture a 40 percent market share within 12 months." But perhaps they can decompose that goal into specific project actions and product features aligned with achieving the market share target. Disconnects between success criteria and business objectives give stakeholders no way to assess whether the project is likely to meet those objectives.
Success criteria shape many aspects of your project, beginning with the functional and nonfunctional requirements. If the stakeholders understand the project’s business objectives and success criteria, it’s easier to make decisions about which proposed product features and characteristics are in scope and which are not.
Table 4-4 shows some simple examples of project success criteria. Well-written success criteria are feasible, quantitative, and verifiable.[6] For example, performance goals are often written against either internal benchmarks or external industry reference data. A goal might compare a new search engine’s performance to that of the prior version and also to the performance of a competing product under some set of standard conditions. Such success criteria let the project team design tests that measure whether performance, reliability, or throughput goals are being met. Trends in these measures can provide early warning that you might miss a success target, so the team can either take corrective action or redefine the success criteria.
Table 4-4. Examples of Project Success Criteria
|
[a] Function points are an implementation-independent measure of software size (IFPUG 2002). |
Not all of these success criteria can be top priority. You’ll have to make thoughtful trade-off decisions to ensure that you satisfy your most important business priorities. Without clear priorities team members can work at cross-purposes, which leads to rework, frustration, and stress. Weight your success criteria based on how strongly they align with achieving the critical business objectives. This tells team members which ones are essential and which are merely desirable. In one weighting scheme, stakeholders allocate 100 points to the success criteria associated with each business objective, with the more important items receiving more points.
Consider summarizing your success information in the form illustrated in Table 4-5. List each business objective, the stakeholder who provided it, corresponding project success criteria, and each criterion’s method of measurement and priority weight. Use the stakeholder list to verify that you haven’t overlooked any important business objectives. You don’t need to associate all stakeholders with every business objective, but every objective should be important to some stakeholder.
Clearly defining what success means at the beginning of your project greatly increases the chance of achieving it at the end. Understanding your stakeholders’ interests, writing clear business objectives, and defining corresponding success criteria lay the foundation for a happy project outcome.
Table 4-5. Sample Success Criteria Table
Business Objective | Stakeholder | Project Success Criteria | Measurement | Weight |
|---|---|---|---|---|
Achieve a customer satisfaction measure of at least 4 out of 5 within four months after release. | Marketing | Human factors approves user interface design through usability review. | All major severity UI design defects are corrected. | 20 |
UI prototype evaluation with focus group results in at least a 4.2/5.0 rating and will enable 90% of high-priority use cases to be performed. | Survey of focus group members; count of defined high-priority use cases. | 30 | ||
Product passes acceptance criteria defined by 80% of beta site evaluators. | Pass/fail rating by beta sites. | 50 |
[6] Too often, success criteria are worded imprecisely and cannot be assessed objectively so it’s difficult to judge if they’ve been satisfied. Tom Gilb has developed a flexible keyword notation called "Planguage" that permits precise statements of requirements and project goals (Gilb 2005). See Chapter 5 for a brief overview of Planguage and an example of how to use it to specify a product’s release criteria.