Q&A: Ensuring Success in Your Enterprise-wide BI Project
There are many traps to rolling out an enterprise-wide BI project. We show you how to avoid those problems.
- By James E. Powell
- April 10, 2012
Thinking big is fine for BI projects, but how can you avoid ending up with a department-level project or one that doesn’t meet the original requirements? To find out the best project management practices, we turned to Peter LePine, managing director for the BI and information management practice at Emtec Inc.
Peter has lead successful projects at Fortune 500 companies in high-tech manufacturing, life sciences, finance, and insurance, using tools and technologies such as ETL, source data profiling, master data management, data warehouse and data marts following Kimball's data modeling approach, business intelligence reports, analytics, and dashboards. He’s delivered enterprise-scale projects utilizing the leading data architect, ETL, BI, analytics, and dashboard technologies.
BI This Week: Organizations often start with ambitious enterprise-wide goals but end up with departmental deployments. What gets in their way?
Peter LePine: We typically see organizations going down one of two paths:
IT sets enterprise-wide goals in an attempt to meet a wide range of business needs. It’s also easier for IT to justify the investments in technologies, people, and processes if the resulting data warehouse platform and BI tools can be utilized across the organization. Modern businesses are very dynamic and the “going in” requirements for the data warehouse and BI tools will almost certainly change before the initial deliverables are ready to be deployed.
At a more tactical end of the scale, we have seen internal politics where IT has ambitious enterprise-wide goals but a strong departmental business sponsor wants his/her dimension of the data warehouse and BI reports given top priority.
The challenge before IT is how to achieve enterprise-wide goals while still being responsive to a changing set of business user demands. One approach Emtec recommends is, build a technical architecture for the enterprise and then focus on tactical deliverables that meet specific business requirements. We’ve adopted a classic waterfall approach to the high-level requirements gathering, architecture, and logical modeling phase of the data warehouse; then an agile release level approach to design, analysis, build, and deployment phases. We’ll typically build project plans with ETL and BI work streams in parallel so data warehouse and BI report delivery are coordinated.
No question, it is challenging because sometimes what seem like trivial (business) requests for additional information can result in major changes to the underlying data warehouse, but that can be mitigated too. With a well-thought-out plan, good internal (IT to business) communications, and a strong delivery model, the challenges of an enterprise-wide deployment can be overcome.
Organizations tend to take a “seismic shift” away from the current messy reporting environment, to a unified BI platform, with little or no thought given to the transition. Why do large and small organizations continue to underestimate the impacts to business users and their regularly scheduled (daily, monthly, etc.) information needs?
Looking at the BI world from the perspectives of technology, processes, and people, the IT organization is focused on technology and the technical processes. Business users -- and this shouldn’t come as any surprise -- are focused on people and the business processes. I think this speaks to a large part of the failure by IT to recognize the impacts of the transition.
In most cases, the business users have been dependant on a standard set of reports bundled with their applications, generally supplemented by XLS files that provide the analysis and workflow requirements. As inadequate as the current reports might be, the business users have found ways to work with the limitations. We have also seen many cases where these standard reports are supplemented by Hyperion for example, specifically for the CFO, or for budgeting and planning, so we’d argue it’s a specialized tool not a general-purpose BI reporting tool.
In Emtec’s experience, the primary reason IT underestimates the impacts on business users is the focus on deploying a new (BI) technology, and a failure to place a similar focus on the people and process impacts. One recommended approach is to map a set of related reports to a business process, and then build a decision tree for business process. Who else is affected? What decisions are made? What are the upstream, downstream, and collateral impacts?
With this sort of approach, a report is no longer a singular report but part of an information flow through a department and across departments. In our experience, this is something IT business analysts fail to do when deploying a BI tool.
How have organizations tried to overcome these obstacles?
Continuing the general theme, when we’re proposing a BI project, we build into the project plan business user training and support costs, as well as analysis of the business processes. In an IT environment focused on outsourcing to the lowest-cost provider, this doesn’t get a lot of traction, but it really is a false saving. If the project costs are beyond the project budget, the first line items to be deleted are training and support costs for the business users, and analysis becomes narrowly focused on replicating an existing report in a new BI tool.
Let us drill down into each of these three elements.
Business user training and support: Earlier we commented on an agile, incremental approach to delivery. This is one way for organizations to help themselves. By implication, an organization will be training smaller, incremental groups of users. As expertise is developed in one group, the skills and experience can be transferred to another. These individuals also become the nucleus of the Center of Excellence (CoE) which we’ll comment on later. In addition, as expertise is developed within a group, these individuals can become first-line support for other business users, relieving IT from some of the support responsibility.
Technical training and support: Relative to ETL tools and BI tools, budget for administrative training and developer training. Each of the ETL and BI tools offers multiple ways to accomplish some end, but only one right way. What we mean by this is that there are many ways to design a BI repository or an ETL process, and when we encounter performance concerns, it’s generally a result of how a data model has been represented in the BI repository or the mapping of an ETL process. Generally, it’s a lack of experience, not a bug per se in the tool. Even if a project is being outsourced, we recommend building a nucleus of design and developer skills in house for the ongoing support of the data warehouse platform and BI toolset.
Budget and costs: We just discussed the need for both business user and technical training which have cost implications. As a side note, all the major vendors offer Web-based training, so it’s not as expensive as it once was.
When budgeting for the transition from a legacy reporting environment to a BI toolset, we always recommend budgeting for a more fundamental analysis of why the report was required in the first place, and given the new capabilities, ask if the report is still required.
We have seen many examples where a list of thousands of legacy reports can be refined down to a list of a few hundred because of the new capabilities offered by the BI toolset. This has a substantial impact on both the time and costs of the conversion. We have seen examples where a report conversion project is reduced from a 12 month duration to 3-4 months.
Most organizations see a Center of Excellence as an IT group, but why not include business analysts and business sponsors?
We recommend a multi-disciplinary CoE group, and typically the group will be built over time. We’ve found a two-tier approach works well.
The business sponsor, CIO, and other senior management form the IT steering committee (first tier). They provide strategic direction and business prioritization across the organization. Taking direction from the IT steering committee is the CoE (second tier). In this two-tier structure, IT and business priorities are “merged” so it’s a necessity to have business users and IT equally represented.
There a couple of additional points to be considered. In most cases, the CoE doesn’t have a clearly defined charter -- it only has an informal scope of responsibilities and no power of enforcement. As a result, the CoE is seen as overhead and a barrier to getting things done. The CoE starts out with good intentions but ultimately collapses because the broad user community finds ways to circumvent the CoE.
What are the biggest mistakes IT makes in enterprise-wide projects?
The most common mistakes we see when IT embarks upon enterprise-wide projects fall into several general categories.
Time to delivery: It’s accepted that data warehouse and BI projects are large and complex initiatives. Often, we see the scope isn’t clearly defined -- it’s generally more complex than anticipated, so it’s not surprising these projects often run over time and over budget.
We made the point earlier about agile, incremental delivery. Delivery of functionality in a phased approach has a number of benefits. Business users begin to utilize the new BI toolset sooner rather than later; IT can validate it’s on track in terms of the new functionality; and training and user adoption gain traction with smaller groups.
Breadth and not depth:This is an outcome of time to delivery, and it’s a tough balance to strike. One strategic approach is delivering a data warehouse with some number of subject areas and reports that can span across the organization, but without much depth. The other strategy is to deliver depth within a subject area and rich reports.
In line with aligning strategic business initiatives with DW and BI deliverables, we typically recommend depth and richness in the BI reports because that’s what drives business value.
Strategic business initiatives: IT will often tackle technical complexity early in a project life cycle rather than tackling high business impact early. Evaluate new projects on the basis of the impact on the business first, then evaluate the technical foundation required to support the business. Ideally, IT is evaluating new projects on the basis of high business value that have low technical complexity to implement.
Internal communications: With very rare exceptions, IT does a terrible job of communicating progress to the organization. IT “owns” the portal log on screen, so why not use it for more than a userid and password? One of the deliverables of the architecture phase will be a road map or blueprint, so use it to communicate prioritization of projects and progress along the road map. This seems so simple to fix, but after the initial project activity, most business user groups feel as if they’ve been forgotten by IT.
Go-live support and training: We’ve already commented on the importance of support and training earlier, but here’s an additional point. Most IT organizations think that once business user training has been done, it’s done forever. Given resignations and new hires, staff promotions and inter-department moves, there’s an ongoing training requirement.
As part of the initial training requirement, think of ways to record the training and make it available online to meet the ongoing training requirement. Most business users can and will only spare an hour’s block of time for training, so don’t try to do one four-hour session. Break it up into multiple, shorter sessions.
What best practices can you recommend to avoid these mistakes?
The Center of Excellence should be the repository for best practices and data governance and should have the authority to enforce policies and procedures. All too often this is not the case, or there are so many “one-off” exceptions, so there are no effective standards in the organization.
Our first recommendation regarding the CoE is to start with a small “footprint” and scale up as appropriate.
High-level strategies we typically recommend are:
1. Start with an EDW vision that maps to high-level business initiatives.
2. Layer down into an understanding of the business process workflows.
3. Layer down into an understanding of the data required to support the above.
4. Develop an implementation road map that is prioritized on high business value deliverables. Incremental deliverables are derived from the road map, and you can build project plans from the incremental deliverables.
5. Develop strong working relationships with key business sponsors.
6. Develop a nucleus of key technical (ETL and BI) resources.
7. Develop a nucleus of key business and data analysts.
8. Take a release level approach to the incremental delivery of new (ETL and BI) functionality. Use strong (ETL and BI) tools and adopt common development standards; the ETL admin and the BI admin will be the central point for development standards. Pay attention to data profiling and data cleansing, and informally start to build master data. Don't underestimate legacy data challenges, and don't underestimate the challenges of unstructured data. Don't underestimate training and support requirements, including the initial technical training, the initial business-user training, and ongoing training.