If the model of Figure 2 is accepted, the question then arises as to what differentiates ‘not success’ from ‘success’ and ‘not failure’ from ‘failure’. Following Lyytinen and Hirschheim (1987), we contend that it is the expectations of the stakeholder concerned that provides this distinction. However, Lyytinen and Hirschheim’s concept of expectation failure, which they define as ‘[an] inability of an IS to meet a specific stakeholder’s expectations’, does not, in our view, go far enough. We believe it is necessary to further distinguish between different types of expectation, both in their relevance to success or failure, as well as in their relative importance for the stakeholder concerned.
As an example, it is possible that for a certain information system development effort the IS department in an organisation (a stakeholder) expects that the project will be under its overall direction. If this expectation is not fulfilled, which would constitute an expectation failure in Lyytinen and Hirschheim’s terms, then the development effort might well be perceived by the IS department as a failure, for them, whatever else happens. On the other hand, if the expectation is fulfilled then the project will not have failed (at least in the eyes of the IS department, and all other things being equal) but is unlikely to be said on this account alone to have succeeded. That is, the expectation of control of the project concerned, by the IS department, would in this case be one of the differentiators between failure and not-failure rather than between success and not-success. Of course there may be other differentiators too, and generally will be. A similar scenario may be painted for success versus not-success. For instance, suppose a particular user group is expecting expanded functionality in an area of their special interest. If the project and resulting information system provides it then they are very likely to regard it as a success, other things being equal. But if not — say only existing basic functionality is maintained — then does that mean it is a failure in their eyes or simply less than a complete success? If the latter, then their expectation of expanded functionality in their special area of interest is, for them, a differentiator between success and not-success and has no direct link to failure or not failure.
In most discussions of user requirements it seems to be implicitly assumed that requirements or expectations are of what we would call a ‘positive’ nature. That is, the system will have some characteristic or provide some feature or functionality. But we contend that expectations may also be negative. For example, a stakeholder may expect that a system will not use a particular operating system or should not affect their existing standard operating procedures in certain ways.
Now it could obviously be objected that the distinction being drawn here between positive and negative expectations is artificial and simply dependent on phrasing. From the point of view of a two-valued logic this is of course true. For example, one might argue that saying ‘the characteristic of user friendliness must be present’ is equivalent to saying that ‘the characteristic of user unfriendliness must be absent’. But we are not dealing in simple two-valued logic. Instead it is the psychology and perceptions of stakeholders that are the issue here. The importance of the distinction between positive and negative characteristics lies in the psychological effect in the mind of the respondent. When asked for characteristics that should be present (positive expectations), the effect on the stakeholder is likely to be quite different from that produced when they are asked for characteristics which ought to be absent (negative expectations).