Be careful about “solutioning” too quickly

Be careful about "solutioning" too quickly

One of the great things about software developers is that they tend to be "solutions-oriented." By that, I mean that if you give them a particular data management challenge, they want to figure out some way the software can address that challenge. This is a good thing!

But too often, we jump to solving a problem ("solutioning") before we really understand the scope and breadth of the problem itself. An example:

One challenge a client has is address changes made by members via the member portal. When these address changes are made, sometimes they can affect which chapter the member belongs to. And so the client wants a solution that allows for the staff to check address changes before they are "posted" to the member's account. An interim step to allow for quality control.

On the surface, this seems like a challenge worth addressing, and anything that could automate the process would certainly be helpful. Upon further digging, though, we discovered that, for most of the year, there are only about 10-12 of these changes per month. So rather than trying to build something to automatically deal with this, the correct approach is to check these manually as address changes are made. No automation required.

My recommendations before solutioning an issue:

  1. Understand the depth of the problem. How often does "this thing" happen? How many transactions occur in a given time period?
  2. Understand the breadth of the problem. For example, what's the financial or reputational impact if we don't automate this? If it's done manually and takes a little more time than automation would, who will notice, and is that a big problem, or a little problem?
  3. What if we did nothing at all? Or put another way, do we really need to do what we think we need to do? If we did nothing, would anyone notice?

Solving problems is great. But sometimes the solution is more than the problem demands. Be careful about falling into the trap of "solutioning" without understanding the breadth and depth of the problem.

Wes's Wednesday Wisdom Archives

The challenge the AMS providers see

April 7, 2021

The challenge the AMS providers see Over the years I’ve asked AMS providers what they …

The challenge the AMS providers see Read More »

What’s our next action?

March 24, 2021

What’s our next action? As you can imagine, I spend a lot of time in …

What’s our next action? Read More »

Don’t automate for the sake of automation

March 17, 2021

Don’t automate for the sake of automation I’m the laziest person in the world. I …

Don’t automate for the sake of automation Read More »

Don’t forget about what got better

March 10, 2021

Don’t forget about what got better Negativity bias is the tendency to focus on only …

Don’t forget about what got better Read More »

Give a little at a time rather than taking away

March 3, 2021

Give a little at a time rather than taking away I’m sure there’s research somewhere …

Give a little at a time rather than taking away Read More »

First, you gotta have the data

February 17, 2021

First, you gotta have the data When I work with clients on a new AMS …

First, you gotta have the data Read More »

Work on your relationship with your AMS vendor

February 10, 2021

Work on your relationship with your AMS vendor It is no coincidence that my most …

Work on your relationship with your AMS vendor Read More »

Dashboards for Data Integrity

February 3, 2021

Dashboards for Data Integrity I’ve written a bunch on data integrity reports. (Click here for …

Dashboards for Data Integrity Read More »

Next-to-Nothing Goals

January 27, 2021

Next-to-Nothing Goals I saw a Ted Talk by Christine Carter recently discussing the concept of …

Next-to-Nothing Goals Read More »

Just because you can…

January 20, 2021

Just because you can… In response to a recent Wednesday Wisdom on averages hiding the …

Just because you can… Read More »

Scroll to Top