How to Add Value to a Project Using Smart Knowledge Sharing Strategies (Part II)

Author: Adriana Beal

In How to add value to a project using smart knowledge sharing strategies (Part I), we discussed the many reasons for having up-to-date system information available for business and technical stakeholders in order to avoid a dependency created when only the BA is capable of answering questions about software behavior and other project details.

In this second part of the article, I’ll describe the method that has been serving me well over the years, both while the project is underway, and when it’s time the hand over the software product to the maintenance team.

1. Remember: knowledge sharing is not about sharing documents

Many of us would agree that documents are lousy containers for knowledge, and that there is a line of diminishing return as the page turns in a massive BRD. The purpose of your knowledge base is not to control project deliverables, but rather to make useful information easily accessible to the project team and the entire organization. Keep your requirements artifacts stored in their proper repository according to the formal (or informal) process your organization uses, and link to them when necessary, but don’t focus on bringing formal documents to your knowledge sharing environment.

2. Select an appropriate tool to facilitate knowledge sharing

There are many tools that can be used to capture a knowledge base. Unless you have another effective system in place (such as an intranet with a high user adoption rate among your constituents), I recommend using a wiki, a cost-effective solution that facilitates both storing and retrieving information. There are plenty of open source wiki solutions that can be installed for free, providing excellent functionality for creating and organizing content, including ways to link, categorize, catalog, annotate and arrange information, as well as assign searchable metadata to it. Another advantage of wikis is that stakeholders don’t need to be trained to use them to consume information: anyone used to navigating the web will find it extremely easy to browse topics and search for information in a well-organized wiki.

Make sure the selected tool does not restrict you to textual information. A good knowledge sharing environment will accept diagrams, storyboards, and even video to be embedded in its pages.

3. Create a system that makes it easy for people to find the information they need

A good knowledge base will have a solid information architecture to facilitate searching and browsing. In addition to using descriptive titles for categories and pages to make the repository easy to navigate, when applicable I use a system that classifies information in 3 main categories (actual, expected, and future behavior), using different color conventions to make they visually identifiable.

4. Start to selectively feed the knowledge base with relevant information

In my experience, stakeholders’ demands for information follow the 80-20 law: 20% of the total information is needed 80% of the time. Instead of trying to produce “full documentation”, or to maintain the entire collection of requirements artifacts always up-to-date, allow for some of your initial requirements documents, UML diagrams, etc., to become obsolete, and just don’t include their contents in the knowledge base, or remove them from the knowledge repository as soon as they stop to reflect reality.

Business analysts are in a strategic position to facilitate a level of knowledge sharing that avoids information bottlenecks and enables business and technical stakeholders to perform their jobs more efficiently.

When you don’t know where to start, see if you can find any decision tables to bring to your knowledge base (these are typically good candidates for the 80-20 law). Then start adding any “popular topics” that you notice you and other people need to refer to from time to time. As you move forward with the project, pay attention to frequently asked questions, which may include, “who can do X in the system?” (user permissions), “what is the priority for processing accumulated orders?” (business rules), “what happens if the approver rejects a submission?” (workflow) and so on. Based on the most common requests, you can easily extrapolate what type of information is not obvious for most  project stakeholders, and therefore must be kept in the knowledge base for easy retrieval by interested parties.

Tip: Don’t just replicate your requirements documents

Do not assume that the most important information you can bring to the knowledge base is included in your requirements documents. Here are some examples of information that may be important to capture in your knowledge base and won’t be found in many requirements artifacts:

  • Rejected requirements (and why the rejection occurred) to avoid time-wasting discussions that may take place when business or technical stakeholders are replaced, and the new people end up presenting the same ideas already discussed and dismissed for a good reason.
  • Deferred requirements as a reference for planning the next system enhancements and prioritizing future work.
  • Rationale behind system behavior (current or future). Besides knowing how the system behaves, stakeholders often need to be reminded of the why, particularly when conflicting opinions existed prior to a decision, or the explanation for the behavior is not obvious without additional context.

On the other hand, information that is typically found in software requirements specifications and may be left out of a knowledge base include:

  • Formal requirements documents. Unless there is a good reason (for example, a contract is being used to manage a customer-vendor relationship, and there aren’t other convenient places to maintain the documentation), do not bring entire documents to the knowledge base.
  • Requirements that are obvious to all stakeholders. Some requirements become so well-known within the organization that including them in the knowledge base becomes irrelevant. For example, if nowhere in the organization orders with future dates are accepted, and whenever a user tries to enter a future date the system displays an error message “order date must not be in the future”, there is no reason to include this information in the knowledge base.
  • Outputs of analysis exercises that have become out-of-date. Leave out use cases, wireframes and diagrams that may have helped with the analysis and negotiation tasks, but are now out-of-date, and consequently would be misleading to anyone accessing the knowledge base.

The requirements documents and supporting documentation can remain in their appropriate repositories; you should bring to the knowledge base only the pieces of information that remain valid and represent a good source of reference for decision-makers, end-users, developers, or other project stakeholders. Use visuals (storyboards, diagrams, wireframes, etc.) as much as possible to communicate system behavior. In many cases it is easier for someone to “click through” a series of wired mock-ups or screen shots than read a textual description of those images.

5. Teach the stakeholders how to find the information they need in the knowledge base

When someone calls or emails you to ask a question whose answer is already in the knowledge base, provide the requested information, but follow up with an email linking to the appropriate page in the knowledge repository. I always send a polite note reminding information seekers that even though they can contact me at any time for this sort of information, there is a place where they can go to get an immediate response for many of the questions they have.

Most stakeholders will get used to looking in the knowledge base for answers, as long as it is well organized and easy to navigate. Many people will immediately realize how convenient it is to be able to do a quick research any time they want, and reuse pieces of information from the knowledge base in reports and memos they have to prepare, without having to rely on a BA to provide the answers. Sure, some technology-averse people may never let go of the habit of asking you for information, but having an up-to-date knowledge repository will help you save time responding to them as well (instead of having to search inside a specification document to confirm how a particular requirement was written, or trying to find a business rule buried in a use case, you can go directly to the knowledge base and quickly retrieve the answer).

6. Keep feeding the knowledge base throughout the project

As the information in the knowledge base grows, so do the requirements for maintenance. However, this updating process doesn’t have to become excessively time consuming for the business analyst. The best approach is to incrementally update the content based on events such as proposed requirements getting approval or being rejected or deferred, business rules changing, etc. to prevent sections of your knowledge base from becoming dated or stale.

You should be making it a practice to spend a few minutes here and there documenting information such as:

  • Answers for new questions stakeholders ask. There will always be information that someone asks for and isn’t yet in the knowledge base–if it looks like the question is important and may be asked again in the future, make a point to put the provided answer immediately in the knowledge base. The next time the same question is asked, rather than having to rely on your memory, or waste time explaining the concept a second time, you can save time either providing a link to the appropriate page on the knowledge repository, or copying and pasting the requested information to an email.
  • New information elicited from experts. Any valuable information about business rules, work flows, business processes, etc., that will have to be referenced later, should be added to the knowledge base as soon as possible.
  • Changes in the existing content. If you come back from a meeting that changed a business rule or a previous decision about how the system should work, or produced sign-off for a requirement, before getting back to other tasks, update the affected sections of the knowledge base.

Tip: How to justify the time investment

What is being described here may seem like a lot of work, but if you think about it, it is truly more of a “pay now or pay later” proposition. Yes, especially if if you are starting to capture information for a project that is already halfway, it may take some discipline on your part to find opportunities to make progress with the knowledge base in the presence of competing demands for your time. However, once you have stored priority information on its proper place, the fact that it is now available to anyone at any time will start producing immediate time-saving benefits. Not only other stakeholders will be able to retrieve the information they need to perform their jobs without having to ask, but you, the BA, will also start seeing the benefits of having a much more efficient source of knowledge about business processes and system behavior to serve as a reference for your analytical work.

If you are using a user-friendly, well structured knowledge base, after the initial build effort, it doesn’t take that much work to make the necessary updates from time to time. This value-adding activity can actually serve as a good exercise to refresh your understanding of business processes and system behavior, or offer you a “break” from more complex analytical work.

7. Remove information that is no longer valid from the knowledge base to keep it from obsolescence

