Knowledge Management in projects?
Hi you all PM collegues in LinkedIn!
I would like to start a discussion about Knowledge Management tools & techniques, processes and best practices you are exercising throughout the project's life-cycle in projects and/or programs you manage. I have strong personal interest in KM (Knowledge Management), and am trying to make some more ideas to study and model in the thesis I'm working on.
I have identified quite a few of different practices, but would like to receive some more from the experts in "real world" (to avoid too "academic approach") - what is your approach for managing the knowledge, and what do you consider when planning, managing/controlling and closing projects?
Plenty of thanks in advance!
Clarification added March 22, 2007:
Thanks guys for your excellent replies, much appreciated!
I would like to elaborate my idea behind - what I have in my mind is to establish PMI type of processes for KM where there are inputs, tools & techniques and outputs in three process areas:
1) Knowledge Planning & Estimating,
2) Knowledge Assurance, and
3) Knowledge Distribution
Inputs in first process area are Scope Statement and Communication Plan (I haven't detected all, yet). In first process area my idea would be creating Knowledge Management Plan (output) that gives the frame for controlling the processes during project's lifecycle (tools & techniques in 2nd process area). In last area I am trying to define necessary actions for delivering the "collected knowledge" for the use in organizational level.
I'm familiar with the social aspects, and also that tool alone isn't the answer. I'm trying to establish first steps for managing KM with process-oriented aspect, from there the KM could be leveraged further (and after when all the challenges appear, like you guys have mentioned - I do understand that this is not a straight-forward process but I think this could be a starting-point for the better future :) ).
Shortly, more sharing of thoughts about different tools & techniques, processes etc. how you people try to "collect the knowledge" from people (even when having the "short-term view", e.g. risk that some of key resources leaves project)
Thanks again!
Answers (6)
Terrence H
Young Professional Seeking a New Challenge
Best Answers in: Personal Investing (1), Personal Real Estate (1), Starting Up (1), Computers and Software (1), Telecommunications (1), Using LinkedIn (1)
Terrence H suggests this expert on this topic:
Bob B
Product Development, Engineering and Quality Executive and Consultant
Best Answers in: Organizational Development (6), Product Design (4), Change Management (3), Planning (3), Labor Relations (2), Project Management (2), Staffing and Recruiting (1), Business Analytics (1), Manufacturing (1), Supply Chain Management (1)
This is a partial answer but I will say that after attending a seminar from Afterburners (general business topics) on their Flawless Execution (see link below) model my opinion about debriefs was altered forever. My organization start applying this within projects/programs since it made so much sense that teams learn (at least for themselves - not necessarily record for others) from frequent debriefs almost at a task level. I had several programs where this became a habit, seemed to be very low overhead once it was a habit and promoted learning and improved team performance. We still did end of project big postmortems that rarely seemed to have a great payback from a "teaching" perspective.
How things are recorded and how other's learn is another challenge. I have experience creating "books of knowledge" that frankly became unwieldy. Lately since I began consulting I have seem some organizations use wikis to good effect.
The other personal experience I have at a corporate level is that starting a KM initiative based on a "tool" instead of looking at behaviors is a recipe for failure.
Bob Becker
www.pd-advantage.com
Links:
The best KM approach I have seen in the field is having a sharable repository for project document and notes -- like Sharepoint or even a simple file share. But this can be made ineffective if allowed to become stale -- especially if the project principals keep private pools of documents that are only occasionally 'shared'. Being too clever with access restrictions can also be fatal -- better to have an audit trail and frequent snapshot recovery points. Using structure to facilitate access is also helpful -- massive project documents are deadly.
Requirements management systems are one specialized way to capture knowlege -- but usually too expensive/complex for mere mortals. There are simpler tools -- like MindManager, that can provide this function, though with less fluid access.
The social aspects of effective KM cannot be underestimated -- it is a human thing to have private pools of information, particularly in low trust organizations. The technology will work only to the extent that the team members and broader organization believe that a free exchange of information is more beneficial. That having been done, the work process should be structured to ensure that the shared repository remains current.
Links:
Hi Marko,
Above all, the most important part of any knowledge management enterprise is the human factor and participant buy-in. If you do not have an executive sponsor on board to champion it and selling the benefits then it is doomed to failure, even if the technology is really easy to use (like Sharepoint).
Good luck!
Alan A
Business Change and Information Technology Professional
Best Answers in: Career Management (1)
In many ways, I think Knowledge Management is similar to Risk Management. In practice, although one can consider either in isolation, effective Knowledge Management, like effective Risk Management, is an integral part of all project activities. It occurs to me that there is a very real sense in which projects just are Knowledge Management or, if you prefer, a project is an approach to Knowledge Management. And while the essence of risk is uncertainty, the essence of knowledge is certainty, albeit sometimes of a rather formalised and unconvincing kind. So I would certainly consider it useful to manage risk and knowledge in comparable ways. In the end, it all comes down to assumptions, and we all know how dangerous they are. Projects only exist by virtue of their assumptions, however. We may call them "scope", "requirements", "critical success factors", "context" or what have you, but they are just the premisses we assume when determining what the project's actions will be. In other words, it's all about decisions and their rationales. But so is everything else in a project... at least when considered as a goal-oriented human activity system.
So the project's actions derive from its decisions, and its decisions have some rationale. Which decisions are recorded, where, how and by whom are, of course, also decisions and also have some rationale. We are saved from an infinite regress only by the principle of authority. Ultimately, a project is an extension of the will or intent of one or more individuals with sufficient authority. Understanding the rationale for this fundamental intent, together with all the supplementary beliefs and opinions that inform subsequent decisions (including "domain knowledge"), is, for me, what Knowledge Management is all about.
We see something of this in the idea of the traceability of requirements. Requirements themselves are often taken as axiomatic, or related half-heartedly to higher level objectives. Attempts to expose the real rationale of requirements are rare. And as requirements are taken forward into solutions, the rationale behind the solution designers' decisions is also often undocumented, commonly unspoken and sometimes effectively arbitrary. This state of affairs is not necessarily deplorable. But if requirements traceability has value, it is in the promise that the effects of a change can be more efficiently understood. In the real world, any of the other factors that influences any of a project's decisions is also subject to change. Which brings us back to Risk Management. Understanding the potential consequences of potential future changes is a key influence on decisions about the extent to which rationales need to be recorded, validated and communicated.
In principle, we document all decisions and their rationales. In practice, we may decide not to... in which case, we should document that decision and its rationale. Any information that does not figure in any of the project's rationales is, it turns out, irrelevant.
Have you considered a wiki? My team uses pbwiki.com to share news and information on our rapidly changing environment. We've set up various categories and folks just add to the category page when they come across something new.
If you go this route, you'll need someone to maintain the site occasionally in a "gardener" role. I just listened to a couple of great podcasts on the subject - check out The Engaging Brand's recent material on social media in business operations and the Business Week technology cast on corporate wikis.
One other thing - I recommend starting small and encouraging organic use as people get into the habit of checking the wiki updates. My organization hasn't adopted wikis as a common tool, but I think we will gradually get there.
