My last few blog posts have discussed how data failure happens, and how we can change failure into success (with a little economic thinking). Continuing with that train of thought, in this post I’ll be discussing how we can better implement analytic solutions by challenging the convention of requirements gathering.
Don’t “Gather Requirements”. Hunt for Questions.
Requirements gathering. The meetings that are universally hated on both sides of the table. The business is thinking “I shouldn’t have to explain to them what I want again!”, while the data people are thinking “If you just told me what you wanted the first time, I wouldn’t have to keep asking!” We’ve all been in this situation, whether on one side of the table or another, or maybe we’ve had the fortune of having experienced both sides.
I have seen these sessions end in frustration and poor outputs. For example: from the data team there is some helpful talk of “What do you do now? Where are your current reports?” or something similar. The answers from the business are usually equally helpful “We just have it all in this spreadsheet.” or “We VLOOKUP to another spreadsheet.” At the end of the meeting, usually after some disappointment and frustration that of IT saying “We can’t do that.” or the business replying “Why isn’t this in your data already?”, everyone leaves. Waiting for them when they return to their desks is an Excel workbook with the some of the points that were captured during the meeting. These workbooks usually become the “requirements” that are used to build with… It makes me frustrated just typing out an example for you!
I think that part of the problem, again, relates to mindset. The appropriate mindset for both parties is how they can solve a problem together. Far too often transgressions of the past are brought out on how each side of the table has failed the other. And even when requirements are delivered from the business to the data owners, those requirements are symptoms of a greater issue; data dumps from business intelligence or analytical tools are a prime example of this. “I just need to replicate this exact format with these columns”, is a common refrain in these scenarios. (Well… you did ask “What are your requirements?”) And sadly, that is what is delivered usually. It is like seeing a festering wound and the patient only asking for a new band-aid, and maybe a fun Star Wars themed one this time instead of the Captain America one that is being removed. You both know that there is something wrong, but damn, R2-D2 is looking so cute covering it up!
I think the proper way to approach these meetings is to set the tone of understanding that there is a problem to be solved, set some expectations on how fast or slow things may be delivered, and start to ask real questions. Open ended and hard questions like the following (and I am leading with my favorites):
- What question or questions do you have that you need data for?
- What question or questions does this data set answer for you?
- What actions can you take because of this data?
- What actions can you not take because of a lack of data?
- What story does this data tell you?
- Is this data’s story incomplete?
- How does this data help you do your job?
- What do you do with this data when you get it?
There are many, many questions like these to ask and to answer. This is how to identify what is really needed or desired by data consumers. These questions are akin to asking someone what flavors they like, or what kind of food they prefer, as opposed to asking “What did you eat in the last 2 days?” and inferring what their tastes are from that. Someone may love oysters, champagne and saffron, but if it is expensive, they won’t have it all the time. (Remember that data marketplace part? Yeah, it’s still relevant here.) Instead, they may be eating frozen fish, drinking boxed wine and seasoning with Morton’s Season All because that is what they can afford, with some of their desires being a treat. And the same is applicable to data consumers; they may be asking for what they have now because they may be unable to afford the effort involved to capture and use that data, their current solution hasn’t been challenged, or they may think that data is simply “off the menu”. At the very least they can’t afford it without help from the suppliers, and that is part of the suppliers role — putting data on the menu for consumers, at (hopefully) at an affordable price.
Obviously, it’s hard to take the questions above and deliver something quickly. That isn’t the point. The point is to help create organizational change to enhance the data that is being used. Status quo thinking doesn’t bring change, and while change can be a great and needed force, it usually isn’t easy… Don’t fall into the trap of using that method as the default. Stay strong!
My take aways for consumers: Think about what data you need, the data you don’t have and what questions you can’t answer. From there, brainstorm how you can help the data suppliers understand these pain points. An export or data dump is a failing answer in my classroom!
My advice for suppliers: Try to read between the lines and understand what the consumers are really gunning for. Once you understand that, try to find ways to deliver it!
