Drop The Pilot

by Andrew McAfee on April 22, 2010

I was talking about Enterprise 2.0 with the management team of a large publishing company a little while back, hitting all the familiar topics: ROI, risks and threats, whether Millennials really are different than older workers, and so on. As I listened to their questions and comments, though, I heard another topic emerge, one that I realized I’d been hearing about for a while in one form or another without directly addressing or acknowledging it. This was the underwhelming result of most pilot projects, and the difficulties this posed to E2.0’s champions.

I’ve been hearing a lot of comments that go something like:

My company is interested in Enterprise 2.0 and I believe in it, so I got put on the team to prove the concept. We set up a pilot project where one team / division / business unit got software for collaborative editing / social networking / blogging / etc.. And the results so far have been…  unimpressive. There’s not a massive amount of activity, it doesn’t feel like it’s gaining momentum, and there aren’t clear success stories that I can point to in order to convince the sponsor / the skeptics that E2.0 works for us. What are we doing wrong? What should we do from here?

Let’s take that first question first. I believe these kinds of pilots are unintentionally set up to fail, or at least underwhelm. This is essentially because they contain too few people, most of whom know each other too well.

The more I learn about and think about the value of emergent social software platforms, the more I suspect that the deep meta-benefit they provide is technology-enabled serendipity, defined as ‘good luck in making unexpected and fortunate discoveries.’ Serendipity is possible when we’re collaborating with our close colleagues on a well-defined project, but that’s probably when it occurs least often. It’s much more likely during wide forays and broad searches, the kind that are so easy to do with current technologies.

I think serendipity is part of what underlies Metcalfe’s Law and a big part of the explanation for Eric Raymond’s insight that ‘given enough eyeballs, all bugs are shallow.’ Knowledge workers and their organizations should be doing everything possible to increase opportunities for serendipity. This means searching broadly for information, narrating work so that others can become aware of it, asking questions to the biggest possible audience without presupposing who might have the answers, and generally contributing to and drawing from the biggest possible digital commons. This is what Enterprise 2.0 should be all about.

How many of us have found great information in some weird corner of the Web, someplace far from the presumed authorities? How many have had a question answered on Twitter by a stranger? Received unexpected praise or good wishes on Facebook or LinkedIn from someone we hadn’t thought of in a while? The smaller the scale of an ESSP deployment, the less likely all these good things become.

These realizations lead to an answer to the second question posed above. Enterprise 2.0 enthusiasts should abandon pilots and go as broad as possible right away. The risks of doing this are small and manageable, and the serendipitous benefits are many.

Here’s a simple high-level E2.0 rollout plan that abandons the idea of small pilot projects and instead opens wide the doors to good luck, long-distance helpfulness, and fortunate discoveries. And it’s only six steps long! ;)

  1. Deploy tools that deliver a novel capability, like microblogging, social network formation, or prediction markets. Tools that deliver something novel — that aren’t trying to displace an incumbent — avoid the 9X effect.
  2. Make sure the tools are frictionless, freeform, and emergent. This lowers barriers to participation and altruism.
  3. Give them to everybody with just enough policy-setting to satisfy the people who concern themselves with compliance, risk, and security.
  4. Get a group of both formal and informal leaders to be heavy initial contributors. They’ll draw in others quickly.
  5. Monitor usage over time and make adjustments if and when necessary (for example, if conversations descend into flame wars or anyone’s tone becomes inappropriate or unprofessional).
  6. Collect examples of the good stuff that happens. Use these to justify the project, satisfy the sponsor / boss, and evangelize.

