The Ethics of Software Project Management

S. Rogerson and D. Gotterbarn

Centre for Computing and Social Responsibility, De Montfort University, UK Software project management is the collection of techniques used to develop and deliver various types of software products. This developing discipline traditionally includes technical issues such as: the choice of software development methodology, how to estimate project size and schedule, how to ensure safety, what resources to reuse and which programming environment to use for the development. The discipline also includes management issues such as: when to train personnel, what are the risks to the project success, and how to keep the project on schedule. These choices are then embodied in a software project management plan. None of the traditional software project management materials address the ethical issues that arise because of the choices made during software development. Consequently, these materials do not provide any insights as to how to address these issues. In this paper we identify several critical ethical issues that arise in most software projects and provide a proactive way of addressing these issues which is consistent with most professional software development standards. Software project management is the collection of techniques used to develop and deliver various types of software products. This developing discipline traditionally includes technical issues such as: the choice of software development methodology, how to estimate project size and schedule, how to ensure safety, what resources to reuse, and which programming development environment to use. The discipline also includes management issues such as: when to train personnel, what are the risks to the project success, and how to keep the project on schedule. These choices are then embodied in a software project management plan. Software project management addresses both the process of software development and the desired functional characteristics of the final software product. A complete software project management plan is the design, implementation, control and test strategy for a software development process. Developing software is frequently complicated involving many people from different areas and with different skills, experiences and social attitudes. There are many operational decisions to be taken during this extended activity. There are many different approaches to control the complexity of this activity which can be viewed at two levels. There are those approaches which are concerned with high level decisions and processes such as the Capability Maturity Model and the ISO 9000 series, and

