KnowledgeForward

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

I had an interesting discussion this morning with my colleague Mike Gotta about brainstorming and innovation. After sharing what each term meant to us, it became clear that each has its place and they are complementary concepts. I’m not always a fan of the Wikipedia articles on concepts that IT folk deal with, but the articles on innovation and brainstorming are actually quite good at the moment and are worth a read for some background.

Like all great research areas, innovation represents a process rather than a technology, fuzzy concept, market, or discrete project. It involves tracking and sorting through all the innovation proposals, ensuring the best ideas rise to the top, and continues to manage the process through implementation. Innovation can also be built into research processes. Pharmaceutical consumer packaged good companies, for example, devote an incredible amount of energy into innovation as a repeatable process with replicable practices. A good research discipline can systematically create proposals that can lead to something innovative.

But where do the ideas come from in the first place? That’s where brainstorming comes in. While creative spark is often seen as as something that comes out of the blue, research and experience has shown that it can be created on demand as well. A brainstorming process acts as a spark plug to generate that creative spark. It consists of an environment where ideas can be thrown around without immediate judgement, different angles can be recommended by participants to help generate ideas, and others can build on ideas to see where they go.

I don’t think I’d go so far as to isolate innovation to a pure execution process, but it does seem that brainstorming is think-heavy and innovation is do-heavy (this is the fun of blogging: without peer review and editing cycles I get to make up new words!). Ideally, there would be integration between the brainstorming process and the innovation process so that once a good set of new ideas is generated they can be passed on to the innovation process to be prioritized and, if deemed worthy, implemented.

Both brainstorming and innovation can leverage communication, collaboration, and community. They involve a wide array of people, in different roles, from different locations, inside and outside the organization, and with different points of view. This requires good communication technology to enable concepts to be bandied about. Collaboration can help the participants to work together within a persistent workspace where a record of the exchange of ideas can be kept. Subscriptions and notifications allow participants to be actively or passively aware of the discussion as desired.

Innovation is the hotter topic at the moment with 127 million hits on Google (compared to a measly 16 million for brainstorming and 69 million for creativity), but both have their place in an enterprise. After all, for an enterprise, there are few things more sad than a good idea not implemented.

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):

I’m sure all of you out there in blogland are wondering where Craig Roth was this week.  Was I at the Mandalay Bay in Vegas this week for the IBM Information on Demand conference?  Nope.  Snug and comfy in my bed in my hometown of Chicago for the Lotus Collaboration Summit?  Nope.  Moline, Illinois.  It’s actually a pretty drive about 3 hours west of Chicago and I got to present and co-host a roundtable at a good event called the Network, Analysis, Collaboration Fall Conference.  The issues they are working through and problems they are encountering resonate well with what I’ve been hearing from other large organizations.  Here are my notes:

• A security working group came up with a list of critical questions they are dealing with at the intersection of security and communication/collaboration
  • Who determines classification of information?
  • Can you selectively encrypt outgoing communications?
  • How do you deal with partners who have much more or less stringent security than you?
  • Their current efforts revolved around setting policies, education, and defining the need for data classification (determining what counts as confidential)
• A Collaboration and content working group presented their findings
• Two companies reported severe difficulty unifying content repositories.  One manufacturing company had 28 different repositories.  Another, an insurance company, had tried to consolidate and failed since it was difficult to communicate to users which to repository they should use
• There were concerns about how to determine what counts as a “record” for records management retention purposes
• Two companies said they evaluated the new XML file formats that are the default storage mechanism for Office 2007 and decided to to switch it back to the old format and not XML since they are not ready for it yet
• A large Big 10 university did a presentation on their collaboration challenges
• A university is unique in terms of their turnover.  They have 10k user turnover per year as students graduate, which places unusual burden on provisioning, training, etc.
• Students feel entitled to email and calendaring and have it integrated with their devices
• The students are amateur integrators too, trying to embed one service inside another
• They did a study of the pros/cons of outsourcing.
• Pros of outsourcing for collaboration: cost savings, redirect scarce resources, richer environment, better agility, larger disk quota, SaaS, more functionality
• Cons are lack of control, availability, security/privacy/IP, support and response, viability, portability, records mgmnt
• Their security issues list is topped by identity management, privacy, integrity, availability, data mining (FERPA), and profiling
• They looked at using Google apps, but it doesn’t seem likely at this point because they couldn’t guarantee Google wouldn’t roll over if asked by the government for information and couldn’t handle FERPA regulations

