The longer I work in the IT industry, the more amazed I am at the type of mistakes that project managers make, and also the way they react to them — both at the time the mistake is committed, and when they talk about it weeks, months, or even years later.

I have a somewhat unusual perspective on this issue, because in addition to my work as a project-management consultant in the IT industry, I also spend part of my time working as an expert-witness for attorneys, on computer-related project failures. Since we “experts” are typically brought into a case months or years after a lawsuit has commenced, and since the lawsuit typically doesn’t start until a project has collapsed, it means that the work we do is somewhat akin to archeology. Often, the key individuals who were there when the key decisions were being made have disappeared from the scene: they quit, retired, died, or were fired. Occasionally some of these folks are still around, and can be interviewed (though it’s only the folks on your side of the legal battle, because the legal system almost always precludes conversations with the key individuals on the other side, until formal depositions are taken, under oath, or testimony is heard at trial).

When you do talk to the project managers, or project stakeholders, or key technical people to find out what really took place when the project ran into trouble, it’s not surprising that memories are vague, inconsistent, and sometimes strongly biased. But the e-mail archives are typically still intact, and that’s the first thing the lawyers go after; in addition, there may be status reports, risk management plans, issue lists, Gantt charts from Microsoft Project, and various other documents that provide a more objective picture … and, just like archeologists, often you can brush away the dust of history, and see fairly clearly what key mistakes were made — and when, and by whom.

In these project management lawsuits — which typically involve disputes between the customer who originally asked for a system to be developed, and one or more vendors (and sub-contractors, systems integrators, and advisors) who promised to build that system within a certain budget and schedule — you quickly learn that the world is not completely black-and-white. Both sides made mistakes; neither side was perfect. The question usually is who made the biggest (most serious) mistake(s), when they were made, whether they were anticipated, whether they were “justified” (e.g., caused by events or forces beyond the control of the person or company that made the mistake), and what they did about the mistake.

Especially when you’re dealing with 20-20 hindsight, it also becomes evident that many of the mistakes are “venal,” in the sense that they might have caused some minor difficulty, but the project would have succeeded anyway. Maybe a task was finished a couple days late … but it wasn’t on the critical path, so who cares? Maybe there was a bug in the delivered software, and it remained unfixed for months after it first showed up on the “trouble report” filed by an end-user … but it was a cosmetic bug that made one of the user display screens look a little ugly, so who cares? Maybe the mistake added a thousand dollars to the cost of the delivered system … but if the total budget was three million dollars, then even though it was a larger mistake than I could have tolerated in my own personal checking account, who cares?

On the other hand, some mistakes are clearly cardinal mistakes; even if everything else went perfectly, that one mistake may have caused the failure of the entire project. Or they put the project at such extreme risk that the slightest additional problem will turn out to be the straw that breaks the camel’s back. Inevitably, things do go wrong in large, complex projects — despite our best intentions, and despite our best efforts — because (a) people are fallible, and (b) there are indeed events and forces beyond our control. So it’s not surprising that the largest “cardinal sin” that one finds in reviewing a project is the lack of a robust, up-to-date risk management plan. Sometimes it’s the lack of support (either in the form of benign neglect, or outright attempts to sabotage) for the project on the part of senior executives, or key stakeholders. Or it might be a deadline that was clearly impossible from the outset, or a project team that was utterly inexperienced and unfamiliar with the business domain of the project, or one of several other key categories.

But I’ve been talking about after-the-fact analyses here, i.e., attempts by a technical expert to look back into the past and determine what went wrong. For the confessor-priest in an IT project confessional, the situation is usually different: the mistake has just occurred, or it’s about to occur in the next few hours, days, or weeks. What then?

Well, the distinction between “venal” and “cardinal” is still relevant, and the confessor-priest can usually approach by asking the simple “So what?” question. The confessor priest can say to the project-manager sinner, “Okay, so you did X wrong, or you forgot to do Y, or you did Z when clearly you should not have done so. So what? Is the project doomed?” If not, then it may be necessary to apologize to someone, or to take some corrective action, but the most important advice from the confessor-priest is usually, “Get over it.” That is, do whatever you must to put it behind you, and move on. There’s more work to be done, more milestones to reach, and an “ultimate” deadline still looming in front of you. Brooding over past mistakes, and crying over spilt milk, won’t get you closer to the goal.

On the other hand, if the mistake did indeed fall into the “cardinal” category, it’s important to confront that reality, too. Even in this case, corrective action may be possible — but it will usually require major apologies, major effort and expenses, and an acceptance that promotions, bonuses, and other rewards will not be forthcoming.

In the worst case, the cardinal sin may be so bad that the project is effectively doomed. Nobody likes to hear that kind of assessment, and it’s often rejected as a “defeatist” attitude. Unfortunately, it’s sometimes combined with a bit of “martyr” behavior on the part of the project-manager sinner: he doesn’t want to come out and say it openly, but his post-mistake behavior basically says, “I really screwed up, and the project is doomed, but I’m going to continue working as hard as I can, so that I can show everyone I didn’t run away from my mistake.”

If it’s a one-person project, maybe that’s okay (as long as senior management and the business user knows about it). But when the project manager has a dozen (or a hundred, or a thousand) people working for him, then it’s really not fair at all. I’ve seen situations where the project manager made a critical mistake (or, more commonly, a series of critical mistakes that culminated in irretrievable disaster) but managed to keep it hidden for several months — while the members of the project team continued working at a frenzied pace, and while senior executives continued pouring money into what would eventually be identified as a bottomless pit.

All of which leads to an outcome that I haven’t mentioned up to this point, but which the confessor-priest needs to be prepared for: sometimes you don’t get fired by stakeholders and senior executives who don’t like what you’re saying. Sometimes the project-manager sinner clams up, gets stubborn, and refuses to talk to you any more. Whether the confessor-priest maintains his vow of confidential silence, or whether he decides, at that point, to take the bad news to senior management … well, that’s another ethical question to ponder. Anyone cast into the role of confessor-priest needs to make whatever decision he/she is comfortable with; all I can do is suggest that you think about it carefully in advance.

Tomorrow, we’ll turn to another aspect of the IT project confessional: resisting pressure from higher-level executives …