mind this - by Lars Plougmann

Measuring business value from social technologies

In the span of a few days, Forrester and The Economist Intelligence Unit released quantitative reports based on surveys of social technology adoption. The EIU report, sponsored by Fast, a search engine company, is available for free if you register on the Fast website. The Forrester report can be purchased online ($279 - I have yet to purchase a copy, this article is based on extracts).

Forrester looks at consumer interaction in the age of the read/write web. Who are active participants (creators), who reads and comments (critics) and who lurks (spectators) - six categories in all. EIU interviewed managers in large companies about their experiences and expectations of social software.

A question I get asked frequently about social software is "How can we use it to save money?". While there are some specific business cases for cost reduction I have always felt that collaboration primarily fosters empowerment, innovation and the potential for better quality service; the EIU survey supports this notion with figures stating that 30% of executives expect social software to offer cost savings, nearly 80% see the potential for increased revenue or higher margins.

Mashing up some of the quotes from the EIU survey, it confirms what early adopters have known for some time, namely that social tehnologies "have significant implications for big business" and that "the world's multinationals [have begun] to see many web 2.0 technologies as corporate tools" not just "frivolous" innovation amongst "enthusiasts, especially the young".

Scott Vine extracts key figures and quotes from the EIU report while Charlene Li and Ross Mayfield share their thoughts about the Forrester survey. Although the Forrester survey uses a different classification, it provides a quantitative view of Ross's widely quoted power law of participation.

Tags: web 2.0 social software research Forrester The Economist Intelligence Unit EIU cost+saving power law of participation

BusinessWeek tells CEOs about wikis

In 2004 when I introduced a hosted wiki as an experiment to the knowledge department of a law firm, adoption was almost instant. I primed it with a top level structure reflecting the things that mattered to our team: People, Projects and Ideas. Within a week, two projects had decided that this was the best tool to use for project management and communication, somebody started compiling a list of useful technologies and vendors, others started sharing ideas and links to articles. Most took the opportunity to provide a richer profile of themselves than the intranet allowed. The wiki clearly filled a vacuum, somewhere between email and the document management system. Yet, a few were not interested and didn't participate.

In short, a typical wiki adoption story. But the typical story may be about to change.

Many wikis started as an experiment by a small team, then spread virally. Now, CXOs and the business press have started to notice the power of simple tools like wikis. The success of Wikipedia explains part of the fascination (imagine having your own corporate equivalent) and a number of case studies are becoming well known.

BusinessWeek just published a series of articles on wikis as part of their CEO guide to technology (main article). Last month, InformationWeek reported on Enterprise 2.0, explaining that it is about "a new architecture defined by easier, faster, and contextual organization of and access to information, expertise, and business contacts--whether co-workers, partners, or customers." Their survey found that while a third were using the new tools, most technology professionals remained wary.

As the scales tip, collaboration centric initiatives are graduating from skunkworks to management sponsored projects engaging those communities eager to participate. This increases the likelihood of broad internal adoption of powerful, enabling technologies like wikis.

Tags: wiki law firm collaboration

Google Apps becomes a commercial product

Some five months after launching Google Apps for Your Domain, Google is out with a commercial version called Google Apps Premier Edition.

Google Apps Premier is a beefed up version of Google Apps for Your Domain (Gafyd), itself a repackaging of some well known Google products. With Premier, you get email, shared calendar, instant messaging, internet voice calls, web page publishing and real-time collaborative documents and spreadsheets. Mailbox limit has been raised to 10 Gb, email is covered by a service level guarantee and there is support for users and the administrator. Annual subscription is $50 per user. The existing Gafyd product remains available for free.

The service is not a fully fledged office suite. There is no application to churn out presentations; this could be a deal breaker for many organisations where Microsoft PowerPoint has taken over from Microsoft Word as the environment of choice for writing documents. The spreadsheet is not as advanced as Microsoft Excel, it lacks pivot tables for example. The power of Google Docs and Spreadsheets is in the real-time sharing capabilities.

