Being a PM while executing many project, it's vital to retain project specific knowledge to be used in future projects as well.
What are the techniques that could be used to assist this kind of situation?
-
1You question is currently receiving close votes, probably because you have asked for tools recommendations which is off-topic for this site. However the question itself covers a very real problem faced by PMs. I have edited your post to remove the toolset recommendation request. If you disagree with my edit, or wish to state your case in a different way, please re-edit the original question to remain on-topic and, hopefully, attract further useful answers to this real-world problem.– Marv MillsCommented Mar 17, 2015 at 15:28
-
possible duplicate of How do you encourage project members to document their work for end-of-project handover?– warrenCommented Mar 19, 2015 at 19:32
-
Some what correct Warren, but not exactly the same. End of a project we can have some deliverable to capture knowledge in formal ways like, As-built document, configuration, design document etc. But there is a lot not captured with those exercise, which are informal and tacit. I am concern about those areas actually.– Nuwan PereraCommented Mar 20, 2015 at 22:04
Add a comment
|
4 Answers
Internal Wikis
The best tool that I have run across for knowledge management in any organization is Atlassian's Confluence product. It's an easy-to-understand and easy-to-edit wiki that makes it extremely simple to document decisions, meeting notes, releases, file lists, and shared links. You can create specific spaces for each of the projects in your portfolio and create a company internal space to share knowledge company-wide. It also allows for a blog in each space to keep your employees up-to-date.
Barring this, I would search for another internal wiki program that you can use.
It also helps a great deal to put someone, or a member of each project team, in charge of ensuring that the appropriate information is cross-pollinated in the company. Specific domain knowledge for a project can remain in that project's space, but information that would be useful company-wide should be posted to a more general area.
Enterprise chat/social tools such as HipChat & Yammer can be really effective, especially for distributed teams. Wikis are also great: Confluence, as @JDRoger suggested, and SharePoint are the go-to solutions. The initial investment and rapid learning curve make Confluence a really good choice.
As for processes, agile practices (e.g. scrum) can work really well for communicating day--to-day knowledge. If you're looking to capture knowledge more permanently/broadly, you like to consider post-implementation reviews and publishing project docs on an internally accessible intranet/wiki. For encouraging knowledge sharing amongst your staff, you could explore internal staff secondments and using cross-functional project teams.
Effective knowledge management is based on 3 key factors (this is not a prioritized list):
- Tools
- Process
- People
Tools
There are various knowledge management tools out there. Some good ones were mentioned in others' answers here. Personally, I have very good experience with Confluence.
Important criteria you'd like to consider when choosing such a tool is how easy it is to create rich content in, and even more importantly, how easy it is to find and retrieve content. You'd like to have some control on the structure but still provide freedom for people to arrange their content in their domain. Ideally, you'd like the tool to be integrated with other tools you're using. In a software development project, you'd like integration with issue tracking and build system tools, for example.
Process
This is a tricky one. You can make a great tool available to the teams, but if you don't define a process for creating and arranging content, soon enough you'll get a chaotic mess. OTOH, too much of a process would make people think twice before creating content and they'll procrastinate on it.
You'd like to create high level guidelines and still leave room for people to define their own structure. You should create high level "spaces" in the tool and leave the inner-space structure for the owning team.
People
This one is key. You need to create ownership on different domains of the knowledge. Usually, you'd like to locate one person per domain (could be per team) that are very good at knowledge sharing. It should come naturally to them and they should really love it. Make them responsible for the knowledge management of their domain. It doesn't mean they are responsible for creating the content, but rather they should be responsible for grooming their domain's space and helping others in doing it the right way.
Doing this one right would enable the knowledge base to be maintained in a usable state for long periods of time.
I strongly support the usage of tools like Atlassian's Confluence (+1, JD!).
It's really important to have the knowledge documented anywhere.
Happens that, Confluence provides you information, and what we want to keep and spread is knowledge. In this sense, the ITIL's Knowledge Management area gives us some good hints on how to make sure we're storing and using our team's knowledge.
In my project, we have the information in Confluence. From time to time, people from different areas / components present what they have to the others, in order to 'link information up', creating the knowledge everyone needs.
Besides, is healthy to have people moving around projects, but it's easier said than done. In this case, an approach that values people willing to work at different projects is also important - as long as this movement is also beneficial for these projects, of course.
answered Mar 22, 2015 at 22:40
