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…

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…

But as an intellectual exercise, suppose for a moment that that was not true; suppose that we were doomed to continue using today’s hardware technology for the next 10 years. Would things get any better?

Those of us who have been working in the software industry for the past 40-50 years are likely to have a pessimistic reaction to such a scenario. “We’ve been writing lousy code, full of bugs, for the past 50 years — and we’ll probably continue to do so for the next 50 years. And we’ve been consistently over-budget and behind-schedule on our software development projects for the past 50 years — so why should we expect things to get any better in the next 50 years?”

Indeed, there is some cause for pessimism here, but there is also an optimistic response: “We have gotten better at project management, and we do write better software than we did 50 years ago. But as hardware technology has improved so astoundingly over the past several decades, business organizations and society, in general, have demanded that we solve bigger and more complex problems. And we have taken on bigger and more complex problems, until we reach the point that our efforts are just barely ‘good enough.’”

We could debate these pessimistic and optimistic perspectives for quite a long time, but for now we’ll put them aside. Back to the simple, straightforward question: what if we could only expect improvements in the computer industry from the “stuff” we do in software?

One thing is fairly obvious: it would take us another 5-10 years just to use the hardware we’ve already got! There are exceptions, of course, some of which we’ve hinted at in some of the previous postings in this blog thread. But particularly in the area of personal/home computers, and also in the area of small-business computers, we are using only a small fraction of the available computing resources. We could probably continue for another 5-10 years, writing the kind of “brute-force” software that lazy programmers have been able to write for the past decade or two; and at some point, we might have to start optimizing our code, and we might have to schedule the use of, and access to, our hardware resources. It would be extremely unpleasant to go back to the days of “batch scheduling” of computer jobs; and it would be unpleasant if we had to abandon the idea of dedicated, personal computing devices, and return to the days when lots of people had to share scarce hardware resources … but it could be done.

Again, let’s put that scenario aside for now. Let’s take a more positive, optimistic perspective: what kind of new, “good” things might we expect from the software industry? There’s one interesting perspective that we’ve been hearing from people for the past year or so: look how many apps are available on the iPhone! First it was 100,000 — which was pretty amazing — and then it was 150,000 and now it seems to be 200,000. Interestingly, I recall reading about numbers like this back in the late 1990s, when the Palm Pilot was all the rage. In a long-forgotten article in the Wall Street Journal (which I’m too lazy to track down on Google), I remember reading that Palm had cultivated a “cottage industry” of 40,000 developers who created tens of thousands of Palm apps, which they sold for a few dollars each. Of course, Palm didn’t have iTunes — and the mechanism for finding, purchasing, downloading, and installing the apps was time-consuming and tedious.

So now that we do have iTunes, does this mean we should expect a Moore’s-Law phenomenon with mobile apps? Will today’s figure of 200,000 apps escalate up to 2 million apps by 2015, and 20 million apps by 2020? Even if that were true (the likelihood of which I’ll discuss in a moment), it doesn’t necessarily mean that society will be fundamentally improved — if we had access to 2 million iPhone apps in 2015, it doesn’t necessarily follow that they would all be “killer apps.” In fact, only a small percentage of them would show up on everyone’s iPhone — but the rest could still serve a useful purpose, in the form of a “long tail” of “niche” apps that are only useful to a few people.

Indeed, the long-tail phenomenon is already quite visible in places like Amazon and the iTunes music store. In the old days, when music was sold on vinyl records, and books were only available on dead trees, retail outlets (e.g., book-stores and record stores) only had room for a limited inventory, and were thus constrained to stock and sell only their most popular items. But now, iTunes carries an inventory of approximately 5 million songs; and in any given fiscal quarter, almost every one of those 5 million songs sells at least one copy. And if it turns out that almost all of those songs sell only one copy, who cares? They’re all just bits on a disk drive, and it doesn’t really matter when you transmit one copy or a million copies to the customers who want them.

So maybe the software-driven future of technology is one in which we benefit from a long-tail phenomenon of millions of individual apps on the various hardware devices we have in our pockets, our purses, our homes, and our offices. But if that is the future, we need to ask: who will actually write all of those apps? People who already consider themselves programmers? Depending on whose estimate you believe, there may be a few million such individuals world-wide today, and if they spent their evenings and weekends working on clever apps (assuming that each of them had a clever idea), maybe that would get us from the current level of 200,000 iPhone apps to a couple million. Beyond that, I have my doubts…

Indeed, if we think that the most interesting version of the future consists of dramatically more application programs, we need to imagine a world in which people other than “professional” programmers could create them. Computer programming is no longer considered “rocket science,” so we don’t have to restrict our attention to people with university computer-science degrees; indeed, they don’t have to have any university degree. Even if we imagined that new apps required basic literacy and the educational equivalent of a high-school diploma, that would still be a very, very large number of people … indeed, perhaps enough to get us to the level of 20 million apps a decade from now.

