I've just spent the last week in a series of round-table discussions with leaders from companies in Australia and New Zealand, most of whom have implemented (and a few who plan to implement) data warehouse or data mart systems. It was a good mix of organizations, ranging from some of the biggest to medium size, with all types of projects from bottom-up incremental architected data marts to top-down enterprise data warehouses. We also had the usual mix of a few stunning successes that had radically transformed the businesses, moderately successful systems that hadn't fully lived up to expectations, abandoned systems looking to restart, and second passes at architectures that hadn't proved sustainable. The participants were CFOs, CIOs and senior-level IT management, all with a heavy career investment in data warehousing. They all came to learn and to share experiences and ideas with each other and, theoretically, learn something from me. In the end, as usual, I did as much learning as they did; and I think we all profited from the exchange.

One of the most valuable conversations centered around the CIO of a large forestry company and the CFO of one of the largest retailers in the region. The CIO led it off when he stated that we had the wrong people around the table to be talking about data warehousing. In his view, data warehousing was about the business; and if you wanted to talk about it, you shouldn't have a group of CIOs. You should have a group of business people. My heart skipped a beat. I almost rose from the table and proclaimed, "My work here is done!" I felt even better when the CIOs around the table concurred, and we had an interesting line of comments about the relative merits of technology versus solving business issues. A couple of the people at the table had systems that were either abandoned or did not meet expectations because they had been developed using the "build it and they will come" philosophy. These two provided graphic and moving testimony that the technology didn't matter much if you weren't solving a problem for the business.

The CFO then provided a succinct summary when he said, "Look guys, from the business side, we really don't care if it's done with a computer or reading chicken entrails. We just want the answers." It was humorous and pertinent, and also a lesson for us all. This theme was echoed at each session and reinforced by the people who had systems that were resounding successes. The technology is secondary; you must solve a specific business problem to be politically sustainable.

Throughout the week, the lessons kept coming. The key lessons learned from these groups of data warehousing veterans were:

  1. Build only to solve specific, life-threatening business pain or to provide a meaningful ROI. If you are not solving a specific, life-threatening problem for the business, how can you be surprised when the business doesn't use the system? Building to solve specific pain guarantees that the solution will come shrink-wrapped with political will, resources and sponsorship.
  2. Build only measurable solutions. You can't demonstrate ROI or value to the business if you don't build a system that can be measured on an existing, accepted business metric. In other words, it does no good to build an iterative slice of the data warehouse to "improve customer satisfaction" if you have no operational system that captures and measures customer satisfaction using accepted, endorsed measures and metrics.
  3. Think about process. Don't over-focus on technology at the expense of process. If you don't have your processes (change management, dirty data, more data, more users, etc.) built and tested during pilot, before roll out, you'll never get the chance to go back and build them later.
  4. Think about the human architecture. Build and implement recruitment and retention programs before you lose your best and brightest to more lucrative positions.
  5. Demand documentation. Since you will inevitably lose people once they discover just how valuable the data warehousing experience is, you must require full documentation of all activities.
  6. Think about sustenance. There was much collective grousing among the "Cs" (CIOs, CFOs, etc.) about how the short-term "cowboys" who came in to build the systems rode off into the sunset as soon as the system was rolled out. Political battles, funding battles, resource retention, the "curse of success," ongoing marketing, change management, sponsorship turnover and other issues are all mid- to long-term challenges that you must overcome to sustain a system and have it be an ongoing success for the business.

I love learning, and there is no more rewarding or exciting learning experience for me than spending time with groups of experienced, veteran data warehousing customers. These groups of Kiwis and Aussies were excellent teachers of their data warehouse experience, but I think that subject was too easy. Next time I'll give them a real challenge and ask them to teach me about cricket, rugby and Australian rules football!

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