If You Get This BI Requirement, Run!

The Lamest BI Requirement – And it Won’t Go Away!

Want a sure path to failure in BI and data warehousing? Don’t solicit requirements from your users.

Want a second path? Settle for the requirement, “Just give me everything (JGME) and I’ll figure out how to use it when you’re done.”

I’m over 25 years into this field and I still see this requirement – and I still see BI / DW teams falling for it! It’s totally lame (am I allowed to use my kid’s vernacular in a business post?) and leads to systems that just don’t get used.

JGME: What Your User is Really Saying

You do realize that when your user gives you that requirement he’s just taking your time for granted, right? What he’s really saying is, “I don’t have the time for you right now so, make a big investment because I may have the time to figure it out myself somewhere down the road.” Why is ‘down the road’ better than today? Why can’t your user spend a few hours with you, before you make big investments, to consider what he really needs? To consider what will actually benefit the business?

How Do You Design JGME?

In a perfect world we might provide our users with some thoughts about what’s possible but they are really responsible for telling us what they need. We, in turn, are responsible for implementing it. But, without real requirements, how are you going to design things like data models? How will you know the things on which you should be capturing history? How will you configure BI tools to properly present the data? etc.

Your users said they need everything! So, why not just give them copies of their source systems?

Why Do We Fall For it?

Building systems is fun. Playing with data is fun. BI and DW has been on the cool technologies list for years now. And, frequently we’re just told to build these systems and we don’t want to push back.

What BI Requirements Look Like

While it used to be sold as, “build it and they will come”, the truth is that effective BI is no different than any other type of business system. Business systems (e.g. sales systems, ERP systems, inventory systems, etc.) force business users into defined business processes – sets of steps for doing their jobs. Whether users like those processes or not, they follow them – it’s the only way for them to do their jobs!

Somehow, though, in BI, it’s OK to drop the idea of business process? Rather than understanding how the system will be used and how the business will change it’s OK to just puke data all over our users and assume that everything will work out?

Think about this for a second. Don’t your users already have jobs that require at least 40 hours (35 in France) of work each week? How will simply giving them a new source of data help them? In most cases it won’t and, as a result, you’ll have built a system that no one wants, needs, or uses.

Real BI use is tied to business process. Understand how the system will fit into the work flow and why it’s necessary for improving that work flow and you’re on your way to good requirements. Ignore workflow, ignore business process and you’re on the path to failure. Simply accepting the JGME requirement doesn’t touch on business process.

Push Back

So, yes, we want to say, “Sure, we’ll deliver it” to every request but I suggest that you push back when faced with the JGME requirement. Tell your sponsor that his money will be wasted if he doesn’t invest a little into requirements. Then describe what you mean by requirements…

An Outline for BI Requirements

So, what do decent BI requirements look like?

Beneficiary / Sponsor and Target User

You can’t tell what someone needs until you know who that someone is. So, your requirements should start by indicating who will use the system and who will benefit from it.

What is his job / his business process today?

The next step is to briefly document how the business process is accomplished today. What do people have to go through to complete it? Where is it awkward and inefficient?

What does he think it should be?

Then, design out the improved business process. How will the new system enable that process? Why can’t the new process be implemented without the system?

What analyses does he need to get to this new process?

So, the new process needs data. That data will be presented in one or more formats consisting of charts and tables. What will these look like? At this stage you should, perhaps with a pencil and paper (remember those), draw them out. Work with your user to understand what data he needs to see, how he needs it presented, how he’ll need it filtered, how he’ll need it sorted, etc.

No, I’m not naive – of course his needs will change once you’ve delivered the analyses. So, when developing, you will likely collect more data than his screen designs require. You might also build a few more screen objects than he asks for. However, what you build will be based on a thought-out business need, not on an ill-defined, cop out requirement of ‘give me data.’

What are the expected benefits and how will they pay for the investment?

Finally, it’s important to question if the investment will be valuable. Yes, perhaps a new BI system will enable a new business process but how will this benefit the organization? Why is it worth doing?

Quick example: suppose an automotive warranty group reviews claims every six months to see if particular parts are creating outsized warranty costs. Further, suppose a sponsor in warranty realizes that changing this business process to a monthly or weekly process will catch these issues sooner, saving on warranty costs. With some simple math you can estimate the value of this new business process. (IMPORTANT POINT: The ROI of a BI system is zero. The system is the ‘I’, the investment. The return, the ‘R’, is a result of the new business process enabled by that system).

Two Exceptions

This JGME rule has two, limited exceptions.

Tiny Scale Demonstration Systems

Sometimes it’s important to show sponsors what can be done. In these cases you might create small demonstration systems based on what you already know about the business problem. However, once the business buys in (if it does), then you should capture real requirements for your production system.

Data Scientists

BI tool vendors will have you believe that every user in your company will be clicking around, making new insights. That’s not going to happen. Almost everyone in a company has defined goals and things they need to get done. They execute business processes to complete these tasks. The one exception is your data scientists. This is a very small group of experts whose job it is to find and evaluate new data, looking for new insights. These people may, validly, have the JGME requirement. However, these people usually only need this data temporarily – they do their analyses and then go on to the next topic. Tools like data lakes and unstructured data storage technologies (e.g. Hadoop) are usually best for needs like these.

Any thoughts? I’d love to hear them. Just comment on this post. Thanks for reading!

Need BI and DW Staff?

Over the past few years our business has expanded to include BI and data warehouse staffing. Client reviews have been exceptional. I’d love to discuss your situation and how our staffing and consulting offerings might help. Call me at 734.585.3503.

Thanks!