Years ago, when I was just a novice in the space of my work, I was fortunate enough to be part of an exercise that opened my eyes to the pitfalls of trying to devise solutions without defining the problem first and considering the proper context.
Defining a Problem Right
We had already solved a problem successfully for a particular company. So, when the second one came in, which looked very similar to the first one on the face of it, we had dived right into the solution. However, the solution did not work for the second company, and the team spent a lot of time trying to figure out why it did not.
The answer came a few years later when I had worked on other problems that looked similar at first but had nuances that differentiated them from one another.
The Two Seemingly Similar Problems
Company A – A particular business function of this company was struggling to produce relevant analytics for their operations team. They wanted an executive dashboard with all the key Performance and Risk indicators as well as drill-down dashboards with all the operational metrics. They were using excel in the background to extract and consolidate the data to calculate the metrics, which had to be put on PowerPoint decks for circulation, or extracts were circulated via emails.
The organization was also working towards creating a data warehouse and bringing in a Visualization Tool. But, at the point, we came in the project was still in progress and the entire process of generating insights from the data required time and effort.
Company B – This company wanted to change the way their financial analysts were working. Rather than spending all their time and energy in putting the data together and creating metrics, they wanted the analysts to concentrate more on working with their stakeholders to understand the nuances of why behind the metrics and what they could do to improve some of them. This would allow them to use their metrics not only for just reporting but also for action which would improve their future performance.
The data systems in this organization were scattered, and different regions were using their own systems or sometimes even Excel sheets or lists on SharePoint Sites.
If we look at both cases, their problems were very similar.
- The data ecosystem was extensive. There were a lot of data systems in play.
- Pulling and consolidating data from multiple systems is difficult as they require much data cleaning.
- So much time went into getting all the data and metrics together that there was no time to get insights from there.
- The final output in PowerPoint was not interactive for the executives to drill down into the data, which invariably led to many back-and-forth emails with queries before the data could be fully understood/assimilated.
How Did We Solve It?
Since the problems were similar, the solutions we proposed to both the companies were also along the same lines.
- Automate the process of getting the data extracted from multiple systems.
- Implement data validation rules so that data quality is maintained.
- Create an interactive dashboard on a BI Tool instead of Excel or PowerPoint so that users can slice and dice the data.
The solution worked beautifully for company A. However, in the case of company B, six months after we had built the dashboards, they went back to their traditional ways of doing things.
What Went Wrong?
So comes the million-dollar question: Why can’t two similar problems have similar solutions? With years of experience in partnering with companies that are looking for such solutions, I have come to realize that problems may look similar prima facie; still, one needs to connect the underlying dimensions to ascertain those facets that differentiate them intrinsically.
The People Component Was Not Considered
For company A and B, the problems looked similar because they consisted of process, data, and technological challenges. However, we overlooked the all-important people component. This was a small issue for Company A because most of the users were savvy enough to work on a BI Tool, but for Company B, this was a much bigger challenge as the users were not comfortable with a BI tool, which led them to revert to their old ways of working.
What Should Have been the Ideal Approach
If we had taken some time to delve deeper into the problem statement and asked the right questions on the profile of the users, we would have eventually known that for company B, we would also have to help manage the change so that the solution is adopted by the users. Knowing that in the beginning would have ensured that we worked towards it, and the solution would have been adopted, and maybe we could have adopted another technology for easy implementation and saved on what the organization ended up spending.
We have implemented this learning while defining the problem-solving methodology at DefineRight. Problems may look similar at first and we need to control our natural urge to jump to a solution without investigating the underlying dimensions. No problem is uni-dimensional and spending some time during the discovery and definition stage to connect the dimensions and refine the share of each goes a long way in creating a solution that is adopted better by users.
