Crossing the line

Situation 1

Fred has been recently appointed as the project manager for a new and high profile information system. After undertaking an initial estimation, Fred recognises that the project will cost 4 times the costs being talked about by the project's business sponsor. Fred realises that upon being informed of the revised estimates, the project sponsor will not approve the project. Fred also knows that if the project is not approved, his job and the jobs of a number of system professionals will be at risk. After some consideration, Fred deliberately underestimates the cost of the project taking a relatively low risk that by delaying notification of the true costs until the project is well underway, the project sponsor will be reluctant to stop the project.

Situation 2

Mary is a project manager specialising in PC-based applications. She is evaluating a new mission-critical system request and is considering alternative development platforms. While she is sure that the system can be developed in Clipper, a development platform that she and her team have considerable experience, she is interested in Smalltalk and its associated object-oriented approach. Although the Smalltalk platform will raise the inherent risk of the project and would require a much longer development time-frame, she decides that Smalltalk will be more personally interesting and challenging and recommends it as the development platform.

Situation 3

John is an applications programmer working on a project that is in serious trouble. The development technology being used in the project is "leading-edge" and appears unable to successfully provide a platform for implementing the system within the agreed time-frame. For a number of reasons, the senior business area management who are funding the project and are depending on the deliverables for strategic advantage, are not aware of the technical problems. However, they are concerned about the lack of progress and request a demonstration of the system's progress. John is directed by the senior project manager to write a program to "simulate" the success of the technology. John writes a program to display a series of pre-determined results to set actions that will be entered by the business managers. Impressed by the "live" system, the business areas continue the funding of the project and extend the deadlines. Some months later, the project is cancelled as it becomes obvious to the business people that the technology can not deliver the required functionality.

Situation 4

Lee is a project leader working in a system group that has implemented a metrics programme. As part of this programme, she has been given a pre-determined productivity factor measured in Function Points/per month/team member that she is expected to achieve. Through a number of external and internal factors, Lee's team does not meet the desired productivity for a month. Recognising that this will mean a reprimand from her managers and that her remuneration package may be affected, she adjusts the figures to meet the required productivity.

Situation 5

Angela is working on contract with a large computing group. During her contract, she notices that the organisation's Accounts people do not appear to worry about the accuracy of her contract invoices and that they do not require a detailed timesheet for her work. She also learns from informal discussions with employees of the organisation that their travel and shift allowances are often overpaid and no one seems to care. Finally, when she sees that the organisation has spent many thousands of dollars on PC-based software that is not being used, she begins to bill the company for work that she has not undertaken.

While each of these scenarios, which are based on real occurrences in Australian companies in the past 3 months, may appear to be isolated examples, they are in fact common everyday facts of life for many information system people.

Over the past year, the author's company has discussed these and similar scenarios with over 1,000 Australian, Hong Kong, U.S. and New Zealand system people. A significant majority of these people agreed that these types of situations are common events and that they feel that such behaviour is justified in most cases.

These situations are not just examples of poor management practices but clear indication of a deeper problem - a lack of ethical standards.

Best practice and best behaviour

Most computing groups are undertaking serious reviews of the current levels of service, practice, productivity and costs associated with information system development and support. Many of these reviews are being undertaken by external consultants and involve significant expense and effort. The typical outcome of these reviews includes recommendations on :

• best practice in system development and support;
• investment in CASE and development technology;
• out-sourcing of system development and operations;
• shift of systems development control to client areas; and
• highly mechanistic productivity, cost tracking and quality measurement.

What these reviews generally fail to understand is that there is a long established and undocumented set of values and attitudes [in essence, a culture] within the computing groups that can and do undermine attempts to improve computing group productivity and service. As documented by Thomsett [1992], these values and attitudes have evolved throughout the 30 years of commercial computing. They are passed on by senior computer people to new entrants through a combination of actions and specific but undocumented practices. For example, most junior programmers have been taught an almost mythical rule of estimation - derive your estimate, then double it and add 30% for contingency. This informal culture is further enforced through a lack of effective project and quality management procedures, management training, cost-measurement and accountability that is widespread in computing groups.

These values and attitudes are based on an historical model of control by experts. As outlined by Thomsett [op cit], for the first twenty years of computing, the control of information system technology and corporate impact was controlled by the system experts. The situations described in the introduction are simply examples of these widely-accepted and established values and attitudes and, more significantly, the concern for control and power. In other words, rather than a set of values and attitudes based on what is good for the client, many computing people and groups have evolved a set of values and attitudes based on what is good for computing.

These values and attitudes, which experts such as Maddux and Maddux [1989] and Henderson [1992] agree define a code of ethics, have produced an environment where the situations described earlier can happen without any examination or concern. Indeed, as described by Bhide and Stevenson [1990], Magnet [1986], Mackay [1990] and many others, the high incidence of major corporate fraud and unethical behaviour during the 1980's, has lead to a corporate environment where any professional, business or computer, must be cynical about the whole issue of ethical behaviour. In simple terms, when you see business behaving unethically, it's easy to justify your own unethical behaviour.

This situation is particularly deplorable when so many of the computing concepts and approaches are drawn from other professions which all have well established codes of ethics and associated disciplinary procedures for breaches of ethical behaviour. For example, the term software engineer reveals computing wishes to adopt the technical practices and disciplines of engineering without adopting the formal codes of ethics associated with the engineering professions. In another example, project management is another computing term that has been adopted from a professional management body [eg the Australian Institute of Project Management] with a published code of ethics and disciplinary procedures. While it is true that the Australian Computer Society and other professional IT bodies[1] have a published code of ethics, the majority of computer people are not members of the A.C.S. and, many A.C.S. members are not aware of the existing code.

