The Ethics of Software Project Management

S. Rogerson and D. Gotterbarn

Centre for Computing and Social Responsibility, De Montfort University, UK

Abstract

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.

Introduction

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.

All of these methods have as a major function the attempt to anticipate and avoid all possibilities which may negatively impact a software project. The negative possibilities are those which would delay the delivery of the software which performs the desired functions in a timely and cost effective manner. An additional function is to avoid late changes to the system because the later the change the more expensive it becomes. However, none of these methods consider the ethical issues that need to be identified and addressed during the planning stages and re-considered throughout the development process.

Effective software project management is a vital ingredient in achieving a successful outcome. The objectives for the project need to be agreed at the outset. In deciding the objectives their implications need to be considered, in terms of the actual outputs and the impact these outputs will have. There is also a need to consider the impact of the development process itself. The project team should be well briefed on these issues and have the opportunity to debate them fully to establish its own conclusions. The team should consider all the implications of the plan, including ethical ones. It may need to call on additional resources from inside and outside the organisation. To confine the discussions within close boundaries (in an attempt to save money and time) is misguided. Broader issues will inevitably arise during the course of the project. If the team members are unprepared, they will lack direction and perform poorly. The sponsor of the project therefore needs the vision and the authority to ensure that the project team is supported and coached to consider both technical and ethical issues.

The purpose of this paper is to consider how software project management might embrace ethical sensitivity, ensure ethical issues are considered throughout the development process and provide timely feedback of possible negative and positive social impacts of a piece of software. [Rogerson and Bynum, 1996] suggest that a comprehensive set of ethical tools and techniques needs to be identified and developed which will promote responsible practice in software development. One such item in this set is the Social Impact Statement which can be effectively used to focus attention on the ethical issues associated with each stage of the software development process [Shneiderman, 1990, Huff and Jawer, 1994].

Applying Ethics

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.

By combining and building upon the ideas of McLeod and Velasquez a set of ethical principles can be derived as shown in Figure 1 [Rogerson, 1997]. The principle of honour is to ensure that actions are beyond reproach which in turn demands honesty from the professional. The principle of bias focuses on ensuring decisions and actions avoid the possibility of conflicts of interest and eliminate bias in judgements. Professional adequacy is concerned with the ability of individuals to undertake allocated tasks. The principle of due care is linked with the concept of software quality assurance. Fairness focuses on ensuring all affected parties are considered in project deliberations. Following these principles adds a social cost which recognises that it is not possible to abdicate from professional responsibility and accountability. Finally, the principle of effective and efficient action is concerned with completing tasks and realising goals with the least possible expenditure of resources.

Honour Is the action considered beyond reproach?

Honesty                        Will the action violate any explicit or implicit agreement
                               or trust?
Bias                           Are there any external considerations that may bias the action
                               to be taken?
Professional adequacy          Is the action within the limits of capability?

Due care                       Is the action to be exposed to the best possible quality
                               assurance standards?
Fairness                       Are all stakeholder's views considered with regard to
                               the action?
Consideration of social cost   Is the appropriate accountability and responsibility accepted
                               with respect to this action?
Effective and efficient action Is the action suitable, given the objectives set, and is it
                               to be completed using the least expenditure of resources?

Figure 1 Eight Ethical Principles

These principles can be used to analyse, inform, and colour practice within computing and software project management in particular. Within software development there are numerous activities and decisions to be made and many of these will have an ethical dimension. It is impractical to consider each minute issue in great detail and still hope to achieve the overall project goal. By considering which of the principles apply it is possible to ascertain which activities and decision making points are the most ethically charged. The focus of attention must be on these ethical hotspots because they are likely to influence the success of the particular software project and promote ethical sensitivity in a broader context. [Rogerson and Bynum, 1995] define these ethical hotspots as points where activities and decision making are likely to include a relatively high ethical dimension.

Generic Software Project Management

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.

It is this planning element of project management which lays down the foundations on which the project ethos is built. Here the scope of consideration is established, albeit implicitly or explicitly, which in turn locates the horizon beyond which issues and people are deemed not to influence the project or be influenced by it. How the project is conducted will depend heavily upon the perceived goal. The visualisation of this goal takes place in Step 1. It is here that the scope of consideration is established which should lead to effective discussion by all parties (stakeholders) on all issues resulting in the defining of the project goal(s). Often limited time is spent on this crucial first step. This is because the project manager is under pressure to deliver and so the tendency is to reduce the horizon and establish an artificial boundary around the project with only the obvious issues in close proximity to the project being considered. Steps 2 to 5 are concerned with adding detail and refinements thus arriving at a workable and acceptable plan. Steps 6 to 8 are concerned with implementing the plan, monitoring performance and keeping those associated with the project informed of progress. Step 9 defines the control feedback loops which ensure that the plan remains focused, current and realistic. Finally, Step 10 is the delivery of the project output to the customer and an opportunity to reflect upon what has and has not been achieved.

