Skip to content

Lesson 4 — Ethical and Responsible Project Management

At a glance

Learning objectives

By the end of this lesson you should be able to:

  1. Apply the ACM/IEEE-CS Software Engineering Code of Ethics to realistic project situations.
  2. Identify ethical issues in reporting, procurement, data handling, and release decisions.
  3. Escalate an unwelcome decision in a way that preserves both the record and the working relationship.
  4. Distinguish an ethical question from a legal one, and recognise when both apply.

Prerequisites

Introduction

Project managers make decisions with consequences for people who are not in the room: users, patients, applicants, employees, and the public. Most of those decisions are routine, and a few are not — and the few are rarely announced as ethical questions. They arrive as practical requests: shorten the report, skip the review, keep the data, ship it anyway.

This lesson is about recognising those moments and acting on an established standard rather than on personal preference.

1. There is a standard

Professional ethics in software engineering is not a matter of taste. The Software Engineering Code of Ethics and Professional Practice, published jointly by the ACM and the IEEE Computer Society in 1999, sets out eight principles addressed to the public, clients and employers, the product, judgement, management, the profession, colleagues, and the self.

Three of those principles do most of the work in project settings:

  • Public — the public interest is the primary consideration.
  • Product — products should meet the highest professional standards, and risks should be disclosed to the appropriate parties.
  • Judgement — professional judgement should be maintained with integrity and independence.

The code is a reference for reasoning, not a checklist. The skill is recognising that a routine request has an ethical dimension, before it becomes a decision.

Academic integrity

When you describe a real system in this course, cite it accurately or label it clearly as illustrative. Inventing a citation, a standard, a statistic, or a case-study result is the same kind of failure as a fabricated project status: it substitutes an appealing claim for a verifiable one.

2. Recurring situations

Situation The request, as it usually arrives The professional response
Reporting "Can we leave that risk out of the client report?" Report accurately and escalate; documents exist to convey truth, not comfort
Forecasts "Give them a date they'll accept" Distinguish estimate, target, and commitment; state the gap
Conflicts of interest A supplier selection where you have an interest Disclose it; the test is whether disclosure would change how it looks
Gifts and hospitality A vendor offers a conference trip during evaluation Decline or disclose according to a written policy
Data "Keep everything, it might be useful" Minimal collection and defined retention; verify legal requirements for your jurisdiction
Release pressure "Ship it, the defect is unlikely to trigger" Escalate to the accountable person, in writing, with the risk stated plainly
Scope pressure "Just squeeze it in" Run the change process; the consequence must be recorded, not absorbed silently
Honest labelling A prototype described as a working product Describe what exists, not what is hoped for

Notice the pattern: almost none of these are dramatic. Each is a small accommodation that would be convenient, and each is a substitution of something appealing for something true.

3. Escalating without wrecking the relationship

Escalation is a professional duty, not an act of hostility, but it has to be done in a way that survives the week.

  1. Get it in writing, factually. State the issue, the assessed impact, and the options with their consequences. Avoid adjectives; they invite disagreement about tone instead of substance.
  2. Escalate to the accountable person, not to an audience. Escalation is a request for a decision from whoever owns the consequence.
  3. Offer options you can live with. A recommendation with alternatives is easier to accept than an objection.
  4. Escalate before the deadline, not after. Late escalation converts an ethical question into a post-mortem.
  5. Follow the agreed path, and know what you will do if it fails. Internal escalation first; if the public interest is genuinely at stake and internal routes fail, the code recognises obligations that survive a refusal to act.

4. Ethics and law are different questions

Something can be legal and unethical, and the reverse is rarer but possible under a poorly framed rule. Two practical consequences follow.

First, compliance is a floor, not a standard. Meeting a data-protection requirement does not make excessive collection wise, and passing a safety review does not make shipping a known defect acceptable.

Second, specific legal requirements vary by jurisdiction and change over time. You must verify them against the applicable law and organisational policy rather than assume. This course deliberately does not state the legal position for any country, because doing so accurately requires a source that is current when you read it.

Key terms

Term Meaning
ACM/IEEE-CS Code of Ethics The professional code for software engineering practice
Conflict of interest A personal interest that could improperly influence a decision
Disclosure Declaring an interest or risk so others can judge it
Whistleblowing Reporting wrongdoing when internal routes fail
Informed consent Users agree to a use of their data with understanding
Data minimisation Collecting only what the stated purpose requires
Escalation path The agreed route for raising an issue beyond your authority

Worked example

Task: work through three decisions on the illustrative hospital appointment system. All details are invented for teaching.

Step 1 — The release decision. Testing finds a defect that, under load, can display one patient's appointment reference to another. The launch date has been publicly announced. Fixing it moves the date by three days.

Applying the code's product and public principles together: a schedule deadline is not a reason to expose patient information to the wrong person. The professional action is not to decide unilaterally and not to comply silently, but to escalate in writing, with the fact, the impact, the three-day cost, and the options. The accountable owner decides; the record shows they decided with the risk visible. If the answer is "ship anyway", the escalation goes further up the agreed path.

