Can you build a data-driven solution without data?
More than likely, here is why and how based on our experience.
Let me start this article with a couple of realities. First Deming never said the quote above, nor would he given his opinion on theory. Second, he never considered himself a “data scientist”. Third, when I hear “no data”, I typically respond with “then there is no reason for me to be here”. Finally, there is ALWAYS data.
Why start there? Because ostensible absolutes never are! Can you build a data-driven solution without any data what-so-ever? Of course not, but you likely have more data than you realize and that is more than enough to build a great solution or tool! I recently encountered a problem like this with a major contract.
Case Study:
I can’t broadcast the name of the company, for understandable reasons, but I was recently approached to build a data model. Only thing was, a few days into the job, I learned that no real data existed. Well that is a game changer. I admit, there was a moment of terror, but it quickly passed.
Let me provide a little more detail. The task was to generate a tool for use by the sales team allowing them to calculate a complex and multi-level P&L for potential new customers. The constraints included a need for total transparency, robust flexibility, and a huge amount of simplification & elegance. In other words, no small task. Additionally, the tool had to be shareable with the clients. Oh — and for budget reasons — was engineered in excel (yeah, we did that).
It was a daunting task with data. Without — well, it looked bleak for a moment. But only a moment, data was the starting point for this project, now I would simply make it the endpoint. Put another way, if not having data is a problem — fix it. And so the task gained a new component — collect and store the data.
Adding such a task may seem like a complication, but legacy data brings burdens of its own. Those were gone now. No need to audit and box (the numbers), no need to account for formatting changes, no need to consider any real data constraints (to start). Things had gotten much simpler (not so much easier, however).
Data is only one component of a data-driven solution.
Sure, it is typically the starting point, but order is not always a big deal. By changing the nature of the tool, we were able to build a model that created data. We focused on simplifying how each model was started, how each model was audited, and how the overall outputs appeared for both the client and end user.
It was learning experience for everyone involved and one frequently complimented by the client. The exercise challenged our perspective and forced us to be innovative. Without data, we focused on the process and ways to drive more accountability. We developed an excellent tool for the company — to quote Forrester Research (TEI was a 3rd party to all this) a truly “elegant solution”. And that solution, aside from delivering on the needs the company had laid out originally, also helped create data. It became a tool for information engineering.
Sure, the typical process of developing data-driven excellence is built upon data. But we were able to turn that around and with new perspective create a truly data-driving tool.
Along the way, we did use existing data. Data from employee interviews, some early financial models, and a few other scattered sources certainly informed our efforts. So we were not completely without data, but few people would argue the point.
If you have the right experience and the right perspective, a data-driven solution can be created in almost any situation. Care must be taken when the data layer is thin. We wouldn’t want to build a tool based purely on opinion… Of course, if it were constructed properly — that wouldn’t be an issue either. Just be prepared for the data you collect to prove your opinion wrong.
Thanks for reading. Need help become data-driven? Consider:
