They worry (understandably) about the alignment of their IT activities to the business strategy that they hear about from the CEO and the Board. They worry about whether the hardware and software they’ve invested in will be adequate for carrying out today’s job, scalable enough to accomplish next year’s job, and whether it will last long enough to avoid being classified as obsolete legacy junk within a year. They worry whether they’re hiring the right kind of people, and they worry about whether their IT shop is the kind of place where the “best and the brightest” would want to work. The list goes on and on …

But if there’s one thing at the top of every CIO’s “worry list,” you know what it’s going to be: security. I can’t recall a single CIO that I interviewed who had something else at the top of their list, though some were more confident than others that they were doing a good job in the security area. Most were proud of the efforts they were making, and proud of the securit-related skills of their IT professionals; and many shrugged, as if to say that security was like death and taxes: something that would never go away, and that you just had to cope with.

One theme was almost universal in the security-related comments I heard from CIOs; but there were two other themes that I think are almost as important, but which remained largely unspoken. The three items are as follows:

1. Attackers are becoming increasingly sophisticated, well-equipped, and well-financed. As the CIO of one prominent company said to me, “It’s humbling to realize that an entire country is doing its best to bring your systems down.” Others have the scars to show that attackers view them as “symbolic” of something their religion, their culture, or their government strongly dislikes or condemns; if you’re the CIO of Goldman Sachs, or the Federal Reserve, or the New York Stock Exchange, you’re likely to feel that you’re defending the epitome of Western capitalism. If you’re the CIO of the organization that runs the Scholastic Aptitude Tests (SAT’s), which I first took more than 50 years ago, you might well have nightmares about gazillions of geeky students trying to hack into your system. Electric utilities, airlines, auto companies, oil companies, and high-tech firms ranging from IBM to Microsoft to Apple, all have good reason to worry. I could argue that the only people who don’t have to worry are the folks running the mom-and-pop deli on my street corner … but even they have a web site, and a Twitter account, and a computerized cash register.

2. Security breaches are frequently causes by “insiders” — and today, just about every insider has access to the organization’s IT assets. Once upon a time, we could hide the corporate mainframe in a thick-walled subterranean room, and we could keep a (short) list of the people who had access to the hardware, the software, and the data. Now it’s just about everyone, including our customers, our partners, our sub-contractors, and our vendors in addition to our employees. There are obvious security threats associated with the desktops, laptops, and mobile devices that all of these folks have in the office, at home, and in their pockets — but it’s the human element I’m more concerned about here. Even when we only had a small number of IT people with access to our technology, we had to worry about sloppy behavior that disregarded or flouted security protocols; we had to worry about disgruntled employees, and we had to wonder whether any of our employees might become just a little too tempted by the prospects of fame, fortune, or access to secrets. Now we have to worry about everyone. The odds of one “rotten apple” in a group of a hundred may not be too bad; but when we’ve got 100,000 employees, it’s a different game altogether.

3. The “culture” of today’s worker is different than it was a generation or two ago. I have to be careful here, because I’m not a trained sociologist, and I don’t have any reputable studies to prove or disprove my point. I’m not trying to suggest that everyone is a crook, or that there are no standards of ethical behavior in today’s workplace; indeed, we may have a situation where the “mean,” or “average,” human behavior has remained about the same, but the “standard deviation” has increased substantially. Whatever it is, we now have a work environment where companies routinely outsource jobs and terminate employees by the thousands; what impact is that likely to have on employee loyalty? We have a popular culture where convicted felons — including executives, politicians, and movie stars — serve a minimal prison sentence and then get signed up as a celebrity talk-show host; what impact is that likely to have? And, at least in many of the “advanced” Western countries, we have a social culture where many young adults feel they are “entitled” to the benefits of large salaries and extravagant life-styles, even if those are not readily available through the normal patterns of hard work. The “Occupy Wall Street” protesters may not have articulated their message in quite this way, but if you’re one of the technology-equipped 99% working-class folks, and see your 1% boss making 100 times your own salary, one of your reactions may well be, “How come he/she makes so much, and I make so little? Maybe I can break a few rules, using the high-power computer gadgets they gave me, and scoop up a little of the corporate fortunes for myself.”