As computing groups begin to redefine their roles and to address the issues of professional behaviour and practice, they must also begin to examine the underlying issue of ethics and ethical behaviour. Simply, professionalism is not merely the adoption of best practice but also the adoption of a meaningful code of ethics.

In summary, computing people are members of an occupational group which follows an undocumented code of ethics developed without debate and without any legitimacy.

Organisational and individual impact

The lack of a prescribed set of ethical behaviours within computing groups has major impacts on the organisations using these groups as internal service providers.

In the examples earlier, three of the organisations involved invested substantial money, resources and technology on projects that should not have been approved [in one case, many millions of dollars were involved]. The remaining organisations' investment in external and internal consultancy, productivity measurement software and performance appraisal processes were compromised by wide-spread "cooking of the books".

The implications, however, go far beyond simple investment or measurement issues. The existence and acceptance of such behaviour challenges the control of the information system effort.

As documented by Thomsett [op cit] and others, there is a concerted movement in many organisations to move the control of the information systems resource to the business units via the downsizing of systems development technology and through strict budget control and cost-recovery mechanisms. Further, many organisations are seeking to re-orient the role of information systems through business re-engineering and substantial organisation restructuring. The end result of these behaviours is that the control of the information system effort covertly remains with the system development people. In other words, one of the prevailing values in computing groups is that they know what is best for their organisations and clients. When there is a conflict between what is required by the client and what the computing experts determine as required in technology and system requirements, the computing experts will exert control through unethical behaviour.

The adoption of a partnership or fully independent service relationship between computing groups and business clients must be based on a code of ethics that recognises the fundamental right of clients to control their own business.

A second and perhaps less dramatic impact of the lack of prescribed ethical codes is the personal impact on individual computer people. In discussions with many thousands of computer people, it has become clear that many do understand that, in some cases, their behaviour is unprofessional and unethical. However, the individual team leader or project manager must face these dilemmas and conflicts of interest by themselves using their own values as a guide as their managers and often, organisations, provide no formal ethical framework. As reported by Dwyer [1993], only 42% of Australian companies have a formal code of ethics and the majority of these are oriented towards being compliant with the Australian Securities Commission duties of directors.

For the vast majority of computer people, there has been no formal opportunity to discuss the issues of ethics. As a result, they either use precedent behaviour that they have observed in their peers and managers or attempt to draw some guidelines for their behaviour from their organisation's general practices. Unfortunately, as the "excesses of the eighties" continue to be revealed, there are many examples of questionable corporate ethics that provide little support to an individual looking to his or her organisation for guidelines on ethical behaviour.

Drawing the line - a management responsibility

In the situations described in the introduction, the behaviour could be seen as simply the behaviour of individuals who lack guidelines on ethics. However, in all cases, the behaviour was either directly or indirectly condoned by the managers of those individuals.

Just as it is expected that management must prescribe and support standards for best practice, it has always been expected that managers also prescribe and support ethical standards. As discussed by Berenbeim [1987], corporate ethics are one of the concerns of CEO's and they see the question of ethics as being integral to [1] the corporate mission, [2] constituency [client, employees, suppliers, etc] relations and, [3] polices and practices.

In computing groups it is critical that senior managers begin to address the question of ethical behaviour. As suggested by Berenhim [op cit]they must ensure that the IT group mission, constituency relations, best practices and policies associated with system development and support, as well as human resource development, incorporate a clearly understood set of professional ethics.

This is even more important in computing as, unlike medicine, actuarial studies and accounting, the basic tertiary and entrant-level training offered by Australian computing schools rarely provides new entrants into the area with an opportunity to discuss the question of ethics. In other words, in computing it is the employer's responsibility to define the code of ethics rather than in medicine where the profession defines the ethical code and the teaching schools disseminate it to new members.

The development of an internal code of ethics for computing groups is essential as these groups move to form new relationships with their business clients. The code of ethics provides the foundation for establishing professional service relationships with clients; the adoption of consistent and repeatable best practice in the critical areas of project management, cost management and strategic planning; and, the measurement of productivity, service levels and quality.

More importantly, the development of an organisational code of ethics draws a clear line for individuals to understand and use as a basis for their own behaviour. While it is true that the existence of a clear line of ethical behaviour has not prevented other professions from crossing it, at least, the individuals knew that they were crossing it.

For many computer people, the line does not exist.

A draft code of ethical behaviour

1. I will provide full disclosure regarding my projects and work to my managers, clients, team members and service providers.

2. I will never give estimates or other commitments to my clients, other professionals and managers that I cannot honestly support and achieve.

3. I will not estimate for or make other commitments for other professionals without prior and full consultation with them.

4. I will not agree to requirements, deadlines and so on without explaining the risks and others issues involved; and, without documenting those concerns for the client, managers and other professionals.

5. I respect the right of others to re-negotiate requirements, deadlines, and other service expectations.

6. My clients, managers and other professionals must respect my right to re-negotiate costs, schedules, resources and quality upon their changing of requirements.

7. I have a professional right to say "No" with full explanations and without recriminations.

8. I will never place my personal or professional interests above those of my client or organisation.

9. I will record my work and relevant measures honestly.

10. I will endeavour to treat others as professionals even if they don't treat me the same way.

11. I will not disclose any information regarding my clients' business gained through working with them without their prior permission.

12. I will endeavour to provide an ethical role model for new members of computing and to discuss openly with them the issues of ethical behaviour.

13. I will confront any breach of this code of ethics by other professionals.