Key characteristics of a business sponsor are being politically astute, enthusiastic, and realistic. The first two characteristics are obvious, but it is important that neither the sponsor nor the BI team gets carried away with being overly optimistic. Although having a gung ho sponsor may seem appealing, setting realistic expectations is necessary for BI success. In addition, a realistic sponsor will understand that there may be problems or setbacks during the BI project that will need to be handled. Getting support for the typical issues that one always encounters during a BI project will be extremely helpful.

Ideally, a BI project has the support of the CIO, but that person should not be the sole sponsor of the project. The risks of a CIO-only sponsored BI project can include that it:

The BI project needs at least one committed business sponsor and, if possible, multiple business sponsors representing a cross-section of the organization. This is a balancing act, where one sponsor may create the impression that the BI effort is geared exclusively to that sponsor’s business group, or too many sponsors create friction with conflicting priorities. The best case is one primary sponsor with a couple of secondary sponsors.

The BI team needs to interview business sponsors (see Chapter 3) to determine the business initiative and current analytical pain points that they would like to address, set priorities, and help establish the scope of the BI project. This is where you start to build a solid working relationship with your sponsors. The conversations will be more productive if you have done your due diligence and explored what business initiatives and analytical pain points your sponsor(s) will likely discuss.

Getting the business stakeholders involved while building the business case enables more detailed business input and may help identify gaps and risks. In addition, the stakeholders will likely be the primary input for detailed business requirements later in the project (see Chapter 3).

One of the most frequent mistakes made when engaging business stakeholders is relying exclusively on a business group’s “power users,” i.e., the go-to people in the organization who get the data needed for others’ analysis. The power users typically use spreadsheets or build spreadmarts to provide reporting to their organization. You should engage these folks, but if you limit yourself to them then you may encounter several problems:

Organizing your business case, and later your project deliverables, around business processes offers many advantages because that is how the organization works. Using business processes as the BI building blocks enables you to better identify the business people who will use your BI solution and how it will be used in their jobs. Too often, business cases and BI projects are oriented around BI’s technical deliverables, such as reports and dashboards, rather than a business deliverable. Business focus creates a more compelling business case and often gets business stakeholders more involved in getting BI integrated into their jobs.

Focusing on business processes also makes it easier to identify business benefits resulting from the use of BI in the organization.

Tangible benefits for BI typically fall into several broad categories:

One of the benefits of aligning the BI business case with business initiatives is that the initiatives have likely already been justified and have tangible benefits assigned to them. If BI becomes an essential component of those initiatives, then the work of assigning tangible benefits has already been done for you.

There will also be tangible benefits associated with the business processes that the BI solution is going to affect—you’ve already identified these processes in the business case. Have a discussion with the business stakeholders to determine exactly what tangible benefits are associated with those processes.

Analytics and data-driven decision making has become invaluable to organizations of all sizes and across all industry categories. There are countless articles and case studies proclaiming the business value resulting from BI projects. You should have no problem gathering a list of business benefits that your BI project can deliver.

As shown in Figure 2.2, the product evaluation process will involve these steps:

The costs for these technologies ranges from free (at least in respect to licensing costs) to very expensive. Prior to creating your product short list, you need to get a ballpark estimate on what your organization would likely spend and what the products will cost. You probably will not tell the vendor what your budget is, but you need to filter products based on what you can afford or are willing to spend. It does not make sense to evaluate products that you will not realistically purchase unless it is part of your bargaining strategy with the vendor. The book discusses product evaluations in Chapter 7.

Most evaluations have a long list of functional and usability criteria from both technology and business perspectives. After the product reviews, score each product according to this criterion and then rank them, creating a final score that identifies the winner. An objective evaluation will help lead to the best solution for the organization.

There are two mind-sets regarding when product evaluations will occur. (See Chapter 18.) Some organizations will conduct the evaluations during the BI justification phase in order to determine the specific products and their costs. In this scenario, the organization knows it needs a BI project, but more details are necessary for specific projects to be approved. The other approach, which is more common, is to perform an abbreviated evaluation that would document:

The first step toward building your technical case is selecting the products and technologies, or at least narrowing down a short list, but as we will discuss in the next two subsections, you still need to convince business people and technologists that they ought to use these tools.

What is often overlooked by the BI team is that business people may select other alternatives that they consider “good enough” because unlike the BI solution, those alternatives:

An alternative to using new technology can even mean doing nothing (continue to use what you have) or use substitutes. These substitutes can include expanding operational reporting or using more data shadow systems. These “good enough” alternatives may mean that the business does not fully engage during the BI project or that they use the alternative solution more than BI solution once it is operational.

The BI team needs to make the technical case that the BI solution is the best choice for the business user. This is where the business case needs to be tightly coupled with the technical case. The BI team has to justify or explain why the BI solution will be more effective at meeting the goals of the business case from functional, productivity, and long-term cost perspectives. This is not a feature comparison like the tool evaluation but rather a comparison of alternatives. Often, the technologists and business power users are so enamored with the new tool that they have no idea that the business community would consider “inferior” alternatives.

