It Doesn’t Work Like That: BI Development Myths

When I was a little kid I would travel by air to visit my grandparents. In those days, PSA was the popular airline, flight attendants were called “stewardesses,” and we all romanticized air travel. When I grew up, I wanted to be a stewardess so I could wear go-go boots to work every day. And I was convinced that the luggage conveyors were part of a vast, subterranean network of moving beltways that transported my luggage as I flew to my destination, where it would rise from the earth and reunite with me on the other side.

“It doesn’t work like that,” said my father.

I hadn’t learned the word “buzzkill” yet, but if I had, I would have used it often with my father. And sometimes my clients should use it with me. This is because we often find managers in both IT and the business who have misinterpreted rules or learned fraught practices for BI development, formulating ineffective processes based on a set of mistaken assumptions or extrapolations. And they’re crestfallen when things don’t work out as planned.

Take the concept of the “single version of the truth.” When the phrase is mentioned, many imagine a huge, centralized database with single, enterprise-sanctioned data …

When I was a little kid I would travel by air to visit my grandparents. In those days, PSA was the popular airline, flight attendants were called “stewardesses,” and we all romanticized air travel. When I grew up, I wanted to be a stewardess so I could wear go-go boots to work every day. And I was convinced that the luggage conveyors were part of a vast, subterranean network of moving beltways that transported my luggage as I flew to my destination, where it would rise from the earth and reunite with me on the other side.

“It doesn’t work like that,” said my father.

I hadn’t learned the word “buzzkill” yet, but if I had, I would have used it often with my father. And sometimes my clients should use it with me. This is because we often find managers in both IT and the business who have misinterpreted rules or learned fraught practices for BI development, formulating ineffective processes based on a set of mistaken assumptions or extrapolations. And they’re crestfallen when things don’t work out as planned.

Take the concept of the “single version of the truth.” When the phrase is mentioned, many imagine a huge, centralized database with single, enterprise-sanctioned data definitions that have been blessed by everyone via widespread consensus and executive sign-off. The database rests in the middle of a complex set of business applications, which consume its pristine and static data forevermore.

It doesn’t work like that. In reality, BI users need to see the data differently depending on where they work, what they do, how they interpret and use it. A product hierarchy in the Finance organization may be defined differently than a product hierarchy in Marketing. The company may be able to define a term at the enterprise level but that doesn’t mean there’s a single, sanctioned definition for each data element. When it comes to data, context matters. This means that as that data changes along with the business, data dimensions and definitions can likewise change, rendering the data warehouse less of a centralized behemoth, and more of a dynamic platform—or set of platforms—for the provisioning and processing of dynamic data. (See Evan Levy’s TDWI article, “SVT No More” and Peter J. Thomas’ blog post on the topic for some more myth-busting.)

Another example is business requirements gathering. Many people think it’s a matter of interviewing a few subject matter experts, poring over existing reports, and perhaps having a facilitated workshop (formerly known as a JAD session) to collect and document user input.

It doesn’t work like that. Gathering requirements for BI has changed. It’s more structured and time-boxed, it’s increasingly driven by subject matter experts on the business side, and delineating business, data, and functional requirements is a best practice. Business requirements gathering has also become more automated as new tools provide persistent documentation and definitions that can be used to inform and refine subsequent development efforts. When done correctly, business requirements gathering not only ensures that BI conforms to business needs, it can drive a rigorous development pipeline.

Many managers and executives, new to BI but already sold on its strategic and operational promise, believe that if they start with a good plan success is in the bag. They’ll retain a consulting firm to build a BI roadmap and make some organizational suggestions to ensure that BI-specific functions exist. Then they’ll scout the organization for “who’s available,” to put on the BI project, with little or no regard for previous BI experience. (We call this “warm body syndrome.”)

You saw this one coming: it doesn’t work like that. The most successful BI efforts are ones in which at least a few key delivery personnel are seasoned, having done the work on past projects, and are able to mentor those who haven’t. Even a detailed roadmap reflecting a BI-centric methodology and prioritizing specific tasks won’t guarantee success if the skills and experience are missing.

The best BI development projects involve rigorous processes, experienced staff, an understanding of the development pipeline, and adherence to guiding principles for success. But too many BI teams rely on hope and imagination to get the job done. It doesn’t work like that.

Buzzkill.

photo by ToastyKen via Flickr

Link to original post