How quick wins can sometimes be misleading

October 18, 2011 By Leave a Comment

Summary :most of the projects aiming at changing the way people work or implementing new tools start with seeking quick wins, evidences that the promise can be delivered on a small scale with a limited financial risk. Even if it’s a logical and wise approach, one should prevent from paying too much attention to quick wins or lack of. The specific context of experimentation makes it hard to extrapolate on a wider scale when the project will not be over-monitored and participant under the spotlight anymore. Having goals related to understanding novelty rather than delivering the promise can be more rewarding and less misleading.

 

That’s the mandatory steps in any serious projects : quick wins. In other words, quickly get tangible results, even modest, that prove that the choice is right, the promise deliverable and that’s worth scaling up. Quick wins are sought in the very first times of deployment but also in pilots to decide whether going further or stopping.

At first sight that’s a wise and necessary step : why investing in a large project without being sure that expectations can be met ? But it’s not trap free.

First because quick wins are often been sought on a small scale project, what is not always the right context while a critical mass is needed. To fix the problem, organizations are choosing the “right” people to participate. What causes two problems. The first is that is the “right” people are chosen, it brings a bias because there is no evidence that average employees will be as easy. The second is that, most of times, organizations fail at chosing the right people and choose “those who should” and “those we’d like to…” instead of “those who’d like to participate”.

Second because quick wins often have to be obtained with “current means”, without any change management or any kind of effort. What leads to grotesque situations. “We know that change management matters in such projects but we won’t do change management until quick wins are found”. No comment…

Then comes the context. People know they are watched, that attention is on them and they are expected to be successful. Guess what ? If the purpose is clear, people closely “managed” and supported, the quick wins will come very fast. Very similar to the Hawthorne effect.

Let me add that nothing is easier than coaching participant so closely that perfect story happens by miracle. Facilitating success is a good for exemplarity (other people think things really happened…) but no one learns from it and it does not prove anything. And it does not scale.

All these points are evidences that

- the lack of quick win does not mean the idea was bad.

- the existence of quick wins only shows that things were possible in a given context, with given people but in no way that it may work on the company scale.

So, should be get rid of “quick wins” ? Not at all because some promises need assessment, some things experimentation before a global roll out. On the other hand making it the only point to base a go/no go decision on is dangerous. It may be better to focus on learning and draw all the conclusions (while being aware of the special context in which the experimentation took place). Objectives in terms of understanding a poorly known field may be more relevant than objectives in terms of demonstrating something in a too specific context.

 

Filed Under: Enterprise 2.0 & Social Business, Management & HR Tagged With: , , , , ,

Setting up a pilot is not only a matter of sizing

May 18, 2010 By 1 Comment

Andrew McAfee recently raised the question Michael Idinopulos discussed some months ago :  is the concept of “pilot” relevant to enterprise 2.0 and should we drop it. Some (excellents) thoughts can also be found on Emanuele Quintarelli‘s blog.

In fact the cause of the discussions comes from some assumptions that are not always true :

1°) Pilot applies to over-the-flow activities

2°) The only thing that makes a pilot different from a mainstream project is the number of participants

In this case where reaching a critical mass is…critical, limitating the number of participants is an heresy that is equivalent to shooting oneself in the feet at the beginning of the projet. If something as to be limitated, rather limit the duration than the size (what was brilliantly done at CSC for instance).

That said, thninking that the underlying question with pilots is only about sizing may be a bit hasty.

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.

So the issue is not there but in what this phase is made of. Starting with its goal.

2°) What goal ?

I won’t elaborate too much since I already tackled this issue a few weeks ago. It’s important to know whether this phase aims at taming new approaches that will be implemented on a larger scale anyway or at assessing if the new approaches have to be implemented or not. The stake is not trivial : it’s hard to involve employees in something that can be shut down anywhen, with no certainty about its durability.

3°) What name ?

