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

Always, ALWAYS budget for more training

December 18, 2019

Always, ALWAYS budget for more training Always, ALWAYS budget for more training. I don’t know how else …

Always, ALWAYS budget for more training Read More »

We’ve always done it that way

December 11, 2019

We’ve always done it that way A couple of weeks ago I wrote about approving memberships, …

We’ve always done it that way Read More »

Are you sure it doesn’t do that?

December 4, 2019

Are you sure it doesn’t do that? Even after 20 years of consulting, I’m surprised …

Are you sure it doesn’t do that? Read More »

Be grateful

November 27, 2019

Be grateful As Thanksgiving approaches here in the US, I’m reminded of two words: Be …

Be grateful Read More »

Do you really need to approve them?

November 20, 2019

Do you really need to approve them? I often joke that the very best (because …

Do you really need to approve them? Read More »

Negativity bias is why we need database PR

November 13, 2019

Negativity bias is why we need database PR I’ve written before how cognitive biases can affect …

Negativity bias is why we need database PR Read More »

A system change requires a culture change

November 6, 2019

A system change requires a culture change By its very nature, when you introduce a …

A system change requires a culture change Read More »

Where is that data?

October 30, 2019

Where is that data? This is what data management nirvana looks like: When the question starts with …

Where is that data? Read More »

Be deliberate, but act quickly

October 23, 2019

Be deliberate, but act quickly Be deliberate, but act quickly. These are my words of …

Be deliberate, but act quickly Read More »

Why associations don’t like the “S” word

October 16, 2019

Why associations don’t like the “S” word A couple of weeks ago I asked my …

Why associations don’t like the “S” word Read More »

Scroll to Top