All in all, it’s enough to give anyone nightmares!

The difficulty of tracking them down in the first place was a surprise, and it’s something you might want to experiment with: can you find the CIO of a company that you think is doing a particularly good or bad job with its use of IT? Or, for that matter, the CIO of a company that has recently gotten a lot of bad press because of an embarrassing failure that looks like it was caused by, or exacerbated by, its IT systems?

Almost all CIO’s have a title of “Vice President” or better; some are members of the Board of Directors of their organization, and many report directly to the CEO or COO. So you should be able to go the company website, and track down a page or two that shows mug shots of the Board, or the “executive team,” and you might even be optimistic enough to assume that you’ll find a phone number or a hyperlink that you can click to send an e-mail message directly to the CIO you want to contact.

The reality is that many companies have no public information about the identity, or even the existence of their Chief Information Officer. If you try googling “CIO of XYZ Corp”, you might find a page that tells you who that person was back in 1999, or that the CIO of XYZ Corp has just left, and is on his way to a new assignment at ABC Corp (which you may or may not be interested in). Or you might find the names of half a dozen “assistant” CIO’s who deal with various subsidiaries or geographical regions, but who report to an über-CIO whom you can’t find. As for getting their phone numbers or e-mail addresses … good luck!

What surprised me even more was how many CIO’s that I did manage to track down were uninterested in talking to me about how IT was being used in their organizations. I could understand why a company recovering from a scandal would want to hide its CIO (and probably all the rest of its executives, too!) from the public; and I could understand why the CIO of a company like General Motors would politely decline, citing the hectic pressure of helping to build the “new” General Motors after its emergence from bankruptcy. But several others — including not only the CIOs, but also their administrative assistants, and their public relations/communications contacts inside and outside the company — stonewalled or ignored my repeated attempts to communicate with them via phone, fax, or e-mail.

After several such unsuccessful efforts, it finally dawned on me: in some of these organizations, strategic use of IT really is considered a competitive advantage. If these firms really do believe that to be the case, why on earth would they want to share that competitive advantage with anyone else? Why would they want to discuss it; why would they even want to acknowledge its existence? It would almost be like the CIA or NSA opening up all of its secret files for public review and discussion. We’re no longer surprised that a company like Apple keeps the engineering details, as well as the software features, of its next-generation iPhone and iPad a secret all through the R&D and development phase; why should we be any more surprised that it keeps most of its IT strategies and assets hidden, too?

At the same time, the secretive approach towards IT that these organizations exhibit reminds me of “closed” countries like China and North Korea — or, more recently, Middle East countries like Tunisia and Egypt, where attempts to shut down the Internet essentially shut down the country’s economy. Wall Street financial firms are not the CIA, and in the long run, I believe their attempts to seal themselves off from the increasingly interconnected Internet-enabled world will prove to be a failed strategy. Of course, a cynic would observe that in the long run, we’ll all be dead — and between now and then, there may well be some vast fortunes to make or protect by keeping this information hidden.

Meanwhile, some organizations are clearly proud of what they’ve done, and what they plan to do in the future, with information technology. They’re not going to share their “secret sauce” proprietary algorithms (e.g., the CIO of Google didn’t offer to share its page-ranking algorithm with me when I interviewed him, any more than Coca-Cola would have shared the detailed recipe for its soft drink) and they’re not going to deposit all of their software in an open-source code repository. But companies like these realize that their employees — who often number in the tens of thousands, sometimes even the hundreds of thousands — represent a society of their own, and that it’s a positive thing to encourage their employees to interact with customers, suppliers, vendors, and business partners in the outside world.

