Purchase your Section 508 Compliance Support guide now!

Purchase your Section 508 Compliance Support guide now!

How to Make the Case for a BI Center of Excellence

The phrase "You're only as successful as your last project" is not reserved for business intelligence but feels particularly applicable these days. It's no secret that BI teams are under pressure to engage or re-engage business users. They need to explain why BI isn't like other IT development efforts. They need to remind distracted executives of BI's value. They need to have an answer for the ubiquitous question, "What have you done for me lately?"

The good news is also the bad news. End users are smarter than ever. Many of them have co-opted BI by acquiring their own tools and have funded their own skill development to create specific functionality. As BI is increasingly adopted across organizations, it has become a free-for-all of brand-new silos, unmanaged data, duplicate work efforts and poor data quality, all of which lead to misaligned business decisions. Translation: We're spending too much time and money getting information and not using it cohesively. In response, many BI teams have chosen to launch a center of excellence as a way of refocusing attention on the unique nature of BI projects and the processes that come with them. But such a big project can easily backfire and lead to more chaos. We need to know when the time is right for a BI COE.

Failure to Launch: How Not to Start Your COE

When I asked Craig, the CIO at a regional bank, why he'd decided to launch a BI COE, he explained that, after working for two years as a formal team, the BI developers had practically disappeared. The initial business process management dashboard had been a high-profile success, but users had reverted back to Excel spreadsheets for most of their reporting, enlisting developers only when new query creation proved too complex. Meeting fatigue had become part of the culture, and users didn't want to be proactively engaged in business requirements discussions, however strategic. BI had become commoditized.

Craig's hope was that by announcing a BI COE, his user community would take him and his team more seriously. "I thought the COE concept would give us street cred," he admitted. It had the opposite effect. Immediately, business users began asking why the BI team was getting more funding when they hadn't delivered anything in more than six months.

And it was true. Since the dashboard project's success, BI team members had been focusing their time on infrastructure and platform issues. Data model enhancements and regular data loading activities were absorbing most of the resources. Users weren't seeing value, so Craig's emails advocating a COE seemed self-serving. Craig hoped his COE idea would get attention, but cynical email replies and eye-rolling weren't the kind of attention he wanted.

Craig's users brought their old resentments to the COE discussion. "It's rearranging deck chairs on the Titanic," a segment manager in marketing remarked. "We don't know what these guys are doing - and neither do they. Why should we be the ones to fund a COE when we have no idea what's in their pipeline - and have absolutely no input into it? It's a funding grab if you ask me." Ouch.

I've seen other failed COEs at companies that used high-profile problems - such as an enterprise resource planning system's problems acquiring data or management's desire to standardize on reporting tools - as a pretext for starting a COE. The results have been equally fruitless. In reality, the situations that justify a COE are few and very easy to spot.

When the COE Makes Sense

As real as Craig's problem was, announcing a COE wasn't the answer. Craig needed to re-enlist users in a structured process with clear rules of engagement and begin to quantify the value of work tasks to prove that his team was deserving of continued funding. He needed to deploy BI applications that business users would use and establish structure and BI-specific development processes. Only then would a COE make sense.
And that's the problem with many existing (and increasingly defunct) COEs: They begin prematurely, before stakeholders perceive value. A COE will only become sanctioned if its stakeholders recognize a bona fide need for it. There are three predominant drivers of successful and sustainable COEs:
  1. BI projects often compete for funding with other IT projects that are seen as operationally critical. The executive steering committee at a catalog retailer constantly placed BI at the bottom of the funding list. "When funding came down to either BI or a new merchandise management system, we'd lose," said one director of BI, "and we lost most of the time." The director set out to educate the steering committee about why BI development was different, and how it could enable strategic goals like customer retention and promotions effectiveness. With the caveat that cost recovery was an end goal, the steering committee agreed to fund BI as a separate group with its own organizational structure and governance process.
  2. The data warehouse has become a shared resource across organizations, and the economies of scale justify a central development organization. Alternative, piecemeal and siloed efforts at data management and BI have become not only costly, but also risky, as different versions of data proliferate across the company. A COE not only ensures a deliberate approach to funding and deploying BI, but an ongoing investment in BI-specific tools, skills and data.
  3. Business operations become dependent on BI. When a company relies on its data warehouse or BI infrastructure for business-critical capabilities such as inventory management or financial reporting, the company should invest in a COE. It has become more common to see that certain high-profile business functions or processes can't run without BI, in which case you've established BI as a business-critical platform that justifies its own skill sets and budget.
Without the ability to prove efficiencies, cost savings or revenue generation, the nascent idea of a COE becomes a solution looking for a problem. The risk is that prematurely or casually launching a COE raises stakeholder expectations around delivery and know-how, making the inevitable fall even more painful.

Getting Ready for Your COE

Most BI organizations today are in limbo. They have a vision for a COE, but they're not yet qualified to hang the COE shingle. You can take the following steps to prepare before you make your pitch.
Reconsider your data provisioning model. There's nothing wrong with a data warehouse availing data to various organizations and reports across the company. Indeed, that's part of its value. But if your BI team spends its days modeling and loading data into data marts, you're being marginalized as infrastructure, not as a value driver. Consider helping a high-profile user group to not only get its data, but to use it. Develop expertise in BI applications as well as platforms. It's a truism in BI (and in IT in general) that he who is closest to the end user wins.

Adopt a BI portfolio approach. When companies develop their BI roadmaps the right way, the whole is usually greater than the sum of its parts. A BI portfolio is a collection of business capabilities deployed over time. A portfolio approach guarantees reuse of common data for a range of analytical applications. Defining the initial set of portfolio applications helps establish the short and midterm development pipeline and gets BI team members back in front of key end users to discuss their need for business information in the context in which they use it.


The portfolio diagram in the provided figure illustrates functional applications at the top accessing reusable data in the data warehouse below. After your initial discovery work with business users, the simple act of unveiling the new portfolio can instill confidence that BI planning is rigorous and deliberate, thereby increasing stakeholder support for the BI COE and your chances for success.
Document your development process. Everyone in BI knows that BI development is different than other IT/business projects. As you consider a BI COE, be rigorous about circumscribing and documenting your BI development process. Activities such as user requirements gathering, data modeling, data loading, application and data acceptance testing, and deployment should be well-defined and within the context of an overall BI-specific delivery method with its own artifacts and handoff points. Instituting regular status updates, closed-loop ROI reviews and project postmortems reflects additional rigor and instills goodwill.
Get serious about staffing. A COE that wants to be sanctioned and funded involves more than just a data modeler and a few developers. Roles and responsibilities should be specific to the BI development process, with clear inputs and outputs between functional areas. Depending on the scope of the COE, it may include functions such as business analysis, data stewardship, metadata management, BI application development and more. Discrete job roles should be defined and well-documented, vetted with HR and accompanied by distinct measures of success.

Create a charter and guiding principles. Many IT leaders view organizational charters and mission statements as extraneous fluff. But only by communicating the COE's fundamental purpose and common philosophies can your BI team enforce an effective pitch. The organizational charter includes a purpose statement, a list of recurring problems the COE will address and a value proposition for the organization at large. This can be the glue that secures the buy-in of executive and user stakeholders.
My client Craig retracted his COE pitch and instead invested in some discovery work, pinpointing three key business applications through which his team could prove its newly documented BI development process. Once the applications were deployed, Craig measured and communicated their business value to a handpicked set of business stakeholders, leveraging his newfound prestige to pitch a COE model to executives.

The results are impressive. The BI COE regularly engages stakeholders both formally (through a structured business requirements-gathering process and periodic vendor presentations) and informally (through lunch-and-learn sessions and a corporate portal for BI information and status). As the rules of engagement have become clearer, so has the team's ability to leverage existing technology platforms and drive additional business value through cost savings and strategic enablement. All in all, the BI COE is a celebrated success. After a visible lapse, it took a deliberate plan to get on the right track.

Jill Dyché is a partner and co-founder of Baseline Consulting (www.baseline-consulting.com), a data integration and business analytics delivery firm. Her first book, e-Data (Addison Wesley, 2000) introduced managers to the concept of enterprise data integration and has been published in eight languages. Her second book, The CRM Handbook (Addison Wesley, 2002) is the CRM bestseller. Jill's work has been featured in major publications, and she is a frequent speaker at industry events. Her latest book, Customer Data Integration: Reaching a Single Version of the Truth was co-authored with Evan Levy. You can reach her at jilldyche@baseline-consulting.com.