The Second Most Important Question in the World

There’s a lot to be said for business intelligence practitioners being responsive and being able to deliver to and meet the needs of their clients quickly and much has been written about the benefits of BI teams partnering with their business colleagues in order to provide the best outcomes and value.

But doing so shouldn’t just be interpreted as giving business users everything they ask for as fast as humanly possible. Across my career I’ve found one simple two word question very powerful. That question is: “so what?”

The value of asking "so what" comes partly from asking the “how will you use this data?”, “what decisions will it inform?”  type questions, but it is even more powerful when turned around. Ask the question: “If I didn't have that data available to me - so what?" If the answer is something along the lines of: “I wouldn't know that we had a preventable problem and in 5 minutes there'd be raw sewage running down the main street” then it's worth doing something about. Write that report, enable those analytics – and do it quickly. However, if the answer sounds more like: “I might need that extra piece of information one day”, then perhaps let's wait for one day to come before we spend the effort, time and money.

In today's climate funding and resourcing are not what they once were in BI. There are few open cheque books left and those of us managing the function have to work with other leaders in our organisations to prioritise. Not only does working on low value things demoralise the members of the BI team, it's also an opportunity cost to the organisation. Working on a low value or low impact requests means that something else, something that may have enabled a better decision, led to time saved, a lower cost to serve or a customer prevented from churning was pushed aside and missed.

The “so what?” question is a powerful one. Just be careful how you ask it, and never presume to know the answer or to be able to second-guess your business colleagues!

And, as to the matter of the [first] most important question in the world. Having just spent two weeks travelling long distances on planes and in cars whilst on holiday with my kids I can assure you that the most important question in the world is “ARE WE THERE YET?”

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!

The Next Data Rock Star

I miss the 1980s, there was lots to like about that time: great music, a lifestyle less cluttered by technology, crazy hair, the fact that I could still grow enough hair to have crazy hair. For most of my adulthood if you had asked me which time in my life I'd like to go back to I'd have picked the 1980s. But now I'm not so sure, I'm starting to pine for the late 1990s through to the mid 2000s. Why? Because, that was a time when quite a few data folks working in the business intelligence arena were the rock stars of IT.

I'm lucky enough to have worked on my fair share of interesting and high profile data warehousing and BI gigs during that period. The problems I had the privilege of working on were often difficult, few (if any) commodity solutions or services had manifested, and the solutions we provided were often anything but cheap. However in solving those problems we added real value to the business, at times doing things that their traditional IT staff or software vendors had said couldn't be done or had tried (and failed) to solve with more application centric approaches. Perhaps most importantly during that period few BI projects were undertaken unless the business could really see the benefit. Maybe this was because of the high cost, maybe not. Whatever the reason, those of us lucky enough to be leading the charge and playing key roles in these projects often got the accolades of not just our IT and data colleagues but also  of key business stakeholders as well. I was fortunate to parlay this into a successful consulting career  with word of mouth securing a series of back to back BI engagements stretching for over a decade.

But I fear that the BI Rock Star is a thing of the past. It's becoming a crowded field. Any number of people now "do BI" and what was once bordering on black magic is commodity thanks to advances in (BI) software products and hardware processing power. Even worse, the phrase "reporting" is commonly be used almost interchangeably with "business intelligence". We've all too often moved away using BI undertakings to support complex decisions and solve wicked problems to one where often all too many reports are produced for banal reasons or reasons unknown. It's no wonder then that business stakeholders seem to be seeing less value from their business intelligence dollar.

So, if BI is indeed on the wane, I wonder where the next Data Rock Star will come from. If I was to encourage my kids into the field where would I point them? Will the Data Scientists be the next wave to be lauded by the business, or will those jumping on the Big Data bandwagon get that privilege? Maybe those playing in the NoSQL space are about to be thrust to glory, or perhaps the social media tsunami will mean that's it the intersection of all three which will be the sweet spot. I actually think it won't be any of these. Both Big Data and Data Scientists to me still feel like buzz words - hot topics - that the industry has thrown up and bandied about to the point where airline magazine syndrome has kicked in. I don't see the clear path to the wide stream killer need that means business stakeholders will clamour for solutions in these areas enmasse any time soon.

