In Pursuit of a More Perfect Knowledge Base

In my junior BA days, I worked at a financial services company, where I collected obscure details during requirements elicitation like a child collects rocks. I collected tribal knowledge from subject matter experts about systems they helped design years before. Sometimes the knowledge was so old that it only existed in an email, their paper notes, or worst of all, in someone’s head. I hadn’t learned yet about requirements reusability, or requirements repositories.  I eventually accumulated three thick binders full of notes that lived on my desk. I referenced them often enough that I could not imagine disposing of them, but I had no way to digitize them either. Leaving them behind when I moved on was one of the hardest things I ever did professionally, because I strongly suspected no one bothered to look at them again. I try not to think about them ending up in the recycling bin.

In the next couple of roles, I used Confluence’s wiki features with some limited success.  Each role gave me a perspective on how different teams can manage their knowledge base, but neither of them had a fully realized concept. I asked everywhere I went, “How do you store your requirements? How do you keep information cataloged so you can come back to it later as a reference?” Mostly, I got bemused responses. No one seemed to have a perfect system for retrieving, analyzing, correlating, and reusing requirements from earlier projects. Success largely depended on someone who knew exactly where to go for exactly what kind of information. Once a business analyst or project manager left, it became exponentially harder to track down. That experience taught me to leave as many of my notes as possible in public repositories like SharePoint or the project tools.

Then I met a business analyst who used Microsoft OneNote as a knowledge base and realized I had met a kindred spirit. When we became a team, she showed me her accumulated store of knowledge. What I had done with binders, she had done electronically throughout a two-decade career.  Like me, she had dumped emails, notes, bits of SQL, and other information in the Notebook. She freely shared it with others in the organization, but quickly found the rest of the company was less enthused about using OneNote than she, and few accessed it regularly.

The main problem with both our methods had been a lack of consistency in what we collected and how we managed it. Another significant challenge was that our organization liked to swap out development and PM tools every couple of years like out-of-season clothing.  I nearly cried after she told me about a treasure trove of requirements locked up in an old version of EA Sparx that only existed on her computer, and even she could not access them anymore because the license expired.

Together we brainstormed documentation approaches that would transcend the tools.  She developed an elegant template to introduce both organization and consistency to our OneNote knowledge base. Rewriting and “template-izing” the entire body of work is unrealistic. Instead, we apply the template to new entries, and update existing entries in the new format as enhancements prompt changes.

We use a wiki-like approach. Since we store requirement documents within project tools, the knowledge base only needs to describe a feature in enough detail to help us find the rest of the source material. The template allows us to cross-reference related system features or processes. Microsoft OneNote can hyperlink to pages within itself, supporting a correlation between two related entries. If we stop using Microsoft OneNote someday, we can export entries to whatever new tool we want. While some convenient features of OneNote will not translate to a new tool, at least the cross-reference notations will carry over and we can rebuild them.

These are the sections in our knowledge base template. In our instructions, we refer to whatever we are documenting as “this,” which clarifies that “this” could be a process, a procedure, or something else. One sentence is enough to start a section. As we have more information, we add to it.

• What is “this”?
• Why is “this” in existence?
• When is “this” used?
• What is the history of “this?” We include historical context because it helps us understand the evolution of it.
• Where is “this?”  If we are documenting software, we describe what application has it. If it is a process, it may live within a department repository. We leave a map for how to find it as needed.
• Who is “this” for?  We track who owns the topic, who uses it, and who cares about it.
• What are the inputs and outputs of “this?”  This detail enhances traceability to other processes and workflows.
• What business rules govern “this?”
• What is the procedure associated with “this?” If there is a specific procedure or user guide, we merge it, or point to the site of the source document.
• If “this” relates to another piece of software, we include a cross-reference to that too.

New entries have less detail at first. We know that over time the entries will become more robust, because the knowledge base is a living repository whose contents can change daily.  Ideally, we’d like to start with a complete entry, but even we have a hard time maintaining that standard. To improve our completion rate, we start new entries during a project, and add a bit of information at a time, then complete and merge knowledge base documentation in our project closeout activities.

Let me be the first to admit this is not a perfect tool, nor is it a requirements repository. Nevertheless, having some information for starters has saved me time tracking down the right subject expert, and has even given me enough information to ask better questions to make more efficient use of their time. It serves as a critical piece of business analysis information and is a handy tool in my BA tool belt.