What To Do When Your Client Wants Sizzle Not Sausage

I love a good dashboard- really I do. So, you'd think I'd be pleased that a trend seems to be emerging that has more business folks becoming aware of dashboards and, by extension wanting to make use of them. But I'm not. Sure, I'm all for the opportunity to provide insight and a better means of managing business operations with an effective dashboard, but the trouble is far too many of the dashboards I've seen built don't do that. Sure, they're flashy, with widgets and gauges galore and often even visually appealing at first glance, but they're simply not designed to give the right sort of insight, or provide that insight in a way that allows them to be used effectively and efficiently. Now that's often not the fault of the person charged with designing the dashboard it may stem all the way back to the client - the person requesting the dashboard.

Unless you have a long standing relationship with your client, excellent rapport and tremendous trust it's unlikely that you'll have carte blanche to determine how they dashboard should look. In the majority of cases they will have come to you with a design already in mind. Chances are that that design will have been influenced by what they've seen elsewhere - be it in other dashboards, or in advertising from dashboard vendors or implementation consulting firms, many of whom seem to promote [just] the eye-catching nature of dashboards, showing off the latest and greatest controls and visual capabilities. And here's the hard pill to swallow, no matter how many of Few's books you've read, no matter how many industry awards you may have won for your prior dashboards, no matter if you have a PhD with a thesis written on visual cues and how people respond to them, your client is still likely to look at your with a mixture of confusion and disappointment if you suggest alternative design and layout options which are too far apart from their own ideas. If you just build and present him or her with what you believe is the better option then 8 or 9 times out of 10 he'll say it's not what he asked for or wants. Push the issue, spouting all of the theory you like, and you'll do little more than back him into a corner. He'll still want the same design, you'll still need to build it, and the company will have an ineffective dashboard - no-one wins in this situation.

So, what's the answer? Why not build prototypes for both - build him his, but also build what you think will work. Give your client what he wants and you may in turn get what you want, either through the chance to explain why you believe you dashboard layout is more effective, or he may just see it for himself and have a eureka moment. At the very least you will have opened the door for a discussion and now be better placed to have a conversation about the things you really need to know - what's the core aim of the dashboard, who will its audience be and what behaviour is it trying to produce, etc.  And, who knows, the same may happen in reverse, having seen your client's option made real you might have a similar moment and realise that it does in fact work more effectively than your own concept. That's not a bad thing, the company will have a usable and useful dashboard and you'll have discovered another design pattern that you can store away to be leveraged later.

The Desire Paths in Your Data

On the days that I drive to work I have around a one mile walk from my car park to my office. There's one particular spot where I can take a shortcut by going off the paved path and cutting across some open ground. It saves me a minute or so on the way to work. Despite the fact that there is a perfectly good sidewalk built by the local council it's obvious that a lot of people must do the same as me, and opt for the faster route as well, because there's now a clearly worn path across the open ground, established by people choosing this path every day. Urban planners call these desire paths - the paths that people choose to take between two points regardless of other options that may be available to them.

If you look hard enough you'll find desire paths through your data as well. Your business intelligence solution offers many conventional paths (like the sidewalks built by my local council). These are the pre-built reports and other instruments that you present to your users. But I bet many of your users have built desire paths - the tips and tricks they use to get and analyse the information they need to do their everyday jobs. Or perhaps the extra things they have to do, those downloads and manipulations in Excel or the sneaky Access database sitting on a spare PC under someone's desk,  because your BI solution doesn't let them do their jobs or perform the analysis they need in its entirety. Now you could argue that desire paths in a BI solution actually represent a form of self-service BI. However, unless you've engineered things this way then you're probably only kidding yourself. Yes, desire paths are examples of your users finding ways to help themselves, but chances are that it's due to shortcomings, not features, within your BI solution.

Desire paths have a dark side in the natural world - they often result in trampled vegetation, can contribute to erosion and (not being as safe as constructed sidewalks) can also lead to injury for those using them. Similarly, in the IT world they are actually likely to cause harm to the reputation of your BI solution or of your BI team. Just like people in the natural world wandering a direct route desire path, shaking their head(s) and wondering why their local planning authority spent all that money building a meandering sidewalk twice as long as it needed to be, your users may well wonder where all of that IT spend on BI went, especially when they "can do the same thing (but better) in Excel". Perhaps worse still desire paths can cause actual harm to your organisation, be it financial or other type of loss, due to decisions based upon flawed analysis or data as desire paths can lack the checks and balances that come from underlying planning.

