There is a long time (about three years) I haven’t published this type of article on this blog about dos and don’ts and social business. But when Gartner released a prediction that through 2015, a whopping 80% of social business efforts will fail to achieve their intended benefits, hampered by « inadequate leadership and an overemphasis on technology », back to basics is may be not a bad idea. So here is a commented list of dos and don’ts.
- Make it a global project for the company : whatever the size of your project (I’m not a fan of big bang, but you can begin with a pilot and then deploy more broadly), it is clear that it must be sponsored by someone of the top management, who who really support it. It must make sense to the business strategy and be presented as such, otherwise the change barriers will be difficult to overcome. To much project doesn’t have a real sponsorship and finish plod along in a corner and become just a topic of communication to say : Yes we did
- People matter: Everything is in the title, these are your stakeholders have to be at one with the project and it is very there the main thing. As written in the introduction, to much projects have failed, because they were tools focused.
- Communicate: as any transformation and change management projects, communication is paramount. Back to the idea of meaning. And especially to show what people have to gain (they know what they have to lose, you must show them the gains). Often fears are related to a lack of communication. Avoid the tunnel effect which is stressful. But most of all, trigger a whaoo effect. Most of the time the communication just serves to announce that an ESN is launch. Project team thinks that with a tutorial people will use it. When you discover something new in your daily life, do you want to read instructions. Is it really sexy ?
- Promote the gradual adoption: As I wrote above, it is necessary to do things step by step and especially let time take its course. You should see great, but start small.
- Be user-oriented : It is indeed the key, be based on the users needs. I personally think it is necessary to see what employeed need at first for their daily work. Then according to the requests you must select the same ESN for everyone, else you reproduce the organizational silos. To many organizations have too many tools and can’t really collaborate.
- Encouraged contributions: you can not force people to collaborate. You must show quick wins to convince people of the capital gain, but also find « champions / ambassadors » who will relay your message and support others. They are the ones who will make a difference and convince their peers. Don’t forget to provide roles for everyone, so that everyone finds his place, even if this role will evolve.
- Benchmark: it is always useful to know how it happened elsewhere, but don’t surestimate this methods. Nothing is ever the same, even if there are still passages required in this type of project. But your culture is the corner stone of the way to deploy the project and make collaboration adopted.
I will not repeat all « opposite » of the DOs, but I just take those seems to complete the DOs.
- It is not a question of tools: The tools are what you make with them and nothing more. This is not a tool challenge, it is thus everything except a question of tools. All companies that were tool focused have failed. We’re on the needs and practices foremost.
- Do not underestimate the resistance to change: Usually you have the feelling that everyone want to collaborate.We consider that often, only 10% of employees are convinced of the need for change and 80% are in the prospect. Those 80% are your target.
- Do not try to control everything: If you want to empower your employees and promote the transparency, it is necessary in the deployment to have the same attitude. Walk the talk, else no one will believe you.
- Do not think it will work itself: Thanks to the Web 2.0 technologies, many things are simplified (training can be relieved), this does not mean that employees will be engaged. Community management is one of the key .
- Do not set up your pilot for early adopters: They are your most fervent supporters, but their visions, their uses are not those of the entire staff (especially the reluctant). If you must rely on their enthusiasm, it is necessary to take into account the needs and issues of the more « classic » employees. Nobody should be left at the roadside. Any question is good and should find an answer.
Nothing new under the sun, but when you see the number of failure, and companies which are sure to know how to manage by themselves that type of project, a quick reminder is never excess.