Inside the Biz with Jill Dyche

It Doesn’t Work Like That: BI Development Myths

In which Jill debunks some BI myths and kills your buzz.

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

Rebranding and the Customer Experience

In which Jill argues that rebranding is in the eye of the beholder.

 “Watch your elbows! Coming through!” The outward briskness of the flight attendants is a physical manifestation of their collective intention, which is: “Let’s hurry up and feed these trapped masses so we can retreat to our jumpseats and read ‘OK!’.”

 “We have no implements,” a flight attendant replied when I asked for a spoon. I was 5 rows behind first class, where the tinkling of utensils was drowned out only by the clatter of the liquor cart rolling on its well-worn casters. The twitch at the corner of what was otherwise the straight line of her mouth betrayed her. We were both in on the ruse.

In an act of sheer passive-aggression, I stuffed all my dirty napkins into the seatback pocket, along with a dozen reply cards from various magazines—seven of them from a single issue of Vanity Fair—used the first-class restroom, and contemplated breaking the ultimate rule and texting some friends. I was in a bad mood, suggesting that the Stockholm syndrome is indeed alive and well at 35,000 feet.

Interestingly, this same airline recently rebranded. But rebranding is a hollow exercise if it’s not accompanied by changes in the customer experience. A revamped logo and a signature cocktail in business class hardly count when the flight attendants continue to patrol the cabin like martinets. In the world of customer loyalty what counts is the way your behaviors change. And no, you may not have the entire can.

photo by Aaron Escobar (via Flickr)