For example, just because a team built a bridge across the river doesn't mean they have reason to be proud. Maybe said team over-spent, under-delivered, or ironically delivered something that meets the technical definition of a bridge, but is a violation of all things human due to quality concerns. What if the customer asked for something to enable them to cross a river the equivalent of five car lengths wide and one foot deep and the solutioning team gave them a state of the art suspension bridge? Should the solutioning team be rewarded for their prowess or chastised for their hubristic idiocy? What if all the customer really needed was a fallen tree with just enough girth to keep them dry whilst crossing?
More difficult yet is the customer who fails to articulate the business problem they would like to solve, but communicates what solution they want the team to provide. Absent clarity of the business problem, coupled with a team's sometimes inhuman ability to over-engineer a solution, we end up with a catastrophic miss while trying to deliver a solution to a yet to be discovered problem. For example, when a customer approaches a solution provider and says, "I need a data warehouse". Here we experience a prescription without description rendering mis-diagnosis. Months later we have a data warehouse solution built upon a high per-seat license cost Cadillac database technology additionally using a third party high per-seat license cost rendering tool only usable by people with explicit training provided by another vendor. Later, it is discovered that the customer simply needed a financial run-rate report that could have been created with straight SQL and cron'd on the back-end for daily distribution to a mail list. This solution could have been provided in approximately one hour.
And do not forget the classic complication of a team with a solution looking for a problem. Creating a process framework or solution in a vacuum that will address 'any' problem in the future is called premature abstraction. Why create a solution to a problem we don't yet have? Some will answer, "Because I can". Others may answer, "Because its the Boy Scout way to always be prepared". Both are the wrong answer. Most Boy Scouts I know don't have their own budget, financial targets and growth goals -- they just have Mom and Dad's checkbook and zeal to make their son the "best Boy Scout ever". Prudence suggests planning ahead, not solutioning the future before its time. And regardless perception, elegant solutions are garbage if no one asked for them.
- When a young child comes in from an afternoon of playing outdoors with friends and declares his hunger, why cook a five or seven-course meal when carrots and juice may have solved the problem?
- When a co-worker walks in and suggests the need for a streamlined method of fulfilling work requests, why have a series of one hour fifteen person meetings discussing tool purchases and automation when co-location of two key individuals may have solved the problem? What if the work request was discovered to not even be necessary?
- When a customer calls and suggests they want a particular solution and it has to be done by a specified date, why do we feel compelled to impress them by over-engineering a solution for them as soon as possible? Maybe, just maybe, the customer has failed to understand the true problem and their solution request is wrong. And even if they do understand their problem well enough, why not pursue simplicity on purpose?
Solutioning costs money and solutioning a problem incorrectly costs more. Over-engineering a solution costs even more money. And solutioning a problem before it exists is just plain waste.
What if we practiced two things all of the time?
- First, find out what business problem needs to be solved; and
- Second, find the simplest possible solution to the problem and make it simpler.
Complexity breeds problems. Simplicity breeds satisfaction. So think about this:
If you're not just a little bit embarrassed about how simple your solution to the articulated business problem is, then it likely isn't simple enough.