McKinsey has just authored another article in what could be considered a series on collaboration in organizations. The first two (”Mapping the Value of Employee Collaboration” and “Competitive Advantage From Better Interactions”) were very good at articulating the value of collaboration from a point of view (and a source) that business executives can understand. I use them frequently when setting the stage for the usefulness of collaboration technology at an infrastructure level (in other words, not applied to a specific one-off project).

But I’m not as thrilled about the next in the series. The new article is about formal networks, but is called “Harnessing the power of informal employee networks”. The change in nomenclature comes about because the authors’ answer to how to harness the power of informal networks is to make them formal.

After describing how prevalent, necessary, and useful informal networks are, the article describes how they can be made more useful by providing a leader (”coordinator” is a better term since the person has no managerial authority), a budget, evaluation measures, and IT resources (wikis, document libraries, and the like).

There’s no doubt in my mind that the type of formal network they describe is better than the matrix org chart they say it replaces. And for companies that have no similar mechanism in place (centers of excellence, communities, sponsored “birds of a feather” get-togethers), a formal network would certainly be an improvement.

But I think a formal network is just one type of network or community and that the authors should have been more careful to acknowledge that and provide tips for differentiating which networks are appropriate for formalizing and which aren’t.

I also felt the article did not address several tricky issues related to the formation and subsequent growth of the network such as:

• Does one wait for networks to self-organize and then (at what point?) jump in and pave the cowpaths by making it formal?
• How comfortable can members be about leaving the network if they do not see the value?
• How to people outside the network petition to join?
• Given how the article demonstrates the importance of a “linchpin” in a network, how does the network retain resiliency in the case that the leader/linchpin is a jerk?
• In what cases should an informal network be left alone and not formalized?

Overall I still believe the article to be a good one. It’s based on a lot of research whereas my observations are based on a 12 page summary, personal experience, and gut feel so I may not be capturing the whole essence of their points. And I do think formal networks are a very valuable form of network. Just not the only form of network.

While watching the U.S. Open in September I was bombarded with IBM’s commercials on innovation.  I’m glad IBM is sponsoring the U.S. Open - they do a great job with the web site and someone has to chip in to pay Roger Federer’s $2.4 million winner’s check.

But IBM’s commercials on innovation leave me with a bad feeling.  Their intent is to emphasize that actually implementing innovative ideas, not just holding new-agey ideation sessions, is what companies should be doing.  Which is true.  But in the process they make fun of the ideation process so much, associating it with lying in the dark in a conference room and other wacky antics, that it winds up disparaging the creative process.  Where do great ideas come from?  Unsolicited emails and “are there any questions?” prompts at the end of an executive presentation?  I doubt it.  The marketing folks guiding that campaign should look at IBM’s own InnovationJam as an example of how to create ideas.  The problem may have been selection - I’ve heard there are other commercials in the series (maybe not shown during the U.S. Open) that show the group discussion process in a better light.

So now I’m a TV ctiritc?  Not really, but innovation is one of the core business imperatives driving collaboration technology as I discussed in my recent telebriefing on “Preparing a Business Case for Collaboration” (available to clients only). 

I’m sure IBM would agree that a single-minded focus on executing innovative ideas without supporting effort to spur creation of innovative ideas won’t work either.  But by painting the ideation process as a feeding ground for weirdos it skips over the proper ideation that needs to take place.  This is surprising given that IBM’s product line includes collaborative tools such as IBM Lotus Notes, Domino, Connections, and Quickr.  Maybe they just don’t bring in as much as IBM’s services?

