Why KM is Hard To Do
We recently did a small information management/knowledge management internal initiative at Straits Knowledge. The relative ease with which we did it, compared to the problems faced by several of our clients (much larger organisations) has got me pondering on the way that existing infrastructure impacts an organisation’s current effectiveness, both positively and negatively. In this article I use the case study of our internal initiative to analyse the way that infrastructure in large organisations imposes friction on the rate of change, and propose some project management and change management strategies to deal with that. If you’re the kind of person who prefers to cut to the chase, I’m using this blog post to summarise the takeaways for KM project planning that I ended up with.
Here’s what helped us in our internal project:
• We had very few decision makers involved
• We had a very clear scope and defined deliverables (we don’t have the luxury of time to consider our needs more than once a year, we have to get it right first time and run with it)
• We had minimal inherited baggage to deal with
• We had complete ownership of the timeline
• Our supplier (Maish Nichani) had an intimate understanding of our business needs (he’s worked with us on several projects)
• What we didn’t know internally, either Maish or Edgar (who has a wonderfully practical network of friends) were able to find out
• We remind each other to use the new processes and tools whenever we slip back into old habits
• We saw the results quickly, and got immediate feedback on how well it was working
In reflecting on the relative ease with which we did our small inhouse project for ourselves, the things that helped us be nimble were the things that big, mature organisations handle much less well, and they are all functions of pre-existing infrastructure:
• Too many decisionmakers, focus is not maintained
• Lack of clarity about the scope and objectives because the needs are complex and the possibilities not well understood
• Lots of inherited baggage, lots of invisible dependencies
• Other factors such as budgeting, funding agencies, stakeholders, related projects, impact and pressure the timelines
• Long learning curves for external consultants and suppliers (even internal people don’t understand the infrastructural frictions)
• A tendency to prefer slower, mechanical channels for information gathering, and a corresponding mistrust for personalised social networks
• Too few people who are committed to and aware of the project goals and who act as vigilant “wardens” of the change, reminding their peers on a day to day and localised work level
• Impact for stakeholders gets lost in the mechanical performance of project tasks
To change infrastructure, you have to negotiate infrastructure. The more you have, the harder it is to negotiate.
However, it strikes me that bigger organisations can learn from the relative nimbleness of small organisations like ours. The first step, obviously, is to acknowledge that infrastructure exists, and must be understood and negotiated. Beyond that, each of the areas we’ve discussed above, needs clear strategies to overcome the inherent friction that mature infrastructure provides.
Consult intensively, but keep decision-making simple: we need to make a clear distinction between the activity of involving and consulting stakeholders throughout an infrastructure project, as compared with distributing and confusing the decision-making responsibility. Consultation is critical, for obvious reasons, in anything that affects infrastructure, because your changes will impact lots of different work areas. However, after the initial needs analysis phase, the core project team needs a clear mandate and delegated authority to proceed with key operating decisions. Get the scope and objectives right, and any further consultation is more about validating detail than blowing the project in different directions every time stakeholders are brought in. This means strong leadership, a strong mandate, and constant effort to keep the project focused on its original goals.
Establish and maintain clarity of purpose: success in keeping the decision-making simple depends in part on clarity about project goals. If you have a strong set of goals that meet real business needs identified by your infrastructural stakeholders, then you have something that you can keep your team focused on, and remind your stakeholders of whenever you go back to them for validation or support. An approach with an evolving, provisional set of goals that emerges as the project team learns, might work in small-scale “guerrilla warfare” type projects, but it will not usually work in anything that needs to orchestrate and align changes at several points in an infrastructure. Get the purpose clear, link it to business needs, get your mandate tied to that purpose, keep the focus tight, and refuse distractions along the way.
Acknowledge the baggage: whether we like it or not, the inherited baggage, in the shape of existing tools and systems, work processes, leadership attitudes and experience, policies and priorities, previous project outcomes, will all conspire to slow us down. To ignore it is to gamble blindly on success, where a prudent eye will survey the ground and identify the most likely friction points well in advance. Choose the ones that will likely have most impact on your change, and involve the relevant stakeholders early on – whether or not you think your project will tread on their toes. Plan the necessary infrastructure changes at one step removed from your direct project, with those stakeholders. In military terms, don’t just fight the enemy troops, disrupt their supply chains and communications as well. In gardening terms, have an eye to the whole ecology of your garden, and your cultivation of individual plants will be much more successful.
Manage the timeline: it’s rarely possible in large organisations to completely own the timeline of a project, because infrastructure is all about inter-linkages, dependencies, and distributed effort. However, timelines can be influenced by involving, again, timeline stakeholders, those who own the timelines that pressure your own. Notice how important it is with both baggage and timelines, to identify and map the most important stakeholders right at the beginning, engage them early, and communicate intensively with them, in order to influence their bits of infrastructure positively in your favour. This will require flexibility, and a modular as opposed to a monolithic approach to project scheduling.
Shorten and leverage learning curves: this is a tough challenge to meet, because tendering and procurement guidelines often force organisations to engage people who are strangers to them. If you can work with regular suppliers and service providers, all the better. If you can engage suppliers for extended durations during an infrastructure project, you get more leverage out of what they’ve learned about you. With new suppliers, it’s terribly important to understand and provide for learning curves in your project planning. It’s also terribly important to maintain your internal project team continuity throughout the lifetime of an infrastructure project, particularly at the decision-making and leadership level. I can’t tell you how many projects I’ve seen fail simply because of leadership changes along the way. It’s too many, and it’s nothing to do with the competencies of the successor. It’s about the infrastructural learning the core team has picked up along the way.
Use social networks: using informal networks both inside and outside the organisation can be a powerful mechanism to learn about what needs to be done, get your possibilities well defined, identify the technical knowledge you need to acquire, figure out the friction points in your infrastructure, and pick up tips and strategies from other organisations’ experiences. Frankly, there’s no earthly reason I can think of why this practice shouldn’t be encouraged and acknowledged. You’re not awarding contracts based on informal networks, you’re learning. That’s what informal networks are for. Use them.
Provide for habit-changing strategies: existing habits and routines are among the hardest bits of existing infrastructure to change. Not even persuasion helps, because habits and routines are largely unconscious. With the best will in the world in support of change, habits trump persuasion every step of the way. Cultivating and supporting a pool of change activists is one step you can take. You can make them more effective by identifying a few key, specific habitual behaviours that need to change for your infrastructure project to work, and running a campaign to change them, with your activists stationed as warders to give reminders and acknowledgements where they are needed. It’s an old language teacher’s trick: don’t try to correct all the language errors a student makes, just correct one error a day, in the order that they need to build their language. We need to get granular and specific about where habit change is needed, and tone down the preaching about “mindset change”. Most of it is irrelevant.
Demonstrate impact to stakeholders: you will have engaged your stakeholders at numerous levels and numerous points in your project. As we’ve seen, you don’t just need input from them, you need their collaboration so that they adjust and realign “their” bits of infrastructure in your favour. Because infrastructure projects frequently span years, you need to keep your stakeholders nourished, and show them benefits along the way. This goes back to the project objectives you establish at the beginning: this statement of purpose needs to be linked very closely to business benefits for them, and the benefits can’t all be delivered right at the end. You’ll need a programme of benefits. It’s like a small business that needs to watch its cash-flow. You’ll need to watch your “benefit flow”.
If you want to find out how I reached these conclusions, read the full article. many thanks to James Robertson, who catalysed me into writing this, and to Maish, who has made our own infrastructure journey so easy.
1 Comment so far
Page 1 of 1 pages
Comment Guidelines: Basic XHTML is allowed (<strong>, <em>, <a>) Line breaks and paragraphs are automatically generated. URLs are automatically converted into links.
Trackback
Posted on June 21, 2006 at 05:44 PM | Comment permalink