20+1 reasons not to launch an Enterprise Social Software project

1
2341

Let’s be clear : I’m talking about the reasons not to launch a defined project because it’s born to fail. That does not mean that it’s the case for every project : more and more of them are born to be sucessful mainly because of the growing maturity of companies about social networks.

1°) Your interlocutor wants hierarchy driven rights : it’s imposssible for any users to have the same rights as his superiors and so on… At the end the average users barely have the right to read. And don’t even think of letting them write or comment ! This kind of solution is an intranet. And it already exists.

2°) Your interlocutor focuses on document sharing : web 2.0 technologie are more about exchanges, are more about flows than about stock. If he wants a shared directory let him know he already has it on his information system.

3°) 50% of the project team aren’t on Facebook, linkedIn or any social platform : it means that those who will be the go-betweens, those who’ll embody the project in front of end users have no experience of social networks tools and practices. Knowing how many invitations we can receive a day to join such or such platform, it’s not accidental : it’s the proof they refuse the concept.

4°) Your interlocutor wants publication workflows : no one is able to publish anything without getting authorization from his superior while one of the project’s purposes if to fluidify information. By doing that, managers are turned into marshalling yards, censors, publication comittee (chose the right answer) and the only sure you can be sure of is that it will have a negative impact on productivité.

5°) Your interlocutor needs a detailed schedule of behavioral changes : Humm…how to say it ? Human nature is irrational and unschedulable, most of all when interconnected.

6°) Your interlocutor targets people he’d like to make work together but who have no reason to do so : he’s trying to use technology to solve management issues and it won’t work.

7°) Your interlocutor has no power over users : so he has only pious hopes toward people whose “day to day life” he can’t impact. So he won’t be able to facilitate anything while these people have to face constraints he can’t do anything about.

8°) Your interlocutor doesn’t want people  to change the way they work : it’ impossible to build new things without impacting old ones, above all if the purpose is to improve these old things.
9°) Your interlocutor’s purpose is to get a 2.0 platform : without taking care of what it would be used for. He forgot that necessicty is the mother of invention and that there are enough plants in offices for decorative purposes that there’s no need to add new ones on the intranet.

10°) Your interlocutor purppose is to make people collaborate and share information : “collaborate and share information”means nothing to his team. They need to be precisely told what they are expected to do. What is more, those words are only means : the real purposes are operational and neglecting them prevents from evaluatin the project. It even prevent the project to progress and receive any support because of its lack of sense.

11°) Your interlocutor will not play any role in the first projects : so he will go fishing for projects and say to someone who didn’t ask for anything “we are going to experiment on your team, for a purpose you didn’t idenfify and provide them with a tools that makes possible things you even cannot visualize. Worse, by recruited “designated volunteers” he may scupper the project by giving the impression of misappropriating resources.

12°) The team’s manager nickname is “Terminator” : and often answer to any idea or suggestion by “that’s bullshit”, “shut up and work”.  His first contributions will surely make people feel like giving up.

13°) The project team has no idea of how contents will be used : producting contents that won’t be reused in people’s daily work is useless. An “idea box” that nobody reads won’t cause any innovation. An informational bubble disconnected from real business is useless and often dies on its own.

14°) Your interlocutor will start a change management project only if the pilot succeeds : it means “I will get involved and mobilize resources only if you bring me the proof we don’t need it”.

15°) Your interlocutor wants to test a tool : once he would have validated functionalities on a blank test, he won’t be able to demonstrate anything, any ROI, any benefits because the tool was not used for business purposes. Perhaps  il will do reverse engeneering, saying “now we have a tool, let’s find it a purpose”. Back to 11°)

16°) Your interlocutor wants one to one conversations : he’s afraid that a conversation between two people could de followed by a third. He needs an email solution.


17°) Your interlocutor doesn’t have time :
he wants things to work without taking any risk, without being seen as a change leader. Don’t expect his executive sponsorship.


18°) Your interlocutor doesn’t make the difference between leadership, expertise and hierarchy
: he wants to be sure that the experts who will emerge will be the same as those who are considered as experts by the company and that a trainee will ot have better ideas than his boss.

19°) You interlocutor wants a one month pilot for ten people : at the end of which he won’t be able to prove anything due to lack to time and critical mass.

20°) Your interlocutor wants to wait untill the pilot ends to turn it into a business project : so he wants to makes his team work on trivial things that won’t mobilize people who are already very busy while people are waiting for solutions to make their job easier, more efficient.

And the last one

When you talk about the social side of the project, of people centrism, you’re answered : “oh ! stop ! be careful ! we are not here for any HR stuff”

A contrario, perharps it will help you to find success factors…