It may seem obvious that having the “best” solution doesn’t guarantee a better outcome, but it seems in IT we don’t always see it that way. It seems that we often forget that there are larger issues at play than whether or not a piece of our infrastructure or one of our applications is “the best,” so here’s how I like to think about how to determine what is often a subjective and variable concept in IT.
The thought to write about what “best” means in technology came to me after reading Joe Weinman’s book “Cloudonomics”. In the book he points out several times that having the best technology doesn’t guarantee that you’ll end up with the best solution or service. So how do you determine what’s best?
Some definitions of “best” in IT include:
- Most comprehensive solution
- Lowest priced solution
- Easiest solution to install and get up and running
- Best performing in high latency situations
- Doesn’t require capital
- Doesn’t lock me in
- Highest price
I’m guessing that after having read the seven bullets above, you’re already starting to get a sense of how we sometimes make assumptions about the appropriateness of an IT solution based on incomplete considerations. It seems self-evident what best should mean, but it’s often true that we don’t recognize how priorities can contradict or shift our definitions.
Buying the best
When you buy the best solution in any product category you assume that you are in fact getting the most appropriate solution for the money. That value might be any combination of things from a name (such as Hermes,) to performance or sex appeal (like Ferrari,) or maybe time per transaction (I won’t wait in line at Whole Foods markets).
The reality is that best could mean all of those things or none of them. While it’s almost certain that a bag you buy from Hermes is going to be well made, is it 30 times better than another brand? Is a $1,000 bottle of wine 20 times better than a $50 bottle? If money is no object to you, then the answer is more likely to be yes, a $1,000 bottle is better. On the other hand, if you value the ability to have different bags for different events, or simply prefer the ability to buy a new bag more often, then the $150 bag is probably “best” compared to the Hermes bag.
Buying IT is no different, except that it’s immensely more complex. In IT there are myriad variables that affect the ability to get the most from any solution. These variables include price, features, latency, maintenance, flexibility, open vs. proprietary, required training, user interface, APIs, and more. What about your team’s ability to sell the solution as the right choice to your customers? How about whether or not you’ve got the correct organizational and financial structure to support the solution appropriately?
How to determine what’s best
The decision process for every new technology or solution selection needs to cover a wide list of criteria. These criteria will mostly all be the same for each business but the priorities will change depending on your organization.
The majority of the standard selection assumptions (need, ROI, cost, etc) are well understood, but even among those “standards” there is room for better decision making and prioritization. I like to include the following non-standard criteria when my team is making a solution selection.
- How much value do we get out of the solution at 80 percent of total feature set?
- What other capabilities does this solution open the door to in the future?
- How many of my customers need to use the solution and to what extent before it adds new value?
- What organizational support (business and IT) do I have for the long term “ownership” needs (staff, training, champions, budget, lifecycle, etc.)?
- How does this solution position my team to execute against larger IT and business visions?
- Does this solution leverage other partners and technologies already in use?
- What’s the time to install vs. cost to purchase or time to benefit? (In other words, will I get 30 percent net new benefit value in year one vs. nothing in year one and two, but 80 percent in year three from another solution?)
- Ownership risk assumptions (what assumptions are you making at the front end of any solution selection and are those assumptions still accurate? With modern cloud/SaaS etc., you might not have the ownership risk you “enjoyed” with many legacy platforms)
While I could easily argue that all of the above bullet points are important to every organization, they must each be measured against the organization’s situation at the time. Are you low on cash, but growing fast, do you have a higher risk profile or regulatory concern? The process of prioritization can only be done by the business making the purchase.
Seems like an oxymoron
Sometimes the best purchase is the purchase you avoid, other times the best purchase is the one you didn’t make. IT is littered with examples of purchases that would have been better left undone. However, just as common are those purchases that were never made because they weren’t “perfect”. When you’re looking for perfect, keep in mind that there’s no such thing in software and many cases in hardware, but if you can solve a problem even at 70 or 80 percent, the purchase might still be better than waiting for the “perfect” option.
The test and fail option is much more real today than it ever has been and it’s a good thing. Now you can test, fail, and retry three or four times all for less effort and cost than making one selection in the past. So, step forward boldly, but don’t forget that when you are thinking “best” make sure you’ve really developed a case for what best means to your organization.