Change Management in Projects – The Overlooked Methodology
The decision to implement a new technology solution is a significant one and, in many cases, a project that typically an organization is unlikely to undertake often. It is a project that requires a significant investment of money, time, and effort and so, return on investment (ROI) represents an important set of metrics that an organization should keep at the forefront of their minds. In almost all cases, the primary ROI metric is in fact a question – “How many people are now using the new software?”. This basic question should never be overlooked and I recommend asking it at the earliest stage of the project and phrasing that question differently- “How do we ensure everyone embraces our new software?”. This subtle nuance is so frequently missed or undervalued, which is understandable as so much focus is applied to the traditional method of running technology projects; the priority is delivery and subsequently, user adoption does not get the attention it requires. Like a motor car, you can build the finest, most performant engine but if you only include one seat, only a select few people will choose to drive it.
First and foremost, it is important to understand that having a perfectly designed and configured technology solution will not alone deliver a truly successful project. In the modern professional world, each of us has a significant level of autonomy in how we work and when using technology; we do not share email addresses or mobile phones and we typically undertake our day-to-day jobs differently from the next person. These examples are obvious when we think about them, so we should look at change through a similar lens; change affects people at an individual level.
The human mind is a complex thing; 1.4kgs of intelligence, hope, love, fear, and everything in between. We celebrate and promote our individuality in life, so we must consider everyone’s uniqueness when delivering a project. When we think back to previous changes we have experienced in our professional lives, almost always the same combination of positive and negative questions and remarks are made. Such examples include:
- “Great! It’s about time we improved that.”
- “Not for me. The current solution works just fine.”
- “The last project was a nightmare.”
- “Wow! This might actually make my life a lot easier.”
It is natural to respond negatively to change. Even as a Project Manager, in the past I have instinctively reacted with pessimism when I have felt a change was forced upon me! It is this realization that has driven me to adjust and develop project delivery methods to encourage people to embrace change.
We need to view delivering successful change as both a lineal and perpetual process. Embracing change starts at the onset of a project and continues throughout the weeks and months ahead until we reach ‘go-live’ and beyond. The sections below include suggested methods for embracing change and delivering a successful project.
1. Ignite Interest – 0-1 month of the project
It is important to start communicating with the user community as soon as possible. This is a vital step- addressing the common complaints raised by users that they were unaware of and/or not consulted about the new software.
Below are some ways to get you started on communicating and igniting interest:
- Announce during any regular “Town Hall” style company-wide meetings
- Send an email to announce and sell the benefits
- If appropriate, force-out screensaver/ desktop wallpaper announcements
- Print free-standing banners and place in communal areas of the office
- If screens exist in communal areas, display messages of the new project
- Utilize the Intranet
The key to these activities is to build interest, not provide copious amounts of information. View this as a method of igniting some excitement so focus on the key selling points of the product.
2. Develop Interest – 1-3 months of the project
It is now time to build upon the initial interest that has been generated in the project. We should now be at a point that everyone in the organization is aware of the incoming software; this initial interest needs to be developed. We must remain mindful that one of the most common complaints following a project’s implementation, is that the end-users have not been consulted or felt involved. If someone feels negatively towards an incoming change, it is often because they feel that change has been forced upon them. Here are some recommended activities you can undertake at this stage of the process:
- Run demonstration Workshops of the software
- Establish user groups from each business area and run “interview” sessions to develop an understanding of how they work and how the software will need to be optimized for them
- Set up a small number of workstations for users to “play” with the software
- Provide regular project updates – most people don’t want huge amounts of detail; they just want to feel included and updated so share timelines and high-level updates
3. Empower Users – 3-4 months of the project
Training users on the new software is not a new concept but it is vital. The training delivery method is of particular importance and tailoring the training to specific departments is something that is highly recommended. When planning the training, ask questions such as “How will this department use the software?” With the knowledge built from the steps in stage 1, you will already have this knowledge so let’s use it to develop tailored training sessions. Training can of course be delivered in many forms:
- Face to face, classroom sessions
- Training videos/ eLearning
- Quick Reference Guides (one-page graphical guides)
- Remote, web-based training sessions
4. Support Users – Go live
To reach this point of the project, a significant level of investment and effort will have been expressed by all parties involved. Users have been trained, informed, and updated, but now they need to use the software. The risk here is that if there is one small gap in a user’s knowledge, then that can spark negativity that spreads throughout their user experience and transfer to their colleagues rapidly. To counter this, I always strongly recommend floorwalking. As outlined in this document, floorwalking ensures users are supported immediately during the first few days of using the software.
5. Into the Future
Change- specifically managing and embracing change, is a perpetual concept. Think of it as sliding down a curly-wurly slide and landing on a roundabout! Each twist in the slide represents the steps required for effective change during the project, followed by the roundabout which is the ongoing process of ensuring the change continues to be embraced and enjoyed. Whilst a new piece of software might not be as enjoyable (or nausea-inducing) as a roundabout, it is important to continue to communicate with your users after they have started using the software. Be sure to give that roundabout a “nudge” every now and then to keep it spinning. These nudges are often best delivered as metrics. The good thing about metrics is that they are typically easy to generate and simple to communicate. Consider options such as:
- Usage stats – share how many people are using the software and when
- Tangible benefits – where possible, calculate the direct or indirect cost benefits that have been realized vs the cost of the solution
- Speak to your user community – remember, most software solutions are to benefit the users so be open to their feedback and share it
I honestly believe that there is no perfect solution to implementing a successful change. The wonders of humankind and technology mean there are just too many variables to have a concise set of rules to follow, in order to achieve a successful change. The points I have made in this document are simply my thoughts and broad suggestions, not a roadmap for success. If I can leave you with one concise suggestion, it is to always put yourself in the shoes of the end-user; base your approach on one that you would be comfortable being a part of.