Project Description

By: Scott Andersen

I’ve posted a number of ethics questions and topics here on the IASA blog over the past 6 months. Recently I got an interesting question that I have been thinking about since I got it. It’s kind of delayed my regular posting as I thought about it.

“What is the ethical response to a project going off the rails?

First off a quick explanation, the person writing is part of a large internal IT project that has gone very poorly. The question refers to the ethical behaviors required once a project does unhinge. I am clarifying because based on the original question I actually had a long email and then telephone conversation with the person.

When projects go bad the blame game starts. Fault and blame are thrown around as if they were tiny dolls made of straw. Flying through the air in meetings, sent to people in all caps emails and texts and written into reports. The project failed and it is your fault.

Acting in an ethical manner during failure means a couple of things. The first thing is you keep your cool. By cool in this scenario it means you don’t blame and you don’t place fault on others early. You begin to breakdown the areas of the project that didn’t work. You consider the original requirements, the modified trade off requirements and finally the risk register for the project. Failure is always an option and isn’t always a bad thing. Blame and fault are always a bad thing.

Evaluate based on that initial review your contribution to the problem. Early in the game be careful what you take responsibility for. Frankly if you are responsible for 1% of the overall problem and take responsibility for that early in the blame process you will end up being blamed for a lot more. It is the ethical thing to do, be responsible and take responsibility. But wait until the initial storm of blame has passed. That initial explosion isn’t rationale and people are looking for someone to blame.

The other side of an ethical response for software architects to determine the root cause in the end of the failure. It is ultimately to paraphrase Thomas Edison the way to learn how not to do things. Again failure isn’t bad, it happens to everyone. Learning from failure makes us stronger, better and smarter the next time.

So based on the email I came up with some ethical rules for software architects to consider when embarking on and frankly recovering from a project that fails.

Ethical Rules for Failed Projects

  • Don’t blame
  • Review the original requirements, trades off and risks.
  • Access the project from all sides
  • Evaluate the organizational roadblocks
  • Don’t find fault with others
  • Once the blame storm has passed accept responsibility for your part.

Projects don’t fail on the first day, but they can fail early on. Be prepared when you see the project leaning to far over to recover. Follow the simple rules above and most importantly don’t be the fault or blame person.