Some information in the knowledge base will have an “expiration date”. For example, if you have documented a workaround used to perform a task in the system until a missing function is added, the information should be removed once the functionality is implemented.

If you notice that a section of the knowledge base has become out-of-date, and you don’t have time to update it, move the section to a separate archive until you find the time to make the changes. This will minimize the risk of stakeholders stopping looking for answers in the repository after being presented with out-of-date information during a search.

It’s all about adding value

Getting things done in an organization requires a collaborative effort. Holding on to old paradigms such as “knowledge is power” is definitely not the way for a BA to achieve personal development and career progression.  The constant need to clarify system behavior to multiple audiences can drain time and energy away from critical path work. By setting aside time to create and maintain a useful knowledge base for your projects, you will not only help your organization operate better, but also increase your productivity by minimizing the interruptions to your work.

Ideally, other project stakeholders (subject matter experts, testers, etc.) will start producing content for the knowledge base as well. However, even if this collaboration doesn’t happen in practice, business analysts will always be in a strategic position to facilitate a level of knowledge sharing that enables business and technical stakeholders to perform their jobs more efficiently. Even though at times it will feel like you are duplicating work when you have to update the knowledge base in parallel with other project documents, this effort will be rewarded later. The benefits will be felt when business stakeholders start relying on the knowledge base to get answers to support their decision-making about the project, the team is trying to bring a new member up to speed, or you are transitioning out of a position and need to protect the organization from losing knowledge that could take months or years to recover.

