Drop the Pilot, Part 2

There were a bunch of particularly sharp comments in response to my recent post “Drop The Pilot,” which advocated universal (rather than limited) initial rollouts of Enterprise 2.0. These responses added so much to the ideas in the post that I thought they deserved a dedicated follow-up.

The first thing to acknowledge is that my post wasn’t anywhere near as original as I thought it was. Sociatext blogger and smartguy Michael Idinopulos wrote a post back in August  2009 titled “Skip the Pilot,” which made many of the same points I did. However, instead of screaming “plagarist” (not accurate; I hadn’t seen his post) or “derivate, unoriginal thinker!” (a lot more accurate, at least in this case), Michael graciously commented:

When I first blogged about this, (http://www.socialtext.com/blog/2009/08/enterpri…) some people thought I was nuts…

My observations, like yours, were firmly rooted in empirical observations of real-world implementations. Bigger implementations (relative to the size of the organization) just do better. It’s for precisely the reason you state: the serendipity that comes from network effects. Piloting social software is like speed-dating your friends. [I love this image. Another good one came from Simon Bostock, who  said “…you wouldn’t dream of piloting a telephone with a small team.”]

The strategy works; here’s just one recent example. We recently persuaded a large Socialtext client in the publishing industry to abandon a pilot-first strategy and launch enterprise-wide. They were glad they did. Their intended pilot audience showed adoption which was good, but not great. In the meantime, the rest of the company started using Socialtext to create all kinds of unintended interactions–finding colleagues, getting answers to exception-case questions, live-blogging trips into the field, organizing events. A lot of that would never have happened in a pilot-first scenario.

A Prem Kumar described his organization’s success after dropping the pilot:

We went in for the big kill back in mid 2006. Deployed a customized platform built on WordPress MU to be deployed org wide. We were 30-40 K heads back then, now we are ~80K. And still it functions. Quite well…. We have everyone, from the CEO to the fresher from College who joined a day ago, talking abt anything under the sun, not just business or technology. And this greatly lends to organizational story telling or the narrative, which elicits a wee bit more of the [tacit] knowledge than formal project documents. It also helps find the experts much more easily than the Outlook search.

And cflanagan17 wrote,

Andrew, I couldn’t agree more with dropping a “limited reach” pilot. As you know, CSC did run a pilot, but it was limited only in duration, not in audience. That meant any of our possible 92K+ employees could participate if they chose on an opt in basis. This allowed us to truly validate the viral nature, if in fact our strategy met the mark, and allowed us to watch collaboration patterns emerge… We created a multi-layer advocate program that included a top down and bottoms up approach. We emphasized self-service over a traditional centrally managed approach to communities. We seeded our environment with compelling business use cases prior to launch so users were greeted with real business groups and communities. And we also remembered the value of a “watercooler” in forging strong bonds across the globe. These practices, and more, combined to make the pilot so successful that the results truly demonstrated to our leadership how this could be used for business, solidifying our business case. Our users had clearly voted with their feet – and we had the data to prove it. It was an easy decision for our executive sponsors and CTO to continue funding operations into a “production contract”.

Roy Wilsker concurred with this approach:

As in Claire’s case, we also had a pilot that was limited only in duration, not in the number of users.

Calling it a pilot had pluses and minuses – the plus was that people felt less pressured to “get it right” right out of the box. Mistakes were acceptable (and expected). The minus was that some people were hesitant about committing lots of effort to a “pilot”.

The real life examples that came out of the pilot – and the tangible pleasure that people expressed about using the collaborative environment – made it much easier to convince management to embrace E 2.0 fully than I think it would have been had we simply jumped in with both feet.

cflanagan17 agreed that calling something a ‘pilot’ was a smart strategy: “Sometimes something needs to be called a pilot to get executive buy in. So labeling a phase a pilot is a clear way to signal to your company (and perhaps even your vendor) that you really are in a trial stage where the commitment, risk and investment are limited. That is often a huge way to start something sooner while a larger business case is evaluated. So I think the label of a “pilot” has very strong political meaning…” Michaelbierly evidently agrees with this; he  wrote: “will [not having a ‘pilot’] work? not in a typical corporation. Too much culture to change on decision making around IT to say we aren’t going to pilot.”

Bertrand Duperrin crystallized this insight with a useful distinction:

First we have to define what a pilot is. It’s clear that not everyone gives it the same meaning and it does not always have the same purpose. In some cases it’s an experimentation that can be shut down at any time, in some other it’s more like a “time to learn” before scaling up.

Stephen Jordan suggested a smart addition to my 6-step program for E2.0 adoption success

I think there is one critical missing piece here, and it deserves its own bullet, perhaps above all others. “Provide some context for using the new tool that gives the user base a reason to connect and collaborate”… Consider launching a “going green” challenge, and stand up ideation software, or a discussion forum or microblog in a community framework, calling for ideas and discussion about how an organization can green its operations. Make the tool a transparent part of the experience and bring the web inside the firewall for your users…

If an organization can provide the context for using a tool, do it for free (or very little “i”), and bolt on the various components to facilitate the conversation (ideas, blogs, wikis, microblogs, etc.), it can walk a much larger portion of its workforce down the path to 2.0 without the users even knowing they’re along for the ride.

However, some commenters felt that pilots were in fact valuable. This sharp comment came from Christy Schoon:

…When a customer enters into a narrow-scope pilot to prove adoption, ROI, or business results they will fail. On that point I completely agree. Where I disagree is that companies should drop the pilot all together. There are two purposes for a pilot that can be important: proving the technology within their IT infrastructure and learning some lessons about their users and themselves.

…Every organization’s IT infrastructure has its quirks and not a single one is exactly like another. Running a short technology-focused pilot can help identify potential issues ahead of time that can then potentially be addressed (or you find another vendor).

The second reason for a pilot is to make some mistakes and learn some lessons with a small subset of your users. During the course of a small pilot you’d be surprised what you can learn, especially by making mistakes. I’m not suggesting that mistakes should be made on purpose, but at the end of the pilot, survey the participants and find out what went well, what didn’t, and study the system-generated metrics. From that data you can learn how to best communicate, educate, and deliver value, not to mention which tools in your arsenal you may want to roll out first. [Christy’s whitepaper on E2.0 pilots is available here (download available after supplying personal information)]

sanjeekval, whose question prompted the original post, agrees with Christy. He wrote:

… I still think a pilot is the way to go (will drop the SMALL pilot part) The biggest benefit, it gives us a platform to experiment without much of an “approval” process. Having a base of 500++ (will be 1000 going almost to 1000) gives us a platform to experiment and get data on points 5 and 6 mentioned by Andy above. Once we do that, we will (and can) tie it in with a top-down strategy as well (that includes a governance framework, defines success criteria etc)

Sanchezjb took the strongest stance in favor of traditional pilot projects:

I respectfully disagree with your call for “Enterprise 2.0 enthusiasts [to] abandon pilots and go as broad as possible right away.” Properly structured and executed pilot projects are important. The “six steps” in your post are good ones (no disagreement there but I suggest swapping #3 and #4; and amend #5 to state “Monitor usage and outcomes, evaluate, and make adjustments …”). They should also reflect the critical need for pilot projects to identify what the expected outcomes are and get agreement on those outcomes from the relevant stakeholders. Failure to do this will almost certainly doom a pilot and the maxim of “Beg for forgiveness later” may not suffice.

The value of Enterprise 2.0 technologies like social media is still questioned in alot of places. Failing to demonstrate success with a “broad project” could curtail an organization’s willingness to do invest any further in Enterprise 2.0.

But Jacobmorgan cautions against dressing up Enterprise 2.0 too much:

I think a lot of E2.0 practitioners have been making E2.0 sound extremely complex and daunting to the point of scaring interested companies.

I think this is a good point, and I find myself favoring a low-key and simple Enterprise 2.0 sales pitch that goes something like:

We’re going to deploy some cheap technology that makes it extremely easy for anyone to share information throughout the company. We anticipate that people will use it to post insights, point to good content, ask questions, and tell their colleagues what they’re working on, what they’re seeing, and what they’re learning.

We’ll recruit an initial set of regular contributors, drawn from both high and low places in the company, and including both formal and informal leaders.

Rather than coming up with and issuing detailed guidelines and policy statements, we’re instead going to trust our employees and make it easy to correct mistakes instead of hard to make them. We’ll monitor contributions, and if anyone misuses the technology we’ll learn about it quickly and take corrective action.

We’re going to run this pilot for x months, at the end of which we’ll report back to you with lessons learned and benefits received.

What do you think? Is this the right E2.0 sales pitch? Is it missing anything critical? Would it work in your organization? Leave a comment, please, and let us know.