Change … Change is looked upon differently by different people. Generally speaking we have two groups. Those that embrace change and those that loath it. But change is a complicated process, Windows 8 for example wanted to change the face of Windows and fill a potential gap in the market. “Gap filled problem solved, but where in the world is my start button?”. Microsoft introduced changes to one of their flag-ship products and all in all, people didn’t like it, too much too soon perhaps?
But the basic moral is that you simply cannot please everyone, people are naturally resistant to change and how you manage that change is the most important part. Microsoft managed the change badly, badly communicated and an end product leaving their valuable customers scratching their heads. To turn the knife they then went and released Surface RT, easily the most confusing release of 2012. Since working with businesses I’m often asked to facilitate significant changes that impact running operations, often it’s a struggle to help the end users see the benefits of such changes so here’s my quick step guide to reduce the backlash.
I’ll use a recent example of the work I did with a business consisting of 30 computer users. I was approached by the manager to introduce an Active Directory password policy and provide filtering, monitoring and reporting of Web and Email traffic. A fairly normal and standard request for a growing business, these things you’ll find in many businesses with a network infrastructure. They come about primarily for the concern of business security, service integrity, employee safety and finally to help ensure employee productivity (goodbye Facebook).
Whilst fairly typical requests they are impacting the end user heavily and therein lies our problem. I can do this sort of work within a day and move on but doing so blindly would result in an end user backlash that you’re leaving your customer (the manager) to clean up. This looks bad on you and you probably won’t be asked to assist with future projects.
- 1. Initial Meeting
Obviously we’ll need to go and see the manager and discuss the specifics of the request and see exactly what he wants to achieve. Go prepared and have products in mind that you’ll feel would probably meet the brief and the needs of the business, be sure that these are products you’re confident in implementing and using because it’s likely you’ll need to discuss them in detail. During your visit, take a look at the infrastructure and hardware in place.
- 2. Plan the Changes
Time to go away and draw up a proposal document detailing the project information and your implementation plan. Having gathered all the necessary data from your meeting you should now be able to confidently decide on a product or service that will meet their needs.
- 3. Communicating the Change
Time to communicate all the changes that are taking place to the business. Correction. Time for the management to communicate the changes. Ultimately this is the managers project and he’ll need to communicate in detail what’s happening to the rest of the staff, you can assist with this of course but the employees need to know that the change is coming from and supported by those at the top. This will help the transition and reduce resistance. Don’t just say it’s happening, say why it’s happening and start providing target dates for completion if possible.
- 4. Employee Committee/Review Group
Once the staff is aware something’s happening I often try to encourage the creation of a Employee Committee. The size of the committee is dependent on several factors, the size of the business for example. Perhaps 1 or 2 for small businesses, perhaps 1 from each department for medium to large businesses? Often whatever feels right in relation to the project impact and the business size. This committee can have some involvement which they can help to communicate back through the staff and the staff can communicate back through the appointed committee member.
The flow of communication in this way helps to stop you from getting bombarded with the same questions. Concerns, issues and ideas thus become effective. In this example the committee might push to have more web access rights during lunch hours or provide a list of websites that must be available for business operations etc.
- 5. Provide Documentation (How to guides, screenshots etc)
Documenting and providing step-by-step guides with lots of screenshots give the end user great confidence that they’ll know exactly what to expect. When they see the strange notification saying their password has expired, or realize what has happened when the WEBSITE BLOCK template appears when trying to get on twitter.
- 6. Offer Training
Some aspects of the project may require some training, for this particular example I didn’t have much training to provide. The hosted solution was overseen by myself as part of a support contract and there was an individual onsite who could log onto the hosted solution and unblock any wrongly quarantined mail items, he was comfortable using it after a 20 minute walk-through.
- 7. Listen to Feedback
As well as the employee committee you may find that people will want to stop you and ask about the change or may even want to give their ideas. Be mindful of this happening and happily respond to queries and ideas where possible to put staff at ease and give confidence. For large projects or changes that might take some weeks to complete you might find a dedicated mailbox to be a useful service for this type of feedback. The designated committee can then access this and collate the ideas of the staff before your next meeting with them.
- 8. Slowly Introduce Changes
Introducing everything at once is like spilling your coffee in an employees keyboard and then running for the hills. It isn’t really fair and even in this example it might prove too much to bear in one working day. For this reason I introduced the password policy quickly. Slowly followed by email filtering two days later and then followed by web filtering for Monday of the following week. Doing it in this way is good for you as well as you’ll be able to manage any surge in support requests a little easier.
Introducing a password policy change sounds simple enough but for a business that’s never used it on their Active Directory domain before it can cause quite a stir. I was kept busy for three hours when this went live due to the 6 character minimum policy, despite this being in the policy document it wasn’t communicated correctly to ensure a smooth implementation. I saw the mistake after of course which I certainly don’t intend on repeating.
When you’re asked into a business to implement a change, do so with the entire business in mind. Overly concentrating on keeping the manager happy is likely to end badly for you and the manager. If the change impacts the entire business then involve the entire business on some level, show you care and show that you’re listening. At the end of the day it’s good for your stress levels and makes good business sense in ensuring you get invited back for project number 2.
Have any stories about implementing change to a business? Lets hear them, good and bad.