"Any change, even a change for the better, is always accompanied by drawbacks and discomforts." ~Arnold Bennett
Some of the biggest mistakes I have made as a professional have centered around insufficiently communicating change and its effects to the user community of the project I was working on. If you look at the statistics from IT Cortex, I am hardly alone. They cite a full 57% of the survey respondents listed bad communications as the top reason for project failure. If that is the case, what can we do the help ensure that we don't fall into the same traps again? IT can be summed up in two simple words that have big consequences: Empathy and Participation
Empathy
One of the first things we need to understand is that anytime we introduce change to the environment, we are truly inconveniencing our user community. This is true even if the ultimate result improves their situation. This is simply because we humans are creatures of habit and any change to our environment requires us to change our habits; which is hard. Once we acknowledge that what we are asking our user communities to do is a difficult thing, we can begin to understand what types of communication are really going to be needed.- Project Scope – What is changing; what is driving the change; what are the intended benefits for both the organization and the end-user
- Project Timing – When will the project begin; when will the project end and "normalcy" return; when will the period occur where end-users can provide their input; when will training occur; and most importantly, when can users expect that the actual change will affect them
- Project Updates – When and how will they occur; where is the location where the end-user community can find out about progress; who should suggestions and feedback be provided to; how should problems be reported
- Transparency – Put the information out in a public place, such as a project folder on a common drive mapping or a dedicated workspace in SharePoint (WSS is sufficient, no need to implement the full version for this). If your user community senses that you are trying to hide something from them, they are far more likely to question you even harder.
- Don't even try to write the 1,000 words – No one would take the time to read them anyway. With the availability of tools such as the Snippet Tool within Windows 7, SnagIt, Camtasia, and others; show the user community directly what to expect. SnagIt and Camtasia even give you the ability to record video of what is happening on screen. Break your message up into small, digestible pieces, so your audience doesn't feel like they need to wade through a 45-60 minute presentation to see what's new. At the end, simply give them a simple, clearly labeled "index page" of what is available. Additionally, don't just focus on "what's better", actively show them what is going to be more challenging; it will pay off in the end as detractors have a much more difficult time simply arguing when you have already pointed out what they are going to say.
Participation
It has been shown time and time again that groups are far more likely to embrace change if they feel they have had a chance to influence it. This is true to the point, that if you adequately involve key members of your user community, they will actually temper some of the initial change "pushback" and filter some of the support requests for you. When done well, taking the time to involve your user community is like investing in an extended support desk for your project.Participation is a significant item, and we will dedicate more time to it in tomorrow's article.
No comments:
Post a Comment