Step 2 — The data request. A manager asks to retain all applicant identity documents "indefinitely, in case of audit". The public principle applies: collection and retention should serve a stated purpose. The response is to establish what the audit requirement actually is, propose a defined retention period that satisfies it, and record the decision with its justification. Note the tone: not refusal, but a request for the purpose that justifies the retention.

Step 3 — The reporting request. A steering report is drafted showing that the project will miss a milestone by two weeks. A senior stakeholder asks for the variance to be described as "minor timing adjustment" to avoid alarming an external partner.

This is the product and judgement principles in practice. The report is amended to be accurate — a two-week variance is a two-week variance — while the framing can legitimately address the audience: what the impact is, what is being done, and what is required. Accurate and reassuring are not opposites; inaccurate and reassuring are.

Step 4 — Notice what all three have in common. None offered a large sum of money or asked for a crime. Each offered a small convenience. Ethics in project management is mostly the discipline of noticing small conveniences.

Step 5 — Record the reasoning. The escalation, the decision, and the reason are recorded in the decision log. That record protects everyone — including the person who decided against the escalation, who is entitled to show that they decided with the facts in front of them.

Common misconceptions

“Ethics is a code you comply with”

A code is a reference for judgement, not a checklist. The skill is recognising the ethical dimension of an ordinary request.

“If it's legal, it's fine”

Compliance is a floor. Legality does not answer whether collection was necessary, whether a disclosed risk was acceptable, or whether a prototype was described honestly.

“Raising concerns is disloyal”

Concealing a risk from the people who bear its consequences is the disloyal act. Escalation with facts, options, and timing is the professional relationship working as intended.

Practical activity

Reason through a dilemma. For one example project:

  1. Write a short scenario in which a plausible, convenient request has an ethical dimension. Make it uncomfortable rather than obviously wrong.
  2. Identify the principles of the ACM/IEEE-CS Code of Ethics that bear on it.
  3. Write the escalation: fact, impact, options, recommendation, and deadline.
  4. State what you would do if the escalation were refused.
  5. Note one part of the situation that turns on law rather than ethics, and state how you would verify the legal position for your jurisdiction.

What "good" looks like: a scenario where the wrong choice is genuinely tempting, correct identification of the applicable principles, an escalation that is factual rather than indignant, and an honest recognition that legal questions need verification rather than recollection.

Self-assessment

  1. Why is "it's legal" an insufficient answer to an ethical question?
  2. What should an escalation contain, and why does timing matter?
  3. A vendor offers your team a paid trip during an evaluation. What is the test for whether to accept?

  4. Why is it wrong to withhold a known risk from a status report?

  5. Apply it — release decision. One week before release, acceptance testing shows that the mobile banking app writes a customer reference number into an application log where it should not be. It is invisible in normal use and has no functional effect. Fixing it slips the release by two days; the release is tied to a marketing campaign, and your manager says the log is internal-only.

    Hint: A strong answer names the principles involved, separates the ethical question from the commercial one, and states what you do if you are overruled.

Show answers
  1. Because law sets a minimum standard that is often far below what the affected people would consider acceptable, and it changes over time. Meeting a requirement does not settle whether collection was necessary, whether a risk was acceptable, or whether a description was honest.
  2. The fact, the assessed impact, the options with their consequences, a recommendation, and a decision deadline. Timing matters because escalation before the deadline is a decision, while escalation afterwards is a report on something that has already happened.
  3. Whether disclosure would change how the decision looks. If accepting would require you to mention it before the selection is judged fair, decline or decline pending disclosure under a written policy.
  4. Because reports exist to convey the truth to people who must decide, and withholding a risk denies them the information the decision depends on. It also transfers the consequence to people who had no chance to weigh it.
  5. This is a public and product question, not a schedule question: customer data is being handled outside the purpose it was collected for, and the fact that the log is internal does not change who can read it. Record the defect, state the impact and the remediation, and recommend the two-day slip — the commercial argument (campaign timing) is real but it is the business's to weigh, and it cannot be weighed by someone who has not been told the facts. If the manager accepts the risk anyway, escalate in writing to the next accountable level before the release: the facts, the principle you are relying on, your recommendation, and the residual risk the organisation is accepting. Do not go outside the organisation, and do not overstate the severity. One honest distinction to draw in your answer: if the logging is prohibited by data protection law rather than merely unwise, the decision is not the organisation's to make, and the escalation is to whoever owns compliance.

Summary

  • Professional ethics in software engineering has an established standard: the ACM/IEEE-CS Software Engineering Code of Ethics and Professional Practice (1999).
  • Ethical questions usually arrive as small conveniences in reporting, procurement, data handling, and release decisions.
  • Escalate factually, to the accountable person, before the deadline, with options and a recommendation.
  • Compliance is a floor, not a standard; legal requirements vary by jurisdiction and must be verified rather than assumed.

Further learning

  • Lesson 5 — Advanced Project Management and Governance
  • ACM and IEEE Computer Society, Software Engineering Code of Ethics and Professional Practice (1999) — available from both organisations.
  • Institute of Electrical and Electronics Engineers, IEEE Code of Ethics — the broader engineering code.
  • A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Project Management Institute — on professional responsibility and integrated governance.

Next

Continue to Lesson 5 — Advanced Project Management and Governance.