Building a Catalog of Resources

In our previous, blog You Are Here - Mapping an Organization," we discussed mapping an organization from the perspective of the customers and clients. In that exercise we began to build a resource of reuseable information around your organization’s attributes, including:

  • A list of products and/or services, their key features and the target audience.
  • A list of the client’s key stakeholders and their contact information.
  • The products/services they have purchased, licensed, or contracted for.
  • Any client Service Level Agreements (SLA’s).
  • A list of competitors and what differentiates them from your organization.

In this blog, we’ll continue to build a catalog of resources by auditing your organization’s existing internal documentation.  

Audit Existing Documentation

You may be tempted to skip this exercise, thinking it’s a waste of time, but don’t. 

The advantages of auditing existing documentation include:

  • A more detailed understanding of the business processes, products, and services.
  • Identifies the structure of the organization, key stakeholders, and user perceptions.
  • Provides a timeline/roadmap of previous implementations and acquisitions.
  • An increased level of confidence and efficiency, when engaging with stakeholders.

Knowing what you already have and whether it is working or not vs. what you need to update, simplify, clarify, or create from scratch will save you time in the long run. So take the time now or risk wasting your time and the stakeholder’s time later by trying to reinvent the wheel.

Where To Start and What To Look For?

Documentation is, typically, geared toward a specific audience. Deconstructing existing documentation from various departments or levels within your organization will give you an organic view of the business from the multiple perspectives needed to make meaningful decisions. For this exercise we recommend that you begin at the operational level including, but not limited to the review of:

  • Operations and/or process training manuals.  
    • There may be more than one type of training manual based on the various roles within the organization.
  • Any other documentation used to perform daily, monthly, and annual tasks.
  • Client specific operational/process documents.  
    • These documents usually contain customized workflows, rules, inputs/outputs, etc.
  • Client specific Service Level Agreements (SLAs). 
  • Departmental policy and procedure manuals.
  • Government/Agency rules that must be implemented – e.g. HIPAA or FCC rules, etc.
  • Computer/software training manuals and videos – these may be role specific.

Again the purpose of this exercise is to get a deeper understanding of your organization and to identify any gaps in the existing business analysis documentation. In some cases existing BA documentation doesn’t exist and must be created from scratch. This can occur in organizations for a number of reasons, such as the case where developers interacted directly with users and implemented solutions without documentation (shut your mouth Betty – say it isn’t true!). 

As you’re reviewing this information, begin building your catalog of resources to either create new BA documentation or to confirm that the information is captured, accurately, in existing documentation. These are some of the things to look for and note:

Glossary Definitions

Note any unique key words/terms that are specific to the business, the workflow, product, etc. that require a definition.  

  • Keep in mind that the development and quality assurance (QA) teams may know nothing about your organization or what it does. This is especially true of offsite/offshore teams.

Roles

Identify the various roles/users that will interact with the process, software application, etc.

  • Don't forget to capture any third party providers that your organization may interact with such as fulfillment houses, printers, providers of products/supplies, etc.

Key Stakeholders

Previous documentation may indicate who the key stakeholders (e.g. key decision makers) were in the past and gives you an idea of who was involved in the approval process.

  • Although actual stakeholders may change over time, all stakeholders areas should be represented. For example, if software is part of the solution/enhancement, don't forget to include areas, such as Product, Development, and Quality Assurance. Including key stakeholders early on in the process will streamline the requirements approval process later.

Process/Task Flows

Whether labelled as a work flow, task flow, or process flow, you're looking for a sequence of predefined steps as it relates to the interactions of the organization. These steps can occur based on human and/or systems interactions.

  • The easiest way to document these types of flows is by using visual flow diagrams like you would find in Visio. However, for various reasons (e.g. size, lack of previous business analysis, lack of a formal documentation process, etc.) an organization may not have visual modeling, flow diagrams. What do you do? Look for a sequence of steps or patterns in the text of the documentation to begin building your own flow diagrams. 

Business Rules

A business rule is, basically, a statement that defines part of the business as something that should or should not occur based on set criteria and/or conditions. Look for specific policies, procedures, regulatory rules, operational rules, calculations, conditional decisions, industry standard rules, and any type of criteria that enables the organization to achieve their goals and maybe your bonus!

  • When documenting these rules, ensure that they are non-conflicting and finite so that when they are tested the result would be true or false, pass or fail. Complex rules that contain multiple conditions, should be broken down into multiple business rules so that there is no ambiguity.

Congratulations - you're well on your way to creating a catalog of re-useable, updatable resources!