This is the next in a series of posts focused on process work. Particularly process work being carried out in projects. It links in closely to my eBook ‘The Perfect Process Project’, version 2 of which has been released. If, after reading these posts, you want to purchase a copy of the book please feel free to click over to the appropriate page and do the business.If you are already a subscriber to The Process Cafe you will receive these update automatically in your RSS reader or inbox. If you don’t already subscribe you might wish to do so by clicking the RSS icon on the right of this post.
This post is going to focus on having the right users involved at the right time.
- Get the users involved at the right time
- Keep communicating to them at the right time
Any project will involve an amount of change and that change will be visited upon the users. It is therefore vitally important that you involve and communicate to the users and keep them up-to-date with what's happening
Get the users involved at the right time
Essentially this means if you are going to dump a new process, or system, or methodology, or set of standards, or organisation or whatever on them at least let them know early on and in advance. Only last year I was working with a volunteer theatre organisation who were looking to automate their box-office process through their web-site. Their technical guy spent a long time - and a large amount of effort - putting together a workable, simple, easily linkable checkout system that could be merged seamlessly into their existing web site. We tested this amongst ourselves and were happy that it worked. However at the final presentation where this went before the committee this guy had - despite my numerous reminders - not spoken at all with either the treasurer or the box office people. As a result they both dug their heels firmly in and decided not to have anything to do with this system. This delayed everything for several months whilst apologies were given and adjustments were made Ultimately things were accepted, but only after box-office decided to outsource the management of this part of the process to the technical department Morale of the story? Get the users involved at the right time (in this case, early). This is especially important where you are implementing process change which will directly affect a given user or set of users. Familiarity is a very comforting thing for a user and once a change is proposed (or made) this familiarity will disappear. As a result the users will become less receptive to helping and the job will become more and more difficult for you.
As you start to make change, keep the users involved in deciding what the changes are going to be. Make it clear at the outset that there are going to be changes but that you would like them to be involved in defining the changes. Set the boundaries for where the involvement will occur. It is too easy to give users a large amount of leeway and end up with either a process that doesn't ultimately work, or a process that is identical to before the change was made (Neither of which are useful situations).
Keep communicating to them at the right time
General theory on human communication indicates that a person has to hear the message seven times before it sinks in. This is important to understand especially when dealing with project change and including your users. What this means is that you need to establish consistent and frequent communication initiatives to your user base. This could be through a newsletter, regular e-mails, town hall meetings or other mass communication mediums. But it is also important to remember that process change affects individuals not departments. Speaking to a department is one way of trying to communicate, but speaking to an individual is for more powerful. Get into a department and sit with individuals (or small groups of two and three maximum). Make the communication two way. Ask questions and provide answers. Pass across information, good and bad, and don't hide anything from them. If there is a bad news to be said then say it. Don't try to sugar coat anything because doing so will come back at a later date and bite you. Users expect to know what is going to happen and why. The worst thing you can do is to tell someone that 'x' is going to happen when, in fact, 'y' is actually going to happen.If things change (as they invariably will) get back and tell the users. Don't keep them in the dark. Let them know what the change is, why it happened and what the impact is going to be.
Timing is also key to making your communication successful. Tell the users with plenty of time what you are trying to do and then tell them again as the event approaches. But when talking to users, don't just tell them what's going to happen, tell them what they need to do to accommodate this change. If the process change involves the users needing additional training then tell them when they will be trained and what they will need to do during and after the training. Don't expect the users to know what you expect them to do.
Summary
I consider the user interaction one of the key items needed to make a project successful. It is important to make sure they know what is expected of them at all points, that they are involved in the whole change processes and that you communicate with them often and regularly. I can't guarantee that this will solve all your problems, but I do know that without doing this your project is doomed.
Part six of this series 'Doing the wrong things" will be published on Wednesday 23rd December 2009
For earlier posts in this series please click here:
(Also don't forget the Process Cafe is available on a mobile version for your internet-enabled phone. Just click here or go to http://processcafe.mofuse.mobi/ to view).
Reminder: 'The Perfect Process Project' is still available. Don't miss the chance to get this valuable insight into how to make business processes work for you.
Click this link and follow the instructions to get this book.
All information is Copyright (C) G Comerford
See related info below
