Showing results for 
Search instead for 
Did you mean: 

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

Level 9

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?"

Level 17

Excellent, I think that "Why" could be the compass in decision making when it comes to structuring. Having the underlying understanding, or even the underlying reason or background from the decision maker. Knowing this info usually sheds light on what they think is important, allow you to make sure that is covered - then let your expertise fill in, and you will seem like the Golden Child.

Level 18

Sometimes it is not the matter of asking the right questions but getting the others on the project to understand "why" the question is relevant and the impact if it is not related to an area they are intimate with.  For example it could be a limitation that is brought out by asking the right question but others might not understand the relevance or impact and dismiss it lightly.   At times the answer is in proper documentation...this is especially true for legacy items where tribal knowledge is lost and people trying to "streamline" things turn something off or change how it is manipulated in the name of efficiency.  With proper documentation why it is there and why it works the way it does and why it is important to the business, many of the questions are already answered.  This applies to data as well as other projects.

Level 15

As every company that I have worked for continue to try and implement LEAN techniques, it seems that there suddenly are SME (Subject Matter Experts) that think they know the processes and how things are working.  I find it intriguing in your post that the need to ask the "Why" questions.  It seems that is the hardest part of every Kaizen or Rapid Improvement Event that I have been part of.  I never thought of extending it to include data as well but now that makes a lot of sense.  I too think that documentation helps and if you have the risk assessment security documentation that puts you into a position to be able to properly answer those "Why" questions.

It takes some time to develop the LEAN thinking methodology to solving problems but ultimately the projects solve easier.

Level 9

Both of your points are very sound, with the former one probably driving good BAs to drink more than they should. Us tech folks don't always "get" all of the real business needs right off the bat, and may need to be clubbed over the head a little extra to really understand the relevance of some small detail or "weird" requirement.

Level 9

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.

Level 13

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.

Level 14

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.

Level 9

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.

Level 15

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!

About the Author
Kerry Tyler started his SQL Server career when he debuted as an accidental DBA in 2005. It wasn't all bad, as he had been hoping for such an opportunity. Seeing Reporting Services 2005 demoed for the first time sealed the deal, and it has been all data ever since, leaving the worlds of networking and systems admin behind. After being a full-time dev/operational DBA with everything since SQL 2000, Kerry is now back to BI, as a Senior BI Engineer/Consultant in Nashville, Tennessee.