So far we have considered only a single stakeholder. But, of course, there are in general many stakeholders in an information system development effort. What effect does this have? Our answer is that we must construct a 2x2 success/failure matrix such as that shown in Figure 2, with its defining characteristics differentiating success/not-success and failure/not-failure, for each stakeholder. In effect each stakeholder has a different definition of the information system (Mathieson, 1993). Our diagram now becomes as shown in Figure 3.

Given a situation like that of Figure 3, what now of the prospects for success overall; that is, for ‘success’ and ‘not failure’ for all of the stakeholders? Clearly, this depends on the defining characteristics for each one and we may conclude that for overall success to even be possible requires that none of the set of defining characteristics, across ALL of the stakeholders, be mutually exclusive of any other. In a development effort with many stakeholders this is arguably unlikely and then the probability of success overall, by our definition at least, becomes correspondingly remote. Perhaps this represents a partial explanation of the notoriously high failure rates that characterise large information systems projects.

Seen in this light, it is clearly necessary for information systems developers to uncover and determine, at the outset, both the positive and negative defining characteristics for success/not success and failure/not failure, and to do this for all of the stakeholders of a proposed system. They must be prepared to ask questions like all of 1 to 4 above. However, in practice it would seem from our experience at least that only questions like 1 and 4 are asked in the requirements gathering process, and it may be that it is often the absence of questions like 2 and 3 that contributes to difficulties of understanding and resulting system implementation problems.

It is also possible that defining characteristics could apply not only to a delivered system but also to the development process or the project itself. For example, a particular stakeholder’s defining characteristic for failure/not failure might be that a project should be constituted in a certain form, or a development process carried out in a certain way, and if it is not then whatever system is finally delivered (if any) may be deemed by them to be a failure regardless.