Equally important, most of the companies I spoke with have finally accepted the wisdom of the vintage-2001 The Clue Train Manifesto: the end of business as usual, with 95 theses describing the new “reality” of networked marketplace. A decade ago, it sounded quite radical to suggest that “Markets do not want to talk to flacks and hucksters. They want to participate in the conversations going on behind the corporate firewall” (thesis number 62), or that “Companies need to realize their markets are often laughing. At them.” (thesis number 2). But today, more and more companies realize that the best way to confront these theses (which have turned out to be realities, not abstract theories) is to be honest and open, and to be pervasively and intimately involved in the activities of their markets and their customers. As the authors prophesied, this cannot be done by having “flacks and hucksters” talk at the marketplace, but by having everyone, from the lowliest clerk to the mightiest executive, talk with the marketplace — via Twitter, Facebook, smartphone, blogs, wikis, and whatever new forms of interaction may come along in the next few years — via an integrated IT strategy.

In any case, the bottom line is that some CIO’s would be happy to talk to you, and are delighted that their employees are “talking” via mechanisms like blogs (last time I checked, companies like IBM and Microsoft had thousands of “external” blogs authored by their employees). And some CIO’s are doing their hide themselves and their company’s IT strategy from anyone and everyone. You may agree or disagree with such a strategy, but it may not have occurred to you just how differently these companies may be operating.

Regardless of whether you favor an “open” or “closed” approach, vis-a-vis the CIO and his or her IT strategy, I think it’s a good idea to write down a list of “key” organizations — e.g., companies you like, dislike, depend on, or are otherwise impressed by — and see whether their strategy is compatible with your own. You may well be surprised by what you find, and it may encourage you to seek a closer relationship … or to do your best to minimize your interactions with, and dependence on, such companies.

Now that the book has been out for a few months, and has survived its first few reviews, I want discuss some of the insights and issues in more detail – as well as commenting on new developments in the field, which obviously did not stop on the day the book was published. With the convenience and simplicity of a blog, I hope to provide these insights and updates quickly, succinctly, and informally – so that (if I do my job right), it won’t take you any longer to read these notes than it did for me to write them.

One of the first interesting things I learned is that while virtually every large organization today has a senior executive in charge of its “information,” many of them really don’t want the public to know who that person is, or how they might be contacted. For that matter, they really don’t want the public to know the details of what information they acquire and use; or how they manage that information; or what strategies they have for maximizing their profits or optimizing their company’s performance with their information.

There are reasons for this, as I’ll discuss in future blog postings. Many of them are quite understandable, and some might be acceptable to a large segment of the population and business community. But others might take you by surprise; at the very least, it might cause you to give the topic a lot more thought than you’ve been doing so far.

A simple example to illustrate the point: one of the big news items in recent days has been the controversy related to third-party apps that access address-book information in Apple’s iPhone “address book.” For details, take a look at a Feb 14, 2012 article titled “Your address book is mine: many iPhone apps take your data.” It started with an app called “Path,” which was discovered to be uploading the contents of iPhone users’ address books to their servers. Shocking, just shocking! The CEO offered an apology (see “Path CEO: we screwed up by uploading your personal data, and we’ve erased it“), and a naive member of modern society might have dismissed the whole thing as a one-time mistake by an inexperienced startup company… Except that it turns out that Facebook, Twitter, Instagram, Foursquare, Foodspotting, Yelp, Gowalla … and goodness knows how many other iPhone apps — have been doing the same thing, many without asking for permission.

As you can imagine, there’s a lot of detail associated with this particular situation … but it’s merely an example of what’s going on all over the place, in almost every company, in an attempt to acquire, harness, manipulate, and use information to a company’s advantage. That being the case, who better to discuss such issues — within any particular company — than the CIO?

I’ll have more to say about this in future blog postings…. stay tuned.

The tools basically consist of security features on top of open-source tools that are frequently used to build cloud-computing apps: Apache’s Hadoop distributed file system, Google’s Mapreduce and the University of Cambridge’s XEN Virtual Machine monitor. The research team at UT Dallas has focused on tools that will provide secure query processing, as well as tools that store sensitive data in encrypted format in order to add security to data storage devices.

The work is based on a project being carried out for the Air Force Office of Scientific Research, and additional steps are being planned to include the departments of Defense, Justice and Homeland Security, as well as various intelligence agencies and other companies. Demonstration of the tools is already under way at King’s College London and the University of Insubria in Italy.

