I have a unique job; I am actually paid to visit with customers and prospects to discuss data warehousing and the associated applications CRM and business intelligence. Many people ask what is so unique about that? The answer is that I am neither a salesman nor a consultant. I have no deliverables and no quota! Because I do not have my hand out, I can ask some rather unique questions. It is worth a moment to exam them.
After the usual introductions and formalities with the ritual walk through of the state of the project, I will generally ask, "Do you want the truth about the project or do you want the propaganda?" Some would call this a crass question but there is method to my madness. When you have reviewed 500, yes 500, data warehousing projects the problems become apparent within minutes after entering the conference room. While I virtually always get the "tell me the truth" answer it triggers an old movie line "but can you handle the truth?" The answer in many cases is no. Lets examine some of the issues.
The consultant’s dilemma centers about the question of getting the business as opposed to executing the business. In the selling process the revenue drive is so high that they will avoid conflict at all cost for fear of losing "the deal." In execution mode they then have to live with the consequences. Those consequences include an inability to get key issues resolved, failure to get the customer to adhere to a committed project schedule, undersized infrastructure and poorly defined deliverables. All of these lead to failures in meeting expectation.
Another side of the dilemma involves putting the horse before the cart. Often you walk into a meeting and the dialog goes: "We can’t define the business problem we are solving, we have never done a data warehouse before but we are going to do it on this platform with products x, y and z." Clearly the commodity salesman has been a work here. They don’t know what the problem is and where the funding is coming from but their product is the solution. This is called the sales-created dilemma. Generally, there is a total disconnect with the business user who has not participated in the incipient project. This is often the beginning of a phenomenon called "user alienation," a major source of project resistance.
What can a project team do to avoid playing into a potentially no-win scenario?
First, always begin with the business problem. If the solution does not involve revenue, profit, security (only a recently added concern) or market share, it is probably not worth doing!
Second, does the solution fit the architecture of the business? A loose conglomerate of companies is not going to gain value from an enterprise warehouse. That does not mean that each individual unit cannot derive value from a unit-based warehouse, just that a global solution will not work.
Third, are the parametric limits of the project understood? There are three: number of potential users, amount (duration) of data and potential query mix. Without these approximate sizes (order of magnitude), the project will search for the "right" technology base without data.
A fourth requirement is active user participation. Data warehouses developed without active participation lead to the "great dilemma" (stay tuned I will get there). The message here is that the development process and participation are the methods to gain user acceptance.
A fifth requirement is to "never drink the vendors Kool-Aid." Every consulting company and every product vendor will have a "total solution." If there was a total solution everyone would use it; there would be no competition. The best solutions, which usually are associated with highly integrated ERP-type front-end systems, reach into the 90 percent bracket in terms of meeting requirements. They also come with a requirement that you change your business to match the package, not something that business people accept well.
A sixth requirement is listen to all the technical options. A lot of people in the business today are technical "tree huggers." That is, they are so committed to a technology that they cannot or will not hear technical alternatives. This is the kiss of death in data warehousing. Its not about the technology, its about information to run the business. There are no right or wrong solutions. There are, however, solutions which allow for great scalability or solutions which are more cost- sensitive. These are the two poles of the scale. You can acquire higher-level technology that mitigates the risk of unknown demand or buy cheap technology that will require rehosting or rebuilding at shorter intervals. All of this leads us to the "great dilemma."
What is the Great Dilemma? The dilemma is whether or not you truly understand data warehousing and client/server architecture. Many project teams begin the project with an imperative to provide good performance. There is no such thing in data warehousing! Because data warehouses make people smarter, the query load will always get more complex. In fact, if the query load does not get more complex you had better worry; what you have is an overgrown reporting system, nice to have but far from the maximum business value.
By now you are agitated! You are going to have to wait for the next column to find out the solution to the dilemmas. Do you think I watched too many cliff-hangers as a kid? Bye for now.
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
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access