Stop being lazy when you’re introducing new tools

When introducing new tools, make sure you take something else away

What the hell are all these parts for, anyway?

Slack has made the headlines in the last year, being purported as a potential email killer and the ultimate collaboration tool. However, opinions are mixed and some people have chosen to break up with Slack after a tumultuous relationship.

I can imagine this is happening in MANY organisations around the world as they are introducing new tools, particularly as the proliferation of “free” tools continues.

I’ve worked in a number of organisations that have tried introducing new tools to try to fix old problems, without much success.

What not to do when introducing new tools to your organisation

It goes like this:

  1. Somebody in your company has used a tool somewhere else before
  2. They love this tool and they bring it along to your organisation
  3. They use it and champion it (along with some other evangelists) for a little while
  4. Nobody is really told *how* they should be using it, or what it should replace
  5. The organisation assumes “this is what we use now, great”
  6. You end up with a combination of tools which are used differently by different user groups
  7. Information is stored in multiple different places, confusing the hell out of people.

The problem with this is, nothing has been taken away.

We’ve added a new tool but it is sitting alongside the others, complicating things.

Unfortunately, I’ve found this often happens with free platforms. A free tool will be seen to have no adverse impact (“why don’t we just try it out?”), because it doesn’t cost anything. What you are actually doing is modifying communication channels and causing issues with productivity.

Not all organisations and environments are equal

If you add new tools but fail to remove anything, what results is a big mess. I worked in one organisation where someone had the bright idea to introduce a Wiki which they’d used elsewhere.

The product was pretty good and I’m sure it serves its purpose in some places.

The issue was that this free tool was used in a very small organisation. An assumption was made that when you brought it into this substantially larger organisation, it would work just as well.

Wrong. In particular, the issue that arose was that this tool was a Wiki. In the previous small organisation, you can have discussions about how to manage the content (i.e. Bob yells to his coworker Anne, “don’t edit that page!”).

Translate that to a large organisation who doesn’t know what the tool should be used for, and we have chaos. People editing stuff everywhere. Operational procedures in various states of draft, with multiple copies (which one is correct?).

Introducing new tools can complicate the landscape

Now we had:

  • A shared drive
  • A Wiki
  • A Document Management System
  • A Content Management System (SharePoint)
  • Email

This list isn’t all that overwhelming. After all, it’s only five tools. But when you’re adding a Wiki, you are presumably storing and building content there. So where were you storing it previously? What is the process change involved?

So how should we be introducing new tools?

When you introduce a new tool, it solves part of a problem. It contributes to the completion of a process that generally already exists.

We used to use a road map, but now we use Google maps. We still look up the address and plot a course (the process still exists), but the way we do that is significantly different.

Communication tools are no different – we always used to communicate, but now we do it differently. The organisation needs to say what that difference should be.

So let’s try again:

  1. Do an analysis of the tool and how it would fit into your organisation. Why do we need it? What will we use it for?
  2. Communicate to the organisation that it is coming. There are probably some videos about it online. Send them out to the team so they can see what it is.
  3. Tell the organisation why you are considering the tool. The benefits. Start with why.
  4. Do a Proof of Concept (POC). Try it out on a small project or in a small team, whatever is sensible.
  5. Tell the organisation that the POC is happening. Give them updates about how it’s going. Remember, a POC is to prove the concept…not to say “Yes”. If the answer should be “No”, then the POC has been successful.
  6. Assuming we’re going ahead, develop some training for the organisation. Make it a combination of “roadshows” where you demonstrate the tool, and actual training on how to use it.
  7. During training, explain what the tool does and how you’re going to use it. Use language like “we used to do it THIS way, but now we’re going to use this tool to do it THAT way”.
  8. Communicate any restrictions. “You should no longer be using the blue filing cabinet for storing your TPS reports. These will now go in the new tool.”
  9. Take away the blue filing cabinet, so people don’t accidentally use it (you can just hide it for now, in case you need it later).
  10. Assess your progress in using the tool. Has it been successful? Use metrics to track the success. Employee satisfaction is one metric and “hard” productivity or financial metrics are great too.

This sounds like a lot of effort doesn’t it? It can be.

“But I don’t want to spend all this money on a free tool!”

You damn well better spend money on the “free” tool! Otherwise you can be sure it will be consigned to the scrap heap and labelled as a “crappy product”, which may not be a fair outcome. In the future, you’ll find your efforts to make change even harder as people remember this failed attempt.

Leave your optimism at the door. “If we put it there maybe people will just use it?”

They might use it, but a lot of people won’t, and others will use it poorly.

Just do it properly.

By |2018-07-21T14:08:39+00:00March 15th, 2016|Tools|

Leave A Comment