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…

1. The blatant sales pitch in most of the “keynote” presentations was pretty obnoxious, and a real turn-off. I’ll remember that for future conferences, and I’ll be sure to warn anyone I know to avoid them like the plague.
2. At least one or two product-related keynote presentations were okay, because (a) the products play an important role in the marketplace, and conference attendees did want to hear about them, and (b) they were presented without the blatant sales pitch. The best example of this was Microsoft’s presentation about Sharepoint 2010, by Christian Finn, which was titled “Seven Essential Truths About Enterprise 2.0″.
3. Several of the vendors and presenters gave interesting case-study examples of massive adoption of E2.0 tools and products in their organization. The afore-mentioned Microsoft was one: they’ve got 92,000 employees. And IBM was another: they’re rolling out their E2.0 products to a global workforce of 400,000 employees in 170 countries.
4. There are now lots of knowledgeable consultants in the E2.0 field, many of whom gave excellent presentations, and/or participated in various panel sessions, about real-world experiences helping their clients implement new tools/products, and dealing with the political and culture-change issues. On the exhibitor’s floor, I saw an Infosys booth, and I’m they had plenty of people ready to provide such assistance; but I didn’t see any booth staffed with people from Accenture, or PwC, or various other large consulting firms you might have expected to see.
5. Many of the small vendors who exhibited here last year are gone (or at least they’re gone from this conference). And I suspect that several of the small vendors I saw this year will be gone soon, too. This is not lost on the large customers: they obviously like the security and stability associated with large vendors like IBM/Lotus, Microsoft, Cisco, etc.
6. Most of the discussions and presentations seemed to concentrate on E2.0 products and services behind the firewall — e.g., how to use such products/services to enable better collaboration among employees, faster response to proposals, business opportunities, and/or problems. There was much less discussion about reaching outside the firewall to interact/collaborate more effectively with customers, suppliers, and business partners.
7. Microsoft had the most amusing give-away toy: a flying pig, which could be launched in a slingshot fashion, and which “oinked” as it flew through the air. I brought one of them home, and our dog has been looking at it suspiciously ever since he laid eyes on it.

As growing evidence of the popularity and acceptance of Enterprise 2.0, the conference organizers will be hosting another conference in Santa Clara, CA on Nov 8-11, 2010. You can get additional details here.

Let’s start by acknowledging that is not just one future lying ahead of us. There are many “potential” futures, some of which will come to fruition, and some of which will be ignored rejected. Your future may not be the same as my future; and of the millions of possible futures, many will overlap, and some will conflict. Indeed, some futures may nullify other futures, and some futures may look so appealing that they shift attention away from others that could be more beneficial in the long term.

None of us has the time, resources, or energy to identify and track all possible futures; all we can do is identify the ones we think are most likely to be of interest to ourselves, our family and friends, our employers and customers and business partners, and the society in which we live. We can nurture and plan for the futures that appear more appealing, and we can plan for, and perhaps mitigate, the ones that appear more problematic (e.g., the ones that involve pollution or severe climate change or global conflict).

Some potential futures are more visible than others; indeed, a few of them really are secret. Steve Jobs is not going to tell us what the next iPhone looks like; we’ll have to wait until he unveils it, or until some unlucky Apple employee leaves the next prototype behind in a bar. IBM and Oracle aren’t going to publish their product plans for the next 5 years in the Wall Street Journal. And Google isn’t going to reveal the details of the next generation of search-engine technology until they’re ready.

But even secretive companies like Apple have to file patent applications to protect the intellectual property they’re working on. And they have to publish “help wanted” ads to advertise job openings in the areas they’re planning to exploit in the near-term future. No doubt there are some government/military R&D groups who really, truly hide everything they do; but overall, the world is becoming more and more of an open book — if you go looking to see what’s out there.

Indeed, the irony is that the people with the most innovative ideas are desperate to tell as many people as possible. They do so in traditional ways, by publishing papers in scientific journals, and giving talks at industry conferences. They visit the big companies — the IBMs and Microsofts and Googles — looking for financial support, strategic partnerships, or outright acquisition of their ideas and whatever startup company they’ve created to develop and exploit those ideas. They visit venture capitalists, they talk to bloggers, the attend “meet-ups” in high-technology cities around the world, and they do their best to use Twitter and Facebook and other social media to help spread the news about their ideas, with the hope that it will go “viral” somehow.

