Lyytinen and Hirschheim (1987) as well as Seddon et al (1999) recognise that there are, in general, many stakeholder expectations and many of these may be unstated, vague, unformed or only partially formed, and, initially, even unconscious. This of course represents a practical difficulty for developers who are concerned with satisfying expectations, but even if this were not so, and more fundamentally, Lyytinen and Hirschheim (1987) omit to distinguish between expectations of differing importance and it is, we think, evident that not only may a stakeholder hold many expectations but also that some will carry much greater weight than others. Furthermore, in addition to explicit and well documented expectations, there may also be other implicit or pseudo-rational requirements that remain hidden. Leifer et al (1994) call these ‘deep structures’. Hidden expectations could even be the most important from the stakeholder’s point of view, and may, in the final analysis, critically affect their attitudes to success and/or failure. The question therefore arises: ‘which, among all of the stakeholder expectation(s), are important enough to differentiate between success/not-success and failure/not-failure?’. This is unanswerable in general because expectations are so context and situation dependent. Instead, we use a concept called ‘defining characteristics’.
The idea of information system ‘defining characteristics’ presented here is derived from a philosophical analysis of definition and meaning in language given in Hospers (1967). Discussing definition, Hospers asserts that it is necessary to:
… consider carefully which characteristics of a thing we consider to be defining. A defining characteristic of a thing … is a characteristic in the absence of which the word [under consideration] would not be applicable to the thing. (Emphasis in original).
Furthermore:
… the test of whether a certain characteristic is defining is always this: would the same word still apply if the thing lacked the characteristic? If the answer is no, the characteristic is defining; if the answer is yes, it is merely accompanying.
The simple example of a triangle is used: ‘Being three-sided is a defining characteristic of triangles, since nothing would be … a triangle unless it had three sides … but being at least two inches in height … is not a defining characteristic of a triangle … since something can be a triangle … and yet be smaller than this.’
This idea can be applied to information systems success and failure in four ways. (paraphrased from Hospers wording above). Firstly:
What characteristics would, if absent, prevent the system being classified as a success? Or, equivalently: What characteristics would, if present, make the system a success?
These are the positive expectations on the ~S…S dimension. There is nothing new here since these expectations may be equated to the traditional mandatory requirements. Now, secondly:
What characteristics would, if absent, prevent the system being classified as not a success? Or, equivalently: What characteristics would, if present, make the system not a success?
These are the negative expectations on the ~S…S dimension. In essence, this question is asking what must be avoided if the system is to be a success. Such a question seems, at least in our experience, to be not usually asked and may well cause the stakeholder responding to think in very different terms about the system under consideration and what it means to him or her. This difference of effect, of the question asked, on the respondent’s thinking may be extremely important in eliciting a more complete picture of relevant stakeholder’s views. Now, thirdly:
What characteristics would, if absent, prevent the system being classified as a failure? Or, equivalently: What characteristics would, if present, make the system a failure?
These are the negative expectations on the ~F…F dimension and are the things that must be avoided if a failure is to be averted; they are the absolute ‘must not do’s’. And lastly:
What characteristics would, if absent, prevent the system being classified as not a failure? Or, equivalently: What characteristics would, if present, make the system not a failure?
These are the positive expectations on the ~F…F dimension. The characteristics being identified here are similar to what are often called ‘hygiene’ factors in the theory of motivation (Herzberg et al, 1959). They must be present to avoid failure, but their presence is not of itself a guarantee of success.
This leads us now to a definition of ‘defining characteristics’ in an information systems success and failure context:
A ‘defining characteristic’ of an information system is any characteristic that is held by a stakeholder to be of such importance that its presence (or absence) will differentiate between success and not success, or failure and not failure.
Presumably, for each individual stakeholder, the number of defining characteristics will be relatively few. However, no assumption is made about the clarity, awareness, breadth, or apparent triviality or otherwise of these characteristics in the perception of the stakeholder holding them. Like the dimensions of success identified by Seddon et al (1999), our concept of defining characteristics is firmly based in the expectations of the stakeholders, unlike any so-called general or objective list of specific system features or characteristics for defining success. Moreover, unlike the expectation failure idea of Lyytinen and Hirschheim (1987), our concept also takes account of the differences in importance of expectations, focusing specifically upon those both positive and negative that will determine overall system success/not-success or failure/not-failure, in the eyes of the stakeholders concerned.
Finally, it is necessary to note that we have presented our analysis of defining characteristics in terms of a priori stakeholder perceptions regarding success and failure and consequently painted a rather static picture of them. There is always the possibility, however, that stakeholder perceptions and therefore potentially also their defining characteristics for a system may change over time, perhaps because of the emergence of unanticipated benefits or disadvantages that were not evident initially. Analysis of stakeholder defining characteristics may therefore need to be a continuing or repeated process rather than a once-off exercise in a system development effort.