AUTHOR
Mike Bowern, Craig McDonald and John Weckert
ABSTRACT
This paper discusses some of the findings of an empirical research project set up to identify ways to predict the impact of software projects on a wide range of people, through an analysis of software project types, their stakeholders, and the issues which arise during the development and operation of the systems. Outcomes of the project include a critical literature review of stakeholder research and a new method to identify and quantify the impacts of information systems on their stakeholders. In recent years the term “stakeholder” has become commonplace when referring to people involved in the development and use of computer systems. However, there has been little discipline in the term’s use and, more importantly, as the impacts of computer systems on stakeholders can be so great, the topic deserves much further study.
In the 1980s and 1990s, processes for quality management and improvement of software and systems development were introduced in software engineering practice. Amongst other aspects, these processes focussed on easily identified stakeholders such as the project manager and team, the project sponsor or customer equivalent, and the immediate users. We propose that the next important step in the improvement of the software and system development process should be the consideration of a broader range of stakeholders and a broader range of the kinds of impacts they experience.
Despite careful risk analysis, a large percentage of software projects, and the products they create, are defective. Some project defects are associated with budget overruns, missed schedules and poor quality. Other defects relate to adverse social and ethical impacts. Research has shown that in many cases failures are due to an inadequate anticipation of the impact of software projects on users, society and the environment. The solution lies in modifying software risk analysis to include adequate stakeholder identification and consideration.
The paper considers a wide range of stakeholders and types of system, and explores their relationship and involvement with, and the resultant effects of software projects and products. In so doing, it covers aspects of stakeholder theory; definitions of stakeholders; identification of stakeholders, including special types, for example, non-human.
There are a number of important non-human stakeholders which should be considered appropriately by system developers. An obvious example is an “organisation”, and several of the definitions of stakeholder include organisation in their wording. In some instances an organisation can be considered as being a stakeholder which is separate from its members, some of whom are also stakeholders. The “environment” is another example of a possible non-human stakeholder, and this could lead to the identification of further subsets of stakeholders in particular instances or systems. Some have proposed that computers, networks, an encryption algorithm, and air-conditioning plant as possible non-human stakeholders. The paper discusses the validity and relevance of identifying these artefacts as stakeholders.
One problem in identifying stakeholders is in knowing how wide to cast the net. If “stakeholder” is defined too narrowly, many people with legitimate claims to consideration may be left out. If the definition is too broad and admits almost everyone who may be affected in any way, it becomes just about useless as a tool in practical decision making. An attempt will be made to find a workable balance by applying J. S. Mill’s account of other-regarding actions in On Liberty. The roles of responsibility and accountability principles are brought to bear on this discussion.
The theoretical issue of stakeholders being represented in an authoritative way on software development projects is explored in the paper. We note that there are established groups which could represent stakeholders, for example the Australian Shareholders’ Association could represent shareholders in the development and operation of trading systems. However, in many instances these representative groups could be stakeholders in the system in their own right, with conflicting requirements, and hence conflicts of interest. In fact, it could be that any stakeholder representing the interests of other stakeholders would have a conflict of interest. The representation of stakeholders on a project, by people with the authority to do so in an unbiased way, would appear to be as important as identifying the stakeholders in the first place.
One outcome of the research project is a method to quantify the consequences of not considering all relevant stakeholders through the lifecycle of an information system. This method will prioritise these consequences, in terms of the number of people affected and the cost, ethical or other impact on those people. The purpose of this is to enable developers of information systems to identify where their consideration of stakeholders should be applied to the greatest effect.