What do you think? Will this work –  will it attract usage, deliver results, and not lead to disaster? Am I missing anything important? If this isn’t a viable blueprint for getting started with E2.0, why not? Leave a comment, please, and let us know.

  • cflanagan17

    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 approached the pilot with the same organization change rigor we would have as if it were “production”. We paid close attention to planning for adoption. 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”.

  • artmurray

    I agree that pilots, being narrow and deep, put a lid on emergence. So going broad is definitely better. I think over time the word “pilot” emerged into a buzzword because it made management feel safe. But the risks from choking off innovation could be even greater. I like the six steps you've outlined – they establish simple ground rules and clear boundaries. I'm willing to go that way, but may still call it a “pilot” in some cases in order to provide comfort to the risk-averse…

  • cflanagan17

    Art, you raise a good point. 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 for the reasons you mention.

    Now we just need to educate the evangelists, who run these programs internally how to sell the scale and scope differently to measure true emergency and true success.

  • http://twitter.com/BFchirpy Simon Bostock

    Totally agree. We're so used to people asking for scalable solutions and asking the question, “Will it scale?” that we forget that scale works in both directions. It's counter-intuitive to have to ask, “Will this E2.0 stuff scale, erm, down?”

    I think many organisations are so locked into seeing 'scale' on the output side of the equation they struggle to see it as the critical success factor it is. It's slightly trite, but you wouldn't dream of piloting a telephone with a small team.

    Why are organisations like this? I think they still haven't come to terms with the fact that – for the first time ever – the technology available in the enterprise is lagging behind consumer tech. So they're still looking for monolithic solutions – and, let's face it, some of the dinosaurs need the quarantine that pilots can provide.

    Art and cflanagan17, I think there's also the issue of Escalation Bias. I can't get rid of my Blackberry despite it being massively inferior to other smart phones. I'm trying to get my money's worth. A pilot limited in time might work better than a pilot limited in size.

    Lastly, Michael Idinopulos (from SocialText) has written some good stuff about this same issue:

  • http://enterprise20.squarespace.com Saqib Ali

    Prof McAfee,

    I super totally agree with you. But what about Escalation Bias as defined by Barry Staw:

    “[W]ithin investment decision contexts, negative consequences may actually cause decision makers to increase the commitment of resources and undergo the risk of further negative consequences” (Staw, 1976)

    Would like to hear your thoughts on this……

  • http://caddellinsightgroup.com jmcaddell

    Nice Joan Armatrading allusion!

  • lauriebuczek

    I agree with not limited the use of these technologies. They fundamentally require the network effect in order for value to be received. I evangelize that the best social tools don't make a social enterprise if you apply them over a silo. With that being said, that is a huge paradigm shift. It flies in the face of how enterprises have collaborated for years. I am finding that shifting the collaborative model is like pushing a boulder uphill. Finding frictionless capabilities would be a much easier route to introduce Enterprise 2.0 within a corporation. I think your six steps are solid advice.

  • http://twitter.com/Rwilsker Roy Wilsker

    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.

    Finally, being able to say “the pilot's over – we're in production now!” has been energizing (if also slightly terrifying) for all of the core group that's been working on this project.

  • sunnylim

    On the first point, about small pilot, I believe depends on the what you are piloting. Enterprise Wiki for example, I would think that a small pilot is more beneficial because the team knows and trust each other. Hence they do not have to worry about any inappropriate content that might go into the wiki. In additional, if the Wiki is project or work related, it can be used to demonstrate to the organisation how is co-authoring on a wiki is more productive and efficient as compared to sending emails with attachment. With such demonstration that it works, then it will be easier to convince both management and employees of its benefits (because it has a working example) and adoption. Apologies, my experience so far have been limited to Enterprise Wikis so I can't comment about E2.0 Tools. Professor Andrew, thanks for your book Enterprise 2.0, I enjoyed reading it :)

  • sanchezjb

    Andrew, I don't know the full context of the example that you cited at the beginning of your post. However, one challenge, and a potentially significant one at that, is that the pilot's objectives were not clearly established and agreed upon at the beginning.

    The comment states: “We set up a pilot project where one team / division / business unit got software for collaborative editing / social networking / blogging / etc..” “Collaborative editing / social networking / blogging / etc.” should be viewed as the means to achieve one or more outcomes.

    Was a specific “Enterprise 2.0″ end-state defined for this specific organization? Were one or more outcomes associated with this end-state clearly established? Were performance measures established for these outcomes? Were the data and/or information sources for these performance measures identified? Given that it appears this pilot was focused on enabling improved collaboration (“collaborative editing”), was a governance framework established to facilitate this collaboration? Perhaps, most importantly, did key stakeholders agree on all this prior to the pilot beginning? There are more questions but these are some of the important ones.

    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. Further downstream, that lack of investment could negatively impact that organization's market competitiveness.

    Lastly, good pilot projects and the identification and incorporation of “Lessons Learned” (both good and bad ones) can serves as the basis for an organization to become a knowledge-focused learning organization – an important attribute of Enterprise 2.0 organizations.

  • michaelido

    Andy, this is a great post and excellent advise. When I first blogged about this, (http://www.socialtext.com/blog/2009/08/enterpri…) some people thought I was nuts. A few suggested that I was just trying to sell more Socialtext licenses.

    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.

    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.

  • http://twitter.com/mbuyens Marc Buyens

    A valid observation you make and correct conclusions. Solutions such as enterprise social networks do need a certain critical mass to be able to deliver on their promises. At least, they must enable participants to reach beyond the boundaries of their own team, department, division or local office, because only then, the potential to “make unexpected and fortunate discoveries” exists.

    However, serendipity only cannot be an objective. As the “good luck in making unexpected and fortunate discoveries” description suggests, this is not a guaranteed deliverable. You might get it, but most often, you don’t.

    During our own use of social tools, we were lucky enough of having a few of these unexpected and fortunate moments. They didn’t make us rich, but they enriched our life.

    However, what was the investment in time and effort to get to these moments? How many hours, days, months were we using these tools before getting the “aha” moment?

    Getting the buy-in of participants and keeping them engaged sufficiently long enough to get to this “tipping point” requires that the solution adds sufficient value for the down to earth, day to day basic tasks. Delivering immediate value “in the flow”.

    Without that value, people get frustrated, demotivated, they lose interest. Deliver value in the flow and they might stick with you long enough to experience the “unexpected and fortunate discoveries”. But do not make serendipity a business model.

  • http://www.duperrin.com/english Bertrand Duperrin

    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. Limitation of people and / or duration are amon the issues but are not the only ones.

    It also appears that the underlying assumption is that pilots are made only for over “over the flox” experimentations.

    You can also socialize teams or “organic group” in the workplace whose size is limited by definition and whose success will be driven but the existence of a clear, shared, common purpose. I usually call it “sense and alignment”.

    It also depends on the company's culture : some are more likely to start with in-the-flow things because it sounds more like “real work” while some are ready to embrace a “full social experience”.

    In my opinion a comprehensive enterprise 2.0 pilot should include both because companies also have to learn how to articulate. Small purpose driven groups and large interest-driven communties and networks, people being supposed to be a part of both depending on sense and their desire to expose themselves or not.

  • sanchezjb

    “Holding Social Media Marketing's Feet to the Fire” @ http://ow.ly/1CIVf echoes points that I advocated in my earlier comment. While “Feet to the Fire” (One way to stifle innovation!) is probably not the best phrase here (“Accountable” would be better), “It's time to set objectives for…social media marketing efforts, measure the results, and refine programs accordingly.”

  • http://twitter.com/yatman Yatman Lai

    Solid advice. This maybe why most successful web2.0 technologies in Enterprise are viral, vs. the structured deployment which IT dept. favors. #yam

  • http://www.jmorganmarketing.com jacobmorgan

    An interesting discussion. I think we can all agree on two points though:
    1) social platforms need large numbers (scale) to really show value
    2) most companies are not going to deploy broad E2.0 initiatives without a pilot or some sort of proof that it will work.

    The cost of broad deployment tools is not cheap, take EMC that is spending somewhere around 600k/annually on their Jive deployment alone. Software vendors in the space are charging a pretty penny and they know it.

    I'm a bit curious of the conversations you are having when you say they are interested in Enterprise 2.0. I usually come across conversations that address a business problem and in my case studies around Vistaprint and Oce neither company referred to what they were doing as E2.0, they were out to solve a business problem and E2.0 tools and ideas just happened to be the solution.

    While I agree that the pilot programs can hurt the success of an E2.0 program I think the reality within the enterprise forces us to figure out another solution other than a broad deployment that may or not be expensive and/or work. 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'm trying to come up with a modular/phased approached to E2.0 that doesn't involve a “change now or die” mantra.

    I'm curious to hear more about the discussions you are having, what people are asking for, and what you are seeing.

  • http://scorpfromhell.blogspot.com A. Prem Kumar

    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 did not label it Enterprise 2.0, nor do we now. 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 tactic knowledge than formal project documents. It also helps find the experts much more easily than the Outlook search. Just two examples out of the various other benefits we have had. Our costs are the hardware & the small team maintaining, supporting & enhancing the platform.

  • sanjeevkal

    Its likely that the company behind the posting of Drop the Pilot likely refers to my organization and if so the person asking the question was me.

    First off, I do want to say that I agree 100% with Andy; in that serendipity is probably least achieved when collaborating with close colleagues. Also, while this might have been somewhat intentional on my part; the topic of discussion with Andy did pique the interest of several of my colleagues so much as to rapidly grow the usage of our social collaboration “experiment” from a 40 user footprint to over 500 users in 1 week!! (and it likely will hit 1000 in a few weeks)
    While it is too early to tell, there clearly has been a significant amount of interaction, collaboration and interest in the platform where people can micro blog, share and collaborate. Large groups do result in more social collaboration thus increasing the probability of finding “serendipity”

    I do respectfully disagree with a reader below who was questioning our pilot approach, particularly on the methodology of the deployment; ie “were the goals defined, end-state of Enterprise 2.0, governance framework established etc” While all of those are worthy questions to answer, investing in effort and cost for a top-down strategic approach for e2.0 collaboration would have been DOA. And to answer them effectively an organization will need a top down approach with multiple stakeholders involved vs. an evangelist acting with a few other colleagues.

    However, 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)

    Also enterprise social collaboration is only 1 piece that might constitute a larger intranet strategy (something that we might embark on) The governance and success criteria for us will likely not be limited to enterprise social collaboration tools but on Enterprise Collaboration as a whole (again social just being 1 element of it)

    I do want to thank Andy for the presentation that clearly was the stimulus for a larger user base with our experiment. As mentioned above we are at point #4 currently and are working to institute some formal “good stuff” collection mechanisms. Any thoughts/ideas on this would be great.

  • http://twitter.com/junkfishjordan Stephen Jordan

    Andy, I have a lot of things to add here but think it would take a separate blog post to address some of them (what was the ROI on email, and isn't the value proposition of 2.0 about getting people OUT of email despite “impressive” Outlook/Notes adoption stats?). However, specific to your request for comments, I might add the following:

    1. To avoid wasting time on ROI discussions, agree that if you can't promise a return, you will not ask for a monetary investment. So, adding on to your first numbered point, “implement something that is free and open source if it is available and use internal, passionate IT resources to build and deploy”. If it is successful and becomes an enterprise production platform down the road, perhaps companies could spend a tiny fraction of what they WOULD have spent otherwise and donate to the developers of the FOSS tools.

    2. 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”. Admitting I have a bias towards idea management because of my background, I think ideation and social problem solving is a great place to start. 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. IMHO, the lack of context in these “pilot” rollouts is the real reason they seemed doom to fail (if enterprise adoption is your success criteria, which, by the way, I'd question).

    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.

  • http://twitter.com/nigelfenwick NigelFenwick

    I agree Andy.

    Running a pilot has been the accepted wisdom for so long it's challenging to shift people's thinking. Yet a pilot is often viewed as the best way to prove the potential for ROI. As you point out scale matters and so does broad adoption.

    I recently wrote a case study on a successful rollout by an organization of 6000+ employees spread across many different subsidiaries. They achieved ~80% adoption within twelve months but only on the second time around. The first deployment was a failure in part because the technology didn't support the needs of a successful community and in part because the roll-out was not driven by on-going internal marketing.

    The lessons learned boil down to three essential elements required for success:
    1. Ownership by the CEO: being willing to drive by example and holding business unit owners accountable for adoption within their own lines of business.
    2. Hiring a manager whose sole role was to drive adoption and publicize wins. This person found people/teams who could benefit with tangible business results and got them involved. He then encouraged them to share their success stories.
    3. Getting the right technology in place to remove technology obstacles to adoption. (i.e. make it easy ).

  • Greg2dot0

    At Alcatel-Lucent, we JUST launched our Community platform. This platform was originally scheduled to be a pilot, but was delayed. Demand was so strong that we decided to drop the pilot and go full, global launch. We launched on April 6, 2010 and as of today (4/29) we have almost 2,900 users.

    The most important thing in my experience is to have a vision and coach people through that vision both in planning and execution. As more people share the vision, it's easier to build the support.

    While people are still “kicking the tires”, we are starting to see real business problems being solved which are the “success stories” used to justify the platform and future expense (all within 3 short weeks).

  • sanjeevkal

    Greg, Can you describe a bit more on what kind of forums you are using to figure out that real biz problems are being solved and articulating/quantifying “success stories”. One option is to use the social platform/framework in itself to crowd source the ideas. But did you deploy other frameworks…setup a forum of cross-functional group to observe,monitor and recommend etc.?

  • http://twitter.com/christyschoon Christy Schoon

    Don’t drop the pilot just make sure you are running it for the right reasons. At NewsGator I have worked on 30+ pilots with F500 customers across multiple verticals and some truths hold steady no matter the organization. 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.

    NewsGator has come into some organizations after other vendors have failed strictly from a technology perspective. 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.

    So Mr. McAfee, I agree with your points while I disagree with your call to action. Organizations should run their pilots but do it for the right reasons. If they are interested in how to run an effective E2.0 pilot they can check out my whitepaper at http://bit.ly/9dk1zk.

  • michaelbierly

    will this work? not in a typical corporation. Too much culture to change on decision making around IT to say we aren't going to pilot.

  • Greg2dot0

    I feel that my job in part is around helping others understand the business possibilities of E2.0 platforms. We have more or less let the crowd explore and try (and fail), but again, it's still WAY early. Think about 2,900 all moving into a new house and you imagine the chaos that ensues

  • http://andrewmcafee.org/blog amcafee

    It's actually a Kaiser Wilhelm / Otto von Bismarck reference…: http://www.phrases.org.uk/bulletin_board/54/mes

  • shariffdinah

    This is what I like to read:”Knowledge workers and their organizations should be doing everything possible to increase opportunities for serendipity. This means searching broadly for information, narrating work so that others can become aware of it, asking questions to the biggest possible audience without presupposing who might have the answers, and generally contributing to and drawing from the biggest possible digital commons. This is what Enterprise 2.0 should be all about.”
    I did my dissertation on Knowledge Management, I could not agree more.
    Keep the ideas flowing!

  • http://andrewmcafee.org/2010/05/drop-the-pilot-part-2/ Drop the Pilot, Part 2 : Andrew McAfee’s Blog

    [...] 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 [...]

  • http://blog.inmagic.com Phil Green

    Andy, I agree with your premise to “drop the pilot,” but for very different reasons. Companies do not care one iota about pilots. They care about achieving business objectives and finding answers to the problems they are experiencing, including growing sales, reducing costs, speeding product innovation cycles, accelerating time to market, and so on.

    Lack of focus is the #1 reason pilots and/or E2.0 rollouts fail. Let me give you an example. I was speaking to a prospect last week and they mentioned that they went through an exhaustive selection process, purchased an E2.0 collaboration platform, and launched it with great fanfare. The immediate result was massive usage for the first month, and then a very rapid decline in usage, so much so that the system was scrapped.

    When we asked who the system was targeted at, the answer was “everyone.” When we asked what the focus of the system was, the answer was “everything.” Let’s get down to brass tacks. The question employees face every day is, does this tool help me do my job better? If the answer is yes, then they will use it. If not, they won’t.

    Does a pilot solve this problem? Stephen Jordan hit the nail on the head when he said, “… the lack of context in these ‘pilot’ roll outs is the real reason they seemed doom to fail.” So, no, the pilot, per se, does not help this problem.

    Is there an alternative? I would unequivocally say YES. It is called an initial “targeted project.” The targeted project has a lot in common with a pilot. Initial cost is low, it is usually focused on a smaller set of users, it allows the organization to vet the technology and IT infrastructure issues, and the organization can learn a ton.

    But here’s what makes it so much better than a pilot. Rather than entering into a short-lived pilot where expectations are set for an over 50-percent failure rate, a targeted project gets much deeper commitment because a) it is not a test, it is a real implementation, and b) it is focused.

    The E2.0 solution is tasked to solve a real problem and make it easier for a group of employees to do their jobs. The focus also means the implementation team knows where to invest its time and effort. If it helps the business objective, do it. Otherwise the feedback and other ideas can be attended to later.

    Phil Green
    CTO, Inmagic

  • fashionphotographer

    Shimmer Modeling and Productions Offering model management services, fashion model management, fashion event management, fashion show organizers, female model agency, male model agency, fashion photography shoot, professional photography shoot management. Visit now for more information:

    photographer in delhi

  • http://www.yaxislive.com Rajesh Kumar

    I think I quite agree to the 'move forward, don't wait' emphasis that one finds in this article.

  • http://twitter.com/SteveCogan Steve Cogan

    To #3 the best comment I've heard to far is to treat enterprise social commentary/micro-blogging as akin to 'corridor conversations' (for a UK audience, rather than 'water-cooler'…).

    #6 to me speaks to ROI and also enagement with the 'whats-in-it-for-me?' question.

  • philsimonsystems

    The short answer is that the success of pilots depends on what an organization is trying to do, the industry, its culture, and myriad other factors.

    My own thoughts on the matter:


  • Charlie Bess

    Although you may be able to drop the pilot, you can't drop the measurement aspects of business value delivery. It's a business not a hobby so you must do more than just hope that something good will happen. You must also measure progress to objectives. That's one area I see many in the Enterprise 2.0 community loosing their way.

  • Charlie Bess

    Although you may be able to drop the pilot, you can't drop the measurement aspects of business value delivery. It's a business not a hobby so you must do more than just hope that something good will happen. You must also measure progress to objectives. That's one area I see many in the Enterprise 2.0 community loosing their way.

  • http://www.socialenterprise.it/index.php/2010/04/23/enterprise-2-0-pilot-si-o-no/ Enterprise 2.0 pilot si o no?

    [...] qualcuno di voi avrà già letto l’interessante post Drop the Pilot in cui Andrew McAfee, padre fondatore dell’Enterprise 2.0, muove pesanti critiche [...]

  • http://www.justmobilephone.com RedSnow

    will this work? not in a typical corporation. Too much culture to change on decision making around IT to say we aren’t going to pilot. 

Previous post:

Next post: