Data Projects Need the Right Answers…So Ask the Right Questions

Over the last few months, I've spent a lot of time talking to different people about the importance of the "B" in BI--as in "Business Intelligence" (stay with me, DBAs, I'll get you roped in here soon enough). I joke that that "B" is there for a reason and it's no accident that it's the first letter in the acronym. The point I make is that the hard part of BI projects isn't deciding what technology to use or working through hurdles that come from questionable data, but instead, understanding the Business needs that got the project started in the first place.

Or, put another way, making sure that the "Why?" questions are asked first and foremost, and that the answers to those questions are used to ask better "What?" questions on down the line while the solution is designed, developed, and implemented.

This works well when the word "Business" is directly included in the type of data work I do, but this applies just as readily to plain ol' DBA work, as well. Everything from data modeling considerations to planning big database consolidation projects need to start out by asking and understanding the "Why"s coming from our business leaders and our userbase. Sometimes these questions are easy--"Why do you want to be able to restore yesterday's database backup?" Other times they might be hard to get answers to--"Why is this KPI calculated three different ways in this one report?" (true story!). Chances are, asking these questions will have some kind of monetary impact. For a BI project, it may cause the project to complete quicker with less re-work late in the game, while the need to upgrade some old, unreliable hardware may lead to a server virtualization project for a DBA team.

I've seen both BI and DBA projects go sideways because the right questions weren't asked early enough in the project lifecycle; conversely, I've worked with some great BAs who are fantastic at understanding the business rationale and ensuring we, the technology team, all did, too.

What kind of save-the-day stories do you have that started out by asking "Why?"

  • If only everyone thought the "chit-chat" was that important.  Imagine how many more projects would start off on the right foot and never hit those "oh crap" moments months into the project!

  • Hahaha, yes, yes it does. I tend to think the only people who regularly/all the time don't think such meetings are welcome are the same people who may miss the whole point of asking "why" in the first place... "oh, it's a waste of time; we don't need to know this info to design the DB/business logic/OLAP system/etc, let's just start..."

    I tend to think the more time we spend with the business users/project champions--and it sometimes starts out as just chit-chatting with them about what they do--the more "why" answers just pop out...This is my favorite, because we didn't have to think to ask the question in the first place, we just got good info dumped on our lap.

  • The Why question always seems to spark a long meeting.  Sometimes it is a welcome meeting, sometimes it is not.  But in the end, it is usually good that it is asked.

  • The "why" is definitely the most critical. If you focus on the "how" and ignore the "why," you may end up quickly and efficiently completing a project that turns out to be completely the wrong project for what the business needs.

  • I've worked in shops where all of the "real" SMEs are gone, and there wasn't enough "tribal knowledge" (thanks for reminding me of that term, Jfrazier) to fill in all of the gaps, so we had standing rules of not touching certain areas of the data models...the risk was too high, because nobody could identify all of the areas of code that could be affected. It's not a fun place to be where there's no documentation nor people around to address the "why" questions we need the answers to.

    "Why" questions are good for data projects, and especially Business Intelligence ones. Lots of times the business users who are looking for some reporting (for example) can't quite articulate exactly what they are looking for, but if you talk them through the "why" of their job or the data elements they can point out, what really needs put together pops right out for all involved.

Thwack - Symbolize TM, R, and C