If you were planning to go to the Shared Insight (now IIR) conference on Portals, Collaboration & Content I have a discount code that I can give you to get a 15% discount.  You can use my code “SPKRM1991CR”. The conference is November 5-8, 2007 at the PGA National Resort and Spa in West Palm Beach, FL.  I don’t play golf (tennis anyone?) but it seems like a nice place.  And be sure to see my presentation “Picking the Right Collaboration Tools for the Job” while you’re there. To register go to www.iirusa.com/pcc .

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.

As part of my research into enterprise use of virtual worlds I spoke to a virtual event solution vendor called Unisfair today.  I like what they offer as it seems to meet their user’s needs, but am apprehensive that the phrase “virtual” may be getting distorted.

First, what did I like?  Their proprietary event management system and Flash-based interface takes some of the good features of Second Life and dispenses with some of the problems.  Which good features and problems do I mean?  Well, the good part is that it has some of the cool factor of Second Life, looks 3D, and allows serendipitous social interaction and discovery things the user was not explicitly looking for, and can display content in several forms (video, slides, text).  Unisfair dispenses with some problems that enterprises have had with events in Second Life such as scalability/performance issues, distracting unbusinesslike elements (e.g., flying, strange-looking creatures as avatars, bizarre clothing), griefers (flying unmentionables at conferences), and a larger learning curve to get around than first-time business users want to tackle. 

So far, so good.  But it’s not a virtual world.  Unisfair says it is a “virtual environment”, not a “virtual world”.  I suppose that helps a little, but not a lot.  It’s clear a connection will be drawn to virtual worlds and Second Life though.  For example, The PC World article “Cisco Launches Virtual World for Resellers” about Cisco launching on Unisfair states

Cisco Systems Inc. launched a virtual online 3-D world based on a trade-show motif Thursday … the new Cisco Industry Solutions Partner Network (ISPN) is loosely based on the animated look and feel of Second Life and related sites … Relying on the concept of Second Life makes sense for serious business needs, Sage added.

An environment suggests a world, which implies to me (and I think many others) that it does 2D rendering of objects in 3D space.  There’s a big psychological difference using an interface that allows free movement versus one that only allows movement up and down a set of prescribed paths.  Sure, once you are in a virtual world for a while you may not stop to smell the flowers anymore, stare out over the water, tilt your head up just to see the clouds.  But you like to know you still can if you want to.  If a user cannot interact with their environment, what is the difference between an environment and a bitmap with hotspots?  When you look at a room using one of those 360 viewers on a hotel (like this one) or real-estate website - where it’s really just one big wide bitmap but they let you scroll right and left and zoom in and back - is that a virtual environment?  Or virtual representation of the room?  Was the old videogame “Dragon’s Lair” (which looked like you were moving through a lushly animated 3D world but was really running a cartoon clip off a videodisk that ignored your joystick except at cut points) a virtual world?  Nah. 

This is deja vu from covering portals.  In 2002/03 when portals were hot, too many vendors called their product a “portal” to connect to a meme that guaranteed attention.  When I quizzed many of them privately about their portal features, they admitted they were not really portals “in that sense”.  And sure enough, when portals cooled down a few years later they all took the name “portal” off their products.  The same could be happening with virtual worlds and Second Life.

So what?  Does that matter for users of Unisfair?  Not really.  They’re not there to walk around the booths and study the architecture of the conference center from all angles.  It seems like a good solution for online events with social networking and communication capabilities and a hipper navigational interface.  I don’t mean to disparage them and I’m sure my teammate that covers conferencing, social software, and chat tools would especially appreciate the integrated and purpose-built nature of the tool.  But it’s a signal to me that I now have to be careful when I see the word “virtual” being thrown around.  For the next few years anyways.

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

In my telebriefing on “Preparing a Business Case for Collaboration” I was pleased with the great questions that were submitted. I’ve posted them here along with my answers.

Q: You mentioned “managing high expectations” [as a risk factor for collaboration projects]. How do you recommend a deployment strategy strike a balance between addressing enterprise-wide expectations with focused hand-holding deployments? In other words, a great solution for a few or a plain-vanilla for everyone?

