THE POLITICS OF DATA WAREHOUSING
By Jill Dyche

I know of a data warehouse development organization comprised of more then 50 people that hasn't done very much in the last few years. When it comes to having actually received new decision support functionality, the company's end-users just shake their heads.

Meanwhile, the Director of Data Warehousing has his developers re-packaging existing functionality into yet another reporting tool. ("Let's call New-Vendor x and see a demo!") Developers no longer talk to end-users. The data warehouse development team has transformed itself from a cost-recovery center into a large corporate expense. Over half of its permanent staff members are administrators. And it has delivered no new business value for a long, long time. (One hallmark of a data warehouse development team in trouble is if the majority of the team members spend more time talking about architecture and acquiring technology than they do discussing gathering additional data and defining new business functionality.)

In reality, a competent project manager, a DBA, a data administrator, a business analyst, and a few crack programmers could turn the entire project around in a matter of weeks and begin delivering real value for a fraction of the current budget.

What happened here? Many of those failed data warehouses everyone's been citing floundered for reasons having nothing to do with technology. While the failure rate may have been overstated or understated, most of these projects crashed and burned because of cultural and political issues. Indeed, I've seen data warehouses fail-good data warehouses with valuable data-for reasons that were strictly political.

I know, I know. Avoiding corporate politics is easier said than done. Granted, the issue is bigger than you and me. Often politics are so entrenched in an organization that behavior simply doesn't change, regardless of the type project. The director mentioned above increased his staff from around 18 people to over 50, and his budget money five-fold, while deploying fewer applications and less data over time. Inexperience? Probably. Empire-building? For sure.

The danger here is widespread disenfranchisement, not only among users, but also among managers and even external people. The data warehousing practitioner community is a small one, and people talk. The project described above has an unbelievable attrition rate. Other companies in the same city have heard about the project and avoid recruiting its staff. Developers who quit expunge the project from their resumes. The end-users have launched their own decision support development projects and are calling outside consulting firms for help.

If we applied the old Maslow's Hierarchy of Need to today's business world, it would become apparent that basic human need for survival is alive and well in corporate America. And in their effort to "survive," people take on interpersonal and social roles that will give them the most control over their outcomes. This need for control unfortunately often supersedes the need for the greater good-delivering meaningful information to end-users, for instance-and can steer a data warehouse project off-track in no time.

The need for control can be translated into a struggle for "ownership," and the ownership battle is bloodying the hallways and executive office suites of companies trying to deliver decision support as a business solution. While we've already touched on well-documented conflict between IT and the business community, strife within those organizations also foments data warehouse setbacks. Should the executive sponsor be from Marketing or from F&A? Should the Advanced Technology Group select the appropriate application software, or should the development staff? Should the project manager deliver status reports to the steering committee, or should the CIO? And who owns the data?

In fact, a data warehouse project, often involving months or years of development time and millions of dollars in funding, can upset the organizational apple-cart, replete with employees who are comfortable with their place in the heap. Corporate data warehouse projects poach staff members and budget money from other programs and often hang their own shingles as separate development groups. And because these organizations do things differently-talking directly to users, often simultaneously with other IT projects, and delivering high-impact tools quickly-employees on different projects are either threatened or tempted to join the data warehouse team themselves.

Sometimes you can spot the trends, nipping them in the bud before they topple the project. This chapter's final Top 10 List illustrates a few warning signs that may indicate that politics are hindering your data warehouse's progress. Look for the following indicators, and take decisive action early, and you may have spared your business untold cost.

The Top 10 Signs that Politics May Be Sabotaging Your Data Warehouse

1. Hiring and staffing take up much more time than actual development activities do.
2. Key stake holders come from either IT or the business side, but not both.
3. The same business users showing up time and time again to articulate new requirements.
4. The establishment of euphemistic job functions such as "program manager" or "architect" without socializing an understanding of what those functions are intended to deliver, or relating them to existing job functions.
5. One or more "skunkworks" development projects that people don't know or aren't supposed to talk about.
6. Staff members continually being reassigned to other projects or different roles.
7. Executive sponsors who selectively spoon-feed progress reports to other organizations or staff members.
8. Executive sponsors who favor a single vendor and impose that vendor's technology or architectural tenets on the project with no due diligence and without consensus.
9. No formal processes for requirements sign-off, changes to project scope, prototype review, or end-user acceptance.
10. No formal processes for establishing projects, their priorities, their time-lines, and their review.

The premise behind Occam's Razor says that the simplest solution is most likely the best. But overkill technologies, numerous staff resources, and padded budget money are the dictum of the day for many data warehousing projects that should be straightforward and easily-executed.

My advice? Don't go into the light! Try the easy approach first, identifying the work, then the skills needed, then the people, and identifying core requirements prior to selecting technology. Make your development team small and nimble and your deliverables quick-wins.

If it's an empire you want, deliver decision support right the first time, and you'll be recognized based on your merit, not on your head count.

For more information, contact: www.Baseline-Consulting.com.