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

The “S” stands for “Standard”

October 9, 2019

The “S” stands for “Standard” In a conversation with a past client, we were discussing …

The “S” stands for “Standard” Read More »

Is that meaningless data?

September 25, 2019

Is that meaningless data? I’m not a big quotes guy, but one of the few …

Is that meaningless data? Read More »

Be aware of unintended consequences

September 18, 2019

Be aware of unintended consequences I’ve written before that every decision involves a trade-off. When …

Be aware of unintended consequences Read More »

Positive change is harder to see

September 11, 2019

Positive change is harder to see Humans are wired to see negative change because we …

Positive change is harder to see Read More »

MVP: Minimum Viable Product

September 4, 2019

MVP: Minimum Viable Product In product development there is a concept known as MVP, or …

MVP: Minimum Viable Product Read More »

You always need a reason for collecting data

August 28, 2019

You always need a reason for collecting data When you ask for data from someone …

You always need a reason for collecting data Read More »

If you’re unhappy, speak up!

August 21, 2019

If you’re unhappy, speak up! My clients will often ask me something along the lines …

If you’re unhappy, speak up! Read More »

Does it advance the mission?

August 14, 2019

Does it advance the mission? Because associations are mission-driven, everything you do should be seen …

Does it advance the mission? Read More »

How should you start a new data project?

August 7, 2019

How should you start a new data project? When you’ve got a new data project …

How should you start a new data project? Read More »

A Data Integrity Report…for Reports!

July 29, 2019

I’ve written elsewhere about the value of data integrity reports. But one of the most …

A Data Integrity Report…for Reports! Read More »

Scroll to Top