Software could be akin to purchasing a car; it’s a sunny Monday afternoon of June, and you’re leaving the dealership with the latest Ferrari model caressed by the gentle breeze of the summer wind. As the manufacturer’s most performing model, the salesman assured you that no other car has more features or more performance. It’s smooth driving right until you come across your first Montreal pot hole or your first speed bump!
In a previous article, I discussed how to select a new software solution, whether to replace an existing one or to automate a manual process, from questions to ask to establish a clear scope to tips to help discussions with vendors. Here, we will see what is needed to navigate the complex subject of change management to get your team fully on board with this software solution you’re scouring the world for.
INVOLVING PEOPLE
Although there are countless reasons to involve other people – whether from your team or within the organization – during different stages of your project, here are a few reasons why you absolutely should:
- You don’t have all the necessary information to make informed decisions;
- The common understanding of the project’s scope is not clear;
- You don’t have full legitimacy or credibility to spearhead the effort – however hard this is to admit;
- Your project will significantly affect your team’s output, policies or practices1.
This involvement can be formal, informal, or anything in between – each with its own set of advantages and disadvantages – as long as it happens.
Then the question is: whom to involve? In software implementation projects, on the customer side you’ll traditionally have:
- Executive sponsor(s): people who give momentum and resources;
- A project owner: someone who organizes and directs;
- Super user(s)2: people who will know the new software solution inside out to act as a guide to other users; and
- Users: people who will be integrating the software solution to their toolkit.
Be aware that it may be challenging to accurately determine who will act as a super user as well as who will act as a user if the project’s scope has not been well defined beforehand, as they could include people from outside your organization (e.g., vendors, consultants or customers). Either way, each group should have its own forum, set up with its own pace, agenda and expectations.
An emphasis must be made on the importance of users in the implementation phase. Users are often thegroup that deserves more attention than what is usually afforded; consider yourself warned:a single email announcing the deployment of a new software solution may not be the right way to go around. At the end of the day, users are the ones to convince if you want your software solution to be successfully adopted. The reason for that is that they’re the most impacted by the software solution. You’ll need to be attentive to the fact that they implementation of the software willrequire from the users to learn new tools and processes in addition to their standard workload, all the while potentially battling out software bugs and other woes.
PEOPLE’S REACTION TO CHANGE IS COMPLEX
Surprisingly, you may not find resistance where you expect it! The technophile may be hesitant because they wanted a more cutting-edge solution, while the technophobe may be your greatest ally because of the solution’s positive impact on their daily challenges. Among challenges, add the impossibility of predicting reactions that your team will have to each adoption profile on the technology adoption life cycle3 and remain mindful that you can’t blame people’s response to change for a project’s failure. No reaction is in itself wrong; rather it’s all about how change is introduced.
This is worth stressing over: despite our extraordinary ability to adapt to situations, people have a natural tendency to be reluctant to change, even more so when it’s imposed4. Consequently, one of the key concepts is to ensure that people impacted by change are involved in a way that makes them partners of the change. This mindset should guide you through the selection and implementation process, from the smallest to the most crucial decisions. Among other things, it may entail letting your team weigh in on the final selection based on vendors you shortlisted, proposing different training methods or offering a scaled implementation timeframe to integrate the solution to their work habits.
Be mindful that reaching a critical mass of supporters for a project does not necessarily equate to absence of fierce opposition or involve dismissing critics or dissenters risks creating polarized camps5.
TRANSPARENCY IS YOUR FRIEND
It goes hand in hand with the goal of partnering up with people impacted by change. First, choose your preferred method of communication. Then, provide the same information to everyone at the same time using the same channel, keeping in mind that super users and executive sponsors may need additional information given the nature of their involvement. Avoid dizzying your audience; e.g. sending an email with an update, then discussing follow-up questions in team meetings with low attendance, then sending an instructional video through the internal communication platform, etc.
Transparency also means your team should know, at minimum, the “Five W” of the project (Who, What, When, Where and Why). In more detail, this involves informing them on:
- Who within management is sponsoring this project
- What issues and problems does this software solution aim to fix
- What results are expected and how will they outshine the costs of change
- When will they contribute or be expected to do so
- Where will they be receiving updates on the project
- Why is this software effective and how has it helped other teams who’ve faced similar issues6
After which, and throughout the whole process, follow up with regular updates on how the project is moving along, covering for each phase as much the wins to celebrate as the failures that force pivoting identifying clearly the moments to intervene. Details and granular changes are not always relevant to share; though people should have general knowledge of the project’s phases and progression, evaluate how much confusion oversharing may create. Finally, feel comfortable continuing regular communications well after the software solution’s successful deployment in order to fine-tune the implementation process.
THE ART OF TIMING
Your organization is rearranging its entire customer management process to be better positioned in the market? It may sound great to add a new contract management solution to the mix, since you’re already undergoing so much change!
However, in doing so, remain wary of burning out your team, scattering your resources, addressing issues too slowly to properly fix them because of the increased workload, or simply plainly missing key issues in your implementation process7…Instead, take time to understand ongoing projects across your organization to assess the availability of resources and identify opportunities to integrate with other projects to streamline internal processes where possible.
CHEW SMALLER BITES
An incremental approach helps ensure that a failure in your implementation plan – which is unfortunately highly probable – will be fast and small8. This will allow you ultimately to pivot out of an undesireable situation with agility. For example, you may choose to divide your project into ten main phases:
- Establishing the scope
- Prioritizing needs
- Identifying key stakeholders
- Clarifying technical aspects
- Comparing and selecting vendors
- Configuring and/or customizing the software solution
- Migrating data
- Providing training
- Rolling out the deployment through various teams
- Scheduling a Go Live9 post mortem
Before diving into any phase, dissect it into smaller phases and then tasks that you can readjust as you encounter unexpected challenges. You want to migrate five thousand documents to the new software solution? Select a subset, or even a fraction of the subset, to test how smoothly the migration goes – technically and time-wise – until you can confirm that the newly migrated documents truly meet the results you expected.
RIDING INTO THE SUNSET
Implementing a software solution, like any new tool, is a balancing act. Move too fast and risk a brutal fall, move too slowly and risk missing the boat… While there is no perfect solution fit for all hurdles along the way, taking time to dissect the project’s multiple steps and valuing your team’s input is a good way to give your project the means to succeed.
- Pierre Collerette, Martin Lauzier and Robert Schneider, Le Pilotage du changement, 2nd Edition, Quebec, Presses de l’Université du Québec, 2013, p. 13 and 16
- Author’s note: to be understood from the business management standpoint, not the computing standpoint
- Wikipedia, “Technology adoption life cycle”, see online https://en.wikipedia.org/wiki/Technology_adoption_life_cycle (consulted on December 11, 2021)
- P. Collerette, M. Lauzier and R. Schneider, supra note 1, p. 6
- Ibid., p. 223
- Ibid., p. 10
- Ibid., p. 220
- Author’s note: the mantra of “fail fast, fail early, fail often”, or any of its derivatives or ancestors, is widely used in business, especially in the world of start ups
- Usually the date when a software solution starts being used“inproduction”,i.e.whenit’sbeingusedinareal- world situation with real output
