Software is not a solution

I hate using the word “solution” when it comes to software: it implies that it solves problems. Software never solves problems, quite the opposite in a lot of cases. At best it can only augment stuff you already do in other ways; at worst it can make tasks more difficult. Here’s a real world example. On a recent PSL discussion thread, Jason Meinzer from CityRyde asked for suggestions for task management systems. Simple enough question, and a pretty common need. However in the additional comments we find out that they have already reviewed and considered several services…

Google tasks don’t work because you can’t share them, and solutions like WizeHive, RememberTheMilk, Manymoon, BaseCamp, etc. don’t seem to work because nobody wants to rely and commit to them because they each have their frustrations and inevitably don’t jive w/ somebody’s task management method. It would be great if there was a tool that enabled everybody to keep doing what they are doing and simply sync their “tasks” comprising of a description, due date and owner to one central portal for all to view.
They’ve pretty much argued themselves into a corner. It seems that every existing market offering presents an issue to someone on the team. “We need task management, but task management won’t work.” Sound familiar? I see this happen time and time again when businesses seek out technology to handle real world issues. The intent is perfectly fine and logical; they’re on the right track in fact. However the stumbling block isn’t compatibility with the available options, but rather the staff’s reluctance to do something new. CityRyde doesn’t have a technology problem, they’ve got a people problem. If you find yourself in a similar situation, here’s some food for thought. No piece of software will ever please the entirety of any team. As the saying goes, you can’t please everybody all the time. It’s important to consider the perspective of each team member, but never at the expense of the business’s perspective. In CityRyde’s case, Meinzer and the rest of his team should consider their company’s unique task flow in addition to employee preferences. Ask questions like… * How does work present itself? * How do tasks get taken care of? * Is there anything you want to change about the flow as it stands right now?

From a technical perspective, I think that most any of the services that Meinzer referenced would meet their needs, they simply need to pick one and run with it. Answering those types of questions should hopefully reveal a product that best fits their style. People will always complain, but we naturally crave structure. If you make a decision, set it in stone, and execute that decision ruthlessly, people will go along with you. You see this all the time in other businesses: “I’m sorry, but those are the rules, and my boss will kill me.” When it’s decision time, you must be that killer boss (so to speak). Don’t forget that you can always shake things up if whatever you pick doesn’t work out, get 6 months down the road and re-evaluate. But don’t be surprised when the same people complaining about your choice now are complaining when things change again! I said as much in a response, and I think Meinzer’s follow-up confirms this analysis…

In actuality, over the past 2 years we’ve “6-month” tested about 3 different… don’t hate me… “solutions” with varying degrees of success in terms of efficiency which we have tracked and which is what brought me to this quest. We are all about efficiency, and while we recognize there isn’t going to be a perfect tool out there we are just hoping to get some thoughts on one’s that have worked well for others that fits into our culture and methodologies that could prove a bit better than the one’s we’ve worked with in the past. I’m sure we aren’t the only one in this boat…
3 completely different packages and no dice? There’s (almost!) no way that all three were unworkable for their situation. They either lack the gumption to set a course, or one or more employees are being especially verbal on the matter. Either way, they have enough information to make an informed decision. All that’s left is to determine the best possible option and go for it! I can’t fault CityRyde for the situation, it happens all the time. I wouldn’t be writing about it if I didn’t see this sort of thing over and over again! So when find yourself in the same boat, remember that when software-related problems arise, the software often plays the scapegoat, but is rarely the true source of the trouble. Update: The author gave me permission to use his company and name, so I’ve updated the post. Jason and CityRyde both welcome any comments you may have, so feel free to email him directly.