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

Try flowcharting your processes

October 21, 2020

Try flowcharting your processes Working with a client recently on their membership join process reminded me …

Try flowcharting your processes Read More »

“I just want a system I don’t have to fight with.”

October 14, 2020

“I just want a system I don’t have to fight with.” I asked my client: …

“I just want a system I don’t have to fight with.” Read More »

Inertia Contributes to Bad Data

October 7, 2020

Inertia Contributes to Bad Data Without knowing anything about your organization or its data, I’d …

Inertia Contributes to Bad Data Read More »

What are you doing with new contacts?

September 30, 2020

What Are You Doing with New Contacts/ I was very interested to read in a …

What are you doing with new contacts? Read More »

Be Aware of Selection Bias

September 23, 2020

Be Aware of Selection Bias I wrote recently about the mistaken perception of older members …

Be Aware of Selection Bias Read More »

Some Things Just Take Time

September 16, 2020

Some Things Just Take Time I learned recently that an elephant’s gestation period is 18 …

Some Things Just Take Time Read More »

Sometimes It’s the Least Bad Choice

September 7, 2020

Sometimes It’s the Least Bad Choice Just like in life, sometimes when we’re making technology …

Sometimes It’s the Least Bad Choice Read More »

Our Members Aren’t Tech Savvy

September 2, 2020

Our Members Aren’t Tech Savvy Having worked now in the association space for more than …

Our Members Aren’t Tech Savvy Read More »

Motion vs. Action

August 26, 2020

Motion vs. Action One key to successful data management is understanding the difference between motion …

Motion vs. Action Read More »

There is ALWAYS a Trade-off

August 19, 2020

There is ALWAYS a Trade-off I’ve written many times about trade-offs (you can read a …

There is ALWAYS a Trade-off Read More »

Scroll to Top