HRMS Team Communications: Part Two
Part One of this delve into HRMS team communications looked at the importance of choosing the right method for communicating project messages to stakeholders and listed a number of options that might be incorporated into the team’s HRMS comms strategy.
In Part Two, we establish a guiding principle on the content and ordering of that strategy; i.e. what to communicate and when.
HRMS Communications Strategy Drivers
There are two broad sets of needs that any HRMS project comms strategy will need to meet: those of the stakeholders and those of the project itself.
From the project point of view, the team knows that it has a go-live date for the new HRMS and naturally, certain events have to happen before the ‘big switch-on’ – users must be trained, data must be cleansed and transferred, technical testing and maybe parallel running must take place, and so on. All of these activities and more have an impact on users and other members of your HRMS team, so they must be informed at the appropriate time. Once you sit down with a list of project tasks and a calendar, certain communications events become inevitable – that’s the easy part.
The other driver is the reaction of the stakeholder groups themselves to the new HRMS. The project is putting them through a change process and as we know, people react to change at different rates. This can be a complicating factor in planning your comms; put simply, it’s no use putting somebody through the user awareness training for the systems advanced features if they’re still waxing nostalgic for the days when employee records were maintained on file cards.
Stages of Change
Luckily, people being what they are, your HRMS team will all be passing through a broadly similar ‘change reaction’ process and that enables you to break up your comms and information activity into a series of stages, each building on the last:
1) Why – first of all, you need to tell/persuade people why the change is necessary; give them the bigger picture as to why the organization needs a new HRMS.
2) Motivation – once the ‘why’ has been established (and hopefully accepted) stakeholders must be motivated to want the change; what’s in it for them to have this system; also, point up what was slow, inefficient or just plain wrong with the old system.
3) Equip – now that the people are motivated, you need to give them what they need (the information, the knowledge, and maybe the skills) in order to use the new HRMS.
4) Enable – knowledge is power, they say but application is success; ensure that your people can genuinely apply and use what they’ve been equipped with.
5) Reward – reinforce the new behaviors and use of the new system with ongoing comms to your HRMS team that show the benefits are being realized.
So, while the various communications methods mentioned in Part One may be used at pretty much any point in the HRMS project lifecycle, the content of those communications is largely determined by where the audience are in terms of their adaptation and acceptance of the project. Basically, know where your HRMS team is, decide where you need them to be next, and devise the content of your communications to help bridge that gap.
Native apps vs browser based HRMS: an objective comparison
How to tell whether you’re better off with a native HRMS app or a browser-based solution when sel...
Four expensive HRMS implementation mistakes
Avoid these mistakes or watch your HRMS costs skyrocket!
Cloud HRMS support packages: what works for you?
Even if you select the perfect cloud HRMS for your business, a poor support package will render i...