As strange as it may seem, the way this phase is called is not neutral. On the user side first (pilot = be sure we won’t give up…but may seem a little bit top down / experimentation : you are guinea-pigs, we don’t promise anything) but also on the business side, some namings making it easier to get the “strategic project” label and the exectuive sponsorship that comes with.

Maybe some have found the “magical name” that reconcile both needs.

4°) What kind of social experience ?

Maybe that’s where things should start. Deploying enterprise 2.0 logics and tolls is not about doing something uniform. As I mentioned in the past, there is “social for communities” and “social for teams“. In other words, gathering an undefined population around some topics and optimizing the “organic” functioning (departments, teams…) of an organization are two complementary but different logics. I won’t elaborate on the management and leadership differences between both and the difference bewteen conversations and interactions, what matters is that in the one case a critical mass is needed and in the other a deeper work on alignment and integration in workaday practices and actions is  key. In short, that’s one more case where distinguishing between in the flow and over the flow matters, and that’s a part of the pre-rpject analysis that’s too often overlooked.

The truth is that both approaches have to articulate and live together in the organization, so it should be the same in a pilot. In the other hand, according to the goals (it’s possible to experiment many social experiences at the same time) businesses should now that some experiences have a defined and limited number of participants by definition and some others need a critical mass.

So the matter is neither sizing nor “pilot or not pilot” : it’s about knowing what is aimed at, what the organization is trying to validate, assess, learn…and the rest will naturally come.

Filed Under: Enterprise 2.0 & Social Business Tagged With: , , , , ,

Are you piloting or experimenting ?

May 6, 2010 By 3 Comments

When an organization tries to embrace something new, the first steps are made in a very cautious way and that’s logical. Even when there’s a clear idea of what is being done, things have to be tried on a small scale to validate some things, compare the plan and the reality. I don’t even mention cases when something is tried without having any idea of the purpose and of the possible benefits that can be expected.

This applies to many things and enterprise 2.0 is not an exception. So, even if this post will be more about this topic, many things can be generalized to other fields.

I won’t rewrite the debate that took place last summer about knowing if this preliminary steps made sense or not. As a matter of fact, when a critical mass is needed, a smaller scale may made this steps more or less relevant. In concrete words, the question is about :

1°) Knowing what is being done

2°) How it’s called and explained.

[Read more...]

Filed Under: Enterprise 2.0 & Social Business, Management & HR Tagged With: , , , , , ,

Why haven’t I use this app earlier ?

November 27, 2009 By Leave a Comment

A few weeks ago I was in a meeting, taking notes. A glance at a colleague’s screen aroused my curiosity and I asked her : “what’s the application you’re using ?”. Then she showed me this wonderful app she just discovered weeks ago. As for me, I only had to blame myself : it’s not been weeks but months that it was installed on mu computer. I even had a “beta” account. When I first tried it, I made a quick tour then switched to another task. Not because the app was good or bad but because, at this time, I did not want to take the time to ask myself some questions. And here comes the lesson I learned through this short piece of worklife.

Like everybody, I have my own routine when it comes to manage information. There are notes I take, what I read on the web…then comes a “buffer” step, then I treat it what means delete/keep for later/bookmark or undertake any action. This routine applies to both my professional and personal watch (in fact both are about the same topics). Of course I organized it with applications : each task has its app and I push the info through my process. An application to read, another to queue, another to bookmark, another to…

Adopting a new app, ie changing one of those I’ve been using so far, would have made me change my routine. It doesn’t matter if the new app is better that the one one it replaces or not. Then, since I was only testing this app before deciding to adopt it or not, it would have meant I spread my datas (or have some data duplicated) before I choosing to switch or not. Since I had no time to waste, I contented myself with testing the functionalities without trying in real work conditions. So, since “testing” things this way is more about playing than working, I didn’t used the app for real work purpose so I couldn’t say if there were real benefits or not. A last point was missing too :  I did not take the time to think about the application’s scope (personnal/profession, notes/notes+…., overlapping….). All these things put together made that I was unable to see myself using this app in my day to day work, to visualize what I could mean to my routine.

