How do you measure success? My brother thinks I'm a success because I get to work with the world's most successful companies and my work takes me all over the planet. I think he's the successful one because his schedule allows him to coach little league baseball and referee youth basketball.

Some of my peers think I'm a success because I keynote conferences, write this column, provide a voice of pragmatism and look out for the data warehouse troops in the trenches. On the other hand, I do most of my speaking for free, I don't have a dozen books, I don't have any overt or covert vendor money deals and don't resell hardware or software so some of my peers think I'm an altruistic idiot who is missing the gravy train.

As you can see, success depends on your perspective and your measures of success.

Recently, the long-dormant issue of the success rate of data warehousing has been revived.

A few months ago, I heard data warehouse success defined as any site where the data warehouse project is not shut down for more than six months. In other words, regardless of business impact, team retention, political sustainability, etc., as long as some work is done on the data warehouse every six months, the project is deemed a success.

In the same time frame, a vice president of a storage system vendor defined success in this manner: "Using the correct criteria ­ did the business get some value out of the project ­ my personal experience (not a survey) says that more than 95 percent of the projects experience some success." The vendor VP doesn't define specifically what "some value" means. Thus, we'll have to assume that as long as one business user gets one answer from the system, it has passed his success test.

If you're a data warehouse team member or project manager, you're probably thinking the same thing I did when I read these definitions of success, "Why can't I ever work on a project like that?" In more than ten years of building data warehouse systems, I've never had a client who let us get away with such loose standards and low hurdles. I doubt you have either.

The key here is scale. You and I are concerned with the success of specific projects, systems and companies ­ in effect, a micro scale. We're only as good as our last project. Others are looking at the macro scale. If the global data warehouse market does well, because they are practically guaranteed a certain percentage of that business, they do well. Their view isn't invalid. It is just a different perspective than ours, one driven by the scale in which they are invested and rewarded.

As you can see from their criteria, macro success measures may not align with the hurdles that those of us in the trenches actually building these systems have to deal with at the micro level.

A good rule of thumb for you to determine if someone else has the same success criteria as you is to ask, "Will they still have their job if my team fails?" I'm sure you are painfully aware that if we don't meet the standards the business sets for success, the entire team will be looking for employment. I think you will agree that regardless of what happens to the project, the business and/or team, the people who are rewarded based on the macro scale will still be doing quite well. Thus, we have the fundamental disconnect between measures for success and the consequences of failure between the macro and the micro.

How do you measure success?

First, and most importantly, define the measurements of success with the business before you start. The criteria that you and the business agree on are the only criteria that count.

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