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

Two tips for data conversion

September 15, 2021

Two Tips for Data Conversion I’ve written a lot about data conversion over the years …

Two tips for data conversion Read More »

Who should “own” the database?

September 8, 2021

Who should “own” the database? One of the most common questions I get from my …

Who should “own” the database? Read More »

What makes you weird?

September 1, 2021

What makes you weird? When I work with clients on selecting a new association management system, one …

What makes you weird? Read More »

Why “AMS Consortiums” Don’t Work

August 25, 2021

Why “AMS Consortiums” Don’t Work About once a year I will get a call from …

Why “AMS Consortiums” Don’t Work Read More »

Your vendor will disappoint you

August 18, 2021

Your vendor will disappoint you I follow politics as a hobby. A past publisher from …

Your vendor will disappoint you Read More »

Learn how to lose

August 11, 2021

Learn how to lose “Winning is great, sure, but if you are really going to …

Learn how to lose Read More »

Ownership is Required

July 28, 2021

Ownership is required When asked for the most common reason AMS implementations fail, I typically respond …

Ownership is Required Read More »

It’s all relative…

July 21, 2021

It’s all relative… Over the course of my 22 years of consulting, I’ve consulted with …

It’s all relative… Read More »

Eliminate to optimize

July 14, 2021

Eliminate to optimize So much of data management is habit (both good and bad) which is …

Eliminate to optimize Read More »

For data governance, ask “Why?”

July 7, 2021

For data governance, ask “Why?” Recently I’ve had the opportunity to work on several data …

For data governance, ask “Why?” Read More »

Scroll to Top