Our challenge as practitioners, managers and custodians of our organisations' BI assets is to find these desire paths (and in so doing also to find which of our pre-built paths are no longer as relevant as they could be). Can we build established footpaths where the users' desire paths have been worn in over months and years of usage? It works in the natural world and it can work in the technology world as well. There are stories of park planners in some countries visiting areas after fresh snowfall to get a sense of where those using the area are choosing to walk. I've heard of at least one university which built no structured sidewalks on a new campus until such time as the students established desire paths between buildings, simply choosing to pave these paths one year on.

In today's reality of shrinking budgets we all get busy just keeping our BI environments running and meeting the needs for new reports and analytics, let alone spending time worrying about how we'll deal with the next big (data) thing looming on the horizon. But I'd advocate there may be good value to be had in taking the opportunity to look for and act on desire paths when we can. The trick will be finding, or engineering, those occasions, like those times of fresh snowfall, when the circumstances are right to see the desire paths and incorporate key ones amongst them into your BI solution.

Happy (re)building!

BI - It's Not Just Reporting

Many times across my career I've been frustrated by what is, in my opinion, a gross under utilisation of business intelligence tools, platforms and even functions and teams such as Business Intelligence Competency Centres. All too often significant investment has been made in purchasing software, building data warehouses and other solutions, training staff and hiring external consultants, only to have this considerable horsepower and potential being set to work on (just) "the reporting".

Building BI solutions often comes at considerable cost in both time and money and if the chief item provided is purely a set of static reports that tell us what has happened in our organisations then someone, somewhere (and probably somewhere higher up in the organisational chart) will sooner or later start to question the wisdom of the investment. And that's not just a problem for the here and now of the current project, but for the future too. If he has been tainted as to the general value of business intelligence then he may well push back against future initiatives in the area, potentially robbing the organisation of future competitive advantage or effectiveness gains. The problem is made worse still when the default approach to setting project scope is to examine the set of existing reports available from in and around the incumbent solution. In this case the company will have a shiny new toy and (maybe) a prettier set of reports, but may not have gained much in the way of additional business value or actionable insight.

We need to remember that BI offers the potential for much more than just reporting. This was true well over a decade ago and is even more true today with the technology and tool advances we've seen between then and now. Just look at the name: BI, that's Business intelligence folks - intelligence for the business. Simply knowing what happened (via a report), for the sake of compliance, audit or because the procedures say we need to have a piece of paper punched and filed on a shelf, really does little for the running of the business, let alone its advancement. BI should be about helping make decisions that better the business, that help it carry out its operations in the best way possible.

The term "decision support" may seem a bit old school, but perhaps it does capture what BI can offer to the business other than just "the reports". Recently I heard the phrase "the three tenses of BI" and it resonated with me. The first phase is historical - this is the looking back, telling us what happened, function of BI - these are the reports that so often get developed as the majority, or even the entirety, of a BI project. The second tense is the present tense. BI instruments in this area tell us what is happening right now. Reports can serve this function too, but often they miss a key component that stops them playing an effective role. Whatever is used here, be it reports, OLAP components or some type of complex event processing, the information conveyed must be provided in a form and in a time frame that allows it to be used by the recipients in a manner and a timeliness which causes a change which benefits the business that would not otherwise have occurred. The third tense of BI looks to the future - using not only internal information but also looking at wider information sets to try and predict what may happen in the future in and around the organization, thereby providing food for thought for those setting the strategic direction for the organization. What's important to note there is that the second and third tenses of BI require information and intelligence to be presented in order not just to enable decisions to be made, but perhaps also go so far as to highlight that decisions should, or even must, be made.

Simply having a great set of tools available isn't enough. If we want to move on from being perceived as just report writers then it's up to us, as BI professionals, to educate others as to the potential of BI, challenging and assisting them to find ways in which it can be better used across our organisations. So go on, take the first step - share this blog post :)