A: This is a difficult issue to address since in many cases one benefactor is footing the bill for collaboration technology that can be used by many users. Naturally that benefactor expects it will be customized to meet their needs over those of the non-paying masses. If you truly think the solution meets only a narrow niche in the organization, I’d recommend examining the following strategies:

• Try to find basic infrastructure that can be customized (i.e., templates) to meet the benefactor’s needs today and then, when business needs justify rolling it out to more users it is be customized to meet other needs as well.
• Try to hunt down one or two more areas of the business that can split the cost of the project in return for balancing the requirements to meet everyone’s needs.
• Talk to a CIO that is above the benefactor and see if he/she can exert pressure to generalize the requirements or chip in on the price to give the rest of the organization a say in the capabilities needed.
• A last resort is to purchase a niche product to meet their very specific needs (hopefully it’s not too expensive or maintenance intensive) and put governance in place to make it clear this is not for the entire organization.

Q: How would you overcome cultural roadblocks to Collaboration deployments?

A: To be clear, there are generally not many cultural roadblocks to the collaboration technology itself other than the difficulty in getting people to learn a new interface. The roadblocks are all non-technological. And there’s no silver bullet either. But your question was what have I seen used in practice to overcome them. Here are a few that I’ve seen in practice

• Big splashy rollouts: Meeting in the company cafeteria, catchy names and slogans, balloons, little knick-knacks to put on the desk. This generally causes a small spike in usage but doesn’t go much further. In theory if awareness was the only roadblock this could work, but it usually isn’t.
• Changing performance reviews to emphasize collaboration: Some organizations have realized their review processes focus exclusively on individual performance and have altered them to take collaboration into account. This can be in the form of qualitative ratings (obtained by talking to peers, work on team projects) or quantitative measures (social networking ratings). One always has to be careful when tweaking performance evaluations, but this can be part of a good strategy if individual performance is being exclusively emphasized when teamwork is needed.
• Internal research: Most organizations don’t really know the reasons collaboration is being avoided so imposing solutions is a shot in the dark. In this case it is a good idea to actually talk to people from the executive office to staff workers in short interviews and determine their views on collaboration and why it does/doesn’t occur in their area. This is often done by external consultants to encourage anonymity. Formal network mapping can provide a more extensive look at where the informal collaboration networks in organizations lie and where opportunities are being missed.
• Changing incentives: In cases where specific incentives are often tied to individual behaviors (e.g., salespeople), formulas are sometimes tweaked to provide better compensation for collaborative efforts. This can be very tricky, but probably needs to be addressed if the behavior being incented doesn’t match the collaborative needs of the organization.
• Removing inferior alternatives: Eliminating shared drives while making information workers aware of team workspaces can tip their behavior in favor of collaborating. It’s no guarantee - they may simply walk files over on a thumb drive or email them too, but it eliminates one avenue. I’ve seen the same done with e-mail attachment limits as well, although there are sometimes good reasons to e-mail large files rather than posting them to a workspace.
• Leading the horse to water: Sometimes collaborative tools aren’t used because there is no established pattern of behavior. They simply haven’t used them and are more comfortable with the old ways. In these cases, a mandatory activity that forces usage of the tools at least once exposes them to the technology. Just like coupons are, in part, to establish patterns of behavior, these efforts can get information workers used to a technology as well and if they see a need for it soon thereafter, they may use it. Examples include requiring status reports to be filed on a wiki, requiring time off to be noted in a shared calendar, or requiring presentations for an internal conference to be uploaded to a workspace.

Q: Do I have an example of this methodology being used for a government agency?

A: I don’t have completed examples I can give you. I do have a template that guides you through the sections that I showed briefly in the presentation and in more detail in the Methodology and Best Practice document I published on this topic (Building a Business Case for Collaboration Initiatives). If you’re working on a business case I’m also happy to talk to you and give advice as well as give it a once-over before you send it to your management to see if it can be strengthened.

Q: Can I get a copy of the slides?

A: Yes, they are posted on our website here. You can also hear a replay of the telebriefing there as well.