It’s far too early to tell whether this particular set of tools will become widespread, commercialized, and “mainstream.” But the fact that the research and development is underway, and that it’s being sponsored and supported by such prestigious organizations, is promising. As the article says, “the biggest obstacle to wide adoption of cloud computing is concern about the security of sensitive data,” and the work underway at the UT Dallas Cyber Security Research Center encourages me to hope that we will have robust tools in the not-too-distant future, with which to build cloud-based systems that organizations and individuals can trust with their most sensitive data.

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 …

Assuming that the conversation takes place after a mistake has been made, the confessor-priest should first ask how recent it was. If the mistake was made within the past day or two, it’s possible that it can be corrected/fixed/recovered; more about that in a moment. But in any case, it will still be fresh in everyone’s mind, and it will be considered “relevant” to all concerned. By contrast, suppose the project manager says to the confessor-priest, “This has been troubling me for months, and I have to get it off my chest: six months ago, I gave my key software engineer a performance review without any salary increase at all, because I was too chicken to fight for it with my VP…” Chances are that (a) it’s too late to do anything about it, and (b) the VP won’t remember or care if you decide to bring the issue up now, in an attempt to rectify the situation.

Obviously, one of the main things that confessor-priest needs to figure out is just how “serious” the mistake is (or was). It’s one thing for the project manager to say, “I made a mistake, and our 12-month project is going to be a day late.” It’s something else entirely if the project manager says, “I lost my temper, yelled at the whole project team at the top of my voice, and called them a bunch of childish idiots. When I came into the office this morning, I discovered that every single one of them has quit and left town — and they erased every bit of technical work they did from day one of the project.”

Also, as suggested above, the confessor-priest needs to determine whether the mistake is “recoverable.” Quite a few project-management mistakes turn out to be “human” issues — inopportune statements, insults, jokes, or comments that may have offended a subordinate or a superior. Left to fester, the mistake could have grave consequences; but a timely and sincere apology can often undo the damage, and perhaps even lead to a better working relationship in the future. (I emphasize “sincere” here, because I’ve noticed an all-too-common tendency, perhaps made palatable by politicians, movie stars, and other public figures, to say something utterly outrageous in public, and then offer a bland, passive-voice pseudo-apology along the lines of, “I regret that X was said. It should not have happened….”)

Unfortunately, sometimes the mistake cannot be undone — at least, not with the resources at the disposal of the errant project manager, and not even with the assistance of the confessor-priest. If the entire project team really did quit, and if they’ve got better-paying jobs working for a competitor, it may not be possible to get them back again. If the project manager failed to carry out the required risk-management planning, and didn’t have a contingency plan when something went utterly wrong (a certain oil spill in the Gulf of Mexico comes to mind…), there may not be any practical way to plug the leak, repair the damage, and get things back on course.

All of this typically leads to one of four recommended actions on the part of the confessor priest, when the project-manager “sinner” describes the details of the mistake that he or she has made:

• ignore it — some mistakes really aren’t that bad. And some are “mistakes” only in the sense that they violate bureaucratic rules that had no meaningful impact on the project anyway
• fix it — it may cost money, it may take time, and it may take extra work — but many mistakes really can be rectified. Of course, the sooner you acknowledge it, and the sooner you ask for help and/or begin taking remedial action, the better off you are.
• ask for forgiveness, and vow never to do it again — if the mistake was a human-relations blunder of some kind (e.g., needlessly annoying/insulting a key member of the project team), it may be sufficient to grovel and beg for forgiveness. I find it amazing how rarely management-level people are willing to publicly (and sincerely!) acknowledge their mistakes; more often, they try to stonewall the situation, and bluff their way through it. But asking for forgiveness often works only once; the second time you tell your spouse that you’ve had an affair, and that you’re terribly sorry and really won’t do it again … well, it’s not likely to be very convincing.
• acknowledge defeat — hopefully it won’t happen very often, but let’s face it: sometimes you make a mistake that’s really serious, non-recoverable, and completely unacceptable no matter how much groveling and apologizing you do. If you were the Apple engineer that left the iPhone4 prototype behind in the bar a few months ago, chances are the best thing you could do would be to write a short, polite resignation letter and shove it under Steve Jobs’ door. But even here, sooner is better than later; and taking ownership/responsibility for the mistake (rather than making excuses, or trying to blame it on someone else) is the honorable thing to do.