To illustrate that this is not as crazy as it might sound, consider that until the mid-1970s, almost any kind of non-trivial computation for business, scientific, or engineering purposes required a programmer, who would hand-craft a program in FORTRAN to produce the required computational results. Today, we refer to such a program as a “spreadsheet,” and we refer to the “programmer” who creates it as a “person.” I don’t know how many copies of Excel have been sold by Microsoft, but I’m willing to be that it’s far more than 20 million; and there are many more than 20 million spreadsheets providing useful results.

So perhaps what we’re saying is that software-related technological advances will come from the introduction of a “tool” as simple and powerful as a spreadsheet, with which ordinary people can create whatever app they might imagine for their mobile computing device (or, for that matter, any computing device). Maybe it will be a “mashup” tool, developed along the lines of Yahoo Pipes, or the tools available from Microsoft and IBM and others. Maybe it will be some kind of widget, template, or other mechanism.

I don’t know if this is how the future will turn out, and I can think of one reason why there might be no relationship at all between the world of spreadsheet-developers, and the world of mobile-phone app developers. Consider this: spreadsheets are generally created in order to solve a “real” problem — e.g., because someone wants to add rows and columns of numbers in order to make a business decision. I’m sure there are exceptions, but most of us would not consider a spreadsheet to be “entertainment,” or “fun,” or some kind of “game.”

But if you look at the items in the iTunes App Store, the vast majority are games, fun, or somehow related to entertainment. There are, again, lots of exceptions (I’ve got only one game, Klondike, on my iPhone), and there are lots of apps that provide serious, productive solutions to some kind of problem. But you can’t get away from the fact that most of the apps are for amusement.

Not only that, they’re not for the amusement of the person who created the app. Instead, the app-developer is hoping to persuade others to play his game, and join in the entertainment. If millions of people are thus entertained, and if they’re willing to spend $0.99 to download and play the game, then the developer gets rich. Conversely, if nobody likes the game, or nobody even notices its existence, then the developer makes no money — and is likely to conclude that he wasted his time…

As for the “productive” apps that one finds on a mobile device, a large percentage are simply scaled-down versions of the same app that one already has on a laptop or desktop computer. In any case, though, here are the categories of apps that I think we’ll see a lot more of in the next several years, some of which may well turn out to be as much of a killer app as spreadsheets and Google:

• collaborative apps — it may be the next generation of Facebook, Twitter, and other “social media” apps, or perhaps something like the newly-released Google Wave
• virtual-world apps — most current versions of computer games could be thought of as a “virtual world” in which player(s) battle enemies, search for treasures, etc. But I think these will become far more sophisticated and intricate (e.g., like Second Life, with social rules and currencies), long-lasting, and multi-player in nature. If it can be embedded into your mobile device, with the ability to call, text, or email to you (and from you), it’s easy to imagine that some players could essentially abandon the “real world” altogether.
• more “location-aware” apps — indeed, the collaborative apps, and virtual-world apps, become all the more powerful if they know where they (and their associated human “owner”) are located, as well as knowing where other relevant participants/players are located. Looking at my iPhone, I see that roughly 25% of my apps are not only location-aware, but are able to use that information constructively. I think we’ve only begun to explore this area, because it’s only been the last couple of years that our mobile computing devices have had GPS mechanisms attached. The question to ask here, I think, is not what the “killer app” will be in the location-aware space, but rather who is likely to invent it…
• assistant/agent apps — aside from alarm clocks and simple “filters” that tell us if a designated keyword has been spotted in a newsfeed, most of today’s apps are fairly passive. We have to tell them that we want a task carried out, and we typically have to provide a great deal of specific data in order for the task to be performed. Tomorrow’s apps will gradually accumulate more and more “knowledge” about the humans they’re “connected” to, in terms of likes and dislikes, habits, areas of competence and expertise, short-term vs. long-term goals, willingness to make tradeoffs and compromises, etc. As a result, tomorrow’s apps will be able to take a more active role, offering advice, guidance, companionship, and warnings. Again, I have no idea what the specific “killer app” will be in this area; but it’s the generation of today’s children and teenagers that I think we should be watching for inspiration.

I’m here in Rome this week, presenting a two-day seminar on  “Managing Death-March Projects” for Technology Transfer Institute. You should be there so you can hear whatever clever jokes may occur to me while I’m presenting my material, as well as the comments and questions from the other participants. But if you’re stuck in some other part of the world, or you couldn’t persuade your boss to send you to Rome, you can click here to download the (17MB) PDF version of the presentation, which has a whole  bunch of embedded links to other presentations, publications, books, articles, websites, etc.

 But after a week of watching a gut-wrenching roller-coaster ride on the New York stock market, and reading various gloom-and-doom predictions of bad economic times ahead, I thought it would be more appropriate to replace that talk with a presentation on “Death-March 3: Software Processes in the New Hard Times”:

If you click on either icon, you’ll download a 12.2-megabyte PDF file that actually contains both presentations. So you can look at either one of them, depending on whether you’re feeling optimistic or pessimistic. Enjoy … or don’t.