When do we tell them?
Updated: Mar 7, 2018
What is going on with the project, why the secrecy, we want to be involved in testing and approving to make sure what you do us right. Why do you tell us about this, it won't happen for another two months, I don't have time for your spam...
The above are just a few of the extreme reactions I get as a change manager on any type of transformation project. It is a fine balancing act to know when to communicate what to the key stakeholders to help build trust and maximise your adoption rate for the change you manage.
Some things that can go wrong:
The project team needs business involvement to get input on business processes and when you are introducing a new software, to test the system. So they email business representatives often with no positioning of the context in which help is needed
Projects move very quickly and from a business as usual (BAU) point of view it is random and feels like fire fighting. The project team's reality is that it is "agile" or sometimes they call it "ambiguity".
The fear of sharing incomplete information is big one. How can we talk about the change in a "precice way" when everything is always changing? Intranet sites are not set up and not advertised because the information is perceived as vague and inaccurate. So ther is hunger for information in the organisation and a sense of distrust.
Managing change is not about the moving parts. It is about finding and communicating the "safe space", the things we know won't change. For example:
Before getting business input, we always know what some of the key activities will be on the project. There is usually some process mapping and change impact assessment, that takes 2-4 weeks and some conyinuous monitoring that takes 2-3 hours/week. On an IT project there is data cleansing and system testing, which also takes about 4-8 hour/week or more if we talk about a major programme, like SAP. Usually there is a need to help with additional process input, training material review and supprt for local communication, translations. Therefore, it makes sense to set the expectations in the beginning of the programme. Ask for sufficient resources in form of full- or part-time champions. More information about resourcing and planning for change programmes is available in the Applied Change Management course of our Change Management Academy.
To manage ambiguity and "agile ways of working", watch your language. Always talk about the moving parts in a positive way, indicating that the change comes as a result of the work done to uncover unknown factors that when resolved will make the change more successful. Always demonstrate that the findings are a result of the diligent testing work done by the dedicated business resources and celebrate this success. Also, refer to more changes to come, which are a natural result of the transformation process.
Always share at least milestones by when information will be available. Typically, for example, people are worried about training, as that requires booking of diaries. No matter when you know the exact training approach, always indicate time frames and time effore required as soon as possible.
More information is available n the Applied Change Management course of our Change Management Academy. Or contact us via email@example.com