As BI consultants, we’ve worked with a lot of front-line BI teams: the people who design, build, and implement business intelligence (BI) systems, and one recurring theme we frequently see, they have a love/hate relationship to their internal customers (i.e. “users”). When the pendulum swings more to the hate side of the relationship, we often hear BI teams talk about the lack of business/user involvement, participation, engagement, and commitment is a risk, an obstacle, and a common cause of BI failure.
But there’s a way to swing the pendulum back to the “love” side of the relationship; and we’ve seen our more successful clients do so by educating their internal customers about what they need to do in order for the company’s BI undertaking to be successful. After all, both the BI and the business sides have a vested interest in that success. Toward that end, this post describes how an ideal BI consumer would work with the BI team to satisfy their company’s overall goals.
Before we begin, let’s talk a moment about “users.” A user is someone who interacts with the BI system in a hands-on way. But users represent only a subset of the customers of BI. There likely are people downstream from the hands-on users who utilize the information provided by the BI system in their decision-making; let’s call them information consumers. There also are executives who approve and fund BI projects. All of these people – hands-on users, information consumers, and executives – are customers of the BI team.
BI projects follow a predictable life cycle that we can use to organize this discussion of ideal customer behavior. Referring to that life cycle, we can group ideal customer behavior into three phases: up-front; during development and implementation; and during production use. Going forward, I’ll be speaking directly to the BI teams, so when you see me using the term you, I’m referring to BI teams. When I say them, I’m primarily talking about BI consumers.
Up-front: Collaborate on BI Need and Value
At the beginning of a BI project, the focus is on what is to be done, which we usually call requirements, and the business value that the organization will realize from doing it, often formalized as the business case. Customers must specify both the requirements and the business case. What you need them to articulate is:
- What information they need: The information customers don’t currently have, but need to have, forms the basis of requirements. This aspect of requirements best is articulated as business questions to be answered.
- Why they need it: “Why” typically is the statement of a problem or problems the organization faces. “Why” describes the current state of the business, how it is lacking/imperfect and could be improved with new/better information.
- Who will use it: “Who” begins the description of the future state that will be enabled by the BI system. It specifies the hands-on user population for the system, which we often group into user classes or profiles, each with a defined set of needs. “Who” must articulate more than just users. It’s important to know the entire customer population: everyone who will be affected by the information the BI system will provide.
- How they will use it: “How” completes the future state description that began with “who.” There are two aspects to “how.” The more important is how information consumers/decision makers will use the information provided by the BI system to make more informed and thereby better business decisions, and thereby drive better business results. This statement is the reason for building and using this new BI system, and the essence of the business case for it.The second aspect of “how” is a more-detailed description of which business process(es) will change to incorporate use of the new/better information. The more specifically the business process change to consume the information can be described, the more likely the desired business benefits will be achieved.
- When they need it: The “when” element of requirements specifies how frequently the information to be provided by the BI system must be updated to reflect subsequent events. It also can address “latency,” which is the period of time between when an event occurs and when information about it becomes available. Both frequency and latency are critical drivers for how you will design the BI system.
Projects to design and build BI systems often begin to fail early: when customers don’t hold up their end and we attempt to fill business case and/or requirements voids on their behalf. No matter how sincerely and diligently you do that, you can’t take the place of engaged, articulate, business-savvy customers.
During Development and Implementation: Prototype, Test and Train
After the business case is approved by the organization, you willl take the requirements and use them as input to the various tasks you do to design, build, and deploy the BI system. While customer involvement is less during this phase, you will still need them to participate in these activities:
- Prototype review, if applicable: a best practices method to stimulate requirements validation and refinement is to employ a prototype that gives customers an early opportunity to see “what they will get” from the BI system. If a prototype is used, you will need substantive customer review of it and feedback about it that you can use to make the production version better.
- User acceptance testing: once you complete our technical testing of the BI system and believe that it satisfies the requirements, you will need customers to test it for themselves and confirm that it does indeed satisfy their requirements. Such customer testing usually focuses on hands-on users and is called user acceptance testing. Comprehensive user acceptance testing entails significant effort to plan, prepare data for, execute, and record the results of tests to confirm:
- Information completeness and accuracy
- User experience interacting with the system
- Information presentation and delivery
- Performance considerations, such as query response time
- Sufficient privacy and security protection
- User training: while a small cadre of power users typically handles user acceptance testing, the scope of user training is the entire user population. The goal of user training is to enable every user to effectively use the BI system for his/her specific purposes. Various approaches to user training are valid: formal classroom training, train-the-trainer, video-based training, and more. All best are designed and conducted by users themselves, with appropriate support.Once user training has been developed and is available, the next ideal customer behavior is commitment by all users (and their management) for them to complete the training, and then follow-though to fulfill that commitment.
- Business process change: user acceptance testing and user training focus on the subset of the customer population that interacts hands-on with the BI system. Business process change, on the other hand, affects all customers, and might affect information consumers more than users.Business process change must be part of any new BI system in order for it to be successful. The logic is straightforward and goes like this: the new BI system will deliver information to customers that they haven’t had before. That information might be more timely, more accurate, more integrated, better presented, and more. In order for the business to realize value from this new/better information, some business process(es) – and likely some business decision(s) – must change in order to leverage it. Business process change is mandatory, and only BI customers – the people in the business – can determine which business processes must change, and how, and then make those changes. All change is difficult, but it must be done to realize value from BI.
During Production Use: Continuous Feedback and Refinement
Once the BI system is made available for production use, the responsibility for success shifts dramatically from the design and development team to the customer population. If you have done your job effectively, you will have created a BI system that provides customers the information they requested. Now it’s up to customers to use that system, take that information, and leverage it to realize the business value they committed to in the business case. You cannot realize business value for them.
During the production use phase, you need continuing interaction from them in these areas:
- Ongoing requirements refinement: BI systems fundamentally are different from transaction processing systems in that the requirements for BI cannot be perfectly specified up-front. As customers work with the information provided by the system, they see ways that it could be improved and enhanced, presented more effectively, and so on. This iterative requirements refinement might begin during development and continues throughout the life of the system. It is the key to incrementally improving the system over time, and must be initiated by customers.
- Feedback regarding business value realization: because the value realization from BI occurs out in the business functions that use the BI system, it can be opaque to the BI team. But you very much want to know about it, because that’s what makes the work you do matter. So try to get your users to share feedback regarding how the BI system you designed and built for them improves business results and makes the organization better. Such feedback – especially quantifiable achievements –helps explain and justify both this system and the overall contribution of BI to the organization.
Get the BI You Deserve
“In a democracy, people get the government they deserve” is a saying often attributed to Alexis de Tocqueville (1805-1859). Paraphrasing liberally, we might say, “In an organization, people get the business intelligence they deserve.” If you are a user, customer, or anyone affected by BI (or the lack thereof) in your organization, and you want to be better served by it, help the BI team to help you. This post describes ideal BI customer behavior or, put more simply, what you need from your customers.
By Bill Collins