I have helped set up the Google Apps for Your Domain service for three startup companies and Gafyd remains a good, free option for small firms and organisations. In fact, the free version of the service is more attractive now that Premier offers a way to grow (extra mailbox limits, meeting room schedules, support and SLAs). There is little reason for startup firms to opt for the Premier Edition right away, but Premier could be attractive to organisations that want to simplify their IT or save costs - and need migration of users, email, data or integration with an existing infrastructure.

All the concerns raised about SaaS in general are applicable to Google Apps Premier Edition. Don't use if you are concerned with what jurisdiction your data resides in. Don't use if you are based in a country that is likely to block access to the service. Think twice about it if your teams are offline for long periods of time or served by low bandwidth (see Zero bandwidth scenarios, March 2006).

Most of my previous predictions about Google Apps have been proved right with the launch of Premier. I suspect future versions will address behind-the-firewall access and include more applications. Behind the firewall access will be provided by rolling out Google Apps to the users of Google appliances. Behind-the-firewall access is likely to be addressed before offline access. A wiki is a likely application to be added to the mix, perhaps a one with presentation features to address the lack of a slide composer. Google has more applications that would be useful in an enterprise setting and some of them, such as Analytics, Blogger, Translation, may find their way into the Apps bundle.

Some organisations that start using Google Apps might find it difficult to adjust to "2.0" thinking, particularly if they have been used to traditional office suites. Throughout, these tools rely on tags and search rather than folders, inviting participants instead of emailing copies and a timeline of changes instead of formal version control. All very wiki, bringing with it a change to a more agile relationship between information, people and the organisation.

Tags: Google Google Apps Premier Edition Google Apps Gafyd SaaS office suite Google Enterprise Gmail collaboration tagging

If your organisation has no intranet: An opportunity

I have recently had a series of meetings with a number of small and medium size, high growth, knowledge intensive firms in the professional services sector. None of them has an intranet. My reaction and advice is "Great opportunity. Don't get a traditional intranet."

The concept of an intranet is a great idea. Making all relevant content accessible to everybody in one place. But many companies' intranets suffer:

• Information changes quicker than the intranet team can update it. No content is static.
• When the perception is that the information on the intranet is not up to date it stops being the first source for vital business matters
• The intranet structure typically reflects the shape of the business as of yesteryear
• The process for updating information on the intranet involves finding out who is responsible for a particular page, then describing a proposed change in an email which gets added to a work queue. Most people only involve themselves once in that process if they don't see the page updated within a short time
• Ownership is often skewed: When only a few people can edit stuff on the intranet, an "us" and "them" culture arises. In the worst cases, the intranet becomes the object of blame and ridicule.

The opportunity available to organisations without an intranet is to use some of the new social tools and build an open intranet. An open intranet is one where any user can create a new page and every page has a nice friendly Edit button on it. Anybody within the organisation who wants to update or add information is empowered to do so.

Doesn't that approach lead to chaos? is one of the objections. To a certain degree it does, but there is order in the chaos. This type of intranet will not necessarily evolve into a neat hierarchical structure. But that is not a problem: The information itself is not necessarily hierarchical in nature, and navigation aids exist to work with information organised by different means (search, links, tags etc.).

Can we trust our people to write and edit the information on the intranet? is another one. You already trust your people to advise clients on business strategy so I don't see why not. Besides, most tools offer mechanisms that facilitate review of recently updated content, and everybody is free to correct inaccuracies. Similar information is already being exchanged via email; with no transparency, no mechanisms to discover inaccuracies and limited ways of collecting information for the purposes of wider sharing.

An open intranet helps develop a culture of sharing relevant information and encourages broad participation in maintaining that information.

Tags: intranet wiki open intranet SME information sharing participation

Shared calendars as an example of alignment with individual incentives

