BI: where 90% of everything is ... crosstabs
Summary: When dealing with business managers, canonical correlations and factor rotations are way over the top - if you can't show it as an A by B crosstab with a few row and column percentages, don't bother showing up.
Business intelligence has been a hot area for years but more than 90% of everything actually being done in it still consists of cross tabulation - and a lot of people don't even understand that.
In one of my first "professional" jobs I did an analysis of grain transportation in Western Canada. As part of that I got the data for about 1,800 points of lading, best guess rail and sea freight costs by grain type from those points to each major Canadian port and thence to our historical export markets, and ran the problem as a constrained transshipment model to see where the grain would go if rail rates were set competitively. The results showed that grain flow would first max out the port of Churchill, then Vancouver, and finally New Orleans with next to nothing going down the St. Lawrence Seaway from Thunderbay - the route most of Canada's grain actually does take.
I could not get the client to understand the method or the result - and neither could a professor of Agricultural Economics from the University of Alberta. In the end, the study was used as supporting documentation for a Government of Alberta investment in the port of Prince Rupert - and I learned an important lesson: stick to crosstabs and simple bar charts when dealing with government.
Sadly, it didn't take - nearly two decades later I ran the systems for one of Canada's bigger technical recruiters and, as part of that, decided to see if I could tell from the intake data (initial recruiter notes, resume, references) which candidates would make the most money for the company -i.e. stay longest in the jobs they were sold into.
The data showed that contract duration predictions made on the basis of six simple characteristics measurable during the intake interview are significantly better than those made by either the recruiters or the employers.
What I discovered next, however, was that the senior people were all comfortable with the idea that their customers would lie to them about the available budget and thus job durations, but absolutely refused to believe that the candidate's pre-placement profile could be used to predict customer behavior in terms of contract extensions.
I had the numbers, I had beautiful overheads with color graphs and output tables, and I had their attention. What I did not get was comprehension.
From this, I learned an important lesson: when dealing with business managers, canonical correlations and factor rotations are way over the top - if you can't show it as an A by B crosstab with a few row and column percentages, don't bother showing up.
Just recently I had occasion to look at an "operational cockpit" for "business intelligence" built as a PC client to an Oracle data warehouse "solution." Know what it does? draws pretty dial-like pictures of A by B crosstabs or single variable time series and then exports the data file to Excel - where proud users are as likely to show you their "complex linear projections" (of row percentages) as anything else.
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
Ehh...
The BI applications are perfectly capable of presenting the data in xls, pdf or html format.
Double ehh?
data! Printing is exporting data. Export refers to
anytime data leaves the internal program actualization.
Contract length algorythem
like it would be quite useful.
Your story is somewhat typical of IT's stereotypical
inability to translate IT terms into business speak,
even if you have to simplify the crap out of it. Would
you not characterize it as that after all of these
years? Hard to blame the people you were trying to
explain it to.
Too true
Sometimes it helps to hide the numbers and just show them colors.
Remember - they don't need to understand how the conclusions were derived - just how they need to act on them.
Technical people tend to assume that others care a lot more about their work than they do. You could make predictions by reading tea leaves, and unless it was auditable they would care as long as the predictions worked.
Sounds like a "trust me" approach
That's why you don't sell
People like magic better than technology. Magic is natural. Technology is something created by a bunch of overly analytical miscreants who are looking to overturn the natural order for their own benefit.
If you have technology that brings an obvious benefit, and people aren't buying it, then it doesn't look sufficiently like magic.
forgot to add...
Don't look at the computer behind the curtain.
Magic
You're also right that technologists think about their work to the Nth degree, because that's what they're used to their audience expecting. There's the expectation that the other people in the room know about as much about the domain as you do, so you'd better be up on your stuff.
My own limited experience with executives, though they're not monolithic, is that they're interested in "can it get the job done?", "Is it better than the competition, or what came before?", "can we deliver it on time?", and "how much is it going to cost?" The way they problem solve is pretty simple. They don't want a detailed analysis. All they want is for you to identify the problem area (in short), to identify if it's a "show-stopper" or not, and what resources need to be marshalled to solve it. The rest is just details they're not interested in. They expect you to worry about that, and to just give them the "executive summary". In other words, you've done most of the decision making for them about the details, and they get to make a decision based on the "big picture".
Technologists can find this disconcerting, and there's a reason for that, and I think it has to do with responsibility. We expect the leader to be completely accountable for the decisions they make. The only way that can happen is if they completely understand what they're deciding on. If most of the decisions about details are left up to us, then the executives can turn around and say, "But you told me this was the better option." This is just from my POV, but I think it's because typically we don't feel we should be expected to get the "big picture". We're just making a proposal that we think is [i]likely[/i] to work for the people considering it. Therefor we desire to [i]transfer[/i] responsibility to the leadership, and ideally if there's a problem with the proposal for their purposes, they will understand why they're rejecting it, or if it does work, why it'll work. I think this comes out of our own world view. If you accept code into your system, you had better understand what it will do for you. If it doesn't do what is required, it doesn't typically work out to say, "I thought this would work." You're expected to KNOW whether it will work or not, and that requires understanding it, not just accepting a sales pitch.
Unintended consequences
I also think the law of unintended consequences demonstrates how often the big picture suffers severe, and retrospectively obvious, rot at the detail level.