Development team ethics, Part II – The Cesspool

Are standard project management practices really unethical? Or are they simply the lesser of the available evils?

I won’t stoop to an Anthony Weiner tie-in. I won’t stoop to an Anthony Weiner tie-in. I won’t I won’t I won’t I won’t …

Oh, hello there. Welcome to Part 2 of our review of a moral cesspool. No, not that cesspool. We’re talking about project management as described by Scott Ambler in his recent article, “Survey Shows Unethical Behavior Rampant Inside IT Development Teams,” (Dr. Dobb’s Journal, 5/3/2011).

Last week’s column set the stage by reviewing three relevant ethical principles and distinctions:

• Deontologism vs Consequentialism: Whether to judge ethics based on the action itself or its consequences.

• Corporations as moral entities: They aren’t. They’re presumptively amoral (not immoral) entities whose “ethical” guideposts are profits and shareholder value, and whose ethical boundaries are whatever the law and applicable regulations allow.

• Employee ethics: When acting as employees, human beings are their employer’s agents, subordinating their own ethical code to that of their employer. This includes how they work with their employer.

Now we’re ready. Mr. Ambler lists four areas of questionable ethical practice: Budgeting, scope management, scheduling, and quality.

Here’s where development teams are guilty with respect to budgeting: “Padding the initial budget (effectively deceiving stakeholders as to the actual expected costs); requesting extra funds at the end of the project even though they’d committed to a fixed budget; or reworked the initial estimate to align with the actual results at the end (effectively ‘cooking the books’).”

The complaint about scheduling is parallel: Padding, extending, or re-working it even though flexibility wasn’t negotiated up front.

Scope? Project teams change it even though flexible scope wasn’t initially negotiated.

Quality compromises? Done to “get the team out of trouble.”

Deontologically speaking, these practices are all either deceptions or failures to live up to commitments, and therefore, wrong.

Take context and consequence into account, though, and you’ll arrive at a different conclusion.

Here’s what project managers face all the time: Bad business sponsors. Some don’t understand the role, some reject it, and some adopt a company-defined bad version. Regardless, bad sponsors make project failure more likely.

Project managers balance five parameters in trying to survive the experience: Budget, schedule, scope, quality, and risk. It’s a zero sum game because when you’re planning a project you’re dealing with a period of time called “the future.” Some business sponsors appear to be unaware of its most significant property – uncertainty. How the future will play out … whether one team member comes down with the flu at a critical juncture; another “calls in rich”; or an infrastructure upgrade outside the project team’s control changes the development environment in unpredictable ways … isn’t known and can’t be built into the project budget and schedule before the project launches.

Competent business sponsors understand this annoying property of the future. When untoward events happen they collaborate with the project manager to make appropriate course corrections.

The others? They consider the initial “negotiated” budget, schedule and scope to be commitments … contractual obligations with the force of holy commandments, inviolable no matter how the future turns into the present (and then the past where 20/20 hindsight reigns supreme).

Which is why padding is mandatory. With competent business sponsors it takes the form of clearly identified contingency allowances. With incompetent business sponsors? Smart project managers insert covertly named items in the budget and tasks in the schedule to achieve the same purpose.

Project managers who don’t successfully pad have to take other steps when bad things happen. Are they unethical? Of course not.

First and foremost, the sponsor is acting as the company’s agent so his/her behavior defines the development team’s ethical obligations, not Mr. Ambler’s standards.

Second: By Mr. Ambler’s standards, all of the available choices are unethical. As changing the scope, schedule, budget, or quality are, in his eyes, unethical, the only remaining alternative is a deathmarch. This leaves the budget, schedule and scope intact, although the ethics of insisting on a deathmarch are, for some of us, more questionable than padding a budget.

And ethics notwithstanding, deathmarches cause fatigue and stress, leading to poor quality, and increasing the risk of complete implosion.

Ambler’s analysis fails to take this lesser-of-evils conundrum into account. When all of the available choices are bad, judging a choice in isolation is ridiculous.

Finally, self-defense and protecting others are widely accepted to be acceptable justifications for all sorts of situations, up to and including killing someone.

Seems to me that when good project managers have to contend with bad business sponsors, “self-defense” is describes their best choices perfectly.

Unethical? Hardly, especially as the supposedly more-ethical alternatives all lead to far worse consequences.

—————————————————————————————————————————

For this week’s Great Quotation, click here.

—————————————————————————————————————————

Bob Lewis is author of Outsourcing Debunked and eight other books on information technology in business. He is president of IT Catalysts, Inc., a consultancy specializing in business change … in particular the impact of IT organizational effectiveness and integration.