One of the aspects that hampered knowledge management (KM) initiatives in the previous century had to do with the separation of work and KM activities. First you did the actual work, then spent some time doing the KM bit. Some systems forced you to do the KM bit first, trying to increase the probability that it got done. KM required individuals to invest time in making information useful in a larger context, on the basis of top-down categorisation schemes that had to be learned. The approach didn't gel well with human nature and plenty of people found ways to circumvent it.

Consider for a moment the near-ubiquitous electronic calendar as a good model of interaction. It allows you to organise your time without requiring extra effort compared to a paper organiser and it even offers some handy features: You can reschedule appointments without using an eraser, you can create repeating entries easily, it will remind you of upcoming meetings, it can synchronise with multiple devices. But the real benefit of using electronic calendars is evident at the aggregated level: Using shared electronic calendars drastically reduces the time required to schedule meetings with colleagues.

Crucially, the benefits are there without the need for additional effort on behalf of individuals to make the information useful to the group or the organisation. The same principle is the driver behind the new breed of collaborative tools.

A good collaborative architecture provides a platform that works for the individual - a place to work with, store, contextualise, search and exchange information - while offering an unobstructive way to make the information useful to a wider group. A spectrum of opportunities for participation is opened up, from discovering relevant information and co-production to refactoring, syndication and mash-ups [link to FT article behind paywall].

We are moving away from old KM (with its separation of work and the places you put work) to better support for knowledge intensive processes (SKIP?). Skipping onerous tasks associated with KM is more in line with human nature. The tools themselves are simpler and the benefits greater.

Tags: collaboration knowledge management support for knowledge intensive processes KM SKIP collaboration architecture human nature calendar shared calendar participation

The flip-side of email and collaboration

What would enterprise adoption look like if collaborative platforms had been invented before email? Andrew McAfee at Harvard Business School shares his opinion for discussion.

The question is a fresh take on the email vs. collaboration platforms debate.

Tags: email collaboration Andrew McAfee

Patterns in collaboration

Light is waves and particles. Work is process and collaboration.

Until recently, the main focus of businesses was process. Efficient process execution, quality processes, process re-engineering, process management systems. Even BPR followed a process.

With the accelerating adoption of collaboration tools, like wikis, there are effective ways for groups to break out of processes when required. We are also starting to see process tools offer free-form collaboration for exception management (where the process is not defined).

Even defined processes evolve - as requirements or regulation change, as better ways are discovered or as technology opens up new opportunities. From process ABCD to AXD to AZ over a number of process generations. Accelerating process improvement in this way means connecting the people in the process with the end customer and stakeholders. Here, collaborative tools play an important role as a parallel tool where existing processes are evaluated and feedback is allowed to loop. Process innovation becomes a continuous process instead of (ir)regular process reviews or an approach of only fixing-it-when-it-is-broken.

Other organisations adopt collaborative platforms across the board because few or no processes are defined. (This is the case for many fast-growing small or medium size companies.) It is great for supporting innovation and they find that processes do evolve and are adhered to as conventions. Loose collaborative tools become the organisation's process and innovation platform in one.

As collaborative platforms become more powerful, they are evolving to embrace processes. Wiki software company Atlassian also sell JIRA, a project management / issue tracker software package that users are also deploying to manage business processes such as task management or CRM.

I expect to see future systems take the integration between process and collaboration further. At one end of the scale we want free-form collaboration to support our innovation efforts, at the other end we want repeatable processes to ensure consistent results and keep costs down. Emerging patterns could be discovered by the software and codified as processes. Sort of the equivalent of the infamous Microsoft Windows paper clip popping up announcing "It looks like a business process has emerged for this task. Would you like to (1) follow it, (2) edit it, (3) do it your way?"

Tags: wiki collaboration process business process process improvement exception handling innovation BPR Atlassian JIRA

Counterpoint: email vs. collaboration technologies

In an article called The Big Match, Michael Sampson joins the ongoing discussion about the effectiveness of email versus other collaboration tools (I compiled a summary of the discussion about a month ago).

