Documenting institutional knowledge and legacy systems

Question

I am a long-tenured employee at my company and have become the subject matter expert for our business rules and the reasoning behind them. Additionally, I'm the last person around that knows the legacy systems which means I'm often the bottle neck for issues/questions and the first person who gets called if something goes wrong.

I want to start documenting all of this information so that my coworkers have access to the information they need and if I'm hit by a bus, operations can continue successfully. The things that need to be documented are a) hardware and software infrastructure and b) business rules and processes, so the format and process of collecting this disparate information may be different.

We currently use the Confluence wiki, so that seems like a good place for the documentation to live, but the body of knowledge is both wide and deep, so I'm looking for advice on processes or tools that I can use to get started.

EDIT: To address the (insightful) first comment. We are looking to replace a lot of the legacy system over the course of the next year, so the documentation I'm looking to create won't be so much a "living document" but an explanation of the current state so that the information lives somewhere other than just my head.

Answer 1

First off, congratulations on taking the high road. Too many IT "professionals" that I've worked with would use this kind of situation to extort ludicrous salaries from their employers.

We currently use the Confluence wiki, so that seems like a good place for the documentation to live, but the body of knowledge is both wide and deep, so I'm looking for advice on processes or tools that I can use to get started.

Since this is a PM board I'll answer your question from a PM perspective, in other words more around the process rather than the tools.

• Establish a vision. Make sure you get your senior leaders to sit down together and agree on what they want to accomplish with this project. This provides a common set of guiding principles to focus your work within particular boundaries. Don't just assume everyone has the same big picture in mind, the risk to your project is too severe if they don't.
• Define needed business capabilities. Start at a high level. Start out with your "project product" and break it down from their into subcomponent products. Initially only do this to the point where you can get a high-level cost/benefit assessment going. Trivial example is a cake (project product) needs equipment, ingredients and cooking instructions. Equipment includes oven, pan, bowl, mixer, etc. Ingredients can be subdivided into ingredients for the batter and ingredients for the icing. Cooking instructions can also be subdivided according to batter and icing preparation.
• Document your initial business case. Using the initial business capabilities that have been defined above figure out if there is a valid business justification for proceeding. Remember that "doing nothing" is an option that should always be on the table.
• Do your analysis and define requirements. Assuming you have a valid business case, spend the time/effort/$$ to go into greater detail with your analysis of business capabilities needed and the system solutions available to deliver those capabilities. This includes getting enough data to make a build-or-buy decision. Note that this and the next step will be iterative, you should time-box your analysis efforts to avoid wasting time on something that won't fly at the end of the day.
• Refine your business case. As noted above, iteratively refine your business case on a regular basis. With each iteration make sure senior leaders agree that further effort is worth pursuing. As soon as you no longer have a justifiable business case become a forceful advocate for closing the project.
• Start "working". Most senior leaders will want this to be the first step of the process. Fight this. You won't save any time in the end by starting early but will certainly raise costs associated with unnecessary rework.

Answer 2

In terms of processes, Doug B's answer covers this pretty well, so I've gone ahead and up-voted that.

In terms of tools...

... the documentation I'm looking to create won't be so much a "living document" but an explanation of the current state so that the information lives somewhere other than just my head.

In that case, you don't really need a wiki. It's complete overkill, and unless you already have the Wiki up and running for other "live" documentation needs, I'd say it's a waste of time (and resources), given that a static, print-friendly document will do just fine.

Having said that, the Wiki does provide useful navigation functionality (such as links to categorised pages, and the ability to search), but I'd first make sure your colleagues are comfortable navigating / reading the Wiki, otherwise you're probably better off with a simple PDF that can be kept on file.

It really all depends on your company and their level of IT savviness.

Answer 3

I also applaud your desire to share your knowledge, having worked recently with a hoarder and been reminded how unpleasant that can be.

I would still vote for a wiki, because in my experience

1. plans to replace legacy systems WILL take longer and cost more than anyone currently expects - and have every possibility of being cancelled although no one will likely admit that today.
2. even if everyone is diligently pursuing the replacements, one often doesn't have the luxury of aiming at a fixed target. If ANY enhancements are being made to the legacy systems, a wiki where someone (probably you) can make changes to the (hopefully minor) changes to the system, and others (the people building the replacements) can subscribe to those pages relevant to their pursuits... you've solved a LOT of the communication problem that can bring these types of efforts to their knees. (Or the participants to blows...)

Good luck!!

Answer 4

My thought is to use the ribbit tool for the storing the documents, sharing the documents and a great collaboration tool. It has facilities like ask, sending e-mails etc...

Check this site for more information: http://www.ribbit.net/tools/collaboration