Here’s a few bullet points (in no particular order) to help encourage user buy-in to a project:
- Continual communication: probably the simplest and quickest but unfortunately the most under-utilised. It doesn’t need to be much, e.g. a regular email to the end-users and/or through their managers, updates on your intranet, brief presentation at team meetings etc, they all help. And you can get feedback from the users too. In addition, many of the points below by their very inference are continual communication, but having a structured approach can really help.
- Involvement at design stage: Do involve key users at the time you are designing the database, whether it is the customisation of a package or the detailed design of a bespoke system. This may sound obvious (even necessary! I hope so) but it works. And do plan ahead for any such involvement; I find users really enjoy and want to get involved but not if you ask them to do 2 four hour workshops next week when they are just about to launch a new campaign!
- Demos of the software & opportunities for hands-on experiences during the implementation: Show the software to the users – it’s a great way to get them excited about the new database and even if you do an initial demo at an early stage, then you can ask for their feedback and comments and make them feel even more involved.
- Assurance of training: It’s always one of the top 3 questions from users – What sort of training will we have? So give them details as soon as you know, and even before that, pre-empt the questions by assuring users that training will be provided.
- Ask for ideas – during implementation and after go-live: Continue to ask the users what they would really like, although you’ll need to this in a ‘controlled environment’. If you let them ask for anything and expect everything then that can be worse than not asking at all, so do communicate that ideas will be considered but may not all be implemented.
- Keeping promises, so don’t over-promise! Hand-in-hand with the above, and in general, keep your promises but don’t over-promise. A slightly trite phrase is ‘Under promise and over deliver’ and even if I don’t like that specific thought process, the underlying concept is reasonable.
- Remember, What are the benefits to them? When you’re selling a new database to the users, what are the benefits that they are going to get themselves? It should of course be the case that the organisation will benefit from a new database, and although that should ultimately mean the users will too, it can also mean that processes may change, more data entry may be needed etc. So, identify specific benefits which the users will get and communicate those. That will help them understand the need for any changes which they don’t like so much.
- Pro-actively address the common objection of “I don’t know what I want from the database because I don’t know what a database can do” – because it’s (usually) a fair point. Don’t just ask, ‘What do you want the database to do?’ because many users quite simply will not know the capabilities of a database. If they have not had experience of a really good system then they may not be aware of all the benefits they can get from one. Instead, ask ‘What do you do in your job?’, ‘What are the problems you have?’, ‘What would make your life easier?’ and so on. Classic business analysis.
- Stories of how other charities have benefited from it: Find out how other charities have benefited from the same database as you are implementing and tell your users.
- Quick wins: It’s a slightly hackneyed expression, but can be very useful. If there are Quick Wins which you can implement when you do go-live then try to do those. It will show how the new database can help and keep up enthusiasm.
- Listen! And acknowledge.
- Automation: In pure technical terms, automating a process is one of the best benefits many users can have. For example, instead of having to enter a donation, then open Word, cut-and-paste an address, write the letter, insert the donation amount etc - automate it. Yes that is basic but even basic automation helps. And if you can automate even more complicated tasks then that’s even better.
- Excite the users by implementing one or two really ‘whizzy’ things! E.g. Maps with donor details plotted on them, analytical graphs they haven’t seen before, automation and interaction with the web. It’s going to vary between organisations as to just what is considered whizzy, but by doing just a few high-tech things early on after go-live, it does get people excited.
- Involvement at Testing. Again, I would hope this is a given, but do involve your users at the time of testing. It isn’t the most exciting of tasks but it encourages adoption and involvement.
- Competitions: I have known charities who have run competitions during their implementations. For example, every week/month during the implementation phase, they send out an email with a question which relates to the project and to which the users will know the answer if they have got involved, if they check the intranet for updates etc. The charity then does a random draw and the winner gets a prize. A very small prize to start with but as they progress through the project, so the questions get more involved (e.g. when training users, ask specific questions about functionality) and one charity even finished their competition by giving the lucky winner an extra day’s leave.
- Be realistic about implementing new changes. Having said all the above, be aware that implementing a new database is a time-consuming experience. Don’t expect to implement lots of new things on day one of go-live. Make sure you get the basics right and plan any key changes carefully. Users will thank you for that.
No comments:
Post a Comment