The Seven Success Criteria

Each of the success criteria is evaluated independently. However, there is an indirect relationship among them.

Degree or Level of Stakeholder Satisfaction

This is a very controversial success criterion. There are many stakeholders involved in and impacted by a project. In the majority of projects, it is not a requirement for success that all stakeholders are satisfied with either their relationship with the project or the impact of the project on them and their work. For example, the changes being implemented by the project lead to a substantial deskilling, loss of control, or other negatives to the jobs of some people. It would be na ve to expect these people to be satisfied with the results of the project. It is critical for the project manager to determine which stakeholders must be satisfied at the end of the project and to identify those who will be unsatisfied at the end. As we discuss later, both groups of stakeholders are communicated with and different strategies are used for each group .

Meeting of Objectives and Requirements

These requirements deal with the business processes, data, and documents that are the basis of the business or information system. Techniques such as use case, OOA and OOD diagrams, data flows, process mapping, and data models were designed for and, when used properly, are capable of documenting these. In addition, visual development environments such as Microsoft Visual Basic can also be used to capture these requirements through the use of prototypes and early working versions of the product. Again, in most projects not all requirements need to be met for the project to be considered successful.

Meeting Budget

This is a relatively easy success criterion to understand. Budget includes people, equipment, accommodation, and overhead costs. In some projects, the budget is completely fixed and, in others, the budget is more flexible. As with deadlines, budget has tended to be a dominant measure in traditional projects as it is relatively easy to measure (we'll look at how budgets can be manipulated later).

Meeting Deadlines

Again, this is an easy measure of success. The calendar tends to move one day each day. Like budget, this success measure has been used consistently in the past to measure and, in many cases, unfairly condemn projects as failures. Again, as in the case of budget, there are projects in which missing a deadline is critical. There are many other projects in which the deadline is flexible.

Added-Value Requirements

This criterion is probably the most important component of expectations. Traditional approaches to project management and business or systems analysis used extremely crude models of cost “benefit analysis. The common use of intangible benefits such as improved customer satisfaction or management decision making to justify projects and the lack of formal approaches to benefits realization has perpetuated loose and fuzzy concepts of added value. As we show you, techniques such as the added-value chain, the identification of primary and secondary benefits, and stakeholder buy-in can effectively model the business client's expectations of financial benefits from the project. In addition, these techniques also clarify the real business objectives.

Death March Revisited

My friend, Ed Yourdon, wrote a wonderful book on projects where the team was sacrificed to meet deadlines. In Death March (1997) , he tapped into the terrible experiences of project managers and team members whose working lives (and in many cases, personal lives) were ruined by the pressures of deadlines, shifting requirements, lack of support, and poor project management practices. Clearly, in the organizations these people worked for, team satisfaction was not a relevant success criterion.

Quality Requirements

Quality requirements are often confused with functional requirements, but quality cannot be modeled using standard systems modeling techniques. Quality requirements include attributes such as conformity (functionality), efficiency, reliability, maintainability, flexibility, portability, auditability , security, usability, and reusability. By using techniques such as software quality agreements (see Chapter 9, "Analyze Added Value"), the team can model which quality attributes are required by the clients and stakeholders.

Team Satisfaction

This is, without doubt, the most contentious of all the success criteria. This factor determines whether the team's sense of satisfaction matters for the project. We accept that, in some projects, the other success factors may be more important than the team's emotional state; however, we know that the decision to "sacrifice" the team (see sidebar) must be made openly and at the start of the project. We have seen projects in which the sponsor changed his or her deadline and quality expectations to ensure that a team was allowed to do the best that it could. The sponsor made it clear that he or she wanted the team to "feel good about the project" as the team was needed for another project. We have also seen situations in which the decision was made to drive the project to a deadline, sacrificing both quality and the team's satisfaction. At least the project manager had an open choice as to who worked on the project (e.g., team members with more experience with "tough" projects and a number of contractors).

We now introduce you to our first and probably most powerful eXtreme project management tool.