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: , , , , ,

Getting rid of unproductive shadow organizations

August 30, 2011 By 1 Comment

Summary : enterprises will have to improve their organizational and management. Projects, pilots, initiatives are multiplying to experiment, learn, understand. But what is the right duration for sandbox ? The common answer is that it should take the time it needs but there’s a risk that’s growing with time. Many projects do nothing but creating shadow organizations inside enterprises, organizations that sometimes compete the one with the other and often with the official one. In the end, no one wins in such zero-sum games when they last too longs : enterprise see their immediate performance decreasing, projects fail at delivering their promise and employees lose their motivation. It’s essential that, at a given moment, enterprises align themselves with the projects they launched if they don’t want to loose everything.
If there’s a consensus on the fact today’s organization are far from being efficient and that things aren’t improving over time,  it does not go further. To some extent, we can say there’s a convergence on the future model but not on the way to get to it. Top-down, bottom-up, both, in an interventionist or optional way, evolution or revolution model… It would seem that all roads lead to Roma…let’s hope that’s true. But it seem logic : on people-centric project (people as a matter, a lever and a target) it’s impossible to overlook the past, culture etc..

To make it short, “push organizations” are dying, welcome to “pull” ones. Consequence : the largest part of what we call management is to make it difficult for people to work (these are not my words but Peter Drucker’s one…and I fully subscribe to that). This leads to the need of reversing the pyramids and to do it in an efficient and productive way. It reminds me of an anecdote taken from Vineet Nayar’s experience. At the beginning he set up the first elements of an organization designed to serve those who actually create value, then he realized the limits of his approach. Everything that was being implemented was applying and relying on the existing model, systems and processes, designed to be top-down. Hence a new approach aiming at building, step by step, a new coherent model aligned with its goals instead of a poultice on a wooden leg.

Now, let’s have a quick look at many enterprise 2.0 or social business projects. In how many cases did they come with process re-engineering ? With a reflexion on how to trace how value is created ? On how things and people are measured, evaluated, assessed ? Of course, that’s still a young and emerging matter. But, as I recently heard from two people that can be considered as convinced people, advocates, project ambassadors : “it’s been young and emerging for such a long time that it’s getting old now !”, “Ok for chaotic experimentations but we’ve been trying so many things in so many ways in so many directions for 5 years and the people ‘above’ haven’t understand that it’s time to blow the end of game whistle and make things square”, “Honestly, I’m about to give up the fight…I’ve been knocked about too many times for no benefits…and they still don’t get the thing”.

What were they talking about ? They were saying that these projects were generating new structures and way of working that go against the official organization compete with it and, even experimentations that compete the one with the other. [Read more...]

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: , , , , ,

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: , , , , , , , , , , ,

ROI of enterprise 2.0 : let’s use old recipes

April 28, 2009 By Leave a Comment

A pragmatic approach used by many people is to say that, since we’re talking about a paradigm shif, the calculation of ROI can’t be done according to our current thinking processes and deserves an empiric approach.

Of course, knowing that there is no blinder person that the one who don’t want to see, some may answer that empirism is not a serious thing, that companies need a reliable formula to calculate certain results.

So let’s have a look at a good old methodology that no one could disagree with.

• Archimedes found the so cold theorem while having a bath.

• Isaac Newton made a major discovery while sitting under an apple tree from which a fruit felt right on his head.

In both cases, formalization came from experience.

Inspiring ?

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