Problems in life are often fuzzy; thus, finding solutions is also fuzzy. One response is to turn to a peer and say, “Tell me what to do”—a passive approach.
But great consultants understand the problem, turn to their clients and say, “Here are some options and a recommendation”—an active approach.
The Problem with Fuzzy Problems
Let’s say you are working on a web application, and your colleague Karen says, “I need to be able to manipulate time.”
Ok, yes, this is definitely a bizarre, fuzzy request.
What not to do
Less experienced consultants might approach this in a few of different ways.
- Avoid – Decide the request doesn’t make much sense; ignore it and hope it goes away.
- Assume – Start building a feature to change time in the app without knowing why, what, or how.
- Grouse – Complain about how Karen provides poor requirements and direction.
We can all agree the three above approaches are poor, and in the case of the third, particularly bad, as bad attitudes can be toxic to a work environment.
A Strategy for Solving Fuzzy Problems
1. Identify the deeper need
Our first step is understanding. The single most important thing I have learned from the design community is that we must understand the need before creating a solution.
Back to the original ask—”I need to be able to manipulate time.” Let’s assume that Karen is not insane and is not asking for a superpower. Instead, she’s probably referring to changing time within our web application.
But why? Understanding helps uncover the deeper need.
Using an approach like 5 Whys leads to some helpful questions:
Aha! We’ve found a deeper, more concrete need—testing time-sensitive features, not manipulating time, which is a more abstract problem.
2. Identify options
The next step is to think through ways to help with Karen’s testing.
- Allow administrators to click on a clock, be presented with a time picker widget, and save the selected time to the server and all clients.
- Use a Greasemonkey script† to change time in the web app running on the local browser.
- Use a command line script to change system time on the server.
Options alone are not enough. (Given this list, any sane person would pick Option 1—it’s obviously the best!) We also need to identify costs for each option:
- Full-fledged time picker feature – 8-point implementation cost. Gives the most robust testing across the entire system.
- Greasemonkey script – 2-point implementation cost. Only allows testing time on the local client.
- Command line script – 1-point implementation cost. Creates a security hole on the server.
Now we are well-positioned to negotiate with Karen.
3. Provide a recommendation
A good consultant can see and respect both return on investment and risk.
Option 1 is clearly the nicest, but it comes at a significantly higher cost. Additionally, the newer time-based features Karen wants to test may mostly exist in the client and not the server. In other words, the investment will provide relatively low return.
Option 3 is cheap, but it exposes a security risk. This might be acceptable for an internal application, but Karen’s is public-facing so security is a significant concern.
Given the above evaluation, Option 2 is the Goldilocks solution and what we’ll recommend to Karen.
It’s worth noting that, ultimately, this is Karen’s decision to make. She may know that there will be several more time-sensitive features coming in the future, and that the bigger investment is worth it.
Nevertheless, we’ve accomplished our job as a consultant–we’ve actively understood the problem, identified relevant solutions, and made a recommendation through the lens of risk vs. reward.
†Yes, I do realize how I’ve dated myself by referring to this as a Greasemonkey script. :)