Monday, 19 August 2013

50 ways to wreck your KM strategy

Philadelphia Spectrum demolition: Smashing! My colleague Stephanie Barnes and I are putting the final touches to our new book, "The Knowledge Manager’s Toolkit; A Step-By-Step Guide to Building Your Custom Knowledge Management Strategy".

At the suggestion of Rod Abson, who reviewed the text for us, we have included a chapter on "how not to write a KM strategy" (similar to the chapter from my last book on "100 ways to wreck organisational learning"). Here's our first pass at that chapter, for your interest. Please let us know if we have missed anything!

"In the previous chapters, we've looked at how you can write an effective Knowledge Management Strategy, which will provide context, direction and limits to your Knowledge Management implementation. We've looked at the success factors, the things you have to get right; the principles, the inputs, the approaches. In this penultimate chapter, we will turn it around, and look at how not to write a strategy. If you follow any of the advice in the list below, you will weaken your strategy. If you follow all of the advice, your job as a Knowledge Manager can be mercifully swift, and you can sabotage your company’s competitive future as well.
1. First of all, don’t even bother with a strategy. Tactics are so much more fun, and save you a lot of difficult thinking. 
2. Don’t try to understand the field of Knowledge Management before you start. I mean, how complicated can it be? Knowledge is pretty simple stuff, so this won’t need much research. You can make it up as you go along. 
3. Don’t check your understanding of KM with your manager. When he or she says “Knowledge Management”, it’s a safe bet that they mean exactly the same as you do, when you say “Knowledge Management”. The topic is not at all broad or fuzzy. 
4. There’s no need to limit the scope of your strategy. Knowledge Management is surely a small, well-constrained topic, isn’t it? There can’t be any room for scope creep in a Knowledge Management strategy? 
5. Also, there is no such thing as too narrow a scope either. If you narrow your scope far enough, for example to a single tool or a single approach, then you can be unencumbered by any embarrassing success. 
6. Don’t bother to define your own role. A touch of role-ambiguity makes corporate life so much more exciting, especially at performance-appraisal time (“You never told me you wanted me to do THAT!”) 
7. Don’t bother to define any other KM roles either. Let’s share the ambiguity and confusion. 
8. Principles? You don’t need any principles! Guide your KM strategy by imagination and whim, rather than a set of principles.
9. Avoid learning from past KM implementations. Your Knowledge Management implementation will be so unique that there’s no point in looking at success principles from other implementations. Just start from a clean sheet of paper. After all, what’s the point of a wheel if you can’t reinvent it. I am sure you will avoid all the pitfalls that others have found. 
10. You know that statistic about “80% of KM projects fail”? That won’t apply to you! Don’t worry! 
11. I would not bother trying to make the case for a KM strategy. It will be immediately obvious to the senior staff that a KM strategy is needed; you won’t need to collect any evidence. They will be bound to give you the go-ahead anyway. 
12. Similarly, there is no need to demonstrate that value is being lost through lack of KM. Everyone already fully accepts that KM is needed, and worthy of big investment, and they have a pot of money available for you somewhere, I am sure. 
13. Also, there’s no point in getting too clear about who the decisions-makers are for KM, or what you want them to decide. Your KM strategy and KM program will find support from somewhere, somehow, to do something-or-other. 
14. The best way to write the strategy is to shut yourself in a room and write it yourself. There’s no need to include input from anyone else. Interviews and workshops will be a waste of time. 
15. You don’t need your Knowledge Management program to be business-led. That would be such a hassle. Its far easier to be tool-led; to select a new shiny KM tool (or even several tools, if they are shiny enough) and just roll them out. Business value is bound to follow somehow. 
16. That means that there’s no point in trying to identify business drivers. Knowledge Management is bound to help with something, so there’s no point in trying to decide up front how KM supports the business. 
17. Demographics is a red herring. If your company is full of experts, or full of novices, surely the knowledge issues will be identical? 
18. Vision statements! Don’t make me laugh. Visions statements are a total waste of time, and clarity of vision never helped anyone. (Now, remind me of what we were trying to do again?) 
19. Oh yes - scope statements. That’s another total waste of time. Let’s just keep KM open ended - the strategy can cover anything, all staff, all topics, for as long as you like. If we set a scope, we would just be in danger of excluding things, like new shiny tools, or going off on tangents. 
20. If you DO have to write a vision and scope, then, again, there’s no point in involving anyone else in creating these statements. Just make them up yourself - they’ll all buy into it just fine. 
21. Avoid all temptation to focus on specific areas of knowledge. Far better to leave yourself free to address every knowledge topic, whether it is valuable to the business or not. Surely all knowledge is of equal value? 
22. Also its better if you free your KM strategy completely from the company strategy map. You don’t want KM to bear the burden of being seen as something strategic; that would be far too risky and high-profile. 
23. Start Knowledge Management from a completely clean sheet. There may be some aspects of KM in place already, but it’s better to demolish and reinvent these wherever possible, no matter how well they are currently working. 
24. This applies to technology as well. You really need the users to abandon all old habits, and start afresh. 
25. If you are forced to do an assessment of the current state, then do this yourself, rather than hiring an experienced consultant to help you. It doesn’t matter that you “don’t know what you don’t know”. 
26. You don’t need to treat Knowledge Management as a Management Framework - better to see it as a single tool, or perhaps an optional “pick-and-mix” toolbox. That’s how every other management system works, eh? 
27. Don’t seek to embed the framework in business activity. KM works better as an add-on to “real-work”, so that people can ignore it if they want to.
28. There’s no need for Governance within KM. Let’s keep KM low key, let’s leave it up to the individual, let’s keep it as an optional activity. Everyone has plenty of time for optional activity. 
29. There’s no need for Roles and Accountabilities within KM. Just present it as “everyone’s job” and everyone is bound to do it. 
30. If you want to save time and heartache, just ignore the issue of information architecture, and information lifecycle. Information can just look after itself - all you need nowadays is a search engine. 
31. Selecting Knowledge Management Technology is easy. Don’t bother with business requirements, don’t bother with user requirements, just listen to the vendors. They will let you know how valuable their own products are, and in fact you may be surprised to hear that (according to the vendors) there are many products that will just “do KM for you” with no effort from you at all. 
32. Once you have the technology, then there is no need for training or coaching. Roll it out and see what happens. 
33. KM technology, unlike any other technology, is an end in itself, and needs to business justification. All proper companies need a KM toolkit, even if it adds no value to the bottom line. 
34. There are very many types of KM technologies available nowadays. Just buy them all. 
35. OK, here we get to the core of the advice. Forget change management. All the books tell you that KM is a Change exercise, but change is hard, and takes time and effort. Just quietly ignore the Change issues. It will all sort itself out in time. 
36. Similarly stakeholders. Everyone has an equal interest in KM, everyone will naturally support what you are doing, so why bother to engage people - why bother to get powerful people on your side. 
37. Similarly communication planning. KM is common sense, and doesn’t need to be communicated. 
38. Again - piloting - total waste of time. Knowledge Management won’t need any adaptation for your own organisational context - it will work “right out of the box”. Just roll it out to everyone, all at once - you can’t fail. 
39. If you are forced to pilot, then pick the first pilot you think of. Any pilot is as good as any other pilot. Why bother to rank and select. 
40. You can’t make a business case for KM. Don’t even try. Who needs business cases anyway? Your managers will give you the money you need, without you having to explain about benefits, let alone attempt to estimate the scale of the benefits. KM will add value because it will allow people to share knowledge with each other - that’s all you need to say. 
41. If you have to do “KM by stealth”, then be as stealthy as possible. The ideal is for nobody to have any idea at all what you are doing. 
42. You don’t need a leader for the KM project - it will lead itself. 
43. If you do appoint one, make sure they are a KM geek, with no business experience (and especially no Change Management experience). 
44. Don’t appoint a team. 
45. If you do appoint one, ensure they are all from HR, or all from IT, or all librarians (diversity is over-rated). 
46. Avoid any people with passion for the topic. Passion is so exhausting. 
47. Avoid any clear reporting lines. 
48. Avoid using a steering team. Who needs managers meddling in KM, with their “business needs” this and their “operational priorities” that? 
49. Implementation planning is to be avoided at all costs. KM will just implement itself. 
50. You can estimate your budget as being the cost of the software alone. You can treat any other elements (current state assessment, requirements definition, roles, accountabilities, processes, governance, change management, communication, stakeholder management, training, coaching, roll-out) as essentially negligible."

No comments:

Blog Archive