I often speak at conferences about focusing on pain points when deciding upon a solution – any solution… technology or otherwise. I unfortunately see a lot of solutions out there looking for a problem, which to me sounds like pretty bad business. What’s the point of building something that’s cool looking if nobody is going to use it?
The secretary from Tennessee
There is a story that I share in my speaking engagements that resonates quite well with the audience. I’m going to attempt to put that in written form. Let’s see how it goes. If you have a minute, let me know in the comments area if I succeeded or not.
About 6 or so years ago, I worked with a company which did some high level process based on-site consulting gigs. SharePoint Server was the main technology of choice to come up with quick no-code solutions. We visited a government subsidized facility in Tennessee with the intent to look at how current processes can be optimized. There was this secretary there whom we met. One of her daily tasks was to run reports using Microsoft Excel. She would run these reports daily, print them out to a printer sitting behind her desk and then walk the reports to another building where the executive offices were for this organization. She would chat with the executives a bit while at the other building, then come back to her building and resume her other daily routine. The whole process took about 1.5 hours each day.
The Aha moment
Bingo! When we saw this process, we thought we found a pain point that could be “fixed” quickly. These folks already had a SharePoint Server license, but they were not utilizing many of the features available to them. So we quickly rattled out a few smart sounding buzz phrases which made a lot of sense in our mind:
"The reporting process can be greatly enhanced by tabulating the data using Excel Services instead of in Excel. Data and graphical charts can be published directly to SharePoint as dashboards. Once a dashboard is published, an alert from that library can be automatically sent to the executives who can then immediately see the data on their Intranet."
Sounds like a great plan right? The secretary and the executives were really excited about this amazing plan we came up with right? Right…? Wrong!!
The secretary’s reaction
The secretary was not at all excited about this proposition. She did not have any issues with the current process so far. Things were working just fine in her opinion. The executives were very satisfied with her performance and she was also very happy with her job. Besides… she said she loved taking the walk to the next building every day and chatting with the executives as well.
Now I know what many of you are thinking: Of course she liked the current process. It provided her job security. She didn’t want to change the process because that would mean learning something new and unfamiliar risking her current role in the process.
Well... wait till you hear what the executives had to say.
The executive’s reaction
There’s nothing wrong with the current process!
It turns out, the executives didn’t feel this particular process was inefficient. Yes, they admitted that having dashboards and automated reports in their SharePoint portal would be great and they definitely wanted to see that, but not for this particular process. They were actually quite happy with this existing process because it was providing them with all the data they needed for the day.
A big bonus of this process was that when they had the daily chat with this secretary, they got a good understanding of how things were going in that other building where she sat. The other building is also where the engineers and product managers sat as well and getting a pulse of that part of that organization first hand everyday was just priceless for the executives. How can you argue with that?
Saved by the bell
That was pretty close. We almost proceeded to build a solution that apparently no one would have used. The “If you build it, they will come” mantra would have fallen on its face completely in this case. Talking to a few stakeholders helped us realize that what we thought was a pain point had its advantages in its own non-technical ways. We almost “fixed” an unbroken process.
Let’s not fix unbroken processes
I learned a pretty important lesson through this process. Hopefully, this helps a few folks reading this as well. There are Lots of true pain points that can be remedied in one way or another – with technology or without. The hardest part, however, is not the fix, but identifying the actual need. So let’s put our efforts into creating solutions that would actually get used and adopted instead of wasting energies fixing unbroken processes.