That’s why I was about to miss Evernote.

That’s quite a simple case. Imagine what happens when someone has to conduct the experimentation of a social platform at a company-wide scale and how those who are asked to participate may fill. It’s not about one person but 10, 100, 500 peope, that are not as tech-savvy than I can be and have not the freedom I have in the choice of the tools I use at home or at work.

It’s one more point to take into consideration when launching an enterprise 2.0 pilot.

application, Entreprise 2.0, evernote, expérimentation, pilote, routine

Filed Under: Management & HR, Software & Tools, Web & Usages Tagged With: , , , , ,

10 questions to answer to succeed in an Enterprise 2.0 project

November 10, 2009 By 1 Comment

It’s a common place to say that if you want to succeed there are things that have to be done. But, by focusing only on actions and forget thinking, the risk of doing hudge mistakes is obvious, that’s why so many opportunities are wasted. To succeed, you also need to have answers. Answers that allow you to go from one step to the next one. Answers that make you sure you’re not managing the wrong project. Answers you’ll have to provide to you boss to prove you’re not throwing his money through the windows and that your project desserves funding and his active sponsorhip.

At each step of your project, you have to wonder if you have the answer to some key questions. If you don’t, slow down and take the time to find it instead of insisting in a direction that may be wrong.

If we assume that a project is made of 3 phases, exploration (when you try to understand a new phenomenon,), pilot (when you validate what you thought you have understood) and industrialization (when you scale things up to make them company-wide), here a 10 questions you must be able to answer to.

There is not always an only right answer. But an answer is needed. When the choice is between “yes” or “not” I let you guess what is right one and what the other means…

1°) At the end of the exploration phase

What are the tools I’m planning to use do and don’t do ? More precisely, what are they designed for, and what aren’t they designed for.

Do I have any idea of how my project will change the way people work ? Can I visualize what the workplace will look like then ? And am I ready to assume.

Can I demonstrate the project’s impact on the value chain, on value creation, on people’s efficiency ? (At least theorically)

2°) While running pilots

Are the contents and information published and shared by “real” users or by people who have been assigned this task to make things look busy.

Have I formalized and shared the expected “outcomes” ? And checked they made sense in people’s day to day work ?

Am I sure that the purpose of people that play a part in the project (whether internal or external) is to deliver these outcomes or to make enough noise in the tool to deserve their pay ? Does the use of the tool have become the project’s goal to the detriment of operational objectives ?

Have I organized the way how the expected social interactions and what they’ll produce will be reused for business purpose (ex : how an idea will become a project, how people will be able to access and reuse their peer’s knowledge, how one will be able to mobilize people  found through these interactions…)

Did I thought about “social routine” with managers, and began its implementation ?

3°) In the industrialization phase

Do I have concrete indicators that measure social logic’s contribution to business (lenght of the innovation cycle, lenght of the sales cycle, turnover, number of best practices formalized, meetings avoided, ideas gathered, lenght of the decision making cycle, decrease of the time spent by managers to connect people together…)

Do I have examples of things that would not have happened without the project ? And what was their impact.

Of course this is not an exhaustive list but I’m sure that the inability to provide the answer to one of these questions (or provide the wrong one) may have painful consequences one day or the other while taking the time to think about it at the right moment would prevent from future disappointments.

Filed Under: Enterprise 2.0 & Social Business, Management & HR, Web & Usages Tagged With: , , , , , , ,

Does enterprise (2.0) need a pilot ?

October 16, 2009 By Leave a Comment

It started with this provocative post from Michael Idinopulos. His message is quite claire : assuming that enterprise 2.0 relies on networked interactions, that these interations need a critical mass of users not only because of Metcalf law but also because, by definition, it’s impsossible to know at the beginning  who will be needed in the future, he concludes that in a enterprise 2.0 perspective the usual pilots makes no sense and does not allow do demonstrate anything.

His take led to many reactions, even if no clear answer emerged (read Steven Walling’s post, the comments and the results of his poll). At the end, it seems that even if a discovery or learning phase is important, not everybody agree on how it should happen. Said differently, everybody agrees on the big picture but opinions diverge on details or on the meaning of things.

What’s a pilot  ?

What’s a pilot ? It’s a project which goal is to test in a riskless context and a small scope the key points of something that is expected to be deployed on a wider scale in the future. I’d rather say that that’s how people generalized the content of a pilot. If we focus on the real and primary goal it’s about validating something new, learning to master it, understanding its potential, the risks, the limits. Regarding to many things that happened in the pas, this definition was relevant because the only thing that differenciates the pilot from the full deployment is the scale. In a system relying on transactions, if a system, a processus, works for 10 people it will work for 100, 10 000 or 100 000, the only thing to do being to scale the infrastructure.

Conversational or transactional ? Two different logics

What’s new in enterprise 2.0 projects, if we consider the IT side, its the human dimension, not mutch transactional, not foreseeable, and the fact it relies on a people network. In other words, that’s not because something works with 10 or 100 people that it will work with 10 000. And the most frequent situation : something that does not work with 10 or 100 people may perfectly work with 10 000. If the web had only 1000 users, the social networks as we know them may not exist, the probability for a given personne to find his own network, people who share the same concerns being very low.

There’s also another point that is far from being trivial : a transactional application can be tested with blanks, injecting datas and looking at what happens. A conversational application can’t be tested in a sterilized room, disconnected from the operational reality. Isolated from the day to day concerns in order not to impact anything, it can’t provide with any clue or certainty about its future use or efficiency.

Il existe également un autre point qui est loin d’être anecdotique : on peut tester une application transactionnelle “à blanc”, en lui injectant des données et voyant ce qu’il en sort. Une application plus “conversationnelle” ne peut être ainsi mise en salle blanche, déconnectée de la réalité opérationnelle. Isolée des préoccupations quotidiennes de manière à ne rien impacter, elle ne peut donner aucune preuve ni piste quant à son utilité et son efficacité future.

So the goal of a pilot applies to enterprise 2.0 (at least to its software component) but the method should certainly be changed to fit the specificity of 2.0 applications, most of all in terms of scale and positioning toward day to day business issued.

A good synthesis of what a pilot should be in such a context can be found in Claire Flanagan’s comment. A comment that gains a special dimension when you know the results of the pilot she’s currently leading.

A pilot is not an explorer

A pilot aims at validating, refining the understanding of a problematic and improve the tools to…pilot things once the project will become mainstream. In our context it means that there is a critical mass of users and that the pilot is not isolated from the real work. It implies that people already have a quite clear understanding of what the project is about, what it will be used for, what are the preliminary changes to undertake and those who will follow.

When a pilot is restricted to a few people and is help apart the real life, it’s often because people don’t know what they are doing, what tools do and don’t do, what will  be their impact, what they help to change and what changes they need. It’s a discovery phase of tools and concepts, without anything operational, that won’t help to prove anything. Such a project is not a pilot but rather an explorer, and its purpose is to do the spadework on the subject. Its a key element of the necessary (and too often forgotten) strategic thinking phase but it’s not a pilot in any way. And when you expect from an “explorer” the same things than from a pilot, their are many chances to be very disappointed.

It taking the specificities of the 2.0 paradigm in a pilot is key, it’s also very important not to call a pilot the necessary discovery and exploration phase, which purpose is to open up before launching a pilot, in order to understand things and prevent from doing mistakes later.

You my also find Steward Mader’s takes interesting..

adoption, changement, conversationnel, conversations, Entreprise 2.0, expérimentation, périmètre, pilote, réseaux-sociaux, transactionnel, transactions

Filed Under: Enterprise 2.0 & Social Business, Management & HR, Software & Tools, Web & Usages Tagged With: , , , , , , , , , , ,