How to Get Long Term Value from Business Analysis Work Products


NOTE: If you comment on this article you will be entered to win a free copy of Jarett's book: "Business Analysis Based on BABOK Version 2 - A Pocket Guide".

Business Analysts do great work for their organizations. One of the challenges BAs face is that the scope of use for their work products is often limited to the project or situation they are working in; as a result that great work can ‘die on the vine’. Whether it’s a requirements document for a solution enhancement or a stakeholder analysis for a business case, the information cultivated by the Business Analyst can often have use beyond its initial purpose. How can we make BA work come alive for the entire organization?

The key is to figure out how to get this information into the hands of others who can use it when needed without spending so much effort that it would have been more efficient to simply redo the work when it is needed later.

We can use a step-by-step approach to proactively integrate business analysis work products into organizational operations as they are developed:

  1. Identify the relevant business analysis work products that have potential for benefits beyond their initial scope;
  2. Determine the operational assets that would be the best place to store the information once it is complete;
  3. Develop a process to integrate and the information into the operational assets; and
  4. Deploy the process into all business analysis activities in the organization.

1. Identify Relevant Work Products

There are several business analysis work products that are candidates for integration into the organization:

  • Requirements: requirements are often viewed as a point-in-time representation of certain needs of the organization. However, just because those requirements are met doesn’t mean that the organization no longer has those needs. Business and stakeholder requirements often have longer lifespans and are addressed by multiple solutions within the organization. Once identified, they should be catalogued so they can be continually evaluated for relevancy and currency based on the organization’s goals, opportunities and objectives.
  • Business architecture: artifacts such as business processes, business rules, term glossaries, business information catalogs and the like are all things that are particularly useful in the day-to-day operations of the organization.
  • Stakeholder analysis: some of the information documented during a stakeholder analysis can be of use after an endeavor is complete. Things like the organizational structure, key resources, business drivers and group goals and objectives are all relevant on a continuing basis.
  • Business case: the problems and opportunities identified in the business case can be leveraged to assess the ongoing strategic direction of the organization.

2. Determine Operational Assets to Store the Information

In order to leverage business analysis work products you need to find ways to make them relevant to the organization’s daily operations. Integrating the information into existing operational assets reduces the friction of trying to introduce yet another manual, website, database or other item that the organization must remember to use and maintain. Here are some of the items that most organizations will have and where business analysis work products fit in nicely:

  • Procedure Manuals: most mature business processes will have detailed procedure manuals for day-to-day operations. These manuals often are the hands-on guide to getting things done. Business process diagrams, business rules and term glossaries can be easily integrated into these materials. If you develop your business analysis work products with this end goal in mind, the transition into these manuals can be relatively seamless.
  • Strategic Road Map: Executives often have a strategic road map that lists their possible opportunities and current priorities. New opportunities and problems that are identified in the business case should be migrated into the road map, whether the business case is accepted or not.
  • Product Backlog: Organizations that develop products (or other solutions) and use a backlog to track potential changes, enhancements or other features should take unmet requirements and add them to the backlog.
  • Organizational Knowledge Base: many organizations have developed internal websites with some form of knowledge base for key information, whether it is self-maintained in a Wiki or is managed through an organizational group. Business terms, business rules and policies, and stakeholder analysis information can be transitioned to this type of knowledge area.

3. Develop a Process to Integrate the Information

Once you know how you want to have this information stored within the organization, identify the groups responsible for maintaining the organizational assets that you wish to integrate with. Develop a change management process with them so the information will be consistently integrated after each business analysis endeavor.

Ensure that the timing of the integration makes sense given the type of business analysis work you are doing. For example, you may not want to integrate business architecture information until the solution has been deployed and the future state has transitioned to the current state. Also consider who will be responsible for reviewing and approving the updates, and who will make changes in the future.

4. Deploy the Process

Develop a procedure manual that can be used by Business Analysts that summarizes the above steps and then deploy it within the business analysis practice in your organization. Like any new process, you should establish a way to monitor its operation, allow for feedback and develop a method to identify, assess and implement improvements.

Determine who is responsible for managing this new process. If your organization does not have a formal business analysis organizational unit or community of practice, then identify the individual(s) who will be tasked with overseeing its operation.

Case Study: Actionable Business Architecture

With one of my clients there was a team of Business Analysts working on a large change project lasting well over a year. We wanted to ensure that their future state definition of how the business would work once the changes were deployed would not be lost once the project implementation was complete. As a result we focused from the outset on developing an ‘Actionable’ business architecture that would integrate into the organization’s day-to-day operations. The business architecture consisted of:

  • A functional decomposition of all the organization’s business activities;
  • Business processes for each major business function;
  • System-level business procedures that integrated business rules and decision criteria into the procedure manuals; and
  • A business glossary.