Step Description

1 Visualise what the goal is
2 Make a list of the jobs that need to be done
3 Ensure there is one leader
4 Assign people to jobs
5 Manage expectations, allow a margin of error and have a fallback position
6 Use an appropriate leadership style
7 Know what is going on
8 Tell people what is going on
9 Repeat Step 1 through 8 until Step 10 can be achieved
10 Realise the project goal

Figure 2 The Ten Steps of Structured Project Management

Ethical Management

The eight ethical principles can be used to provide an insight to how ethical management might be achieved. The activities within each of the ten steps of SPM have been analysed in order to identify the dominant ethical issues of each step [Rogerson, 1997]. The results of this analysis are shown in Figure 3. It is recognised that most of the eight ethical principles will have some impact on each step but it is important to identify those which will have a significant impact on each particular step. The mapping in Figure 3 shows those relationships which are considered significant. Those with the highest ethical significance, indicated by the number of ethical principles that prevail are, at this level, the ethical hotspots of a generic approach to software project management.

          Step 1 2 3 4 5 6 7 8 9 10
Principle
1. Honour       X     X    X    X   X
2. Honesty      X     X X      X
3. Bias         X X X X       X   X
4. Adequacy         X X   X
5. Due care     X   X   X     X X
6. Fairness     X       X     X
7. Social cost    X       X X       X
8. Action       X X X   X X   X X
                6 2 4 5 4 4 1 5 2 4

Figure 3 The dominant ethical principles in the steps of SPM

This analysis suggests that Step 1 which is involved with defining the project goal, Step 5 which assigns people to tasks, and Step 8 which communicates project progress to all concerned are the most significant ethical areas. The first area defines a project that is ethically, as well as, technically and economically acceptable. The second area concerns the sensitive alignment of people's skills and aspirations with the project tasks. The third area concerns progress reporting to stakeholders and provides ongoing checks and balances throughout the life of the project. The first ethical hotspots (at this level), Step 1 will now be used to illustrate the difficulty in achieving ethical sensitivity and showing how this sensitivity might be achieved in practice.

Scope of Consideration

Stakeholders

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.

Negative affects include both overt harm and the denial or reduction of goods. So obviously the development of a medical software package which delivered erroneous dosages of medicine that killed patients would have a negative effect; but we would also include as having a negative effect software which limited people's freedom of expression. Limitations on positive ethical values and rights are negative effects. It can also be argued that the failure to promote positive ethical values is also a negative effect.

Therefore, we extend the traditional software project stakeholder list from customers and corporations or shareholders to include all those who will be affected by the software and by its production. This includes: users of the software, families of the users, social institutions which may be radically altered by the introduction of the software, the natural environment, social communities, software professionals, employees of the development organisation and the development organisation itself. Given such a range of stakeholders, how is one ever to identify the relevant and significant stakeholders?

Stakeholder Identification

[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].

In determining the rights and obligations of the developers of a software product , one can use one of the professional codes of ethics. A code such as the Software Engineering Code of Ethics [Gotterbarn et al, 1997] defines the rights of the developer and others related to the software process and the final software product. The imperatives of the ACM Code of Ethics (Appendix A) can be used to guide the stakeholder search. The process of identifying stakeholders also identifies their rights and the developers’ obligations to them.

Involvement

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.

Appropriate people from the whole range of stakeholder groups should be consulted. Participation by owners and employees is obvious but it may be desirable for other groups to take part in particular situations. For example, if a manufacturing company wishes to improve links with suppliers and customers then it would make sense to involve representatives from both groups. Similarly, if an organisation wished to form a strategic alliance with a competitor in an attempt to increase market share through synergy then participation by that competitor would be essential. Finally, the drive for efficiency gains through applying IT by a large local employer could mean a reduction in the work-force or employing a different work-force group. In such circumstances the involvement of unions and relevant community groups is probably desirable.

The widespread use of, and dependence upon software within organisations and society affects the lives of most individuals. The project management process must consider, from the start, the views and concerns of all affected parties and do so using the principles of due care, fairness and social cost. Concerns over, for example, deskilling of jobs, redundancy, the break-up of social groupings can be then aired at the earliest opportunity. Fears can be allayed and project goals adjusted if necessary.

Generic Software Development Impact Statement

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.

Any SoDIS requires a set of instructions which include information about what data to gather, how to gather it, and how to document the entire process. The set of instructions should also include information about monitoring the SoDIS development process for accuracy, completeness, objectivity, and enforcement of the results. This paper will not deal with the monitoring and the enforcement issues. These fall within the communications and reporting ethical hotspot mentioned previously and indeed must wait until the SoDIS process becomes a part of typical development methodologies. A SoDIS should have a standardised physical structure which will help its users to organise the issues and the information.