Operational systems are typically bundled with reporting capabilities. (Operational BI is discussed further in Chapter 5.) Business people may complain about these systems, but the short-term benefit is that they are inexpensive and may be producing some value. If the business choses the alternative of expanding these reporting capabilities, it will likely be cheaper and faster than a BI solution, at least initially. Likewise, it is almost guaranteed that business people have been using spreadsheets to do reporting and, if the reporting complexity warranted it, they also built data shadows systems. However, cheaper and faster stops looking so attractive when you look at the medium term, which is more expensive for IT support, and the long term, which is far more expensive and less agile as you attempt to expand with all those data shadow systems.

The technical case, therefore, does not end with comparing different BI tools and selecting the “best,” but rather needs to compare BI tools with alternatives that business people are inclined to use. This comparison is not a feature checklist bake-off; it is a reality check of what would convince business people to actually use the BI tool. The BI evaluation can give a false impression that just because a tool has many features it will be preferable to what the business users have available now. It is not the best tool if the business people will not use it.

The business community has to invest time in learning the new BI tools and changing existing business processes to take advantage of them. They also have to spend time waiting for the new BI solution to be built while the business climate—sales, operations, competitors, the economy, and government regulations—keeps changing. That time is an opportunity loss that must be factored into the cost–benefit calculations. In fact, the first generation of DWs often failed for the very reason that they took too long to build and the businesses could not wait.

But below the surface, you might be surprised that there is resistance to change, possibly even some passive aggressive behavior. The people who say that they are excited may not even realize that when it comes down to it, they do not really want to change. You have to be thinking, “Why would technologists not want new toys?” The answer: basic human behavior. This is a phenomenon that surprises and thwarts many a BI effort. You can avoid this by making the technical case for the technologists.

First, you need to get the technologists involved in the technology and product selection process. In this phase, you will need to:

BI projects, especially the first one for the organization, often need to introduce many new technologies such as various categories of business intelligence, data integration, database, and infrastructure tools. List the technologies that will be needed to fulfill business requirements and classify them as must-haves versus nice-to-haves. Your business requirements are very high level at this point, but should be enough to develop these lists.

Once you have determined the technology categories for the BI project, you need to create a short list of products from those categories.

Second, despite the current state of reporting, the technologists are probably “king of the hill” with their business users and their management. They are the firefighters who people depend on because they are the only ones who understand how to create reports with the current technology. There may be long queues for getting reports from them, and the resulting data may be limited, but nobody blames them for that. Instead, they get rewarded for whatever they can do. But when new products are introduced, they will be novices again. Even if there is no intention of replacing them, that has to be in the back of their minds.

Finally, it takes time to become proficient at a new product. During that time, they will likely keep thinking that they could do things faster the old way. Developers can crank out code pretty quickly. In addition, although there may be product training, there usually is no training for designers and developers on BI concepts, processes, and architectures. This lack of fundamental and architectural training usually results in solutions built the old way—without leveraging the new products. This further reinforces the reluctance to embrace the new tool.

You have to sell the technologists that these new products will not only help the business, but also themselves. I am not trying to be cynical, but it does come down to “what’s in it for me” with the technologists. This is not to say they are thinking this outwardly, but deep down they are experts in the current environment, and no matter how bad that is, they are still the gurus. You can pitch all the business benefits and productivity gain, but if that means they are novices again or worse, they will be reluctant. As discussed earlier, it is most helpful to have a powerful sponsor who can guarantee that people will commit their time and will have enough of their other tasks freed up for them to work on this project.

You need to use care in selecting and using these new tools, and try to help the technologists become even more valuable in their current organization and in their industry. Learning new skills and then becoming an expert in that tool does make them more marketable. You need them to not only help in the selection but advocate their use.

The key data attributes that need to be assessed are the 5C’s (covered in detail in Chapter 1):

You need to review the current state of the data by talking to subject matter experts on source systems and potentially performing a high-level data profiling exercise. A critical assessment of the 5 C’s will provide a data-quality baseline. From this, you can determine the scope of the data integration and cleansing efforts that the BI project will need to provide the analytics that the business is requesting.

Determining the scope will typically involve many back-and-forth discussions with the business. The initial request will likely ask for a level of the 5 C’s that is too time consuming and costly. Unrealistic data-quality requirements can be the downfall of a BI project. After discussing the trade-offs, you should be able to achieve a mutual agreement on data-quality requirements with associated costs.

In addition, business people also will be introduced to new BI technologies and analytical techniques such as data visualization and predictive analytics.

Be aware of these risks:

Most organizations recognize the first risk and take steps to mitigate it. Organizations get training for their staff, supplement their staff with consultants, or have consultants perform all the work with the new technologies. Getting the staff trained is a terrific long-term solution to obtaining the needed expertise, but in the short term, people who have only just been trained will not be as productive and will likely make rookie mistakes, putting the BI project at risk. Augmenting staff or having only experienced consultants work with the new technologies helps mitigate those risks.

