Best Practices for Business Analysts Working on BI Projects

Business Intelligence (BI) can be defined as the access and insight (analysis) into information that provides organizations the ability to improve their existing performance.

The BI ecosystem includes a vast array of applications, tools, and techniques. Working as a Business Analyst on a BI project can be a daunting task as the objectives are clear but the route to success less known. One reason for the uncertainty for the route to success is the variety of stakeholders who feel they are accountable for the activities to be undertaken. Additional issues range from technology advancement and legacy system capabilities. The following sections within this article outline the steps to be followed that will elevate the Business Analyst towards a successful project.

Understand the Drivers for Change

Why is the organization embarking upon a Business Intelligence (BI) project, what are the key elements that are pushing the organization? There are some traditional tools that a Business Analyst can apply to identify this driver for change:

• SWOT analysis (internal and external scan of the organizational position)
• Vision analysis (What is the organizational vision? What is the impact of Business Intelligence (BI) on that vision?)
• CMM (Capability Maturity Model analysis allows the organization to identify maturity across a wide range of processes)

Regardless of the tool uses you will need to understand the overall desire for change and the support for this project.

Stakeholder Analysis

Once the drivers are known the next step for the Business Analyst is to analyze the stakeholders involved and impacted by this project. Stakeholder analysis at is simplest form is the ability to list each stakeholder group and identify their interest and influence.

A Business Analyst who correctly identifies each stakeholder group will be able to quickly understand where they may be issues and concerns as the project progresses.

Business Analyst Work Plan

A critical step in the Business Analyst Work Plan (BAWP) activity is to outline the deliverables, timetable for work activity, RACI, and other project engagement activities. The BAWP allows the Business Analyst to share with the organization the expected activity that they will complete as part of this project. The Business Analyst plan enables the organization to refine the activity before too much work has taken place.

Business Intelligence Specific Activities

The first three steps would apply to the majority of Business Analyst project engagements; this step is now more closely aligned to Business Intelligence (BI). When you the Business Analyst is working on BI projects the deliverables list will include some of the following:

• Data Dictionary (definitions of all data items contained within the data warehouse)
• Relationship Diagrams (document the data structure of the systems, their relationships, data hierarchies, and data refresh timeline)
• Architecture Document (Solutions and technical interfaces, hardware, application, connectivity)
• BI Standards (naming conventions, interface guidelines, reporting structure, UI expectations, security/access)

The Business Analyst will need to facilitate some discussions/workshops with the subject matter experts (SME’s) throughout the enterprise IT department to effectively capture the requirements to support the completion of the above deliverables.

If you are not familiar with the technology and Business Intelligence (BI) environment before commencing work on such a project, I would recommend you speak with the project sponsor or business lead who will be able to outline the project from a business point of view. Having a common reference point from the business to the technology will support your success in the project delivery.

What If You Don’t Follow Best Practices?

Utilizing best practices allows Business Analysts to learn from the experience of others. Of course, you can jump into the Business Intelligence (BI) project and try not to follow the outlined suggestions. Typically, what will happen is the business is excited about the metrics output from the new BI system. They are keen to get everyone in the enterprise utilizing the BI tool for specific metrics. The Business Analyst will focus solely on the output of metrics and its distribution across the business. Getting the first few metrics and dashboards up and running is seen as a success, and the Business Analyst feels their job is completed.

What then happens is data validation, and confidence issues spring up around the business. Users are complaining about the report they run having old / out of date information. They even stop using the BI tool and revert to the more labor intensive source of information (spreadsheets or hardcopy review). The Business Analyst is brought back into the project, and it is quickly identified that there are issues with the refresh cycle of certain data fields or a new table has been added to an ERP system, and it caused issues to the data warehouse. Now you are going to have to work quickly to resolve the issue.

If only you had completed the required deliverables and obtained sign off from the organization, you would not be in this problem.