An insurance company asked Baseline Consulting to come and assess its enterprise data warehouse and business intelligence (BI) development environment. Managers in the company's lines of business had begun questioning the value of the data warehouse. Development resources were scarce, the BI team was trying to juggle disparate work activities and, as resources were reshuffled, the reputation of the data warehouse was suffering.

It turned out that the most vocal business users were getting the lion's share of attention from the development team. The BI development team could never quite explain the business value of the warehouse. After all, they were spending as much time managing disappointment as they were developing BI. They prioritized their work activities based on fear. The director of BI development tried forming a steering committee to fix the problem. Comprised of managers from the various lines of business, the committee's goal was to prioritize BI projects based on business value. But it didn't work quite as planned.

Death by Meeting

After a few steering committee meetings, the process began deteriorating. A stakeholder from marketing, unhappy with the outcome of a recent meeting, "back-doored" the committee's decision and appealed to the COO. The COO countermanded the steering committee's decision, thus sabotaging the credibility of the steering committee and the BI development plan. This happened again the following month, resulting in reprioritization of projects. Important steering committee members quickly lost confidence in the process and stopped participating.

Another challenge facing the steering committee was the vagueness of its role. The desired outcome of the meetings was never clear. Business participants frequently commandeered the agenda, directing discussions toward "crisis of the week" topics and away from their charter. Instead of serving as a decision-making body to approve and prioritize new BI applications, the steering committee had become a political sandbox. The BI director entertained long-winded discussions on customer definitions and conformed dimensions, which detracted from important decisions to validate requirements and map BI to enterprise needs.

The BI team was in the same boat as before, having to guess at project priorities and funding and react to the most vociferous stakeholders. Business users were more disenfranchised than ever. Some began building contraband data marts to support their own specific reporting needs. Concerns about the value of the data warehouse went from corridor whispers to public debates.

That's when the CIO called us. We talked to stakeholders on both the business and IT sides. We knew we could reinvigorate the committee, but accountability and decision mechanisms needed to be put in place. The CIO and COO gave us their commitment not to entertain special requests or back-door conversations. Steering committee decisions would be binding. And the steering committee would only accept bona fide business cases, not off-the-cuff pitches. We drew up a set of guiding principles for the steering committee and defined the rules of engagement, which were communicated to the committee by the COO.

We also established what the steering committee would not do. They weren't there to establish data access policies. They wouldn't act as de facto data stewards, agreeing on terms or defining data requirements. In one meeting, when a marketing product manager insisted that customer value scores be stored on the data warehouse, the steering committee pushed back. The marketing manager was unable to describe the business actions that would result from having the data and was urged to go back the drawing board.

The steering committee's main job was to ensure that every new project was well understood, every business case was thorough and had sponsorship, and that business benefit was agreed to by all participants before development began. For the first time, the company was using structured measurements to weigh the importance of new IT projects. It was as close as they had ever come to IT governance.

The Steering Committee Gets in Gear

The BI steering committee now meets monthly with a predefined agenda. A "package" of proposed projects is submitted and reviewed in advance of the meeting. Because research and evaluation now occur beforehand, the steering committee meetings are rich with decision-making and do not devolve into arduous working sessions.

The new process ensures that the BI team is no longer an arbiter of value, but rather, a delivery organization. As a result of the committee's newfound due diligence, the complexity of each proposed development activity is well understood. Projected development time frames are compared with business benefits so that expensive projects are likely to be high value. Before a project is added to the development pipeline, its business benefits are clear. No one worries about eventual adoption and usage of BI.

The COO was removed from the appeals process and now sees BI serve the company's best interests. Requests for new BI capabilities are based on metrics, not back-office politics. The business had become accountable for IT's priorities. Problem solved! 

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access