My first two guest posts were about the intersection of Knowledge Management and Project Management; in this post I would like to talk about what I think are some of the peculiarities of Knowledge Management projects.
For the most part Knowledge Management projects are just like any other projects, tasks have to be delineated, risk managed, status reports given, you know the drill. What I think is different about knowledge management projects is that they tend to touch on more of the organization, often they are enterprise wide and no one wants to own them in part because they don’t understand them.
If an owner or owners are identified and a management change occurs it can throw the whole project into question. The success of the project often comes down to influence and sustained management support from one person at least for the first little while, until the business case is proven. Although even then I have seen successful projects shut-down because the new management team didn’t understand the value of the initiative.
There are often multiple stakeholders on both the business and IT side, with IT taking a lead. IT taking the lead is a problem. Technology is an enabler and a critical part of the project, but the project needs to be lead by the business. Technology ultimately needs to enable business processes, not be some extra “nice to have.” This only happens if business takes the lead and ensures that the technology is supporting business processes, not hampering them. When business leads they focus on the people and process part of the equation, and work to provide a balanced solution, not a technology-centric one.
The value of Knowledge Management is often hard to measure, in tangible ways. Connecting people to the knowledge they need to do their jobs is often described as an opportunity cost. How can I measure something if I don’t know the value of having it? For example, what if I “recreate the wheel” because I didn’t know a colleague in another region had already “created the wheel”? You never know you’ve recreated something, so can’t measure the cost/benefit.
One project I did was like that, a team in Asia-Pacific had found a solution to their ISO 9000 document management needs, it had taken them 6 months. Another team in North America was starting out on finding a solution to the same problem. I connected the two teams and the second one took 3 weeks to get their documentation sorted out because they could re-use what the first team had done. If the connection hadn’t been made, the second team could have taken six months or even longer to resolve the issue, but would never have known the difference.
Those are what I think are the main oddities about Knowledge Management projects, they aren’t reasons not to do them, just issues to be aware of and monitor closely throughout the project lifecycle.
As we often said at my last employer’s, “If only we knew what we knew.”
This is where the next order of magnitude in productivity will come from: leveraging learnings already learned by others in our own company, and elsewhere. In fact, this is what the Internet is all about. I can’t even imagine trying to do the things we do today without it.
The biggest problem, as you pointed out here, is that it is difficult to measure the impact of knowledge management done right. We are rarely given sufficient time to capture knowledge learned on a project before we are rushed off to the next one. And, who among us has ever been encouraged to review past projects to avoid the mistakes of our predecessors or to tap into the collective wisdom within in our own company to speed product development?
With competition breathing down our necks, perhaps most of us feel like that famous Ferrari driver in the movie “Cannonball Run” when he said, “What’s behind me, doesn’t matter”.