Elements in the Generic SoDIS form

The elements included in a Generic SoDIS (see Appendix B) are directly related to the software project management process. In SPM these elements were described at a high level of abstraction as Step 1 Visualise what the goal is and Step 2 Make a list of the jobs that need to be done. These two steps are reflected less abstractly in individual software development methodologies and indeed further detailed in SPM itself. For example, figure 4 shows the outline for the IEEE standard model for a software project management plan [Fairley, 1995].

Introductory material Title Page
Revision Sheet
Preface
Table of Contents
List of Figures
List of Tables

1. Introduction 1.1 Project Overview
1.2 Project Deliverables
1.3 Evolution of the SPMP
1.4 Reference materials
1.5 Definitions and Acronyms

2. Project Organisation 2.1 Process Model
2.2 Organisational Structure
2.3 Organisational Interfaces
2.4 Project Responsibilities

3. Managerial Process 3.1 Management Objectives and Priorities
3.2 Assumptions, Dependencies, and Constraints
3.3 Risk Management
3.4 Monitoring and Controlling Mechanisms
3.5 Staffing Plan

4. Technical Process 4.1 Methods, Tools, and Techniques
4.2 Software Documentation
4.3 Project Support Functions

5. Work Elements, Schedule, and Budget 5.1 Work Packages
5.2 Dependencies
5.3 Resource Requirements
5.4 Budget and Resource Allocation
5.5 Schedule

Figure 4 The IEEE model for a software project management plan

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.

Section 1.3 of the IEEE model recognises that software development is a very organic process and that all eventualities can not be fully anticipated at the beginning of the project so it is necessary for the plan to be flexible. The way in which a plan may change and what is needed to approve such changes are included in section 1.3 The ethical impact of a software product will change as the product changes, so a Generic SoDIS must also include a section describing its change mechanism. Several large companies now employ ethics officers. If the software development company has an ethics officer, then s/he should be involved in the change process.

The change process requires the same care as was taken in the original development of the SoDIS. If the impact on particular stakeholders changes in a negative way then the ethical obligations to those stakeholders, as stated in the original SoDIS, must be re-evaluated. If necessary new action plans need to be developed to meet the new obligations and these plans need to be integrated into the software development process.

Identify the stakeholders

Primary stakeholder issues

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.

This method focuses on the individual requirements but it can be used at this stage to give a composite picture of the ethical impact of the entire project from the point of view of these two stakeholders.

Broader stakeholder analysis

This process is now used to both identify additional stakeholders and to determine their rights The previous analysis should have identified some areas of broader ethical concern and some additional stakeholders. The primary stakeholder analysis is repeated for these newly identified stakeholders. Even if there were no new stakeholders identified, at a minimum the analysis should use software users, related cultural groups, and society as potential stakeholders.

Higher moral obligations

Each of these processes should be repeated using professional ethical codes to identify ethical issues. Using the imperatives of the ACM Code of Ethics helps the SoDIS team to ask questions which have been of concern to practising computer professional.

Specific Software Development Impact Statement

Work Breakdown Structure

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.

Like the project as a whole, each WBS task can have a significant ethical impact which may not have been anticipated by the generic SoDIS. The particular way in which the WBS is designed may endanger the software user or have significant social consequences. The specific SoDIS is used to address this problem. It is included as an integral part of a WBS task document as shown in Appendix C. A standard WBS task document only addresses technical issues relating to software and hardware, but the modified WBS task document, which includes a specific SoDIS, addresses the potential ethical issues generated by that WBS task and the ways to address or avoid those potential issues. A WBS task document also specifies the criteria the WBS task must satisfy to be considered complete. The SoDIS version of a WBS task document also includes a discussion of the ethical criteria which have to be satisfied by this task. The techniques used in the development of the generic SoDIS are used in the development of the specific SoDIS.

Once the SoDIS WBS task documents are completed their implementation must be monitored. This monitoring process is another ethical hotspot which will be discussed later in this series of papers.

Conclusion

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.

References