Some of their ideas are in the form of university experiments; it may take several years (and several millions of dollars) to transform that research into an “operationalized” future that can change the world. But some of it is already in use — but just by a few dozen, or a few hundred, adventurous innovators and early adopters who don’t really care if anyone else is paying attention. Indeed, the who point of Geoffrey Moore’s classic book, Crossing the Chasm, was that a “chasm” exists between the small marketplace of early adopters and the massive (profitable!) marketplace of “mainstream” adopters — and that many startup companies fall into that chasm (and ultimately go bankrupt) because they don’t know how to get across to the other side.

If you’re a venture capitalist with a large bankroll for funding new projects, or if you’re the VP of Business Development at Google, IBM, Apple, Microsoft, or other such high-tech companies, then the future will come knocking on your door — in the form of bright, passionate inventors who are determined that their new ideas will change the world, if only you’ll give them some money and a quiet place to work.

But if you’re anyone else, then you’ll probably have to go looking for the future … or, more accurately, lots of possible futures. I first saw this in action back in the 1980s, when I traveled to Singapore and was invited to meet some of the people at a government-funded IT research organization. I was told that the organization had a group known as the “horizon scanning” department — whose job was to actively seek out new ideas and new technologies that were “on the horizon,” or perhaps just a little bit over the horizon … because the people involved those futures might not have the time, energy, resources, or interest to get on a plane and travel to Singapore to present their ideas. (Remember: this was in the prehistoric era before Google, before the World-Wide web, and even before open, global email. We did have fire, electricity, and running water, but not much else…)

With today’s technology, almost anyone can be a “horizon scanner,” but it’s easy to get distracted and waste a lot of time and resources going off on a dozen wild goose chases. An excellent blog posting, Horizon Scanning, provides some of the details of “systematically exploring the external environment to (1) better understand the nature and pace of change in that environment, and (2) identify potential opportunities, challenges, and likely future developments relevant to your organization.” The blog goes on to recommend a combination of “out of the box thinking; exposure to many sources, ideas, and challenges; looking beyond existing “comfort zones”; and noting opportunities and risks in an ordered fashion.

Horizon scanning can be done in several timeframes: on an ad hoc basis (e.g., in response to an unexpected crisis), on a regular schedule (e.g., one a year), or on a continuous basis. Interestingly, the group I met in Singapore emphasized the “continuous” nature of their horizon-scanning.

Even the best-organized horizon-scanning process is unlikely to identify a single future in any particular area (e.g., future computer technology); nor will it be able to forecast a future trend with absolute precision or absolute certainty. Inevitably, this means that business leaders and government leaders will find themselves having to make decisions about the future (e.g., whether or not to invest in a specific technology that may or may not be available in four, five, or six years), based on incomplete, imperfect information.

Of course, you could argue that that’s what leaders do. In a free-market, capitalistic society, the ones who do it well are paid the big bucks; and the ones who do it poorly fail, and go out of business. Those who fail to make any decision at all, because of the risk and uncertainty, eventually find that the future has become a fait accompli that forces them to change or fall by the wayside.

But at least in some areas, an alternative model is emerging — based on the “wisdom of the crowd.” Basically, this involves taking into account the collective opinion of a group of individuals, rather than a single expert (or leader), to assess the likelihood of a particular outcome. This is a whole subject unto itself, and rather than blabber about it endlessly in this blog, I recommend that you take a look at the Wikipedia summary of the concept, and follow that up with a review of James Surowiecki’s book, The Wisdom of Crowds. I also suggest that you take a look at a concept known as “prediction markets,” which provide a mechanism for a “crowd” to express, update, and revise its assessment of the likelihood of various outcomes occurring. One company that provides a very interesting service in this area is Inkling Markets; I have no business relationship at all with the company, but I’m intrigued with what they’re doing, and suggest that you take a look at their service.

One last recommendation, based on some of the other trends that we’ve discussed in this thread of blog postings: make sure that your “crowd” and your horizon-scanning process includes plenty of people from the younger generation (e.g., high-school and college students who have not yet entered the work force), and make sure it includes plenty of people from developing nations and poor countries — i.e., people who probably don’t have advanced computer technology today, but who almost certainly will within the next 5-10 years.

Aside from that, you’re on your own. As American E.B. White once said, “I wake up each morning determined to change the World … and also to have one hell of a good time. Sometimes that makes planning the day a little difficult.”

***********

A postfigurative culture is one in which things don’t really change much, from one generation to another. Thus, aside from the rebellious behavior associated with adolescence, each generation expects to learn the “basics” of life from its parents and grandparents. Such cultures learn by looking back, to see how things were done in the past; and this worked reasonably well for most of mankind’s recorded history.

A cofigurative society is one in which things are changing rapidly enough that parents and children are forced to learn things more-or-less simultaneously. Immigrant families face this quite often, and it’s commonplace for the children of such families to adapt to new languages, new laws, and new social customs more quickly and more easily than their parents. Aside from immigration and chaotic disasters, Dr. Mead suggested that somewhere around World War II, the rapid pace of technology began to create an overall cofigurative society — at least in the advanced countries that were inventing, developing, and assimilating those new technologies.

Though there is still some debate among sociologists, many of us would agree that we are now venturing into a prefigurative society — where things are changing so quickly that it’s almost guaranteed that children will learn about new things before their parents do. Part of this is because learning something new often requires us to unlearn something old; and the generation of adults has a lot more “baggage” to get rid of, before they can accept and assimilate something new. Children, on the other hand, have little or nothing vested in old fashions, old styles, old customs, and old ways of doing things that were based on technologies that are being rendered obsolete.

Every adult has his or her own stories to tell about this phenomenon. When I was a kid, for example, I was told that I would not be allowed to drive a car until I could change a spark plug, replace a fan-belt, and fix a flat tire on the family car; and both at home and at school, I was told that I had to learn how to drive a manual, “stick-shift” car. All of the time and energy that went into that part of my basic “education” was essentially wasted: I haven’t had a flat tire in over 20 years, and I have no idea if my car even has a spark plug. (In fact, I don’t even own a car any more, but that’s a different story.) Today’s kids learn how to drive automatic-transmission cars, and I doubt that most of them could even find the spare tire in their trunk. When my older son bought his first car, he was dumbfounded when I suggested that he could save a few bucks by getting a simpler model with an old-fashioned “manual” crank to open and close the windows; for his entire life, every car he had ever been in had an automatic “button” that, when pressed, caused the windows to move up or down.

So, what does this mean in terms of the future of IT? Well, it means that if we’re in the business of inventing/creating new IT-based products or services, or if we are in a (management) position that attempts to control or restrict access to those technologies, we’d better not assume that they’ll react and respond the same way we do. Fortunately, there are lots of market-research firms, academic institutions, and industry-analysts out there polling the public about their attitudes, behavior, expectations, likes and dislikes — and then slicing and dicing the results into different age groups, income categories, and other demographic distinctions.

So we need to devote some time and energy — on an ongoing basis — to reading these polls, and talking directly to the more articulate members of the younger generation, and then think carefully about what this means, in terms of the assumptions we’ve made about new technology. We read, for example, that today’s generation not only does not memorize the phone numbers of their twenty or thirty closest friends (as my peers and I did, once upon a time), but a significant percentage of them don’t even know their own phone number. Why should they? It’s all programmed into their mobile phones, complete with the textual name associated with each number, and a photo of the individual associated with that number. What are the implications of this behavior? Aside from the annoying reality that when people lose their cellphones today, they have no idea how to reach any of their peers, it probably does have some deeper meaning … but I haven’t figured it out.

Similarly, we read that most young people today don’t wear a wrist-watch — because their mobile phone displays the current time. And perhaps that explains why 91% of mobile phone users today keep their phone within a one-meter distance of themselves, 24 hours a day, 7 days a week (see Mary Meeker’s presentation at the 2007 Web 2.0 Summit conference for this statistic.) And since it’s only a (short) matter of time before virtually every mobile phone has a built-in GPS device, we’ll always know where everyone is — even if they don’t know exactly where they are. We may think we know what this means, from our perspective, in terms of potential new products, new services, new laws and regulations about privacy and security and control … but what does it mean to the younger generation that’s most likely to have these devices in their pockets?

On a deeper level, all of this will have a profound impact on the way future generations interact with their peers, their parents, their employers, and the “authority figures” in their lives. We’re already beginning to get a sense of this with the attitudes of today’s “digital natives” — i.e., the generation that was born during the period that PC’s were beginning to be introduced, and which has thus grown up in a world that always (from their perspective) had computers. As Gary Hamel explained in a thought-provoking March 2009 Wall Street Journal blog entitled “The Facebook Generation vs. the Fortune 500,” we can already see a number of younger-generation attitudes that are very much in conflict with the “traditional” attitudes that we find in large business organizations:

• All ideas compete on an equal footing – (every idea has the chance to gain a following; ideas gain traction based on their perceived merits, rather than political power of their sponsors)
• Contribution counts for more than credentials — (when you post a video on YouTube, nobody asks if you went to film school)
• Hierarchies are natural, not prescribed — (some individuals command more respect and attention than others; authority trickles up, not down)
• Leaders serve, rather than preside — (no one has the power to command or sanction)
• Groups are self-defining and -organizing – (no one can assign you a boring task, no one can force you to work with dim-witted colleagues)
• Resources get attracted, not allocated — (the Web is a market economy; people decide, moment by moment, how to spend the precious currency of their time and attention
• Power comes from sharing information, not hoarding it — (to gain influence and status, you have to give away your expertise and content)
• Opinions compound and decisions are peer-reviewed — (truly smart ideas rapidly gain a following no matter how disruptive they may be)
• Users can veto most policy decisions — (the only way to keep users loyal is to give them a substantial say in key decisions
• Intrinsic rewards matter most — (money is great, but so is recognition and joy of accomplishment)
• Hackers are heroes — (online communities frequently embrace those with strong anti-authoritarian views)

Undoubtedly, there are a lot of business executives and parents and “authority figures” (politicians, religious leaders, pundits, and op-ed columnists) who will respond to the list above by saying, “Well, that’s not how we do things around here — and we never will!”

If you hear this from the authority figures in North Korea or Iran or a few other such places in the world, they may be right. But to a greater and greater degree in the rest of the world, it’s an outmoded way of thinking. For better or worse, technology has empowered the younger generation — and they will not only vote with the ballot box (or electronic voting machine), but also with their pocketbook and with their feet. They’ll walk away from their job in stuffy, conservative, technology-fearing company X, and they’ll get a new job (even if pays less) in open, friendly, collaborative company Y.

Thus, the ultimate question for us to ponder when we think about the future of technology is not “What will it be?” but rather “How will the kids react to it?”

For example, we know that “social media” — Twitter, Facebook, LinkedIn, and several other examples — are becoming ever more popular, and also ever more important as an “influence” in society. As of January 2010, for example, Twitter had 75 million users (see “Twitter now has 75M users; most asleep at the mouse“, in the Jan 26, 2010 issue of Computerworld); and while Computerworld felt it was important to emphasize that “a lot of current Twitterers are inactive,” it’s also true that those who do Twitter have a disproportionate influence. It’s not just Oprah and Ashton Kutcher, with their multi-million Twitter armies, but the fact that that protesters and dissidents and ordinary citizens are using Twitter to communicate news more quickly and more effectively than the traditional media.

Cynics might well argue that 75 million is actually a very small fraction — just over 1% — of the global population. But Facebook has a user base that is estimated to be approaching 500 million. True, that’s still less than 10% of the global population; but as of April 2009, it was the fifth largest “country” in the world with a mere 200 million users (see “200 Million Strong,” in an April 8, 2009 posting on Facebook CEO Mark Zuckerberg’s blog)… which means that, by now, it’s the third largest country in the world, with only China and India ahead of it.

Of course, Facebook (and MySpace, and the various others like it) is only a “virtual” country; it doesn’t have an army, it doesn’t have a Parliament, and it doesn’t have a seat at the United Nations. But maybe it should … and maybe it will. Probably not in the next 5-10 years, but it does suggest that we should start paing more attention to the blurring of “real life” and “virtual life.” Thus far, most of our attention has focused on the “virtual life” of individuals (see, for example, the excellent book, Life on the Screen, by Sherry Turkle), or relatively small “virtual communities” of individuals, in places like SecondLife.

We’ll know that things have changed irrevocably when Facebook (or MySpace or Twitter, or whatever) achieves some significant political accomplishment, such as getting a major politican elected or thrown out of office. Note that that’s completely different than the “top-down” efforts by politicians (e.g., Barack Obama) to use social media to help promote their own campaigns.

The social/political impact of future IT will, of course, become all the more important as computing becomes more ubiquitous. You’ll recall that I discussed this in part 5 of this thread of blogs (you’ve memorized all this stuff, right?), and suggested that in another 5-10 years, we might well find that a majority of the human race will have non-trivial computing devices, even if it takes the form of a mobile phone. So, if Facebook (and/or its cousins) grows from 500 million users to 5 billion users, there are bound to be some significant social/cultural consequences — the details of which I’m incapable of predicting with any specificity.

One thing is fairly obvious, though: if we’ve got 5 billion people using computers, the majority of them will be located in what we casually refer to as “third world” countries … or, more politely, “developing countries.” That means the applications that dominate the worldwide computing environment probably won’t be the ones that currently dominate the marketplace in advanced/developed countries. They might be “simple” applications that we have relegated to a back corner, like e-mail or texting; or they might be games that we’ve never seen before. Or they might be something else entirely … in any case, what creates this dominance will be culture, not technology.

One last observation, which I’ll just summarize — even though it probably deserves several blog postings on its own: the relationship between government and members of society will change, and the boundary between government and citizens will blur. I can make some educated guesses about the general nature of this change, but the details of how and when … I simply don’t know.

As for the “relationship”: recall that in part 12 of this thread, we discussed the phenomenon of resistance to change. Specifically, to the extent that new technology threatens to disrupt established political (power) structures, and/or social and religious cultures, it will almost certainly threaten to disrupt established laws, regulations, and other forms of codified behavior.

Of course, most societies have organized methods for changing their existing laws and regulations, but (a) it takes a long time, and (b) it tends to operate from the top down. Yeah, yeah, the people at the grass roots can elect new representatives, Presidents, and Prime Ministers; but unless you live in a society that operates with a “direct” town-hall-style consensus, the reality is that the day-to-day establishment of laws and codes and regulations comes from the folks at the top. And (a) they’re likely to be the same ones who were at the top five years ago, and (b) they’re likely to be 50 or 60 years old, if not older, and (c) they still haven’t figured out e-mail.

But all of that could change if you get a “Facebook army” that’s determined to make some changes. We got a minor taste of this when Twitter got used by the protesters in Iran after their controversial election last year … and I think that was just the beginning.

The other aspect of government is this: in the best of all worlds (without getting into the usual debates between liberals and conservatives), we expect government to do the things that we (individuals) cannot do for ourselves. I don’t expect a “Facebook army” to acquire guns or tanks or planes, and thus replace the government’s army and air force; and I don’t expect the “Facebook army” to start building the next generation of roads and bridges and tunnels.

But they might take on some of the responsibilities for repairing the roads and bridges and tunnels. Well, maybe even that is too much, since they’re unlikely to have the heavy equipment. But to the extent that any of this (even national defense) depends upon effective communication and collaboration — that much can be done by a Facebook army. What it means is that a lot of governmental organizations — bureaucratic committees and agencies and authorities — might find that their services were no longer needed.

Is this likely to happen in the next 5-10 years? Obviously, not completely … and maybe not at all. But it could happen little by little, without make a lot of noise, and thus without creating a lot of resistance. Want an example? Take a look at Clever Commute, and subscribe to the Clever Commute blog — I think it’s an exemplar of things to come.

As we discussed in one of the earlier postings in this blog thread, there is a significant difference between “incremental” change, and “order-of-magnitude” change. Indeed, from a social perspective, “order-of-magnitude” changes might better be termed “disruptive changes” — for they turn things upside down, render established ways of doing things obsolete and irrelevant, and threaten established scientific, governmental, religious, social, and cultural norms.

As the late Thomas Kuhn observed in his classic book, The Structure of Scientific Revolutions, this has been true for centuries, if not longer. Nicolaus Copernicus, for example, had the audacity to propose that Ptolemy’s view of an earth-centered solar system was incorrect, and that the earth actually revolved around the sun. It took the Catholic Church three years (after the publication of his book, On the Revolutions of the Celestial Spheres, in 1543) to even take notice of this radical theory, and sixty years to take action against it. But in 1616, the church issued a decree suspending the book, placing it on the Index of Prohibited Books. As if that wasn’t enough, Galileo Galilei was convicted in 1633 of heresy for “following the position of Copernicus, which is contrary to the true sense and authority of the Holy Scripture,” and placed under house arrest for the rest of his life.

We probably don’t have to worry about being excommunicated today for proposing new scientific theories, or possible applications of new technology — though it’s not always easy to distinguish that kind of knee-jerk reaction from the kind of Internet-related censorship that we see in countries like China, Iran, and Pakistan. Putting religion aside for now, it’s still worth noting that various computer-related technologies have been attacked, prohibited, regulated, belittled, and criticized over the past few decades. In the Web 2.0 world, for example, we’ve seen problems like these:

• resistance to user-generated content — e.g., blogs
• strong resistance to the idea of letting employees blog about their work, in the office
• rejection of web-based products (e.g., Google Apps) as “too lightweight”
• rejection of Facebook applications by various pundits as being “trivial” or “frivolous”
• rejection of “cloud” computing

While it took the Catholic Church decades to decide that Copernicus’ theories were heretical, and then centuries to remove that criticism (Pope Paul VI abolished the “List of Prohibited Books” in 1966), most individuals and organizations react and respond to new ideas and new technologies a bit more quickly … but not instantaneously!

Indeed, one of the most important things for champions, evangelists, and advocates of new technology must be aware of is the so-called “technology adoption cycle,” popularized by Geoffrey Moore in a book from the early 1990s, Crossing the Chasm. Based on earlier work by Everett Rogers on the diffusion of technology, Moore proposed five “categories” of technology adapters:

• innovators – the “pioneers” who want to obtain a strategic advantage by being the first in their neighborhood, their town, or their industry, to use the new technology
• early adopters — typically representing about 15% of the overall market, these are the people who see an opportunity for making a big improvement in some way that matters greatly to them — e.g., more revenues, bigger market share, higher profits, etc.
• early majority — these are the more conservative potential customer/users in the marketplace who are interested in improvements and benefits, but who typically want to wait until they see “case studies” of other people (i.e., the early adopters!) who have successfully used the technology
• late majority — even more conservative people, these are the ones that are typically driven by a desire for cost avoidance and/or cost displacement. They’re not so interested in (or willing to believe in) a 10% increase in revenues as they are interested in the possibility of a 10% reduction in costs.
• laggards — these are the people who will defer, avoid, and delay using the new technology until they have no alternative — e.g., their existing technology breaks down and cannot be repaired or replaced. It’s common to characterize the people in this group as “Luddites,” and indeed many of them are. But you’ll also find a lot of people from government agencies and non-profit organizations, whose budget restrictions are the main reason for waiting until the last possible moment to replace their old technology with something newer.

It’s easy to criticize the people who occupy both extremes on this chart, but that’s not the point I want to emphasize. The main thing I want to emphasize is that a finite period of time elapses between the first sign of a new technology (i.e., the extreme left side of the chart above) and the point where everyone is using the technology (i.e., the extreme right side). If you’re involved with new technology — either as a developer, evangelist, or potential user — you need to be aware of that.

My friend Capers Jones likes to remind me that it took the military 75 years to go from the technology of muskets to the technology of rifles; obviously things move somewhat faster with computer technology. Still, it was common to see a period of 15-20 years elapse between the innovators and the laggards for technologies like relational database, or client-server, etc. If you want something a little more specific and a little more recent, take a look at this May 2008 article, “20% of U.S. Has Never Sent E-mail.”

Some people hear a statistic like this and say, “Yeah, that’s my grandmother you’re talking about — and all the other grandparents in the country.” Aside from the fact that such a characterization is more and more untrue these days (see, for example, this 2009 blog, “Rise of the Silver Surfer – Germany Already Has More Internet Users 60+ Than Teens“), it speaks to the generational aspect of technology adoption. We’ll talk more about that in a future blog, if my fingers don’t fall off from doing too much typing today

The more important point to keep in mind these days is that technology adoption is occurring faster today. As an October 2009 blog, “Speed of Technology Adoption,” points out, it took roughly 50 years for electricity to permeate 90% of the market; it took 30 years for the refrigerator, and 20 years for the cellphone. I suspect it will be even faster for iPods, iPhones, iPads, and the i-thingies of the future.

Finally, one last piece of advice: you need to know what part of the technology adoption cycle you’re most comfortable with. Ideally, you (as an individual) and your employer, and your employer’s current and prospective customers are all at the same place in the cycle. It doesn’t matter (at least, not to me) whether you’re an innovator or a laggard or somewhere in between. The point is that if that’s how you (and your employer and your customers) reacted to the last technology innovation, that’s probably how you’re going to respond to the next one.