Drop the Pilot, Part 2

by Andrew McAfee on May 6, 2010

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.

  • http://twitter.com/stevebellnow Steve Bell

    Andrew, the simple sales pitch, to me, hits the spot. Too many times the larger E2.0 pitch falls on deaf ears. Make is simple so that a fifth grader can understand – and we have something that most internal organizations can wrap their arms around.

    For the larger enterprises – that 4th paragraph or point – maybe a bit scary, but it still is the right thing to do.

  • Ben

    Andrew,

    On the topic of drop the pilot and interesting stories you have shared, you might want to listen to the podcast of Vineet Nayar on Dan Mulhern radio show. He shared a lot of interesting unique new concepts on how they changed the performance review system. You might be interested to listen to this. http://www.vineetnayar.com/everyday-leadership-with-dan-mulhern/

  • http://www.jmorganmarketing.com jacobmorgan

    Hi Andrew,

    First of all thanks for the mention much appreciated. I originally had an idea of something that I wanted to call the modular enterprise (maybe) which basically allows for a phased approach of E2.0. Meaning instead of going for large E2.0 projects at once companies would have the option of gradually getting involved over time, still figuring out what those modules or phases would look like but I think it can be an affective approach.

    At the end you say “run this pilot” yet the title of the post is “drop the pilot,” I'm assuming one refers to a specific time frame whereas the other refers to the type of company distribution?

  • http://twitter.com/nigelfenwick NigelFenwick

    Hi Andrew,

    These are all excellent points.

    As for the pitch, one point I'd be concerned about is that it emphasizes deploying cheap technology and seeing what happens. I've seen more than one project of this nature derailed because there was a desire to deploy “cheap” technology instead of picking the right technology to satisfy the objectives.

    Having easy to use technology that allows people to self-correct is one important facet, but so too are things like the ability to build rich profiles and search them and the ability to create dynamic groups and informal networks – all of which you highlight in your book. Sometimes “cheap” does not translate into effective. As many people have written, E2.0 success is less dependent upon the technology than the leadership, people and culture – but having the wrong technology can sink a pilot or a full-blown roll-out before it has a chance to demonstrate success.

    This emphasis on cheap and cheerful also understates the level of support required to make E2.0 successful. It may well setup expectations that there will be few resources needed and that it will simply happen on its own. My suggestion would be to emphasize the fact that success will only come through a combination of top-down leadership and effective grass-roots evangelism. Highlighting the needs for dedicated support of one or more people focused on helping employees find ways to leverage the platform to solve real problems.

    What if deploying cheap results in a conclusion that it won't work? Was that because of the wrong technology or something else? With SaaS solutions the cost can be spread so that the price only increases as usage grows. So the emphasis can be on quality and value vs cheap.

  • http://twitter.com/MeganMurray Megan Murray

    Short response here on pilots as well as the simplified pitch. There simply is no one size fits all. No right, or wrong. Declarative absolutes don't work. Delivering E20 as the introduction of another set of new IT is a great way to get approval. It misses a huge part of the picture, obfuscates much of the support investment you'll need to do a good job of it (and will create another hurdle for you in getting that support when you need it), but simple always sells better than complicated. Particularly if your culture isn't inherently open to understanding how a social environment may change the organization, or its relationship with employees.

  • http://communities.cilip.org.uk/blogs/update/default.aspx Matthew Mezey

    Hi Andrew,

    I've just written a blog post 'Open Leadership + Enterprise 2.0: the practices that can make them real' that takes up the issue from those concluding comments in your book about the necessity of including Argyris-inspired 'sustained interventions' if Model 2/Enterprise 2.0 is to become a reality.

    It's here: http://bit.ly/bJraEV

    I guess this is the opposite end of the telescope from the quick pilots angle, yet somehow part of the same big picture…

    Matthew Mezey
    (Chartered Institute of Library and Information Professionals)

  • http://www.crystaladmiral.nl Crystal Admiral

    Thanks for sharing. This is very useful for the paper that I'm writing, so just wanted to say thank you rather than leaving anonymous.

  • http://andrewmcafee.org/blog amcafee

    Matthew, thanks for the sharp post. I encourage others to read it!

  • http://andrewmcafee.org/blog amcafee

    Matthew, thanks for the sharp post. I encourage others to read it!

  • http://www.facebook.com/profile.php?id=402377 Josh Dormont

    I think the argument about to pilot or not to pilot is unfortunately one-sided: you either have to agree or disagree. Why not both? In my most recent post I argue why a pilot is good for some tools and less good for others (following the logic of the circles of connectedness). http://wp.me/p1CWCg-2g

    As for the ‘imagine piloting a telephone’ concept, this is metaphor that provides a false sense of logic. The “fax machine law” is a basic principle in economics: the more people that have fax machines, the greater the value of the network of each one. That was the same with the telephone, so yes, there was no point in piloting the fax machine or the telephone. But not all web 2.0 tools are like phones or fax machines. More wikis isn’t better than one really good one. The value of a wiki doesn’t increase with each additional wiki, but rather increase with the addition of articles within a wiki. Better to pilot and learn from users than unleash a tool that could collapse on itself quite quickly.

Previous post:

Next post: