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

Action isn’t the same as progress

January 25, 2023

Action isn’t the same as progress I’ve written before that not taking action is an …

Action isn’t the same as progress Read More »

Start with the end in mind

January 18, 2023

Start with the end in mind Like so many, I probably first heard the phrase …

Start with the end in mind Read More »

It’s quiet in here…maybe TOO quiet…

January 11, 2023

It’s quiet in here…maybe TOO quiet… One of the truisms of data management is that …

It’s quiet in here…maybe TOO quiet… Read More »

It’s ALWAYS about expectations

January 4, 2023

It’s ALWAYS about expectations The headline reads: “Tesla sets record for vehicle deliveries, an increase …

It’s ALWAYS about expectations Read More »

It’s hard to get UNangry

December 14, 2022

It’s hard to get UNangry I often emphasize to my clients the importance of testing …

It’s hard to get UNangry Read More »

Some history IS important!

December 7, 2022

Some history IS important! When I’m advising clients on data conversion (moving data from one …

Some history IS important! Read More »

“Many mickles make a muckle.”

November 30, 2022

“Many mickles make a muckle.” “Many mickles make a muckle.” – George Washington Apparently, this …

“Many mickles make a muckle.” Read More »

It’s easy to collect; it’s harder to manage

November 16, 2022

It’s easy to collect; it’s harder to manage The beauty of today’s highly configurable AMS …

It’s easy to collect; it’s harder to manage Read More »

Tell them why you want the data

November 9, 2022

Tell them why you want the data Because data is so easy to collect these …

Tell them why you want the data Read More »

Don’t get hung up on something minor

November 2, 2022

Don’t get hung up on something minor I’m a problem solver. I love to solve …

Don’t get hung up on something minor Read More »

Scroll to Top