December 17th, 2014 by Adam Sandman
In part one we looked at the process and culture changes necessary to adopt a new tool. In part two we looked at cultivating the tool after launch. This week we look at another aspect of choosing a tool.
Three: Focus on Basic Needs
In my younger years I owned a Camero Z-28. It was a bright blue and turned heads. With removable panels in the roof and an engine with a threatening growl it made a statement - which was all well and good until it snowed. With even the smallest amount of snow or ice on the roads it was useless. The combination of rear-wheel drive and powerful engine made it difficult to control in slippery conditions.
My problem was that I when I bought it I was dazzled by all the ‘whiz-bang stuff’, as my friend calls it, and I failed to focus on basic needs. In this case it was the need to drive in the winter. How does all this relate to success with software tools? The answer is that tools often fail because they were either, a) chosen because of ‘whiz-bang’ features or, b) during roll-out the ‘whiz-bang’ features took all the time and effort leaving very little for ensuring basic necessities.
Avoid Obscure Needs
During my time helping to sell a software product which will remain nameless, I occasionally found myself in sales meetings faced with a series of questions about very obscure capabilities; usually from a single individual trying to impress or promote their favorite tool. I soon learned that I could put the question into context by asking, “Why would you want to do that?” The interrogator, usually having no good answer, would soon stop what was little more than heckling. These types of question are particularly unhelpful to the team as a whole as they distract from the need to understand basic tool features that are essential to project success.
Understand the Basics
It is so easy to rush off down a rabbit hole of improbability just because a scenario can be imagined or because another tool offers unusual features which turn out to be costly and at the expense of basic necessities. If you live in a climate with tough winters, you should ask how well a car drives in snow. But if you live in Hawaii, asking about handling in wintery conditions is just wasting everyone’s time! Understand your basic needs and look for a tool that does those things well. And beware the tool that tries to do too much; it probably does very few things well.
The same priority should apply when it comes to rolling out a product for your project. Time is easily wasted trying to make a tool do things you either don’t need or that it simple was never designed to do. Put the need first, not the tool. Concentrate on ‘bells and whistles’ and you may end up with a product that makes a lot of noise and little else.
You may also be interested in:
Software Tools Are Like Football (Soccer)
When is Configurability a Bad Idea?
Saying 'No' to Innovation