So, if you can see more clearly than I, I'd love to know what the next big data thing will be. I miss being a rock star!

Where’s the BI Value Proposition?

I can remember a time when the pitch for BI could (almost) be made along the lines of reducing headcount – “put in this reporting solution and you’ll no longer need the team of people who currently spend all of their time compiling numbers in spreadsheets for others in the business to use”. Even when BI cost a mint this scenario still offered an organization the chance to come out in front financially. These days things aren’t so simple. Despite decreasing costs for BI the sales pitch is probably harder today than it was a decade ago. And I’m not just talking about vendors and consulting companies selling BI products and services into their prospects. I’m also talking about selling the value of BI inside companies – making the case for a BI initiative to internal funding boards is getting tougher and tougher with shrinking budgets and competition from other projects and programs.

To have the best chance of success the value proposition needs to be clear.  Often now BI projects will be seen as providing productivity support. They won’t save headcount but they may free up some percentage of time for resources throughout the company or help those within the organization make faster and / or better decisions. Proposing cost savings based upon these time savings is a dangerous endeavor. Such savings may not be viewed as real given fixed wage and salary costs or, perhaps worse still, the department may simply have next year’s budget cut by that amount to ensure the proposed benefit is locked in for realization.

Coming up with the appropriate value proposition may need you to stand back and honestly examine what’s within the scope of the proposed BI program. Is it just static reporting or are you largely replacing existing reports like for like due to a burning platform? If so then perhaps it’s time to swallow your pride and pitch the program like an infrastructure project. Chances are your client or your internal funding board looks at the criteria for assessing these types of projects differently than others, recognizing that they are unlikely to deliver strategic value, cost savings or drive top line growth, but rather just have to be done to sustain the business as usual state – to keep the lights on, if you will.

If your proposed initiative is broader and can be aligned to more tangible business objectives then you have a number of things you should be mindful of when building the BI value proposition:

·      Value is a subjective thing. Look at the perceived value of the initiative at different levels of the organization. Do they all see the value, or does your push to realize enterprise value actually make things harder for one or more departments? If you can find win-win scenarios or at least avoid win-lose scenarios then it will be easier to get agreement on the value.

·      Can you show how the value can be measured over time (and is it actually going to be possible to measure this value)? Financials are just one aspect of this. Speed of decision making, greater visibility and transparency and reduced risk might be things to consider. What ever you decide to include make sure that you can measure and articulate the current state. Not only will it give you a benchmark to measure against but you’ll also have concrete examples of the issues you are trying to solve, rather than just pitching the value of the initiative based around academic or theoretical concerns or problems that have manifested in other industries.

·      Is all of the value expected to be realized in a short to medium timeframe? Chances are this isn’t the case, especially if the project involves analytics or data mining. There likely to be a perceived drop in value whilst the design and implement stages are underway and the business resources are having to participate in workshops, field questions and test while holding down their day jobs. The perceived value is likely to spike once the initiative goes live as the low hanging fruit are harvested but chances are the perceived value will again dip as the business gets more complex and costly due to changed and changing processes, new ways of working and information overload. The real value pay-off may well not come until this stage passes and this state of anxiety and uncertainty can be resolved by working with the business to work with these new learnings and new information to further enhance the analytics and any new or changed processes to again simplify the way people work. Expect this, plan for it and build it into your value proposition. If this pushes the benefits realization out too far to the right then look for ways of chunking the program down into smaller tactical projects all building toward the strategic end game. Show the early value and paint the alignment with the strategic aims and the later value that will be realized.

And of course if you’re coming from the IT side of the fence don’t forget to work with the business through all of this. Not only are you likely to have covered off more stakeholders prior to the pitch, but chances are you’ll reap a higher value from the finished product as well.

Oh, and if you’re from the business side, bring the IT guys in on things too!! Involving them early will lead to higher longer term value.