Tomorrow, we’ll discuss what the IT confessor-priest should do if the project-manager sinner warns him of a mistake that he or she is tempted to commit, but has not yet actually committed…

Or consider this variation: the troubled project manager walks into my office, tells me he hasn’t done anything extreme yet, but wonders if I’ll tell him that it’s okay to shoot the obnoxious member of his project team right between the eyes, and then defend him if senior management becomes unhappy about the situation. What should I tell the project manager?

Admittedly, these are extreme situations, and it’s entirely hypothetical. Maybe it happens in a war zone, but it certainly doesn’t happen in a normal IT project environment. In any case, it’s never happened to me. But the fundamental question still remains: where do you draw the line if/when serious ethical conflicts arise?

While the term “confessor priest” may be useful for the discussions in this series of blog postings, it’s important to remember that the consultants who play this role are not priests, in any official sense of the word. Nor are they journalists, with the legal option of protecting their “confidential sources.” It’s highly unlikely that they are psychiatrists, psychologists, doctors, or anything else that would allow them to claim that statements from their project-manager “sinners” were confidential.

It’s one thing to negotiate a consulting agreement with an IT organization, in which the “confessor priest” states that his conversations with the project-manager “sinners” are confidential. And it’s one thing to refuse a demand to divulge those confidential details to a senior executive in the IT organization. Indeed, the consultant who takes on the role of “confessor priest” should be prepared to resign immediately if pressed on this issue. But if you’re questioned by the police, or the FBI, or a lawyer in a courtroom, it’s a different matter altogether; while I’m not qualified to offer legal advice, I’m pretty confident that the confessor-priest will have to answer questions, and reveal confidences, in situations like this.

So it’s important for the project-manager “sinners” who are thinking of asking for help to know that the “confessor priest” cannot help them if they have broken the law, or violated regulatory procedures and restrictions — especially when it comes to capital crimes, felonies, and things of that sort. Obviously, most project managers don’t run around murdering the members of their project team … but it’s not beyond the realm of possibility that a project manager could misrepresent an expenditure on an expense account or a procurement request, in order to provide some much-needed personal relief (e.g., a weekend of R&R at the beach) for an overworked member of his project team, which would be automatically rejected if requested through official channels.

The real issue typically involves “administrative” rules, and bureaucratic restrictions that kill productivity, frustrate the project team, and dampen morale to the point where the members of the project team have no energy or enthusiasm for their project. For example, one of the project team members wants to work at home from his laptop for a couple days, because his wife and kids are sick with the flu. One of the programmers wants to disable the company-installed Muzak system, because it’s driving him crazy having to listen to Frank Sinatra and Bing Crosby crooning over the PA system all day long. One of the network engineers desperately wants to take a day off in the middle of the week — against company rules — to attend a Rolling Stones farewell concert in a city 300 miles away, but says that he’ll make up for it by working both Saturday and Sunday.

These examples may or may not sound realistic, and they may or may not seem like issues worth making a fuss about. But there are issues worth making a fuss about, and the list of possibilities is endless. After he has agreed to such a request, the project manager may develop a guilty conscience, and may shuffle into the confessor-priest’s office and ask whether he has, in fact, committed a mortal sin.

The confessor-priest has to rely on his own experience, judgment, common sense, and gut instincts about what’s practical, what’s fair, and what “crosses the line” into areas that cannot be condoned or forgiven. Given the same situation, two different confessor-priests might make two different decisions; after all, we’re not talking about a formal religion, and there is no “Bible” to tell us exactly what we should do in every circumstance.

In my case, for example, I’m a firm believer in a “don’t ask, don’t tell” approach to overlooking infractions of minor administrative/bureaucratic rules; but if asked a direct and specific question about such an infraction, I won’t lie to a senior executive in order to protect a project-manager “sinner.” At the same time, if I thought I was going to be interrogated by senior management about every possible infraction that might or might not have been committed, I wouldn’t take the assignment in the first place; or I would resign from the assignment as soon as it became clear that such a “corporate culture” was in place.

