I frequently hear discussions along the lines of 'xuz is a terrible tool'. My knee jerk is to want to ask more - why do you think it's a terrible tool?  What did it do or not do, to cause that reaction.

These are good question - but there are better ones to ask if you want to understand why someone thinks that.  Questions like 'ehen it was setup did your team fully understand how to use XY tool? ', 'did the group who installed it take time to understand your needs?', 'did the folks using it get training on how to use it, and how to use it for your needs?'

Frequently I don't get answers to those questions because folks don't know. They inherited a system or joined the company after it was implemented. This is fine, however, I've noticed it can doom a system, and a team, to repeat mistakes and get stuck in blaming their tools.

Tools can be the source of trouble. They may lack a specific feature, or have bugs, or be hard to use. These are all legitimate complaints and issues that need to be addressed, or, at the very least, understood by the groups using it. After all, if I'm aware my tool has a known deficiency I can at least plan around it. 

Many times, however, I find folks blame their tools without examining other things that contribute to their perception.  Things like training, process mapping and understanding intended use.

Training

The eample I always think of here is an equity team I worked with wanting to stop using Jira and go back to zendesk. I asked them to brainstorm all their issues, and then share them with me. After that we met for half an hour, and I resolved all but one of their complaints, and solved the final one the next day. 

Their complaints ranged from Jira not showing tickets a specific way to it missing features. The root cause wasn't that Jira was deficient, instead it was that the equity team didn't understand how to use the tool. They didnt know they could build a dashboard to show them information, or that they could easily reassing tickets. 

Ensuring users, especially the ones responsible for using the system on a daily basis, know how to use the system is paramount to adoption - after all it's their job you're changing.

Process mapping

I'm frequently telling teams I work with that we shouldn't even consider using a system until we can map our our processes on a whiteboard. Being able to do this means we actually understand what the process is - who is responsible for what, where to go for help, etc. if we don't understand what it should be, there's no way a system can support it. 

Process mapping is simple - just start drawing.  Keep adding steps until either you don't know what's next or everyone agrees it's complete.  Clearly indicate any gaps, and then go find someone to help fill them in (this can be a bit of a journey depending on how big the gap is!).  

Don't start using a new system until you understand the process genetically - if you don't know it the system can't. 

Intended use

Similar to understanding a process, understanding what a tool can, or should, be used for is a common challenge.