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

It’s all about managing expectations

September 28, 2022

It’s all about managing expectations I placed an order online on a Friday and the …

It’s all about managing expectations Read More »

Experience is the best teacher

September 21, 2022

Experience is the best teacher Experience is the best teacher. Every one of us has …

Experience is the best teacher Read More »

Don’t ask for what you don’t need!

September 14, 2022

Don’t ask for what you don’t need! Recently I received a bill from a doctor’s …

Don’t ask for what you don’t need! Read More »

It is never done – so celebrate!

September 7, 2022

It is never done – so celebrate! A client of mine recently had their official …

It is never done – so celebrate! Read More »

MDR (Minimum Data Required)

August 31, 2022

MDR (Minimum Data Required) I’ve written about minimum viable product (MVP) in software development in the …

MDR (Minimum Data Required) Read More »

Simpler and Faster is Better

August 24, 2022

Simple and Faster is Better Earlier this week I was fortunate enough to attend a …

Simpler and Faster is Better Read More »

Patience and grace

August 17, 2022

Patience and grace A past client of mine recently told me: “You inspire confidence and …

Patience and grace Read More »

Sometimes you just have to try it and see what happens

August 10, 2022

Sometimes you just have to try it and see what happens The single greatest key …

Sometimes you just have to try it and see what happens Read More »

Training and testing

August 3, 2022

Training and testing I’ve written before that the best form of training follows this process: …

Training and testing Read More »

How to save a “failing” project

July 27, 2022

How to save a “failing” project It is not unusual for me to receive a …

How to save a “failing” project Read More »

Scroll to Top