Again, everyone will have different opinions, assumptions, expectations, and behaviors when it comes to such ethical issues. It’s something for both the potential confessor-priest and the project-management sinners to think about before the issues arise … because, sooner or later, they will arise.

On to another aspect of the IT project confessional tomorrow…

But there’s an obvious analogy: suppose company X has hired me — just to use a silly example, because it’s easier for me to write in first-person form — as the IT project priest. An announcement is sent out, inviting troubled project managers to schedule a meeting with me. The date of my visit is publicized, and people are told that it’s okay to show up at the office where I’ve been sequestered, even if they haven’t formally scheduled a meeting.

So I show up, sit in my office with a nice cup of coffee and bran muffin, and catch up on my e-mail while waiting for someone to appear. Time passes, and I finish my e-mail; nobody has appeared. So I read the New York Times, spend a few minutes on the crossword puzzle before giving up in frustration, and reorganize my to-do list for the umpteenth time. Before I know it, the morning has slipped away; and after a quiet lunch alone (after all, nobody wants to be seen in public with the notorious “confessional priest”), I return to the empty office for an equally quiet afternoon.

What can we conclude from all of this?

If it’s a small IT organization, with only one or two project managers, maybe it means that nobody has any serious problems … at least, not now. Maybe there really are problems, but the project managers don’t know about them. Or maybe everything is actually on schedule, and all of the technical staff members, as well as the business users and key stakeholders, are perfectly happy. It may seem a little strange, but it’s not completely impossible.

In a large IT organization, it really is impossible. Well, maybe not completely impossible — but highly unlikely. Considering the industry statistics about how many IT projects are behind schedule, over budget, filled with bugs, and unable to meet user requirements, you would think there would be a long line of desperate IT managers lined up outside my office, hoping to receive either a miracle cure or a promise of forgiveness and absolution.

Also, why do you think I was brought here in the first place? Unlike “real” priests, I don’t operate as a non-profit charity, and I don’t rely on donations to pay the rent each month (nor do I live in a rent-free vicar’s mansion here in NYC). The decision to bring me in for this purpose is almost always made (and, more importantly, paid for) by a senior-level IT executive who knows that (a) lots of projects are in trouble, and (b) lots of project managers are frustrated, discouraged, and threatening to quit. That would make it even more likely that several people would be lined up outside my door (or sending me e-mail messages asking when they can meet with me).

But there’s actually something far more fundamental to consider: most project managers know when they’ve made a mistake, and when they’re in trouble. Maybe not the most junior managers, who are tackling their first project; and maybe not the most stubborn ones, who are determined to bull their way through any obstacle thrown in front of them. But most project managers are reasonably intelligent, and reasonably aware of what’s going on around them; and at least in the U.S. (though not necessarily in other countries), they operate in a culture where their subordinates will voice their opinions about how well (or poorly) the project is proceeding.

So an absence of people lining up to meet with the IT “confessor priest” usually means one thing: there is a strong atmosphere of fear and distrust in the organization, and none of the project managers are willing to take the risk that senior management will somehow find out they’ve reached out for help. In such an organization, there probably aren’t many people taking advantage of company-sponsored programs to help with problems of alcoholism, drug abuse, or marital problems. When it comes to project management problems, many IT organizations operate in a style not so different from the infamous “don’t ask, don’t tell” standard currently being debated in the U.S. military.

As indicated in a previous blog posting, the project confessional is supposed to be confidential. But if the “confessor priest” sits in an empty office at the end of the hall, far too many people can see the “sinner” project manager walking down that hall for a meeting. Meetings can be scheduled via e-mail, and can take place outside the office environment; but in some organizations, people are paranoid about their e-mail and text messages being intercepted. Whether real or not, the perception of such “Big Brother” oversight is enough to keep them away.