Collins W R, Miller K W, Spielman B J and Wherry P (1994) How Good is Good Enough, Communications of the ACM, Vol 37 No 1, January, pp 81-91.
De Marco T and Lister T (1987) Peopleware, Dorset House Publishing.
Fairley R (1995) IEEE Software Project Management Plan Standard, revised, IEEE.
Farbey B, Land F and Targett D (1993) How to assess your IT investment, Butterworth Heinemann.
Gert B (1988) Morality, Oxford University Press.
Gotterbarn D (1991) Computer Ethics: Responsibility Regained, National Forum, The Phi Kappa Phi Journal, Vol 71 No 3.
Gotterbarn D and Miller K and Rogerson S (1997) Software Engineering Code of Ethics, SIGCAS Newsletter, July.
Green R M (1994) The Ethical Manager, Macmillan Publishing.
Huff C and Jawer B (1994) Towards a design ethic for Computing Professionals, in Huff C and Finholt T (eds) Social Issues in Computing, McGraw Hill.
McCarthy J (1996) Dynamics of Software Development, Microsoft Press.
O’Connell F (1994) How to run successful projects, Prentice-Hall.
Parker D B, Swope S and Baker B N (1990) Ethical Conflicts in Information and Computer Science, Technology, and Business. QED Information Sciences.
Rogerson S (1997) Software Project Management Ethics, in Myers C, Hall T and Pitt D (eds) The Responsible Software Engineer, Springer-Verlag, pp 100-106.
Rogerson S and Bynum T W (1995) Identifying the ethical dimension of decision making in the complex domain of IS/IT, ETHICOMP95, Leicester, UK, April.
Rogerson S and Bynum T W (1996) Information ethics: the second generation, The future of information systems, UK Academy for Information Systems Conference.
Shneiderman B (1990) Human Values and the Future of Technology: A Declaration of Empowerment, Computers and Society, Vol 20 No 3, October, pp 1-6.
Shneiderman B and Rose A (1995) Social Impact Statements: Engaging Public Participation in Information Technology Design, Technical Report of the Human Computer Interaction Laboratory, September, pp 1-13.
van Luijk H (1994) Business ethics: the field and its importance, in
Harvey B (ed) Business Ethics: A European Approach, Prentice-Hall.
Velasquez M G (1992) Business ethics - concepts and cases, 3rd Edition, Prentice-Hall.

Publication details

ROGERSON, S., GOTTERBARN, D., The Ethics of Software Project Management, in COLLSTE, G., (editor), Ethics and information technology, New Academic Publishers, Delhi, India, 1998, pp137-154.

Appendix A - ACM Code of Ethics Imperatives

1.1 Contribute to society and human well being.
1.2 Avoid harm to others.
1.3 Be honest and trustworthy.
1.4 Be fair and take action not to discriminate.
1.5 Honour property rights including copyrights and patents.
1.6 Give proper credit for intellectual property.
1.7 Respect the privacy of others.
1.8 Honour confidentiality.

2.1 Strive to achieve the highest quality, effectiveness and dignity in both the
process and products of professional work.
2.2 Acquire and maintain professional competence.
2.3 Know and respect existing laws pertaining to professional work.
2.4 Accept and provide appropriate professional review.
2.5 Give comprehensive and thorough evaluations of computer systems and their
impacts, including analysis of possible risks.
2.6 Honour contracts, agreements, and assigned responsibilities.
2.7 Improve public understanding of computing and its consequences
2.8 Access computing and communication resources only when authorised
to do so.

3.1 Articulate social responsibilities of members of an organisational unit and
encourage full acceptance of those responsibilities.
3.2 Manage personnel and resources to design and build information systems
that enhance the quality of working life.
3.3 Acknowledge and support proper and authorised uses of an organisation’s
computing and communication resources.
3.4 Ensure that users and those who will be affected by a system have their
needs clearly articulated during the assessment and design of requirements;
later the system must be validated to meet requirements.
3.5 Articulate and support policies that protect the dignity of users and others
affected by a computing system.
3.6 Create opportunities for members of the organisation to learn the principles
and limitations of computer systems
.

Appendix B - Generic SoDIS

The generic SoDIS is part of the deliverables section of a software project management plan and it is revised according to the revision schedule contain in the software project management plan.

1. Software Requirements:

Could be included by reference to other project documents.
The requirements should be numbered for easy reference in the SoDIS development process.

2. Change Process

Frequency of Review

Review Team Members

Approval process
Who is on the review team
How open it to public stakeholders

3. Primary Stakeholder analysis

Obligations list
Right violated _____ by _____ causes _____ obligation to _____

Requirements with a high level of ethical concern

Requirements review in the light of this analysis

Review of analysis process in the light of professional code of conduct.

4. Extended Stakeholder analysis

Identify potential stakeholders

5. Prioritised obligations list divided into actions which are morally wrong,
permissible, and required

Appendix C - Specific SoDIS

Typical Work Breakdown Structure task document with SoDIS modification

Name Name and numeric identifier of the task

Description Technical function of the task

Dependencies What technical and SoDIS tasks must be complete before this task can be started

Project Members People who will work on this

Duration Estimated time to complete this task

Resources Technical and other resources needed to complete this task

Product Product description

Completion criteria What are the technical and ethical marks of task completion

Acceptance criteria Who has the authority to certify that this WBS task is complete in terms of its technical and social requirements

Risks Potential risks to timely successful WBS task completion

Risk Resolution Plan to address these risks should they arise

Specific SoDIS Risks Stakeholder analysis and risk identification

SoDIS Risk Resolution