Developing an effective knowledge base to share with project stakeholders can become an extremely powerful way to develop a reputation for doing work that “goes above and beyond your job” and stand out from the crowd.

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.


  1. Holly Martin says

    One other cool feature our developers added to our internal Wiki was an import feature. This allows us to quickly create new articles based on an import from a MS Word, PowerPoint, or Visio document, a Rich-Text Formatted document or PDF document. We can also upload images to the Wiki to link into articles. This is primarily the method I use to get process flow information into the Wiki. Nothing is 100% correct after the import, I usually have to do a few tweeks to get it looking properly in the Wiki format. But it certainly saves time when you want to upload a diagram or set of instructions. A lot of our early content for the Wiki came via imports from existing documentation. Definitely a feature to consider if you are developing a new Wiki for your organization.

  2. @Holly — thank you for sharing your wiki categories! I’m sure many others will take advantage of this information. Very good idea to include wiki training as part of your on-boarding process.

    (It’s funny that your 8th category is the ‘Playground’ — WordPress interprets 8 + ) as 8) and it was an appropriate icon for this item 🙂 )

  3. @Tony: Indeed, you inspire me to write down my method for knowledge sharing, which ironically only existed in implicit knowledge stored in my own brain :-).

    “The main problem I have seen in the past with ‘long lasting’ documentation is that as soon as the document ‘owner’ or ‘champion’ moves on (e.g. myself) then the documentation ‘dies’.”

    You are exactly right about the “old school documentation” ownership — even I would have reservations about making changes to a document I don’t own, but in a wiki, there’s no reason not to. If you are reading something and see a piece of information missing, like Holly said, it’s really easy to click edit, type, and save the page. Since it’s not a “document”, but rather a collection of pages that are very easy to update without worrying you may be messing something up, as it is pretty easy to revert to a previous review, the motivation to keep it up-to-date highly increases.

    “I was wondering – do you know whether any of the wikis you have set up at previous clients are still going strong after you moved on? What is the ‘keep alive’ success rate?”

    I do not have information from all projects, but I will say that at least two clients, when talking to me months after I left, mentioned the wiki as one memorable contribution I left behind. In a third client, a wiki was already being used by a separate IT team, which I learned when I started talking about installing one. When I spoke to this other group, they explained that in the beginning, there had been some resistance, but with time, when people started seeing how much easier it was to access all sorts of information from their various projects (from URL and login to test environment to the steps followed to get sign-up and so on), it really took off. In this client, when the team I was working with saw what the other team was accomplishing with their wiki with much less effort looking for information, they immediately embraced the change.

    Today and tomorrow I’m transitioning out of another project, and training the lead BA that will take my place. Almost everything he needs to know is in the wiki — from project information to the steps of the requirements definition process to email templates we use to inform a requirements package is ready for stakeholder review. In this project, the program manager immediately took co-ownership of the wiki, and started feeding it as well. That gives me certainty that the knowledge repository will not die after I leave.

    “I guess part of the challenge is making sure the wiki is truly collaborative, and that everyone feels empowered to contribute and maintain it.”

    Fortunately, I do not think this is a condition for the success of a wiki! To repeat what I said in the article, “Ideally, other project stakeholders (subject matter experts, testers, etc.) will start producing content for the knowledge base as well. However, even if this collaboration doesn’t happen in practice, business analysts will always be in a strategic position to facilitate a level of knowledge sharing that enables business and technical stakeholders to perform their jobs more efficiently. ”

    See, as happens also with Wikipedia, the majority of people will be information consumers. They won’t feel comfortable contributing, but will enjoy the benefits of having the information there for their consumption. It is possible that part of the history of the project will not be capture if other business and technical stakeholders don’t contribute, but the core knowledge, which the BA has access to, will.

    In my projects, the only condition for sustainability was for someone to take ownership when I left. If the new BA is convinced of the value (and there is no reason not to be, considering the time-saving benefits it brings, not having to search for information in various places), he/she can easily keep the repository “alive” after you move on.

  4. Holly Martin says

    Wow, this is so apropos! We have actually been using a wiki for a couple years now. It took a while for it to catch on, but it has really helped to facilitate knowledge sharing within the IT department and beyond. I frequently point my business stakeholders to our Wiki as a starting point for their research for new projects. They got so excited about it they created their own Wiki for their department.

    The Wiki categories we came up with over the past few years are:

    1) Architecture ‎
    2) Business Process
    3) Delete – used to flag articles for deletion, that review team will review and purge on regular basis
    4) Glossary – articles that describe terminology
    5) Grain of Salt – used for articles that are bits of knowledge that you’re not 100% sure about, but think it worth sharing
    6) Information
    7) Instructions – how-to articles
    8) Playground
    9) Releases ‎- our web team uses this to dynamically capture which enhancements/projects are going into a release, and where they are at SDLC lifecycle (extremely helpful when keeping track of what off-shore teams are doing)
    10) Schedule
    11) Standards
    12) TestCase ‎
    13) UseCase

    We also created a short on-line training course for user to take to learn about the Wiki, how to find content, how to add content, etc. We put this in our list of new hire on-boarding training courses that folks can take their first week on the job. I think that helped from a grassroots standpoint since new coworkers are more likely to adopt something new (it doesn’t come across to them like it’s yet another task for them to complete in the day).

    Wikis are so much easier to update than your standard documentation, which is why I think it’s taken off. Of course, you still need to take the information with a “grain of salt” and check who last updated the article and when it was last updated. But the Wiki is a great starting point for BA’s when they begin their analysis. It’s also a great place for sharing tidbits of knowledge that you think are useful beyond the project your working on.

  5. Hi Adriana,

    First of all, I’m glad our conversation managed to inspire your article. I knew some day I would add some value somewhere 🙂

    I think using a wiki is a great idea. As you said, it’s much more immediate, available, maintainable and searchable than ‘old school’ documentation (there we go, Word docs are already ‘old school’!)

    In fact your post is very timely as we are just considering creating such a wiki at my current client – initially to capture ‘system overview’ level information. The starting point for this was a very good PowerPoint slide deck that a colleague produced which gave a 10,000 foot overview of the system. We wanted a way to make it accessible and maintainable, and a wiki seemed like a great way to do this. We’re planning to use SharePoint, so I’ll let you know how we get on.

    The main problem I have seen in the past with ‘long lasting’ documentation is that as soon as the document ‘owner’ or ‘champion’ moves on (e.g. myself) then the documentation ‘dies’. I think this is especially true of ‘old school’ docs which have a definite author/audience concept – there seems to be a real barrier to a new author picking up an existing document. You would hope that a wiki (used collaboratively) would remove this problem. I guess part of the challenge is making sure the wiki is truly collaborative, and that everyone feels empowered to contribute and maintain it.

    I was wondering – do you know whether any of the wikis you have set up at previous clients are still going strong after you moved on? What is the ‘keep alive’ success rate?

    Great article BTW, thanks for sharing.

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)


Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.