there are methods which deal with the details of the day to day activities of the project managers and software development teams. These latter methods include COCOMO, PRINCE and Function Point Analysis. Relevant ethical principles must be established in order to identify the ethical issues associated with software project management. Ethics comprises both practice and reflection [van Luijk, 1994]. It is sufficient to consider only ethics practice in this paper because software project management is concerned primarily with action that guides others towards some common goal rather than conceptual reflection of the role and value of project management. An interesting list of generic questions was devised by John McLeod in [Parker et al, 1990 pp 207-209] to help determine the ethical nature of actions within IT. These are relevant to software project management because they address many of the project management tasks with the exception of full consideration of the supplier-customer relationship. The software project is concerned with the delivery of an output by a supplier (the project team) to a customer under some agreement. It is irrelevant whether this is an in-house arrangement or whether it is between two independent organisations or whether it is a combination of both. According to [Velasquez, 1992], such an agreement is concerned with output quality and moral liability. Velasquez argues that the principles of due care and social cost must take effect in these situations so that suppliers accept their obligations to customers and the wider community to provide goods and services that are adequate and beyond moral reproach. Whilst it is recognised that the development of a piece of software might have its own special set of problems and challenges that have to managed there are many similarities in all software projects that means it is worth considering a generic approach which will lay down foundations for the management of all software projects. In his book, How to Run Successful Projects, in the British Computer Society Practitioner Series, [O'Connell, 1994] provides details of the Structured Project Management (SPM) approach. He explains that SPM is a practical methodology that, as [De Marco and Lister, 1987] state, is a "basic approach one takes to getting a job done". This appears to be a generic approach which is practical rather than conceptual and provides practitioners with realistic guidance in undertaking the complex activity of project management. SPM comprises ten steps as shown in Figure 2. The first five steps are concerned with planning and the remaining five deal with implementing the plan and achieving the goal. O'Connell states that most projects succeed or fail because of decisions made during the planning stage thereby justifying the fact that half of the effort expended in the SPM approach is on preparation.

As mentioned previously, establishing the right scope of consideration is essential in defining acceptable project goals. The scope of consideration is influenced by the identification and involvement of stakeholders. In traditional software project management the stated needs of the customer are the primary item of concern in stating the project objectives. Recently, there has been some recognition that in defining how software will address those needs the customer is also presented with a predefined set of constraints which limit the customer's freedom of expression [McCarthy, 1996]. There is a mutual incompatibility between some customer needs, for example, the amount of code required to make a system easy to use makes a system difficult to modify. The balancing of these items is an ethical dimension in the development of a software product. But such considerations are limited in scope to the customer. Investigating 16 organisational IS-related projects led [Farbey, Land and Targett, 1993] to conclude that regarding evaluation of IT investment,"... the perception of what needed to be considered was disappointingly narrow, whether it concerned the possible scope and level of use of the system, [or] the range of people who could or should have been involved ...". They discovered, with the exception of vendors, all stakeholders involved in evaluation were internal to the organisations. The reason for this restricted involvement is that these are the only stakeholders originally identified in the traditional project goals. However, we do not limit our consideration of stakeholders to those who are financing the project or politically influential but broaden it to be consistent with models of ethical analysis. By stakeholder we mean individuals or groups who may be directly or indirectly affected by the project and thus have a stake in the development activities. Those stakeholders who are negatively affected are particularly important regarding ethical sensitivity because they are often the ones overlooked. [Gert, 1988, Green, 1994] use a rights model to help identify relevant stakeholders. Once the stakeholders are identified one can itemise the specific obligations owed by the software developers to each of these stakeholders. Gert gives 10 basic moral rules. Although this is a deontological theory, it has been argued elsewhere that these rules are consistent with a Rawlsian approach to moral standards for software professionals [Gotterbarn 1991]. Gert's rules include: Don't kill, Don't cause pain, Don't disable, Don't

deprive of freedom, Don't deprive of pleasure, Don't deceive, Don't cheat, Keep your promises, Obey the law, and Do your duty. These rules carry with them a corresponding set of rights such as the right to liberty, physical security, personal liberty, free speech, and property. A preliminary identification of software project stakeholders is accomplished by listing each of these rules and rights, and examining the system plan and goals to see who is affected and how they may be affected. For example, according to rule 2 we should ask if the system changes the level of pain felt by anyone. Some of the rights and obligations identified when following this method may be in conflict and it will become necessary to prioritise how these rights are addressed and which of them can, within the bounds of the eight principles above, be addressed. One of the ways to help prioritise the ethical obligations within a project is to determine what actions are necessary to satisfy the perceived obligation and evaluate those actions in terms of whether they are morally required, morally wrong, or are merely morally permissible. This approach to evaluating potential actions is a variation on Green's decision tree for assessing obligations [Green, 1994]. Once the stakeholders have been identified, it is necessary to seek their involvement in the development process in order to meet their rights in the most effective way. As indicated above, in traditional project development there is a very narrow range of stakeholder involvement. Such restricted stakeholder involvement reduces the likelihood that any relevant ethical issues are properly considered. The evidence from Farbey substantiates our claim that no current method of software project management considers ethical issues. One way of addressing the need to modify project goals in a formal way is to use a modification of a social impact statement. A social impact statement is modelled on an environmental impact statement which is required before major construction is undertaken. The environmental impact statement is supposed to specify the potential negative impacts on the environment of the proposed construction and specify what actions will be taken to minimise those impacts. Proposed social impact statements have been described for identifying the impact of information systems on direct and indirect system users [Shneiderman and Rose, 1995], whereas our Software Development Impact Statement (SoDIS) is intended to reflect the software development process as well as the more general ethical obligations to various stakeholders.

There are two types of SoDIS. The first is a Generic SoDIS which has as its primary function the identification of stakeholders and related ethical issues. In the light of the identified issues a preliminary project management plan is developed. A second more detailed SoDIS is then employed. This is the Specific SoDIS. There will be a number of Specific SoDIS within a particular methodology. Each SoDIS is tied to a particular development methodology and to each step in that methodology. Even though each Specific SoDIS is tied to a development methodology, they all include the means of revisiting and re-evaluating ethical issues in the light of the unfolding development process. This organic nature of the SoDIS is very different for the environmental impact statement model. All software project management plans will include similar elements to those included in this model. This plan starts with a project overview which generally states the functions desired, called the requirements, for the software by the customer and constraints on the development process such as time, budget, and resources. These are stated from the customer's point of view. The preliminary material in a plan also includes a list of those things which will be delivered to the customer at the end of the project. This constitutes the developer's contract with the customer. What we propose with a SoDIS is to broaden the developer's contract to include a commitment to develop a product which is ethically sensitive. The Generic SoDIS would be part of the deliverables section of the software project management plan. The development of a piece of software involves many stakeholders each having various rights and obligations and a method is needed to sort out these issues. The process we propose is an iterative one which starts from a consideration of the software requirements and asks of the two obvious stakeholders, the developer and the customer, how those functions will impact upon their rights. One method of completing this analysis is to use Gert's moral rules. Each of these moral rules can be expressed as a right of an individual or group or as an obligation to someone. For example, the rule against killing can be expressed as a right to life, or the rule against depriving of freedom can be expressed as a right to liberty. The list of Gert's ten moral rules/rights can be used as the rows of a matrix. For example, one row could be "Does this requirement effect the level of pain?". This method will identify both the ethical negatives (increased pain) and the ethical positives (decrease pain)

of a system. The columns in the initial matrix represent the developer and the customer. For each requirement in the software requirements statement visit each cell in the matrix and make a note if satisfying that requirement violates that right of the stakeholder. Since rights have matching obligations, this process can be used to develop an obligation list. For each right that is violated someone has an obligation to prevent that violation. An obligation list should state the ethical concern and clearly assign the obligation to address this concern. Later this obligation list will be used in developing the list of jobs that need to be done to complete the software development process. In this stage, the list will also be used to determine the initial feasibility of the project as stated in the requirements. Because the analysis as described is organised by particular software requirements it will be easy to identify those requirements which generate a high level of ethical concern. Thus, the list will also be used to determine if particular requirements have to be modified to avoid significant ethical problems. Most software project management models proceed by decomposing each task into smaller more manageable tasks. These smaller tasks are then carefully described in terms of resource needs, costs and expected time to complete. Once a project is decomposed in this way, the costs of the individual tasks are added together to estimate the total project cost. These individual task descriptions are elaborated and included in the software project management plan. This set of task descriptions, sometimes called Work Breakdown Structure (WBS), is used in the reviewing and monitoring of the completion of tasks. The entire software development process is organised in terms of an ordered hierarchy of tasks, the WBS. Each WBS task is dependent on the completion of other WBS tasks. Each WBS task includes a description of the other WBS task on which it depends. Just as producing software of high quality should be second nature to the software engineer so should producing software that is ethically sensitive. Indeed there is clearly an overlap in these two requirements. The project management process for software development must accommodate an ethical perspective. The major criticism of current practice is that any ethical consideration tends

to be implicit rather than explicit which has a tendency to devalue the importance of the ethical dimension. By using ethical principles, identifying of ethical hotspots and using SoDIS it is possible to ensure that the key ethical issues are properly addressed as an integral part of the software development process. Quite simply, project management should be guided by a sense of justice, a sense of equal distributions of benefits and burdens and a sense of equal opportunity. In this way software development project management will become ethically aligned.