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

A change of systems requires a change of mindset

July 8, 2019

Every AMS vendor will tell you that the toughest part of implementing a new system …

A change of systems requires a change of mindset Read More »

It doesn’t have to be optimal to be beneficial

June 26, 2019

It doesn’t have to be optimal to be beneficial I’m a big fan of the …

It doesn’t have to be optimal to be beneficial Read More »

Look for small wins

June 19, 2019

Look for small wins One of the toughest things about system implementation is simply how …

Look for small wins Read More »

Are you closing the loop?

June 12, 2019

Are you closing the loop? If your association does a call for presentations for any …

Are you closing the loop? Read More »

Declare victory and move on

June 5, 2019

Declare victory and move on The law of diminishing returns is the point at which the …

Declare victory and move on Read More »

Clean as you go

March 28, 2019

Clean As You Go A good cook or baker knows that, when working in the …

Clean as you go Read More »

Baby Steps

March 21, 2019

One of the keys to developing good data management habits is to be aware of …

Baby Steps Read More »

Success Requires Discipline

March 14, 2019

When it comes to data management, most of us know what to do; we just don’t …

Success Requires Discipline Read More »

Take a moment to be grateful

March 7, 2019

Because we’re so focused on always improving what we have now, it’s easy to overlook …

Take a moment to be grateful Read More »

KPIs and Dashboards

February 28, 2019

I saw DJ Muller from MemberClicks speak on KPIs (key performance indicators). In his session …

KPIs and Dashboards Read More »

Scroll to Top