As a counterpoint to my 10-to-1 list of email effectiveness, Michael provides a 10-to-1 list illustrating the effectiveness of wikis as a collaboration tool. The list points to relevant barriers to wiki adoption, such as people being afraid to click 'edit', forgetting passwords or being drowned in RSS feeds. My favourite is:

"5 people will print off the current version of the wiki page and use that as the authoritative version."

I am sure it does happen.

Michael concludes that most of what is wrong with email can be attributed to human behaviour, and that adoption of other collaboration tools will ultimately be struggling with similar behaviours. He asks, "If we conclude that collaborative tools are substantially different from email, what proportion of people's communication and coordination activities would / could / should be shifted to another tool?".

I think a key to effective collaboration lies in the use of the word 'proportion' in the question above. Only in very few settings will a collaboration tool replace email. In most settings, a key to success is to establish how a new collaboration tool should work with email. As it was phrased at the Collaborative Technologies Conference earlier this year, email is the on-ramp and off-ramp to collaborative spaces.

From a simple perspective, email is a communication and co-ordination tool being used for collaboration. Conversely, collaboration initiatives that do not address the communication angle are likely to fail. (Refer to Michael's article for a discussion of the differences between the three c-words, then cross-check with JP Rangaswami's point about the difference between group decision processes and group work using the Five Frogs analogy.)

Sometimes we want to view collaboration as a series of messages and sometimes as a piece of content where all contributions have been aggregated - and have the power to switch between views as appropriate. I predict that tools with such capabilities will evolve allowing individuals to participate in collaboration using their preferred tools, including email.

Tags: collaboration email email project management collaborative workspaces Michael Sampson shared spaces wiki collaboration tools

Mature Google products migrate to the enterprise

The Google Enterprise team consists of some 250 people striving to "Organise the information inside your company and make it accessible and useful". Compared to the Google mission statement, the focus has shifted away from the world's information and it is not about making information universally accessible (rather it is about understanding and respecting rules for information security within a company).

I attended the Enterprise team's road show in London, it was a good opportunity not only to meet some insightful Google people and discuss my ideas about using Google's ad services on corporate intranets, but also to learn about Google's enterprise products and strategy.

With the announcement that the application suite currently available as Google Apps for your Domain (mind this, September 2006) will be made available as Google Apps for Enterprise, a pattern emerges for how we may see future enterprise offerings from Google evolve:

• Google Apps for individuals: Typically launched with the beta suffix, applications are made available for free to millions of people. With the capacity to test new features in only parts of the user population, behaviour, adoption and feedback can be monitored carefully to produce what in the end is a thoroughly tested application with just the right features. The services are funded by advertisements, yielding a cash flow of $billions.
• Google Apps for organisations (a.k.a. Google Apps for your Domain): Allows you to access some of Google's more mature products through an internet domain that you own. Targeted at smaller organisations (typically up to 25 people) and educational institutions, the applications can be branded with your own logo but are still funded by advertisements.
• Google Apps for Enterprise: A new service, to launch 2007Q1, this will be Google's entry into the SaaS market. No advertisements: you pay for the service (pricing is not public). The suite will comprise Gmail, Gtalk, Gcalendar and Gpage, but I would speculate that Gdocs is not far behind. I would expect this to be an attractive option (depending on pricing) for many fast-growing companies that don't want to run all of their own IT. But the service is not for organisations where it might be an issue that data sits on a shared server and you have no transparency as to which jurisdiction your email resides in.
• Google Apps for "serious" enterprises: Allows you to keep your data behind your firewall if you buy an appliance to install in your server farm. Currently search, Gdesktop, Gmaps and Google Earth are available in this flavour but I would expect to see the Google Apps for Enterprise components, Gdocs, Ganalytics, Blogger and Translate to eventually make it to this stage. That data stays behind the firewall seems to be taken seriously: Even the map data set for Google Maps and Earth can be stored locally so that snooping requests to the online data set becomes impossible. The big advantage of these tools is integration with existing data and respect for authorisation levels: Search the document collections residing in document management systems and use Google Earth or Maps to work with data that has a geospatial dimension.