As the organization did not yet have a consistent approach to documenting processes across the entire enterprise, a new knowledge management solution was adopted as part of the deployment of the business architecture. We used several applications to develop the business architecture materials and then integrated the outputs into the knowledge management solution.

As several of the business processes spanned multiple organizational units the architecture was organized functionally, which enabled the team to develop a clean hierarchal map on the home page to allow people to navigate to the processes that were relevant to them. Supporting documentation was managed through a document management repository with the links to documents integrated into the procedure details, so people could access the information when they needed it for a particular process.

These artifacts were not only used in operations but during the testing and training phases of the implementation, which reduced overall effort and ensured that stakeholders were familiar with the outputs before the solution was implemented.

One of the measurable outcomes we are monitoring for this solution is the percentage of support requests that are already answered in the procedure guides. This will help assess the value of the materials and the adoption rate within the organization. We anticipate the percentage to steadily decrease over time as stakeholders become more used to going to a single reference point for all business processes in the organization.

Determining the Right Fit for Your Organization

While there are many opportunities to make business analysis work products more relevant to your organization, I recommend starting with finding one or two value propositions and start with those. Once people realize the benefit it will be easier to get support for further integration. Keep in mind that at some point there is not enough benefit to warrant the effort; sometimes it is easier to re-invent the wheel given the cost of reproducing the wheel in a general format for many different audiences.

What do you think?

Comment on this article and you will be entered to win a free copy of Jarett's book: "Business Analysis Based on BABOK Version 2 - A Pocket Guide".


Author: Jarett Hailes, CBAP is President of Larimar Consulting Inc. and the author of Business Analysis Based on BABOK Guide Version 2. Jarett loves to work with the executives of organizations to realize their goals through business analysis and design.  Jarett also creates and delivers business analysis courses at the University of Alberta and MacEwan University.




“IIBA®, the IIBA® logo, BABOK® and Business Analysis Body of Knowledge® are registered
trademarks owned by International Institute of Business Analysis. These trademarks are
used with the express permission of International Institute of Business Analysis.”

Like this article:
  8 members liked this article


Ryan Milligan posted on Monday, August 11, 2014 3:32 PM
I agree that it's rather unsatisfying to spend hours upon hours creating and refining a deliverable only to have it ignored after the implementation is complete. As a BA, I always look for ways to re-use materials I've written, or at least parts of them. In my experience, I have had more luck with the leveraging content of process-based work products than system-based work products, as business processes tend to change very slowly over time. Functional requirements, on the other hand, are usually exclusive to the system, so there's usually nothing I can do except keep them around for when they need updating. If anything, I re-use templates if I think they are suitable fits for other projects.
Nitesh Sharma posted on Wednesday, August 13, 2014 12:35 AM
There are so many examples where companies wanted to get their applications document done or it is outdated. But have not come across any tool or set method to have these doc created and maintained. With time user/dev team/support team keep chaging and with every change the knowledge is lost... It is very important to think over the same .
Mark Monteleone posted on Wednesday, August 13, 2014 10:23 AM
Jarett, thanks for this reminder on incorporating BA develiverables into the business beyond the project at hand.

I agree with Ryan that process models have the best chance of being incorporated in the business.

Satya posted on Tuesday, August 19, 2014 2:35 AM
Generally in the scheme of things of the change an organisation needs, the long term aspect of the work is given a lower importance. I agree that the re-usability aspect of the BA work should be given equal importance as given to the work itself. This will result in convenience, cost saving and hassle free future work.
mariehalsey posted on Tuesday, August 19, 2014 11:44 AM
Excellent article Jarett!

Developing a reusable and accessible enterprise knowledge base can be a powerful and effective tool, particularly in large and mature organizations where word-of-mouth is insufficient for seeking reusable assets.

In addition to the examples provided above, I would also add a few more:

1. Data models developed for specific projects can be used to help build out and refine the enterprise data model, which in turn can be leveraged to inform data model development on future projects.
2. Non-functional requirements are often applicable across an organization, regardless of the project in which they were initially identified. Security and performance requirements are good examples.
3. User interface requirements can often be re-used, particularly related to the overall look and feel, branding, accessibility, etc.
4. Business Goals, Objectives, and Business Drivers are often common across projects.

Managing reusable assets within a central repository that also supports traceability and similar types of relationships between assets would be powerful indeed.
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC