Conrad Weisert, January 8, 2008
©2008, Information Disciplines, Inc.
NOTE: This article may be reproduced and circulated freely, as long as the copyright credit is included.
October's featured article What Ever Happened to Return on Investment? stirred up some strong comments. Many readers were indignant that the people who cause these costly fiascos usually escape the consequences. They may have moved on to another job, or upper management may just never associate today's effects with yesterday's causes.
Is that necessarily a bad thing? One might argue that blaming a manager for a failure from two years ago is unproductive and demoralizing. But on the other hand, if everyone in an organization believes that there are no consequences to taking expedient shortcuts that may lead to costly future troubles, then there's no incentive to adopt and follow enlightened good practices. Worse, there's little reason to expect the organization to learn from its mistakes and do better in the future.
I'm confident that most business schools and experienced managers would agree that those who make decisions (or fail to make a decision) in an organization should ultimately be held accountable for the foreseeable results of their action (or inaction). That is not to say that that one should be punished when things turn out badly. Performance evaluation rests on aggregate performance over a span of time, like a baseball statistic. If I've delivered solid results on eight projects and then mess up the ninth, I probably don't deserve to be fired; we learn from our mistakes.
Two kinds of people bring about most of these costly I.T. fiascos:
Organizations need to do a better job of holding those villains accountable for the results of their negligence.
Both kinds of people often escape being held accountable by leaving their jobs before having to deliver results. They may accept a job in another organization or they may get a promotion in their current organization. We've all watched a chief information officer, a project leader, or a lead programmer leave for another job issuing an optimistic final status report. His or her replacement inherits commitments that are allegedly almost complete and that have no serious quality issues.
Or they may actually deliver an application system that passes demanding tests but that turns out to be a costly maintenance nightmare a few months later. Maintenance will be someone else's problem.
In most if not all of these situations the person best qualified to raise accountability issues is the replacement who inherits the responsibility. But few managers invite them to do so, and some won't tolerate it.
If you've been offered a new job, a promotion or for a new employer, you should carefully study all the commitments you'll be undertaking. Be especially wary of the project that is almost finished and in great shape.
If you cannot accept the commitments, then don't give in to the pressure to do so. Whatever you do, don't hope for a miracle to bail you out.
And if you're the manager to whom the replacement will report, you should not only welcome his or her care but should actively invite it. I would even be suspicious of a new-hire who doesn't review inherited commitments.
Ideally, all that should occur before the villain gets away with his or her reputation intact. Indeed he or she should be given the opportunity to defend the work and rebut the replacement's negative assessment. In the event of an irreconcilable disagreement, you should have a disinterested party conduct a project audit and quality review.
Learning the hard way
I once took over a project that was in deep trouble. I knew it was in deep trouble, and so did almost everyone except the in-house client organization's management, who had been getting rosy status reports from my departed predecessor. But I assumed that it was my duty to protect the system development organization—my boss and his boss—from embarrassment with the client.
We had a good team and worked furiously to salvage the work without revealing how much work had to be redone and how misleading the estimates had been. In the end the project barely squeezed by, over budget and behind schedule, with relations between the client and the system development organization badly strained but not broken.
If I were confronted with the same situation today I would blow the whistle at the start, even at the risk of embarrassing my organization. There are no miracles.
Suppose we've discovered that a software system under development is of extremely poor internal quality and will be a maintenance nightmare, and suppose we've determined who is to blame. What should we do about it?
First, we'll want to determine whether the fiasco stemmed from:
If it's a (ignorance), then we've got the wrong principal perpetrator. If we've somehow put an employee (or a contractor) to work without informing him or her of the rules and providing suitable training, then we have even more serious problems in our organization.
I have very little tolerance for c (deliberate misconduct), and normally regard it as cause for termination if the offender hasn't already left. At the very least it should rule out any short-range advancement in the organization. An incompetent (b above) emloyee can sometimes be salvaged by coaching or reassignment, but a dishonest or treacherous one is unlikely to change.
If the offender is leaving the company, you may be called upon to provide a reference. These days many organizations are so fearful of being sued by a disgruntled former employee that they decline to give out any information beyond the dates of employment and perhaps salary. But we know that word gets around anyway.
Last modified January 8, 2008
Return to IDI home page