(This is my own interpretation of Google's "product maturity market model" and the categories in bold above are made up names, except Google Apps for Enterprise.)

With an army of volunteer testers and a huge revenue stream from advertising, Google could become a powerful force in the enterprise office application market. Competitors could be left fighting ad-funded free-to-use software in the small business segment as well as thoroughly tested, market proven and familiar applications in the enterprise segment. Nice to see a long-term strategy at work.

Tags: Google enterprise adwords Google Enterprise software SaaS search office suite Gmail maps Google Earth strategy

The 10-to-1 rule of email project management: Follow up

In August of this year, I published some thoughts on how effective email is when it is used as the only or main communication tool for a project. The post became part of a discussion on multiple blogs so I shall try to pull the arguments together and provide my inchoate conclusion.

The piece was referenced by Konrad Marx, Stowe Boyd, Seth Gottlieb and Kurt Voelker. Stu Downes and Pranshu Jain left comments pointing out that collaboration solutions are still in an experimental phase compared to email. Paul Wilkinson points to an article he wrote in February 2006, questioning email capabilities of collaboration tools. Rodolpho Arruda adds that project manager certification focuses on controlling a project, not on collaborating within a project. Jim McGee points us to the danger in assuming that sent messages will be effectively received: "That is not a symmetry that can be safely assumed." Om Malik says that email is our "communication dashboard."

Anne Zelenka responds with a robust defense of email, saying that "email is good enough for most workers’ collaboration needs." She provides a convincing argument that email works better than many collaboration tools because is offers interoperability, personalised organisation, easy access control, and a single point of information access. I agree with many of Anne's points but I also accept Luis Suarez's view that email "is the worst thing that could have happened to Knowledge Management and remote collaboration [...]." John Tropea goes further by comparing closed systems with transparent ones and sharing a case study on email collaboration.

JP Rangaswami delights us with a taxonomy of enterprise email stereotypes, from the "iceberg lettuce" type to the "oops-I-did-it-again'ers" (the ones who habitually hit reply-all to wide distribution emails). He also agrees with Anne that email is a good enough collaboration tool, but for individuals not for teams in an enterprise.

Ed Yourdon published some of his thoughts about email at about the same time that I penned my 10-to-1 rule. In his superb post, he examines five hypotheses about email; one of them is whether email is broken or whether it is not being used the right way: "We never learned how to use the capabilities of email, and our behavior is akin to driving a car on the freeway at 60 mph in first gear."

Rod Boothby provides an illustration of "The Enterprise 2.0 Communication Continuum" and goes further to state three reasons for adopting collaboration tools that offer more than email:

• They create positive externalities because of transparency, context and the persistence of the content
• They increase the pace of internal innovation by providing what innovation creators need
• They provide a platform that can improve ad-hoc workflows

What are the conclusions? Discussions like this make me believe that we will find solutions in the fusion of paradigms and technologies that we presently see as conflicting.

Email is about messages and messages have proven useful for thousands of years. (Part of the reason that RSS is successful is that a feed can be presented as messages). Email software takes the strong conventions pertaining to messages and integrates them with the centuries old inbox paradigm - which itself was a way to transition from an industrial society to the information processing organisation by mimicking a conveyor belt. Altogether a very powerful concept which is the reason that email is how work gets done in today's businesses.

It is only for a decade or so that we have achieved the ability to work together in the new ways that we have started to call collaboration. Our challenge is to explore what we can do with collaboration while weaving into it the message style of communication. Messages and inboxes (a.k.a. email) are an undeniable part of the future, but as concepts they will be fused with transparent, discoverable, content-persistent, workflow-enhancing, buddy-list-integrated, taggable and action-supporting collaboration tools.

Tags: collaboration email email inbox project management collaborative workspaces