"Do not repeat the tactics which have gained you one victory, but let your methods be regulated by the infinite variety of circumstances."
Sun Tzu
A business intelligence (BI) project has to be managed with as much discipline as any other information technology (IT) project in order to be successful. There are a few items that need special consideration given the nature of BI solutions, regardless of the specific methodology or technology involved. This article will discuss how to extract maximum value from an investment in BI software.
BI Challenges
A BI project presents some unique challenges to an organization of any size. The software sits on the cusp of business operations and technology, which demands tight collaboration between end-users and technologists. Without input from the business users, who stand to benefit from better information to help them with their work, the project will have limited value. To obtain useful input from the business users, they must be educated about a complex technology and what is possible with their data. This interdependence rarely exists in other projects. Many IT organizations and consultants have focused on projects that are transparent to users, such as upgrading and enhancing databases and other back office applications, which leave them without experience in dealing with business operations.
Another factor is the often elusive return on investment (ROI) calculation for a BI implementation. A good contrarian example is server virtualization: If virtualization software allows two servers to do the work previously done by ten, then it is easy to calculate the value gained. No such simple formula exists for calculating the value of BI software. Non-financial gains, such as easier and broader access to timely information, less time spent sorting through spreadsheets, and increased confidence in the numbers, often outweigh the financial gains, but the payback is longer and difficult to measure. This in turn can undermine executive support for the project.
Later in the project, when business users start testing the solution, they will sometimes discover that the numbers do not match their intuitive feelings for the business, or that the data contains surprises. Previously hidden data quality issues or sparsely populated dimensions are common discoveries. This can create a great deal of tension between the business users and the technical team, as data quality is not usually within the scope of the project. The business users and executive sponsors start to worry that the project will not deliver what is required.
There is no silver bullet technology or project management methodology to overcome these unique challenges. However, by giving special attention to the following aspects of the project, the chances of a successful BI implementation can be greatly increased.
Requirements Gathering
There are two types of requirements: the wish list and the necessity. Unfortunately, these often overlap and conflict. An approach suited to a BI project is to map out the business processes that can be enabled or enhanced with better reports and metrics. Think about what decisions are made during the course of doing business, then what would be required in order to make better decisions. Brainstorm what can help grow revenue, increase profits or save lives. When are managers and staffers relying on gut instinct? What information would tell management if they are on track to achieve their business objectives? What numbers do you wish you and your staff had on hand? For example, is it the top 10 customers or how many customers are served per hour?
Taking Inventory
This is a two part step. The first step is to find the source of the required data that will serve as the raw material for the BI system. Typically, at least part of the data will be sourced from existing enterprise software, such as a customer relationship management (CRM) or enterprise resource planning (ERP) system. Then, the search may have to go further afield to home-grown systems, software outside the firewall such as web analytics, and flat files exported from numerous other sources where database connectivity is impossible.
The second part of taking inventory is acknowledging the existing BI in place. Is the organization heavily reliant on user-generated spreadsheets and email? What database software and reporting tools are currently being used? Many software packages come with reporting tools embedded. Knowing which alternate BI systems are currently in place will allow better decisions about the future of these tools in an organization. Can, or should, they be replaced?
Investigating Software Vendors
There are hundreds, if not thousands, of products that provide reports, dashboards, data visualization, analytics, and extract/transform/load (ETL) operations. There are niche products specialized for specific industries and horizontal BI development platforms. Licensing varies from commercial to open source to dual licenses. Reliance on standards runs the gamut as well, although the recent trend is toward more open standards, even on proprietary platforms. The only way to sort through the myriad of vendors is to define some criteria. But a feature and functionality list is not enough. Consider also the following questions: What software packages meet the requirements and fit into your existing infrastructure? How much customization will be necessary? Are the licenses cost effective and flexible enough for future requirements? Does the provider's roadmap or vision make sense to you?
Creating a Technical Roadmap
Once a short list of vendors has been created, an overall architecture needs to be worked out. The end to end BI system needs to be considered, from the source data to the business user client interface. The architecture will be influenced by the choice of software vendor, but it should be considered somewhat independently as well. Consider the following questions: If you had to change software or hardware vendors, would your architecture have to be completely overhauled and would that type of change be even possible? What infrastructure do you need in place to support the requirements? What is the most cost effective way to grow to meet future demands?
Defining Programs, Projects, and Timelines
A program is a series of projects. Defining a program helps sustain project momentum and executive interest. Without a program, there is a temptation to pack too much into a single project, and expectations rise considerably. Reduce the risk by defining a program which contains a series of related projects. Each project is created with well defined goals and timelines, such as developing a sales pipeline dashboard for the sales executives by end of quarter. The overall BI program can have a vague ending date, with strategic objectives closely tied to the business, such as increased revenue per customer or better profit margins per transaction. This is an effective way to reduce the project risk, as even if one project is deemed a failure, the program itself can continue to be a success. It also keeps the team focused on the overall business objectives.
Evaluating Staff and Consultants
BI skills are unique. The project management team must be able to make an objective assessment of the human resources available for the tasks at hand. How much technical training will be required before work even begins? Does it makes sense to bring in consultants with product expertise or specific design skills for all or part of the project? What pieces of work can be outsourced to save time and money?
Executing a Change Management Program
An effective change management program not only trains and engages the business users, it also serves to set expectations. Engaging the business users and their management early and often builds trust and diffuses the potential for the "big bust" rollout. The goal is maximum user adoption, without which the BI program will fizzle out as the software turns into shelfware.
Measuring the Benefits
The system has to roll out at an opportune time when the users are not too preoccupied with other issues. Early user interest is critical to success, so avoid conflicting with business deadlines or busy periods, such as end of quarter or end of fiscal year. Collect statistics around usage and benefits to calculate an accurate ROI. It is important to also assess and value the non-tangible benefits.
Automation
Once a project is in production, the technical team needs to start work on any automation that can reduce the administrative and maintenance overhead. Reports, cubes and other objects should have "push button" scripts to migrate them from development to testing to the production servers. User provisioning, temporary file cleanup, and other regular tasks need to be documented and made as simple as possible. This is especially true if the ongoing support and maintenance will be handed off to another team or eventually outsourced to another organization.
Support
Have a great support team in place, as nothing reduces credibility faster with business users than an unreliable system. With BI there are two categories of support to consider. The first is infrastructure support, which includes ensuring connectivity to source databases, making sure that the reports are published in a timely fashion, and maintaining reliable client connectivity. The second set of issues is unique to BI. If the numbers in the reports or on the dashboards appear to be wrong, then the business users need to have confidence in the support team's ability to investigate the issue and quickly come to an unambiguous conclusion. Either the numbers are wrong because of a technical or data issue, and the problem will be fixed, or the numbers are correct, and the business users must have enough faith in the system to be able to accept that conclusion. Are the current IT practices sufficient to deal with both types of issues? Do extra measures need to be taken in order to build trust between the BI consumers and the technical team? Does the support team have enough understanding of the business to be able to troubleshoot problems with business logic and calculations?
Support also includes good documentation. The vendor's documentation will never be sufficient. At a minimum, start writing a frequently asked questions (FAQs) document. Documentation needs to be specific to the data. Screen captures and videos (screen casts) are ideal for answering how-to questions.
Congratulating the Team
Every project needs some type of closing ritual that fits with the organization's culture. It is an opportunity to take pride in the finished product and to talk about the lessons learned. Time needs to be allotted for knowledge transfer, especially from outside consultants who will be leaving.
Iteration
An effective BI system will continue to evolve and change with the business. Solicit user feedback. Start work on enhancements to improve the system. Deliver more functionality to more staff. Get feedback on what is helping and what is just noise.
Conclusion
Independent of methodology, technology, project scope, or size of the organization, a BI project is different than most other IT projects. Tight collaboration and cooperation is required between technology and business teams. With extra attention paid to some key areas, the additional risks can be mitigated, and success will be easier to come by.
Recommended Resources
Business Intelligence ROI example
Scott Berkun's Essays and Blog
Ralph Kimball's Data Warehousing Articles