Don't blame the software

Now I usually maintain that the only technology that KM relies on is a kettle. But lots of people still make the mistake of making direct links between KM and IT, and this is very common at conferences. With that in mind and as I have to put up with it for the foreseeable future I thought I would share an eye rolling moment I came across the other day

I will spare them the embarrassment by not naming them but I was reading comments by a conference speaker who was deriding Microsoft Sharepoint as being responsible for increasing the number of “silos” in his organisation after it had specifically been deployed to counter that.

Now I don't want to get into a debate about the relative merits of particular software packages, and I certainly don't want to be seen as recommending any particular product. But lets face it Sharepoint is a common whipping boy. Now anyone that knows me will know I am an advocate of open source options and so I have no particular fondness for proprietary products but Sharepoint cant be without some merit.

However... I think this habit of blaming the product is a little unfair. It is common but it is a cop out and those doing the blaming should perhaps have a look at themselves - after all the software itself is relatively benign.

Its is how it is chosen, specified, deployed, configured and used that causes the problem, and the cultural pressures that influence those processes.

Some of the common traps for products in the business collaboration arena is that there is often an expectation that one product will do pretty much everything. It wont. Of course the vendors will tell you it does and every generic function you are looking for you will be told it will do – but it will do them in its own way. This is not a good thing and will hamper adoption and use. It is also an easy path to losing site of what you want to achieve because the focus is drawn to the product rather than the objective. Better to find a core application that majors on a core function and then add other familiar specialist tools for the more esoteric needs. Don't be taken in by the promise of “better integration of products all coming from the same house” – its rarely true or preferable.

The other common fault in these large scale deployments is that they are built to reflect the published version of the organisation model and structure. This will rarely reflect the real nature of the structure of the organisation and will also have the effect of hampering attempts to flex and change will will almost certainly be necessary if the organisation is to prosper.

The other common issue is that typically the deployment of “collaboration tools” frighten many as it promises a level of open access that is not what they are used to and typically viewed as a threat to the power held by gatekeepers. This means the promise of openness will often have a inverse effect and the resulting model, after much blood has been shed, is more highly constrained access than existed before – hence more silos.

But all of these things are avoidable problems and it doesn't have to be like that. Much more iterative and emergent approaches will yield better results and hopefully no one will need to blame the software.