DISCLAIMER – this article applies to mainly to Organizations without business analysts and programmers on staff.
A few years ago, we were asked to quote a small automation for an existing, repeat client. They wanted help streamlining a spreadsheet-based process that took about 1/2 day of a high-level employee’s time each week.
Client: Can you help us save some time by writing some Excel macros?
Susco: Of course we can develop some Excel macros for you. But first, why do you need them?
Client: We receive a spreadsheet every week from one of our major suppliers, summarizing the status of all the material we have on order with them. I have to use the information to decide which lots are ready to place on a shipping request.
Susco: OK, what does that involve?
Client: I have to review the line items and quantities that are ready to ship, compare the cost against our current available funds and our material commitments to customers, and generate a shipping request. If you could make some macros to automate some of those Excel calculations, it would save me a lot of time.
Susco: Does this have to be done in a spreadsheet? Would a local database or web application be better?
Client: I don’t know. I’ve just always done it in Excel because the supplier sends it that way. I print it and then transfer the information to our own format because we have information that the supplier report doesn’t include.
This is a good illustration of why it pays to keep asking why. Clients know their own industry, their own processes, their own requirements. They are subject matter experts within that purview.
When it comes to a technological solution, though, clients know only what they happen to have encountered before. When users dream of ways to be more efficient and imagine solutions to tedious, time-consuming tasks, they dream of using familiar tools in better ways. Once those dreams are distilled into requests, all other possible tools are discarded and forgotten.
In other words, the client tries to be the solution architect. That’s not his job; that’s ours.
It’s rare for a client to present the root problem. A consultant’s job is to listen between the lines and keep asking why, to discover the real purpose behind a seemingly straightforward feature request.
In this case, one “tell” was all it took to point us to a more integrated solution: we have information that the supplier report doesn’t include. (OK, I’ll confess I was already leery of doing a stand-alone Excel process, but every once in a while this can be a decent solution.)
Susco: Wait, do you mean you’re using data from your reporting application to process the spreadsheet?
Client: Well, yes, because the supplier doesn’t include it.
Susco: OK, then, here are a couple of choices for you.
Option 1: We can write some Excel macros for you to save an hour or two per week, but you’ll still have to do a lot of manual processing and won’t be able to track or report on the weekly activity.
Option 2: We can integrate this into your custom reporting application to save 3-1/2 hours per week. The data you need is already there; you’ll be able to store and track and report on the supplier status updates along with all the rest of your purchasing and inventory data; and it will mesh with your other purchasing-related work flow.
Obviously, Option 2 was the better solution and the one that we implemented. It provided enriched data tracking and reporting as well as a time savings of 88% for a high-level employee.
It pays to keep asking why. That’s our job as consultants, and that’s how we can provide so much more value than merely saying yes.
TL;DR
Often, clients will ask for a particular feature that may or may not give them the results they desire. Understanding the desired result and underlying business purpose can help prevent disappointment and frustration.
Questions? Contact us here.