Yesterday, I introduced the concept of a “project confessional,” where troubled IT project managers could confess their “sins” and ask for help.

Before we delve into the more subtle issues associated with such a confessional, I want to cover the basics … and before I do that, I want to acknowledge that this is not some crazy idea that I thought up all by myself. The IT Project Confessional was one of many novel and innovative ideas developed over a period of several years, starting in the early 1990s, by a group of IT consultants and educators who gathered together in an unpaid, voluntary effort known as the “Airlie Council,” to offer suggestions and advice to the U.S. Department of Defense for improving their software procurement, acquisition, and development efforts; the group included such well-known names as Tom DeMarco, Capers Jones, Vic Basili, Susan Tinch Johnson, Frank McGrath, Tom McCabe, and others. Oh, yeah, and me.

The Airlie Council, formally known as the Software Program Manager’s Network (SPMN) operated through the 1990s, until its funding was cut off in 2001; some of its products and ideas have been preserved by a Washington-based consulting firm called American Systems, and can be found here on the Internet. Among the innovative ideas concocted by the group were such things as compiling a set of known “worst practices” to complement (and offset) the traditional “best practices” created in many organizations, as well as a “project breathalyzer” test to help make a quick assessment of the likelihood of an IT project running amok and failing catastrophically.

As for the project confessional concept: it became evident that the massive DoD organization had “politics” that were every bit as intense as what one would find almost anywhere else. If you were one of, say, 10 junior officers of approximately equal rank, and if you knew that roughly half of you might get promoted within the next year or so, chances that that you wouldn’t want to blurt openly about your mistakes, weaknesses, and screw-ups. And if your superior officer was a gruff, no-nonsense person whose management approach consisted mostly of yelling at people, or reassigning them to the U.S. equivalent of Siberia, then you probably wouldn’t want to tell such an officer that you had just made a serious mistake on a mission-critical IT project under your command.

And so the idea of a “confessional” evolved. The idea was that one of us would visit a military base or IT development organization where several projects were underway, and let it be known that we were available for “free” consulting about any project-management issues and problems that anyone wanted to talk about. Anyone who wanted to meet with us could contact us directly to schedule a time and place; most of the meetings were about an hour long, but they could be longer or shorter depending on the needs of the individual.

There was an agreement that our conversations were confidential, to encourage frank discussions. On the other hand, most of us (probably all of us) Airlie Council consultants had no military security clearance, so the project managers knew there was a boundary separating that which they could conceivably discuss with us, and that which was off limits. I mention this primarily because it also meant that certain “categories” of mistakes, or project decisions, were generally off-limits, and would not come up for discussion.

And I mention that point because even in a non-military/unclassified IT organization, there may be a boundary between things that the confessional “priest” can keep confidential, and things that he or she cannot. If a project manager says to me, “Forgive me, father, for I have sinned: I took a thousand dollars from petty cash to buy a plane ticket for my star programmer, so he could spend the weekend gambling in Las Vegas,” that obviously poses a serious ethical problem. We’ll come back to this point in a future blog posting…

In any case, the project-confessional meeting is usually over at the end of an hour or so; and there are several possible outcomes. Sometimes, the “priest” can offer immediate advice — even if it’s something unpleasantly negative like, “Sorry, kid, but I see no miracle cure for you; your project is doomed. Better update your resume, and try to be brave to tell your boss now that that you’ve made an irrecoverable mistake.” Of course, sometimes the immediate advice is positive, with some simple suggestions for solving the problem.

Of course, many real-world problems are not so simple that they can be solved on the spot, no matter how experienced the “priest” may be; thus, there may be an informal agreement that the “priest” will contemplate the situation for a day or two, and then communicate a brief recommendation by phone or secure e-mail. A followup meeting may be appropriate, especially if additional questions or discussion are required to understand the nuances of the problem; but this should not be considered the beginning of an ongoing, open-ended consulting relationship.

On the other hand, sometimes the best advice that the “priest” can offer is that some kind of ongoing consulting assistance is needed — perhaps to solve an ongoing technical problem, or perhaps to continue offering some management-related advice and guidance. To avoid conflict-of-interest problems, the “priest” will generally not recommend his own services; but any recommendation is likely to open a can of worms, since (a) it means additional fees and expenses will probably be involved, and (b) it almost certainly means that the details of the problem (i.e., the one that caused the “confessional” meeting in the first place), and the long-term solution to the problem, will become known to the “sinner’s” peers and superiors. Again, we’ll discuss this in more detail in a future blog posting.

So that’s the basic idea of a project confessional. It’s probably not the sort of thing you would be likely to see in a small IT organization with 10 programmers and 2 project managers. But it’s the kind of thing that could be extremely practical and helpful in a large IT organization with a few thousand technical staff members, a few hundred managers, and several dozen development projects underway at any given time.

More to come … stay tuned.