Communication is the key to ERP project successBy John Fatkin, Lead Consultant – Supply Chain Management on
Clearly, it’s axiomatic that if a successful ERP project relies on healthy, yet structured, dialogue, the absence of such can cause the activity of the project team to seize up and risk stopping the project altogether. But do we recognise the signs when communication is drying up and do we know how to intervene?
Communicate responsibilities up-front
It starts with having the project team (and the business) on the same page. Often the Kick-Off meeting is dominated by the excitement of the ‘design and build’, but people need to know what role they are being asked to play and to be given the opportunity to respond. If commitment to project tasks means that gaps are likely to appear in other roles, they need to be called out and not assumed that the ‘backfill fairy’ will tend to the business-as-usual responsibilities. If these issues aren’t managed early on, people can carry unshared concerns that can manifest themselves as communication breakdowns later.
Don’t drown in emails
It can happen to anyone in the project team, but there usually emerges someone who becomes known as the go-to person on matters of design, integration, data, management awareness, etc. Their own value to the project draws more attention to themselves and adds to their workload. Under these circumstances, the communication channels to this person need to be carefully managed. Most critically, they can drown in emails.
For some, there can be a tendency to push an email aside for later consideration or ‘homework’. Clearly, they must learn to achieve a high, first-time resolution on emails. A backlog of unresolved emails can be akin to a project task delay. They must push fervently to make decisions and move the issue on to the next person who needs to act or know the outcome of their decision. This is a skill that can be learnt.
At all times, don’t take the view that ‘if it’s important, they’ll contact me again!’.
If the response to a question is not forthcoming, it can be interpreted by others as tacit approval. Further project effort can then be expended based on more assumptions, only to realise later that misalignment has occurred and rework is needed. The same trap can occur with voice mail responses.
Keep the project manager visible
Don’t isolate the project manager in a separate office – keep it open plan. Private matters can be convened in a meeting room as needed. The value to communication of having the project manager accessible is significant.
In the interest of keeping the ball moving in often complex project tasks, insist that people report back on the completion of tasks. It allows the next person to commence their work, prevents unnecessary delays being added to the critical path.
Encourage common sense
Encourage people to call out if something doesn’t make sense or just doesn’t look right. Don’t let the obvious mistake actually occur.
When the project is well-advanced, resist making design changes – if overused, it can undermine confidence in the mettle of the project management team. If a case is well-presented and can be accommodated without losing another objective, then it might be considered. Ensure that impacts are thoroughly scrutinised then communicate the change itself widely and clearly. Unfortunately, it will add to the noise of project email traffic, hence accept them sparingly.
Check in on agreed actions
Follow up on actions that were agreed at the last meeting, otherwise a message of unaccountability is tolerated and further time will be spent to chase the issue later. If a task has not been completed, unpack the situation clearly and act to ensure that recurring patterns are averted.
When two or more people are gathered for a meeting, it’s incumbent on the meeting organiser to be prepared. The agenda, timing, discussion and decisions need to be well-managed. Even the operation of the video or conference call equipment needs to be anticipated. The project costs associated with gatherings of people can be huge so the readiness for effective communication needs care.
IT gurus aren’t known for having gregarious dispositions – draw them into conversations in the project team.
Although complex matters and statements of commitment might need to be put in writing, encourage face-to-face communication at other times. Sadly, we can all revert to sending emails across the project room on matters that should be better addressed with body language and personal attention. Emails can have a propensity for misinterpretation, especially when the communication is limited to an understanding of the English language only (plus emojis) – just look at the length of some email trails compared with what could have been spoken simply and quickly.
Ban the blame
Break down the blame culture. Working in an environment with a fear of repercussions leads to many communication maladies (buck-passing, concealment, silence, etc.). A leadership step is needed to demonstrate the approach of sharing issues and dissociating the problem from the person. If a mistake is made affecting an integrated ERP design, the impact must be discussed openly, otherwise incomplete views might prevent a problem from being truly resolved.
Midway through the project, it’s easy to overlook the perspective of a newcomer; in large projects, specialists might have short-term roles to play. Such people have missed the project history. Re-state their required tasks and ensure that they have a direct relationship with a leadership figure. Make sure that any emailed links and documents are still relevant.
Keep the business and project team close
There can be a natural separation of project team and the business. Even after business process owners have been named and the project team commit to keeping sponsors in the loop via status reports, much of the keenness and sense of each other’s priorities can fade.
The project team can often bunker down with a mandate to ‘deliver the project’ within an uncomfortably short timeframe and be quite impervious to the changing needs of the business leadership team. To their surprise, the project team can awaken to the news of a company acquisition or change in management team and new tasks must be accommodated in the project plan.
Set up the rapport early, checking in on each other regularly (not just for steering committee meetings). Don’t let a sudden rush of introductions occur as go-live approaches.
Determine what can’t be sacrificed
If a clash has occurred in the calendar, don’t sacrifice the training session that will set up a person with the understanding that they’ll need for the next five years. Don’t cancel the team meeting if it is the only opportunity that you’ll have to check in with the direct team. Be deliberate in the choice of activities that will be delegated or let go. Some communication has greater value than others.
Mix it up
Have project team nights out. Despite talking ‘shop’ most of the time, these will build a broader awareness of what people do and it will bring people into different communication circles. It can later engender unexpected networking that benefits the project.
Avoid closed access
The last audit visit might have frightened the security controller. Key project team members can be barred from having access to the critical areas like the production client. Apart from giving a message of disempowerment to the team, the cross-functional knowledge of project team members will be missed. Their lack of involvement will be replaced with much wheel-spinning and longer periods to resolve issues.
Surely, concerns of control can be addressed by demonstrations of containment and the protection provided by transactional user/time/date stamping.
Don’t hold back
Sometimes people don’t respond because although they know what to say, they don’t know how to say it – especially if it is perceived that it could provoke a negative reaction. As a result, nothing is said. Learn how to say it. It’s worth investing in some training of the so-called ‘soft’ skills, otherwise people will press on working in silos and the inevitable misalignment of work tasks will be revealed later.
Re-state the schedule
It seems almost fatalistic that despite a project manager overseeing a project, the workload will not be evenly distributed across the project timeline. Strangely, a mad scramble to prepare for go-live appears to be unavoidable. As a defence against this risk, the key targets should be called out each week and action taken if slippage is occurring. Often, communication of the project timeline can go quiet after the initial surge of project excitement, or if the official project timeline has been allowed to become outdated. It takes effort and discipline of the project leaders to be vigilant in the declaration of present position and the key areas of required effort. Without such information, the project team’s effort and focus can become fragmented and blunt.
Finally, an ERP project is fundamentally a work task conducted by people. The task itself is subject to much change that must be communicated well. Preparation, attention to detail and management of accountability are necessary for communication to work, however, it is in cultivation of a sound team culture where communication thrives.