I don’t have any magical solutions for this kind of problem; all I can do is report to senior management that the level of fear and distrust is greater than they had imagined and/or acknowledged. A significant culture-change has to take place before the project-confessional concept can be put into practice, and that usually requires a different type of consulting engagement altogether.

Fortunately, this scenario is not very common. While I can’t promise absolute secrecy, it’s not too difficult to create enough privacy and confidentiality to satisfy most people. Meetings can be arranged via e-mail, but with the proviso that corporate e-mail be avoided. My cell phone number can be made available, and people can call me from someplace suitably private. And, in most organizations, people aren’t that terrified of making contact with me…

Indeed, think of it this way: if a project manager has made some mistakes, and if the project is in trouble, that fact is not likely to be a secret. Well, maybe it’s a secret today, because the project team and senior management have not yet become aware of the project manager’s blunder … but it’s only a matter of time. So, before things get completely out of control, and before the project manager has completely lost whatever options might be available to remedy the problem, he or she will often feel motivated to go find someone trustworthy they can talk to…

Of course, there’s always the possibility that the project manager’s mistake was really serious, or that it broke the law. We’ll discuss that in the next blog posting…

Stay tuned.

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.

Or maybe it was something else; maybe something you forgot to do, some budget report you forgot to submit, some paperwork to keep the bureaucrats and bean-counters from making your team even more miserable than they already are. Whatever it is, it’s going to cost your project some precious resources, or add to the bureaucratic burden, or somehow put the project at much greater risk of delay or outright failure.

That being the case, wouldn’t it be great if you could find a quiet confessional booth somewhere, and whisper to a kind old priest inside the booth, “Forgive me, father, for I have sinned…”?

The problem faced by many of today’s IT managers is that they know they’ve made a mistake — but (a) it’s not obvious to them how they can undo, work-around, or rectify that mistake, and (b) there’s nobody they can talk to. For whatever reason, they feel that they can’t talk to their subordinates (after all, they’re the boss!), and they can’t talk to their fellow-manager peers … and most of all, they dare not confess their mistake to their boss. Why not? Because their boss would have a hysterical fit, or fire the errant project-manager on the spot; and his/her peers would sharpen their knives, and begin figuring out how to take advantage of the mistake when it comes time to award promotions, raises, and bonuses.

I don’t want to suggest that it’s like this for all companies; there must be a friendly, supportive IT organization out there somewhere. And it’s not an “all-or-nothing” situation: if you’ve made a mistake but know how to fix it, you can sometimes enlist the cooperation of your subordinates (“we’re in this together, guys, and I’ll really owe you one if you help me out). Indeed, you might be able to make an apologetic confession to your boss, if the mistake isn’t too expensive to fix …

But there are an awful lot of situations where that won’t work… and this series of blog postings is about the formal creation of an “IT Project Confessional” to provide a neutral, objective, confidential, no-risk (well, probably low-risk) mechanism for project managers to seek advice and guidance so they can recover from their mistakes and ultimately succeed with their projects.

As you can imagine, things are a little more difficult in the “real world” of an IT organization than they are in the priest’s confessional booth: you can’t just tell the sinner, “Repent, say three ‘hail Mary’s,’ vow to never commit such a sin again, and you will be forgiven.” Here are some of the topics I’ll be covering in the days ahead:

• Finding sinners – how do you get people to admit they might need help?
• Protecting the confidentiality of project managers discussing their mistakes
• Ethics: what if the project manager has violated a law or government regulation?
• Types of advice – should you tell the sinner to quit, work harder, confess publicly, or something else?
• Categories of project management sins: venal sins and cardinal sins
• Resisting pressure from higher-level executives who say to the confessional priest, “Off the record, no names mentioned, tell me what’s going on…”
• Forgiveness — is it possible? Practical?
• Anticipating a sin – what to do if the project manager says, “I haven’t sinned yet, but I know I’m about to…”
• Measuring results
• Providing follow-up references and resources for ongoing help
• Setting up a “Sinners Anonymous” for project managers who want to network and share their experiences with other sinners

Stay tuned … and if you know any project-management sinners out there, tell them to take a look, and offer their own ideas, experiences, and opinions…