One of the risks organizations often do not recognize is not having the expertise in the new architectural design and development concepts and processes needed to effectively use these new technologies and implement BI. First-generation DWs and BI solutions are typically built the way developers had always been building systems, resulting in systems that take longer to build than they should, perform poorly, or do not work at all. In addition, without BI expertise, the new BI team may not know that it should be performing better. “You don’t know what you don’t know” is the phrase that rings true.

Finally, business people are the ultimate BI consumers. As with technologists, it is recognized that business people using the BI tools need product training, but conceptual training on the use of analytics in one’s job is not typically addressed. There are many analytical techniques offered through BI tools today such as data visualization and statistical analysis. If your business case relies on these techniques being used but your business people do not currently have the expertise, you need to address this in the BI justification and planning.

The BI center of excellence (described in Chapter 19) is one example of an organizational change that can help increase the success of BI in the enterprise while also allowing different groups to share the success and risks.

You have identified the business processes that will be affected by BI. The people working on these business processes need to understand and be committed to the changes that will occur. These changes will often involve much more time and resources than simply using a new BI tool. You need to factor these costs and additional work resulting from the impact of these changes into the BI justification.

You need to develop cost estimates for the full life cycle of a BI solution from design through implementation and ongoing support. Almost everyone will include software, infrastructure, and external labor costs, but you need to include internal costs for both IT and business people. You need to do this even if your financial justification does not need to include the internal costs so that your organization’s management understands the full cost. Often there is sticker shock; that is fine, as it generates conversations on what the business is really willing to spend. You will need to adjust scope appropriately if your financial commitment is smaller than you had planned for.

The other problem that BI projects run into is that although business people and other technologists outside the BI team are assigned to work on the project, these stakeholders are already fully committed to other work. You need their management to free up their time so they can work on the BI project—otherwise it will never succeed.

In addition to the above, document the following in order to establish scope:

It is also worth noting that including a defined change management process will help with resetting expectations along the way. The scope always creeps, so plan for it.

There are two opposing approaches to developing a milestone plan: delivery-based versus time-based. Many technologists feel a delivery-based approach is very logical and therefore the most sensible to use. The reality is that you do not really know the detailed requirements at this time, and they are likely to change and expand during the course of the project. Using an iterative and incremental project methodology mixed with agile enables the time-boxed approach to incrementally build the individual BI applications while managing within an overall milestone project schedule.

A very successful approach is to create the initial project milestone plan based on the high-level deliverables known at that time, but manage the project as a time-based (and budget-limited) approach. The reasons are: (1) business users’ expectations are fixated on the project completion date and the business sponsors are focused on the budget, and (2) BI is never done, so if you keep pushing back the schedule to accommodate changes, you may never be done. In addition, if you push back the completion date, the business will more likely remember you are late rather than that you added more functionality for them. One of the key purposes of the BI road map is to enable additional functionality to move into subsequent releases, and not to have to have everything get done at one time. This allows you to manage scope changes successfully.

You might think it would be a straightforward exercise to determine the cost of your BI project, but at this point there are many unknowns and alternatives, such as:

After thinking about these unknowns and alternatives, you might consider it a daunting task to estimate your BI project’s costs and create a budget. Do not worry, it is really not as hard as it seems. First, you need a ballpark estimate rather than an exact cost. It is best to provide a range of costs with upper and lower bounds to reflect different options that are available.

Second, and most important, this task is especially difficult (and maybe impossible at this point in the process) if you try to calculate the costs bottom-up, i.e., determining the individual component costs and then summing them for a total. Instead, you should develop a project budget by using a top-down approach of estimating cost categories rather than individual components. This is similar to how you would work with an architect in developing a budget for building a house. You would discuss with the architect the type and size of the house, the number and types of rooms, and overall quality of the house, but you would not start pricing out shingles, electrical wiring, and plumbing fixtures. You would get to those details later, just as you will with the BI project; the initial planning is to develop a ballpark budget within a cost range. Once you agree on that budget and blueprints are created, you can start to price out the details.

Remember to work with your organization’s finance group. It is likely that there are standards that you need to follow for estimating budgets and costs.

The reality is that BI is an enabler for business people making decisions and taking the actions that will create business value. This means that the BI solution is valuable for its users to do their jobs and, ideally, improve their performance. Just as we approach the cost side of the equation by ball parking the estimates, you should do the same when working on the business value. Ask the business people what the BI solution is worth to them. Consider this discussion a negotiation. If they cannot articulate how the BI solution will provide value, you may need to shift your focus to other business people who can. There is no question that the BI project offers value, you just need to quantify the value for your organization. Do not beg for business people to fund and use your BI solutions; rather, work with those who do see the value.

How do you calculate the ROI of a successful project? It is going to be different for every situation. Here are some potential business benefits (you will need to quantify them for your own organization):

BI projects may get approved with these intangible benefits, but if an organization does not know what the tangible benefits are, then how will they know how much to invest, how to measure success, and whether more investments are wise? Successful projects have tangible benefits that you can measure.