I find working in IT implementations and, in particular, information management implementations, a good, fun thing to do. As long as the project team has technical competence and sufficient budget has been garnered through the business case process, I find the aspect of managing change in information management project implementations fairly straightforward.
Is there a doctor in the house, do I hear you cry? Kevin has gone a bit troppo. Working in the tropics has addled his brain. Change management in information management is difficult!
I reiterate it’s not, if you know what you are doing. Knowing what you are doing does take some thinking based on experience, and research and skill to know what ‘good’ looks like, but the principles are fairly simple.
Principle 1: Know your Business Goal
What is the goal of implementing your new Electronic Document and Records Management System (EDRMS)? If your answer is to implement an EDRMS and good information management practices, and to comply with a set of standards, then your implementation is working straight toward disaster.
We know this through research and years of experience. We know from reading post-project implementation reports that explain how millions of dollars were wasted to achieve low adoption rates of the new software and business practices. The approach – whether big bang or slow burn – is irrelevant when compliance is the key business driver.
The business must be engaged in the scoping process, and the project outcomes must be measurable in terms of business benefits, not the number of active logins.
What if the business won’t engage? That’s where the skill and knowledge part comes in. Engagement is a two-way street: implementation project teams need specific skills and capabilities to drive engagement from already-busy business managers and teams. If your project team cannot talk the language of business, if their process mapping skills are immature, if their knowledge of key processes of the business is poor, if their questioning and listening ability is questionable, if their facilitation skills are rudimentary, and if their knowledge of the functionality of the EDRMS and how it may be applied to improve business processes is patchy, then you will not be able to adequately engage the business to set agreed business goals for the implementation.
Principle 2: Map your Stakeholders
Not all stakeholders are created equal. Some have more power over your project than others.
The power an individual holds comes from many different sources, not just their position in the organisation hierarchy. It may come from their personality and charismatic approach to communication or from their control over information. They may have significant influence on decision makers or, in some important cases, it may come from their role as gatekeepers to business heads and decision makers. Coercive power is also important to recognise. It comes in the form of single dominant people and from cohorts of people who come to collective opinions to which they don’t deviate, based on some principle important to them.
Not all stakeholders will support your project. Some will actively say what they think, either positively or negatively, about the project. Some will exhibit passive aggressive behaviours.
It is one thing to recognise these behaviours and the nature and level of power that stakeholders have and another entirely to determine how to deal with them. You have to know from experience and a little from the science of psychology, when, for instance, to approach stakeholders one-to-one and when to approach them as part of a group. Or to know when to use someone who can influence them to do your convincing for you or when to reframe the arguments for better information management into arguments that resonate with their innate passions in life or work. If your team does not have those skills, then you need to get them.
Principle 3: Understand and deal with your Risks
Risks are often not fleshed out or dealt with in information management implementations. Project teams either are often unconsciously ignorant of risks or satisfy themselves in identifying the risk events without assessing the likelihood and consequence and therefore do not conduct an evaluation of the acceptability of risks.
Risks need to be assessed for their likelihood and consequence against a specific context. For example, harm to people, assets, or the environment. Whilst it is important to assess the project risks against criteria such as budget, timeliness, and delivery of outcomes, the context should be set by the business, taking into account the context in which risk is managed for the entire organisation. Identifying risks events which may occur and their likelihood and consequence needs experience in both the management of information and in the business processes. Evaluating the risks to determine whether they are at an acceptable level requires a good understanding of the organisation’s risk appetite. Developing and implementing risk treatment plans requires the involvement of the business.
If your project team does not have experience in assessing, evaluating, treating and communicating risk treatments and does not have the involvement of the business, then it is likely that you will miss either identifying or assessing a risk adequately, or not have sufficient buy-in from the business to implement the treatment.
Principle 4: Communicate Strategically
Communication is the most vexatious of skills. It’s so easy to do. Say some words, make a gesture or write something and we communicate. And today we have so many channels we can use. So may channels with such richness of communication. We can use infographics, video conferencing and social media, webinars, to name a few of the plethora of rich one- and two-way communication channels available.
The vexatious part is that we have to communicate with pesky humans who filter communication based on their mood, their personality, their thinking preferences, their upbringing, and language skills, but to name a few. Then they run up the ladder of inference like a rat up a drainpipe, selecting data from what we communicate, attaching meaning to it, making assumptions and conclusions and developing beliefs based on that before taking action based on those beliefs. Once those beliefs are formed it’s hard to change them too, no matter what else we communicate. They just filter away our communication based on those beliefs, selecting data that matches. What a pain. As a project manager said to me once, “Kevin, they shouldn’t think that way!” Alas, they do.
Your project team needs the skills and experience to be able to strategically think through, for the five or six key topics for each significant stakeholder group, what you want those groups to feel, think, and then do as a result of your communications. Then they need the communication skills and understanding of the stakeholder groups and the organisation culture to work out what message or messages delivered by whom, through what channel, and at what frequency will achieve your objectives of feel, think, and do.
Principle 5: Provide pre- and post-implementation Support
If your information management project is focused on business outcomes as its measures of success rather than outputs – such as having everyone able to access the software – then your project team will need to assess what pre and post implementation support the business will need.
The objective of the pre- and post-implementation support should be to ensure that individuals can easily form the intent to use the EDRMS software and adopt the new business practices, and that they will be supported by line management to execute that intent. The support may take many forms. It could involve helping managers to plan and prioritise. Or it might involve running training – in all its forms – to give individuals and teams confidence in their skills and understanding. It might include setting up an environment that motivates individuals, teams, and managers. Or it could involve direct assistance through Superusers, help desks, or floorwalkers.
This is perhaps the most complex element to determine what is appropriate for the situation you face, and requires both a systematic and comprehensive approach to training needs analysis and change readiness analysis. If your project team does not have demonstrated skills in these areas, then it is a key area to shore up, even by considering the use of consultants.
Principle 6: Measure, review, revise, and test your Processes
Research has clearly shown us that those project teams that measure do much better than those who do not. We also know that those teams that are embarking on a two- or three-year large project need to take heed of their measures, and act to change their implementation processes to improve them, and begin the measuring cycle again on the revised processes.
This means measuring the effectiveness of your communication, training, stakeholder management, and risk management. Often this will be by way of survey. Your project team needs to be adept at survey design to ensure that they do not introduce biases that skew the analysis and render the ‘improvements’ to processes impotent.
In Summary
Managing change in an information management project is relatively straightforward with some key principles to be observed. The difficulty for most teams is recognising the skill levels required to execute to the principles.
