We decided that a data warehouse and Web-based reporting system would be the ideal solution. But we also knew it could be very expensive and time-consuming to develop, and the process is full of uncertainties. Every CIO is familiar with the research showing that the vast majority of such projects fail. Since data warehouses often span multiple departments, there’s the inevitable challenge of deciding which department gets capabilities first. And then there’s the task of reconciling different content definitions. In our case, each department used the same terms to mean different things. In marketing, for instance, vacancy might mean unleased space; for Property Management, it might also include leased space that’s currently unoccupied by the lessee.

Agreeing on data definitions, ensuring the integrity of complex data arriving from heterogeneous sources, and managing multiple businesswide priorities can easily overwhelm even a "reasonable" project schedule. And with a data warehouse, there’s no place to cut corners when it comes to data integrity. Put simply, dirty data can kill the credibility of your data warehouse.

And data warehouses—which demand that each department use the same terms for the same things, and are useless without absolutely accurate information—fail more than most.

More than a Pilot, Less than a Megaproject

Given these challenges, I decided that the best way to successfully deliver a large, robust data warehouse would be to start with a small, narrowly targeted data mart. And then if that worked out, we could build another. So rather than accept a pot of money to build everything we needed, we quickly developed and rolled out several single-purpose, low-cost data marts. We hoped that these would provide just enough functionality to demonstrate the business value of a larger system.

We understood that even if these small data marts were wildly successful, additional funding could not be guaranteed. But if it turned out that the business didn’t really want or need a data warehouse after all, it was better to know that after spending only 10 percent of a multimillion dollar investment. In addition, when it came to getting the business units to agree on data definitions, it was easier to get their help with a small project than a megaproject. It demanded less of their time, and they’d be able to see benefits sooner.

So we developed an implementation plan, using stringent portfolio management guidelines to determine which capabilities to offer at launch and which could wait until later versions of the system. My team worked with the business side to develop cost-benefit analyses for every requested capability, looking at the hard benefits (of automating something instead of doing it manually) and the soft benefits (what is the cost of a bad decision on a loan?).