The Annoyance List

We all have things that annoy us about our job. Perhaps it's the smell of a co-workers lunch, or the sound of the copy machine, or perhaps a software program that takes too long to load or has too many clicks to get to the screen you really need. If someone could fix one of those annoyances what would that be worth to you?

I recently had a phone call with a friend of a friend (let's call him Steve), who was experiencing some difficulties with an ERP implementation. During the conversation we both admitted that a successful ERP implementation isn't when the technology meets all the requirements, it's when the END USERS adopt the software and are (mostly) happy with it.


The reason for this is quite simple. Even if the ERP is delivered on time, on budget, and does everything that it was mapped out to do, if the end users hate it, the project is a failure. They won't use it, will find work-arounds, and can possibly even make a project that was opening champagne bottles a month before come to a screeching halt.

When discussing with Steve how to keep the end users happy I provided a personal best practice, which I realize doesn't seem to exist in any "best practices" literature I've read. If you've heard this before please let me know, so that I don't think too much of myself.

I advised Steve to form an Annoyance List. What's an Annoyance List? It isn't a list of people and things that annoy you; but it can be one of the most effective End User Engagement tools, and can help make your ERP implementation a success.

An Annoyance List is from your end users (hopefully super users of the existing system). Ask them to create a list of all the things (large and small) that annoys them in the current system. Some questions to ask in order to help them create the list:

1. What are three things that you would change about the current system?
1. Can you please rank these (1-3) as to which are the most annoying?
2. Which activities seem to take you the longest?
3. Which activities do you need to work in multiple systems to perform?
4. Do you need to find data for your work in shared hard drives, or in some form of written format?
5. If there was one thing you would keep from the existing system, what would it be?

Now you have your Annoyance List. If you can get a similar list from each department affected by the implementation, then you have somewhere to start. But start what? Let's explore how you can use this list:

• You should review this list with your implementation partners and determine which items can be addressed during the different phases.
• Will any of them be resolved by the actual implementation?
• Are there any you should identify as a priority?
• Are there others that won't be addressed?
• This becomes a powerful tool to manage your end user expectations!
• You can communicate items that will make the end user enthusiastic because you are solving their issues (hopefully the higher priority ones)
• If it is built into the original software, then you may be able to do a demonstration to the end users in order to show how the system solves their problems!
• Also, as you advance through design and implementation, it may be worth providing demonstrations of new features that address the Annoyance List.
• In the cases where the the implementation will not address the annoyances, then you can provide early communication to manage the expectations of the end user so that they aren't surprised or angry to find the same annoyance.

After the Implementation and initial Go-Live support phase, it would be a good idea to ask for an update to the Annoyance List. Now you have a list of items to discuss with your implementation partner for future phases. If you manage the communication properly, the end users will be happy that you are listening to them and that they're input is valuable. Project success (from the end user perspective) could be yours!