My previous post, Skip the buy-in and get ’em addicted, is about using a Proof of Concept and beyond model as a fast track to your fulfilling your vision. A way to penetrate the hierarchy in an unorthodox way, and get them to "feel it" and see living proof of it’s usefulness, rather than a Powerpoint pitch, or proposal document (or as living proof of your proposal).
It’s cheeky, but you are doing them a favour at the same time, as you have living contextual proof of the viability (by going ahead and doing it yourself), as opposed to buy-in approval, strategies, time, more time, and some more time…only to not get approved.
The decision-making doesn’t have to be bottom-up, perhaps management agree with a no-cost Proof of Concept as part of the strategy, this is a win for them as they are able to experiment and fail for free, something that was not possible in the enterprise tool arena a couple of years ago. Free hosted sites like Yammer for micro-blogging, and others for blogging, wikis, bookmarking, etc…make all this possible…a move from the Albatross to the Salmon.
The ease of Proof of Concept using social tools is an example of Dave Snowden’s Safe-Fail concept; Clay Shirky also talks of experimentation and low cost failure. Clay talks about organisational costs getting in the way of experimenting and finding the most optimal road. Rather we except sub-standard roads based on them being less risky and more predictable…not really the agile road to innovation at all.
“…most organisations attempt to reduce the effect of failure by reducing its likelihood [and cost].
Imagine that you are spearheading an effort for a firm that wants to become more innovative. You are given a list of promising but speculative ideas, and you have to choose some subset of them for investment. You thus have to guess the likelihood of success or failure for each project.
The obvious problem is that no one knows for certain what will succeed and what will fail. A less obvious but potentially more significant problem is that the possible value of various projects is unconnected to anything their designers say about them…in these circumstances, you will inevitably green-light failures and pass on potential successes. Worse still, more people will remember you saying yes to a failure than saying no to a radical but promising idea.
Given this asymmetry, you will be pushed to make safe choices, thus systematically undermining the rationale for trying to be more innovative in the first place”
But now with social tools you can experiment many options, which in the end is less risky as you are doing what you propose but at a low cost, if not free. What more would a manager want…they don’t have to predict the worthiness, they can see it and taste it. In economics this is collapsing the "opportunity cost".
The other important point is "emergence". You really don’t know what unexpected behaviours/uses may surface unless some experimentation happens. A product is not it’s design, a product is how it’s used. Just look at Twitter; it’s original intention/design was SMS text messaging, but look how it’s being used now; SMS is probably the least way people use it. And look how many different ways you can access it; 3rd party web, apps, toolbars, system tray,etc..And look at the new core features like, re-tweets and mentions, that have been incorporated into the design because people were using it this way. And look at all the use cases, originally it was about sharing what you are doing at that moment, now it’s being used as a customer service and promotions tool by the biggest companies on the planet…personally I use it for research, sharing links, getting help, and talking to rockstar consultants.
Imagine a project like Twitter was given the red-light as it seemed too risky, or other projects seemed less risky. We don’t even know the impact of the initial features and conceptual use case till we use it, let alone all that emergence (it manifests/has it’s own life…a teme).
[ADDED 12/05/2010: Some of the unexpected ways Twitter is being used may be an example of Exaptation]
Proof of Concept is kind of similar to the idea of a pilot or even a prototype…you do something light weight and on a small scale.
But is a pilot different to experimentation?
Pilots are not about feasibility, aren’t they just the stage before release?
Usually pilots are more official. A product has been chosen, there is a strategy behind it, and the pilot is simply an early run before launching to make sure everything is working OK. But prior to this, did you experiment with other products, or did you choose the less risky or what seems as the more appropriate?
Is experimentation the stage before a pilot or is it an alternative to pilots?
The labels "experimentation" and "pilots" are sometimes interchanged. A while back at work I made a request to use a micro-blogging tool from our current content management vendor. There were many meetings (plans, security papers signed for hosted data) and away I went. I was given the product and invited a group of people to use it. At the time this product was performing badly (pretty much alpha stage so we didn’t take it further). But if it became a successful run we may have decided to purchase it, but from the beginning this was not the explicit intention, rather it was to have a go and see what it does (we did not have any strategy documents or a roadmap).
So did we run a pilot or experiment?
Does the fact that it wasn’t open to everyone have any weight on this distinction? Maybe, because of the low numbers it was a more controlled experiment, rather than a pilot?
Maybe it was an experiment because we had not bought the product as of yet, there was no strategy or roadmap?
Or maybe it was "experimentation" because it was bottom-up, rather than a top-down strategy. But I do not see why top-down ideas cannot be experimented, rather than deciding and planning on one path of action.
The context of pilots, and groups vs networks
You can pilot a Community of Practice (CoP) to get an idea of how a group works and coordinates in this new environment. All you need is a group of people to manifest the concept. And then we imagine it’s success would work for other types of groups…not always the case.
A good idea in your pilot would be to run a few different types of groups, to showcase the flexibility of these tools, and how their unstructured nature lends to different use cases ie. these tools aren’t necessarily used in one way, like an ATM machine is designed to be used one way.
One thing you can’t measure or see the benefits in piloting group spaces is see the value that visitors get from your community. Visitors to your community may ask questions, or provide answers, or read a wiki page or blog post and utilise that information. I say this because a pilot is a small scale, which means you ’aint gonna have many visitors, unless they are members of another CoP within the pilot.
I guess what I’m saying is that a pilot will not show the signs of cross CoP action. It will not demonstrate awareness and communication across groups…you know that silo bridging thing.
Just to be thorough when it comes to another dynamic like social networks, a pilot really isn’t as useful.
Unlike group spaces, social networks rely on network effects to reveal their usefulness and emergent nature.
eg. your telephone becomes more useful when someone else gets a new phone (ie. they join the network). A pilot with 5 people isn’t going to show the potential benefits and use cases that emerge when everyone is connected.
eg. Same goes with Facebook, etc. When I’m connected enterprise-wide I can see tag clouds, I get recommendations, I can see who is connected to who, serendipity will lead me to useful content by someone I don’t know but need to know…critical mass is needed for optimal emergence or gifts you receive from taking part in the system.
Andy Mcafee in his Drop the pilot post talks about the limitation of pilots in the context of social networks. Themes I got out of it are: #emergence #serendipity #awareness #diversity
From this post:
|"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."
For more on this see my post, Do group tools get more traction due to not requiring network effects and being in the context of certainty, which was inspired by a couple of posts by Michael Idinopulos called Skip the Pilot, and Launch E2.0 broad, then go deep.
Microblogging as a Stepping stone
In the latter link Michael talks about low threshold participation tools like micro-messaging as a stepping stone to higher effort tools. And he is serious about this as the company he works for, Socialtext, have their micro-blogging product, "Signals", both within the social software suite offering, and also as a standalone product. Michael says:
"Signals was not just a useful tool, it was also a stepping stone that helped participants move to the right on the Participation curve (see image above). As participants started to get the hang of Signals, many started to ask about Socialtext’s other collaborative features: What are workspaces? How do I use the Dashboard? How do I look up an individual?
After the webinar was over, a number of users wanted to go deeper by creating wiki workspaces to collaborate on tasks, projects, documentation, etc. We scheduled follow-up time with them to understand their collaborative needs and build tailored solutions.
This story describes a launch approach that simultaneously achieves seemingly conflicting objectives:
Pilots as learning stage
A post by Bertrand Duperrin about the Enterprise 2.0 Forum relates to pilots being about learning (rather than testing) before the official release, which is different to experimentation where something has just been made available, and is more about trying and testing:
"It’s not a game anymore. Now projects are global and carried by the top management. That’s the end of social bubbles disconnected from reality. Companies think global and pilots are not made to test but are the learning stage before global rollout. I really appreciated Claire Flanagan’s approach that set a time limit (5 month) instead of limiting the number of users what allowed her to quickly get a critical mass (nearly 30 000 users) with an opt-in policy."
In another post Bertrand reinforces this point:
"The purpose is not to decide to carry on or not but to learn what will be needed to drive the program at a wider scale later
Bertrand also mentions not to throw the baby out with the bath water, that we have to learn from failure, that failure is part of the path. An analogy of a car is quoted:
|"…if a car does not function it’s not because the concept of a car is bad, but because either the fuel is not good, the transmission is brocken or the engine is not well set."|
I often say that just say someone new to a vegetarian diet finds themselves not feeling very well, it doesn’t mean the vegetarian diet as a lifestyle is wrong, it just means that person was not very good at being one as they were not aware of all the food groups they need to cover to be healthy. Maybe they were not eating enough foods with vitamin B12, they can learn from failure and keep going on their new path.
Bertrand then says something related to the Clay Shirky excerpt at the start of this post, and that’s the notion of "risk"…and the use of the word "experiment" may have bad connotations (as does the word "social" in a business context), where usually business decisions are very carefully thought out to minimise risk
|"We can be sure that employee will think, even unconsciously “I’m fed up with all their crazes…I won’t buy before it’s definitive and official…no time to waste
for something than can be shut down at any time…being a part of it may expose me and it may be a bad idea if the project goes wrong”. I already heard an employee
saying “experimentation…do they think we are guinea-pigs ?”. Explaining that the experimentation is not “on” them but “with” them is easy…but never happens.
Anyway, we must be aware that this word means lack of visibility and indecision, what is not reassuring when trying to engage employees."
Bertrand goes on to compare this to pilots where it’s not about feasibility, but rather a decision has been made, and the pilot is just the phase before the release, but it’s important to understand that…
|"…the direction is known but that the path will be decided with them, hence the pilot…the company knows where to head to but must be aware of not being too directive or interventionist."|
[ADDED 12/05/10: Drop the Pilot, Part 2
“…you wouldn’t dream of piloting a telephone with a small team.”
“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 […] A lot of that would never have happened in a pilot-first scenario.”
“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”.”
“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.”]
[ADDED 21/05/10: Setting up a pilot is not only a matter of sizing
1°) The question of a preliminary phase
Before going further, what matters is to know if a preliminary phase is needed before scaling up the project. Obviously the answer is yes : businesses need to be sure they can manage things and get some kind of benefits on a smaller scale before applying a new concept to the whole organization.]
[ADDED 5/06/10: Piloting Social Media Creates More Risk Than It Mitigates
“This practice is not prudent for social media where the software complexity should be minimal and the primary goal is to get people interacting. Community participants are fickle and unforgiving (especially external communities). You may only get one shot at catalyzing community formulation. Don’t pilot, test, prototype, or experiment on the community. Don’t artificially restrict participation. The law of numbers is a critical factor in building a thriving and productive community. Why would you only go after a small subset of a target audience when mass adoption is a critical success factor?”]
[ADDED 16/06/10: Stephen Bounds
“I’d say that the essence of “safe-fail” is (a) trying multiple things in parallel; (b) not picking winners in advance and (c) always proceeding incrementally.
For example, most pilot projects run in two phases. First, run a proof of concept. If that works, roll out to the whole organisation.
Safe-fail breaks the process down much further. The idea is to always do things in chunks small enough to allow for roll-back if negative results occur. So an old-style “roll out” might instead happen as a dozen or more “safe fail” experiments, at each point confirming that results are positive before proceeding further down that path.”]