KnowledgeForward

I’m working on my Enterprise Virtual Worlds presentation and was filling in some detail on communication in game-oriented virtual worlds that I would like to share here as well. 

Enterprises are wise to look to gaming from time to time due to trends in:

• Outside-in technology: how consumer technologies such as blogs and wikis increasingly find their way into enterprises
• Emergent gameplay: the use of gaming technology in ways the original designer hadn’t intended
• User experience lessons: UE improvements tend to filter from the competitive gaming market to generalized applications.  Gaming is an optional activity, so UE has to be at a high level when you want the users to pay you to use their systems rather than the other way around.

Communication is interesting to explore since the number of communication channels that enterprises use (and every information worker must now attend to) has increased a great deal over the past five years to include instant messaging, presence, websites, and blogs.  Getting enterprises used to the idea of “channels” and how to manage and select between them has taken some time and some pain.

I was quite impressed when all the methods of communication in World of Warcraft (which was released in November of 2003) are laid out. WoW communication is strikingly similar (and maybe more efficient) than enterprise communication technology in many areas.

It includes:

• Channels: Players can subscribe to communication channels such as /trade to receive ongoing chat on the channel, or unsubscribe.  Another example is in EVE Online, which has a “newbie” channel that can put new players in touch with others taking their first steps, but can be turned off once the player is more confident.
• Chat modes (IM): The variety of built-in IM modes goes beyond most enterprise IM implementations which rely on groups.  They are: /say (vacinity), /party (your group only), /guild (your broader community), /yell (all in larger region), /whisper (one person)
• Presence: Friends can be selected and you are made aware when they come online/offline, and location is displayed (a feature still on the cutting edge in the enterprise)
• Mail: Consists of normal mail, packages, and COD packages. The inbox is visited at WoW Postal Service facilities, which has the pleasant effect of isolating the player trying to accomplish objectives from the stream of email since they only check it periodically when they visit town.  Also, since email costs money to send (a few copper pieces), there is practically no spam
• Emotes: There are over 100 emotes such as /wave, /thank, /cheer, /dance, etc. It is amazing how fluid the use of emotes gets in the real game, such that they do not feel like a conscious effort to be funny, but rather a natural way of expressing oneself in group situations. 

Well, it’s that time of the year when the top 10 lists take over the front pages.  Those of you who read this blog regularly (yes, both of you) know that I tend to focus on communication, collaboration, and content technology and, sure enough, I’ll be bringing this all around to that at the end. 

A quick scan shows that Time magazine published 50 (fifty!) top 10 lists here: 50 Top 10 Lists of 2007.  Hmmm - that’s just a categorized top 500 list, isn’t it?  I don’t have time to get through that much - let me know if they publish a “top 10 ’top 10 lists’ ” and I’ll take a look.  Wired’s homepage today has The Top 10 Heartbreaking Gadgets of 2007, The 10 Best Gadget Ads of 2007, and Top 10 Scientific Breakthroughs of 2007. Perhaps the best of all is The Onion’s What the Hell Just Happened?

I think there are two kinds of readers who enjoy these lists.  The first is people that follow the subject in question and want to see how the author’s list (supposedly some kind of expert) jibes with theirs to validate their views, give them something to gripe about, or point out a few things they may have missed.  Movie buffs love to see the “top 10 films of the year” list to see if they should brag to their friends about their good taste or slam the critic as obviously out of touch.

I want to focus on the second kind of reader doesn’t follow this subject and likes the top 10 lists because it provides a year’s worth of news in a handy capsule.  For these readers the top 10 list acts as a filter to all the noise that occurs during the year.  If you are stuck in with kids all day and don’t get out to the movies, the list is a handy way to fill up your Netflix queue for next year (after a 6 month lag or so for the DVD to come out). 

Now, wouldn’t it be handy if, rather than once a year, that filter was always in place?  I could subscribe to this filter and instruct it to alert me only when a top-10-worthy film, or classical CD, or news story comes out?  And to remove the noise by not bothering me with the lesser films, CDs, or news in the meantime?  It’s hard to guess what will exactly equal 10 by the end of the year, but I’d accept say 15-25 items and a dial to increase or decrease the sensitivity if I’m getting too many/few each year.

I’m bringing this up because I see the “top 10 list” phenomenon as a good analogy to what a slew of technologies at the intersection of portals, RSS, and social software are trying to do: filter out all the noise and just bring me the important information, encapsulated, all in one handy spot.  It is a commonly recognizable form of attention management.

The process for assembling this is the same whether it’s Time coming up with a top 10 list, a blogger filtering news to find just the important stuff worth posting about, or the rules engine for an enterprise attention management system that is trying to find important events and pull them forward into the user’s focus.  The process consists of:

Integration: Connecting up with all the event streams, information sources, and data

Categorization: Determining what subject the event falls into

Rating: Prioritizing this bit of news.  This is probably the toughest part of the process at the moment, but attempts have been made in the form of social ratings engines (Digg) and attention profiling (APML).

Personalization: Lining up the category against the set of subjects that you are personally interested in, either through explicit declaration or implicitly. 

Display: A UI that presents the user with capsules on each of the items and allows the user to notice, track, and manage the information

This process is even more important in the enterprise, where the stakes are higher than missing a good opera CD.  How do you create your own “competitive news critic”, “financial event critic”, or “sales critic” to pick the most important information for you and how do they encapsulate this information and display it for you?  It could be the head of each of these departments flagging important news and alerting others to it (hopefully not just through email).  It could be through social ratings of important events.  It could be through automated alerting mechanisms that work off of triggers or rules.  No matter how it’s done, having an enterprise Roger Ebert to pick the best (and worst) as it happens and a good display channel (like Roger Ebert’s newspaper column) to present the information is as useful in a noisy enterprise environment as it is in a noisy entertainment environment. 

With everyone focusing on top 10 lists, I’m hoping this “angle” helps an evangelist for RSS, portals, social software, or attention management to make their case in a way that will resonate with business partners and executives during the New Year’s season. 

Happy New Year!

Yesterday I posted about the importance of recognizing how a lot of the communication, collaboration, and content technology that is implicitly seen as an application is really infrastructure (Everything’s Now Infrastructure! Where’s My App?).  Like a wolf in sheep’s clothing, it is infrastructure in application clothing - which can be just as dangerous.

The implications of the special nature of application infrastructure (as opposed to pure infrastructure or pure applications) became even more clear when a client asked about doing a risk assessment on Microsoft Office.  Remember that Office is more than Word, PowerPoint, and Excel.  It also includes InfoPath, Access, SharePoint, and many other products.  There’s a lot more variability to what end-user facing collaboration and content creation/management tools can be used for than there is for back end infrastructure such as a router.  Or even pure applications like an accounting system where the application is known.  There’s a level of indirection introduced by application infrastructure in that you first have to determine what the user will create with it, then the risk of that.  Think of the enormous span of artifacts that can be created by these systems:

• End user databases and end user db applications with Microsoft Access
• Portals and all kinds of extranet and Internet websites
• All types documents that may contain sensitive data or macros
• Workflow that can kick off automated transactions (such as approving invoices or links to payment systems

Then consider that the scope of users who can create applications, websites, and content with these systems is pretty much all encompassing (all information workers have access to Office in most organizations), and the idea of assessing the risks is daunting to say the least!

I have no answer or even framework for addressing the problem at this point.  I’ll be involved in some ongoing research into this topic and will post a summary of findings when ready.  Until then, if any readers have encountered this issue - particularly in regards to a risk assessment - please drop me a line.

Burton Group was founded as a special kind of analyst firm - one that is specialized in infrastructure and is able to go deep technically.  Accordingly, our Collaboration and Content Strategies service was founded on the premise that collaboration, content, and communication have become infrastructure as well.

Many users still think of email as an application.  Part of it is.  But the vendors realized a while ago they needed to carve out the parts of email beyond POP3 and IMAP4 that should go on the server, named them Domino and Exchange, and now they are treated like infrastructure with service levels, backup/recovery, contingency plans, farm scaling, and operations-minded folks in charge of it all. 

Well, Microsoft Office is an app right?  Sure, until Microsoft realized they needed to carve out the parts of Excel that could go on the server and created the Excel Server part of Microsoft Office SharePoint Server.  A Powerpoint server is rumored to be in the works too.  And Office Business Applications (OBAs) are being created on the principle that Office is infrastructure that can be reused.  It can be repurposed to produce applications that treat Office as infrastructure, connected to line of business apps, rather than a hermetically sealed application.

Well, SharePoint is an app right?  Bingo!  That’s where this gets you into trouble. It has a purpose built front end and a wide and deep pool of infrastructure underneath it.  When the purpose built part doesn’t do exactly what you want, it can be a long fall down to the deep pool underneath.  SharePoint buyers should understand that as much as the initial demos look like an application, really they are buying collaboration and content infrastructure. If you go into SharePoint thinking it’s an app because the demos or out-of-the-box test install you did seemed to do what you want, you can be very surprised when all of a sudden this starts looking like infrastructure.  You quickly move from being an application owner to an infrastructure owner and those are very different hats to wear. 

As the infrastructure nature of communication, collaboration, and content (I’m including content creation in this category, not just what WCM or DM tools do) is being properly realized, we’re seeing a separation of what used to be considered “applications” into infrastructure with an application on top.  The infrastructure parts keeps getting thicker (such as email going from POP3 to Domino and Exchange).  Accordingly, there needs to be more awareness - from end users and from vendors - of how the transition is made from application to infrastructure. 

The transition is difficult, but doesn’t need to be as painful as it has been.  Not if vendors recognize quickly what parts of their apps need to be pulled out and treated as scalable, reliable, reusable infrastructure and are clear about the depth and solidity (how far are you likely to get before needing to call for a team of coders, is this supported, etc) of the applications layers they provide on top.  Enterprises need to set up management processes and organizational structures to catch new infrastructure as it sinks from the application layer down into their domain and to understand the difference between infrastructure capabilities surfaced in a demo sort of UI and real applications.

Infrastructure has special characteristics that applications do not have and that can stymie implementers of communication, collaboration, and content technology (such as discussion groups, document libraries, portals, and wikis) that seems like an application at first:

• Infrastructure (with regards to the kind of communication, collaboration, and content software we’re talking about here) needs an application to be useful.  Will a little bit of customization and tweaking to the out-of-the-box UI and templates be sufficient to act as an application?  If not, who is going to design and build your application now that you have the infrastructure?
• Infrastructure is meant to be reused and repurposed, so who is going to own something that will be leveraged by a multitude of groups?  Probably not the first team that wants an application - if that’s the case it will be game to see who can stand on the sidelines the longest and let the first, most desperate group that needs an app take the plunge and wind up owning and paying for the infrastructure the groups on the sidelines will now leverage. 
• Infrastructure needs to be managed.  It needs availability (according to negotiated service levels [SLAs]), contingency planning, backup/recovery. This is stuff that tends to be considered boring and “not in my job description” for programmers and power users.

So the next time someone shows you the interface for a great looking communication, collaboration, or content tool, think about stepping back and saying “That’s great infrastructure.  Now who builds the app on top of it and who manages the infrastructure?”

Note: This is a cross-posting from the Collaboration and Content Strategies blog.

I initiated my attention management and information overload coverage because, in addition to my own research as an analyst, I am also service director for a group of analysts that cover communication, collaboration, and content management technology. Many of the technologies we talk about are relatively new and can be very useful in the right situations. But with information workers already feeling overloaded, every new communication channel or collaborative workspace starts with a strike against it since even a useful new tool just feels like one more thing to have to check. You have to spend attention to save attention. But risk aversion and a lack of attention to spend impels many information workers to ignore new tools and keep plugging away in the same way they always have.

Accordingly, IT organizations are often encouraged to go slow with any new communication or collaboration tool and pilot it to build consensus around its usefulness before rolling it out to the organization. Some tools do eventually gain grass roots support that way and go on to greatness in the annals of corporate history. But I want to propose a twist on that advice - to pilot new channels or workspaces when you have something major to apply them to. This could mean holding onto a new tool for 6 months or more if that’s what it takes. The idea is to immediately imprint its usefulness on the user the first time and to make its initial use unavoidable.

There is precedent for new communication channels only taking off when they have something to say. Take CNN and the Gulf War - CNN had been around for 10 years when the Gulf War started in the summer of 1990 and, according to Wikipedia, “catapulted the network past the “big three” American networks for the first time in its history, largely due to an unprecedented, historical scoop: CNN was the only news outlet with the ability to communicate outside Iraq during the initial hours of the American bombing campaign, with live reports from the al-Rashid Hotel in Baghdad by reporters Bernard Shaw, John Holliman, and Peter Arnett.” All of the news channels had improved communications capabilities that hadn’t yet been tested at that point, but CNN’s was the best (at 24 hours it was persistent and they had invested in good infrastructure, even if they underpaid their reporters). But it wasn’t until they had something to really say - an event - that people adapted to the new communication channel.

This applies to a new topic as well. I’ve given my presentation on “Which Tool to Use” twice now and both times a question was asked about whether an e-mail or similar communication should go out to announce the new guidance on which communication tool to use under given circumstances. The answer was a definite no - because the message would be ignored by so many people that it would strain the credibility of the sender and make future attempts to offer guidance more difficult. If the guidance is attached to another event of substance - such as announcing a new IM system or blog capability - then it has a better chance of being heard since it’s attached to a concrete event.

To offer a negative (and personal) example, some piece of software on my work PC has been giving off an alarm sound about twice a day. I’ll be sitting here and a “da-DING” sound comes out and … nothing happens. Nothing flashes, nothing comes up on the screen. I have no way to tell what application is trying to alert me. It’s as if a general announcement is randomly made every few hours saying “pay attention - check things”. It’s an alert with absolutely nothing to say. Debugging a “da-DING” is very difficult. And it’s quite annoying.

Applying this concept with a corporate reorganization would be a perfect opportunity to provide something to say to go along with introducing a new tool. Whether it’s a new intranet, wiki, President’s blog, or web conferencing, making it the primary source of new information about this important event that people care about can show how the new channel or workspace works when it really has something to convey. And it will be doing this better than the old tools could. Tying a new collaboration or communication tool to an event has many advantages over the standard piloting technique as the user sees the tool immediately applied in a useful situation.

Before I head off for Thanksgiving, I’d like to congratulate one guy who has a lot to be thankful for this fall. In October, Roger B. Myerson of the University of Chicago was awarded the Nobel prize in economics for his work on mechanism design theory. Professor Myerson did not join the Graduate School of Business until after I graduated, so I never got to meet him. But it seems he found a connection between the economics I studied then and the topics we study in the Collaboration and Content Strategies service today.

According to the University of Chicago magazine:

Mechanism design theory, he said, recognizes that “the economy needs to be understood as a communications system” as well as a market system. With its emphasis on incentives, information, and communication, the theory also has applications in political science, and Myerson has studied voting systems, including work on how to structure elections in Iraq to promote democracy.

Of course, I’m simplifying this down to the part that connects with the work of my research team. It’s really better described as how to achieve optimum equilibrium in situations where lying or withholding information would otherwise be a rational winning approach. But you can read more about this theory at the Economist (which includes the juicy tidbit that one of Myerson’s fellow prize winners lives in Einstein’s home and dresses up as Einstein on Halloween). Or, if you have a bit more time on your hands over the holidays, take an entire course on it at Harvard online (complete with reading packets and lecture notes).

I would propose that when applying mechanism design theory in a distributed enterprise setting - for example, among suppliers across a supply chain - many of the technologies we cover such as web content management and portals (to set up an extranet that establishes standard, reliable flows of information), e-mail, instant messaging, document libraries, discussion groups, web conferencing, and survey mechanisms could be of great assistance.  It seems Myerson uncovered just one more way in which dissemination of information and communication systems make the world go ‘round.

Whatever happened to the idea of owning your own content?  In the rush to jump on Web 2.0 bandwagons and start publishing every which way, it seems people have lost track of the idea of how to get a hold of their content.  Having import/export mechanisms is the first step. Having those exported files being in a standardized format that could be imported into another system is even better.

If you use on-premises versions of Enterprise 2.0 tools that gives you a lot more control.  But SaaS has become a popular distribution model for these types of services and it has a lot to recommend it.  The problem is that there aren’t easy answers to the questions any organization opening up an end-user content generation tool (e.g., discussion groups, wikis, blogs, social bookmarking/tagging) should be asking:

• How are we going to do contingency planning or do we trust the hoster with what may become critical business data? 
• How are we going to mitigate the risk of using a small vendor or a new product from a large vendor that may be ditched if a juicy acquisition comes along?
• How can we upscale the content that is generated by starting with a body of end-user content and taking it to a more professional, formal level?

These questions could be answered by providing access to the data in standardized XML formats.  At this point it seems the best answer is writing an application against the APIs (if they exist) to pull all the data out into whatever format you like or to utilize robots that can do huge amounts of screen scraping.  Hopefully standards efforts (like this one for wikis) can advance quickly before enormous amounts of enterprise content finds itself in a web 2.0 prison with no means of escape.

I spoke last week at a conference about how users make decisions between e-mail, IM, wikis, workspaces, the telephone, and other methods of communication and collaboration. I’ve seen many articles on when to use e-mail versus an IM, when to pick up the phone, what collaborative workspaces like SharePoint are good for, and they all seemed to be missing something, so I set about codifying my views on this topic into my presentation.

The point of my presentation is that there is an increase in web 2.0-like web content, communication and collaboration channels/workspaces and a corresponding increase in confusion about how to select among them. Ineffective communication and lack of collaboration caused by using the wrong channel or workspace can result in poorer understanding and decisions among the participants. Decisions about which tool to use are often made based on expediency, availability, and familiarity rather than productivity. This is natural and can never be fully optimized for productivity. But individuals and organizations can do more to increase productivity by encouraging appropriate use of channels and workspaces.

So what I’ve attached below is the “poster” version of the guidance I gave on deciding which communication or collaboration technology to use depending on the circumstances. It is just a starting point though - each organization may have a different set of tools or common usage. And there is still debate within my own team of how things should show up on this chart (hence “document libraries” appearing in two spots), so it should be taken as my personal best attempt at this guidance and not a formal, peer reviewed, locked down decision tree.

Some background is in order though: I don’t expect anyone to whip out this chart (or any guidance like it) every time they’re about to send an e-mail. You can only expect this guidance to affect systematic communicators (like corporate communications or HR groups that send important, polished messages to many people as part of their jobs) or those in training. There are certain “teachable moments” when guidance like this is accepted and has a chance of sinking in. Just emailing it out to the department out of the blue is likely to have zero effect (or worse since future attempts at guidance are more likely to be ignored as well).

The main point of the chart is that message senders should learn to distinguish between collaboration / communication and synchronous / asynchronous. It’s important for the guidelines you give to remain realistic and flexible, particularly with informal interactions which should not slavishly follow the flow chart. You should customize these guidelines based on the industry, environment, and role while leaving room for situational factors (like sensitivity of the message). And finally, try to understand and minimize barriers to proper tool usage where possible, such as by making sure information workers have easy access to and feel comfortable with the tools so that lack of familiarity doesn’t come into play when making tool decisions.

So, with no further ado, here is the chart I presented (click on the thumbnail for a full-sized version):

Argh!  I just got back from speaking yesterday at the Shared Insight (now IIR) conference on Portals, Collaboration & Content about how to pick the right tool for the job when trying to communicate, collaborate, or post content. So I get my Wall St. Journal today and it has an article by Lee Gomes (11/7/07, page B1) called “Email Is Letter-Size In a Big-Parcel World, But Help Is Coming” (available online here). In it he attempts to tackle the problem of users trying to email large files by recommending solutions that enable sending of large files.   As he puts it “A number of companies, with all manner of business plans and technology models, are in the business of being for email what UPS is for regular mail.”

But why is the assumption being made that email is the right way to be exchanging these large files?  And that if email isn’t working, one should look for a tweak that is very similar that gets around the problem?  It apparently took him 2 hours to email a 600 megabyte picture (I can’t imagine what kind of resolution and pixel depth this reporter is playing with. He must be designing billboards on the side). He is trying to pound a nail in with a chicken and, when that doesn’t work, is trying an armadillo instead. What is needed isn’t equivalent to “what UPS is to regular mail.”  Maybe what’s needed is what a storage locker with multiple keys is to mail.  Or what an a passenger airline is to mail.  Or what a bulletin board is to mail.  Or a newspaper …

Mr. Gomes says that Will Kennedy, general manager for the Outlook team, promises new versions of Outlook and Exchange will make this easier.  But why not talk to Derek Burney over in the SharePoint group who could easily describe how to create a space to post up files of any size for public or private use.  And you could actually collaborate back and forth on the document, maintain versions, and store discussions about it too while you’re there.

One of the biggest problems with e-mail is that users are so comfortable with it that even when dozens of other tools exist to do better handle what they want to do (such as document libraries, portals, RSS feeds, web content management, instant messaging, blogs, wikis, discussion forums, the telephone, face-to-face interaction, etc.) they try to shoehorn everything into e-mail.  In January we published a document by Karen Hobert entitled “Enterprise Messaging: E-mail’s Evolving Role in Optimizing Communication and Coordination” (client access only).  In this document, Karen said it best:

Enterprise messaging does not have to be a bad experience for users or enterprises. E-mail can be purpose-focused, coordinated communication that plays a pivotal role in the broader communication/collaboration landscape. This can be accomplished as long as organizations stop trying to use e-mail for activities that it is not designed to do and provide users with complementary communication and collaboration solutions that support the activities that they turn to e-mail to complete.

Note: This is a cross-posting of an entry I did in the official Collaboration and Content Strategies blog.

I had a conversation this morning with a large, information services organization about outsourcing.  That may seem strange since the Collaboration and Content Strategies service does not cover outsourcing.  But along with the standard questions about where in the world outsourcing was taking place, near-shoring vs. off-shoring, and legal questions the company also wanted to know about how best practice organizations are working and collaborating with their offshore workers.  I thought that was a very good question to ask, so I’m posting what I told them up on this blog.

Communication, collaboration, and content management are enabling technologies for outsourcing.  It is hard for me to remember how outsourcing worked twenty years ago without these technologies and now I can’t imagine doing outsourcing without them.

Of course, outsourcing was happening twenty years ago anyways.  But the expectations for return were lower, as was the pace of communications and the expectations for collaborative involvement in decision making.  Organizations make a decision to outsource based on competitive pressures.  Accordingly, a certain degree of efficiency is required to get the returns expected from outsourcing.  I don’t believe an organization can get the returns expected today without near best practice in joint creation of documents, sharing of information, brainstorming and decision making, and mechanisms that enable a single source of truth (such as web publishing, document libraries, and document management).  And while there are many non-technical factors and other technology domains (networking and security come quickly to mind) involved, those near best practices cannot be accomplished without a strategy for the enabling technologies that support them.

Furthermore, as I mentioned in my telebriefing on preparing a business case for collaboration, the technology needs to be in place today to enable business collaboration that will take place in the future.  And this technology needs to be adopted in a strategic manner, not just tactically for each individual outsourcing project.  In a tactical adoption of communication, collaboration, and content technology the burden of the research time, implementation time, and learning curve is borne by an individual project.  For this reason, tactical adoption of these enabling technologies greatly increases the risk of not achieving the expected return from business collaboration projects such as outsourcing.  And without strategic forethought, there is a significant risk that the technology that was a good fit for its intended project will not be a good fit for future projects. 

All of this adds up to a good case for any organization that is contemplating outsourcing to evangelize a strategic approach to communication, collaboration, and content management so that these technologies will be ready to be leveraged when needed for outsourcing - or any other project requiring information efficiencies that happens to come along.