3 Fundamentals That Will Transform The Way You Manage Change
The Software Development Lifecycle (SDLC) has taught me so much over the past 25 years, not only about transformation and getting from Point A to Point B, but also the importance of adopting change. Taking the best of what I learned, I’m going to share 3 Big Tips for successfully managing change in any arena.
My first job after university was as a software developer, writing COBOL code. (What can I say? Like mother, like daughter.) It was the start of my professional journey focused on turning ideas into reality. First, I was a programmer, followed by roles writing requirements, designing systems, performing testing, and ultimately managing projects and programs. All these pieces work together to get you from Point A to Point B through transformation and change.
The experience taught me where the hidden gotchas and derailment depots lurked along the way and how to avoid running into them. In this article, I’m going to boil down decades of IT experience to give you a concentrated summary of the best lessons learned.
But first, we must dip a toe into the information technology waters. Don’t worry, we won’t get too technical here. This post will give just enough context of software development for the 3 Big Tips at the end to make sense and help you become a more effective change agent.
SDLC as a Blueprint
Quick Overview of the Software Development Process
For anyone who hasn’t been involved in custom software development, here’s a 2-minute crash course.
Once upon a time, we followed a Software Development Lifecycle (SDLC) called ‘Waterfall.’ In a nutshell, the business ‘users’ who needed the software had to make all their requests at the beginning of the process. Then they had to wait while it was built and the software ‘went live’ before they could see if it was right.
Testing was important. There were multiple testing stages to confirm the software wouldn’t break, and that it performed as requested. When we tested something simple or small, we could quickly fix anything that wasn’t right. As we tested more larger, more significant sections of the system, fixing things took longer and cost more due to the expanded complexity of all the moving parts. An analogy would be changing a tire versus replacing an engine part to make a car go. Bottom line: Finding and fixing things early when the scope was smaller saved time and money.
It Isn’t Easy Being a Business User
To help visualize the risk I’m describing, I’ve included a simple picture showing the V-Model we used. At the bottom of the V, you can see the small the gap between the sides when we’re in programmer land. Up at the top of the V is where the business users sit. The distance between what they asked for (Business Requirements) and what they get (Acceptance Testing) is HUGE. Conclusion: If you don’t find out until the end that you got something wrong, it’s expensive and time-consuming to fix.
Solving for that big time gap between business user requests and seeing a finished product in Waterfall is what spawned the ‘Agile’ development methodology. Agile is a repeating process where the team builds software for a subset of requirements and gets the OK from users before moving onto the next batch. Essentially breaking up the Big V into a bunch of smaller ones.
(Still with me? I tend to nerd-out on stuff like this, but if you’re still reading then you’re doing great, and I promise it’s worth it! There’s even a cartoon coming…)
Map The Change Path
Making Changes Can Be Risky
The software development process is like making any type of change in your life. After all, we start at Point A with a set of things we want and then we work together to get to Point B.
Now imagine our team of users and programmers. Right away, you can guess that they speak two different languages: Business Needs vs. Software Code. Despite having a common goal, they’re going to struggle with communication. The generally accepted process for overcoming this involves frequent testing and checking to ask, “Is it right?” Spoiler Alert: If the solution were that simple, I wouldn’t be writing this article.
There’s another BIG risk in introducing change that has nothing to do with writing code or different languages. It sits within the business users and their transition from Point A to Point B. You find it in these two questions:
Question 1: Do I know what I want, and can I explain it in a way that’s understood?
Question 2: Is this new and different thing actually what I wanted?
In software development, that’s what sits behind acceptance testing. Getting a resounding “Yes!” to these two questions is make-or-break for any new system to be used successfully, a process we call ‘User Adoption.’
User Adoption Is Everything!
Whenever we initiate change, getting it to stick is the way we see results. Think about a New Year’s Resolution to exercise or eat healthy. If we don’t adopt new habits that we practice every day, the change won’t be sustainable. In software development, if the users don’t use the new system, that is a failure in effecting change AND frequently a huge waste of money and resources.
The two things that threaten User Adoption are 1) The software doesn’t do what the users want, or 2) Users can’t get comfortable that it does.
“Here’s What I’m Thinking” (i.e., Articulating Point B)
The first question is an age-old problem: Did everyone understand what the users wanted? The now ubiquitous ‘Tree Swing Cartoons’ hit this nail on the head and have been making fun of it for 50 years! Mocking the disparities between what we thought they said versus what we did versus what they wanted.
This picture is from Guide to Good Programming Practice, Editors: B L Meek and P M Heath (1979) ISBN 0-85312-145-1 (Ellis Hoarwood Ltd., Publishers) ISBN 0-470-26869-7 (Halstead Press, a division of John Wiley & Sons, distributor in the US).
Wait, Are You Sure This Is Point B?
The second problem is arguably more frustrating: When the new software is indeed a tire swing, but the user doesn’t see it that way. Truth Nugget 1: If you can’t agree when you’ve reached Point B, your journey will never be successful.
One approach to mitigate this risk is to keep the users involved throughout the process, to show them progress along the way so that the change at the end doesn’t feel too big, and to give them a voice to ask questions or raise concerns.
This is where project managers come in. A good project manager can represent all stakeholders and doesn’t have a vested interest in the outcome beyond successful project completion. It’s a sherpa role that relies on earning trust and respect as a neutral 3rd party to guide everyone through the change. Truth Nugget 2: Rarely does a well-managed project feel like a nail biter when it reaches user acceptance.
Bringing It Back Around
Was it easy to see the challenges in the software development world when executing change successfully? Did you find yourself relating one of your own ‘change’ experiences to a problem I described? Ready for the payoff of how I’ve taken my experiences and applied them to the work I do today as a management consultant, fractional COO, and exit planning advisor?
[OK… you’ve hung in there long enough. Here’s the list. Phew!]
Do These 3 Things
3 Big Tips for Successfully Managing Change
Tip 1: Ask the people going through the change what “success” looks like before starting the journey.
It seems obvious. Getting an end user definition of “success” at the beginning facilitates buy in and greatly improves the odds of accomplishing change. The tip refers to people (plural) because too often we focus only on a single stakeholder and what that person wants. Whether it’s a C-Suite executive, a group leader, or even a single family member… you get the idea. The end state of adopting change needs to feel good for all stakeholders. It’s risky to rely on a single set of requirements or single perspective to represent everyone. Maybe everyone will fall in line behind the leader, but that’s not guaranteed to result in successful change.
An example from Exit Planning is working with legacy businesses. The older generation currently in the owner seat might have a clear vision of what they want for Point B, but if the next generation doesn’t see it the same way, the transition will be difficult or even fail completely. In worst case scenarios, the process can tear a family apart. Therefore, the next generation must have the opportunity for their needs to be acknowledged. In a case like this, “Whatever my mom/dad wants” is not the same as providing a definition of success.
Pro Tip: Encourage end user stakeholders to find their voices and buy into the change process from the beginning.
Tip 2: It’s OK to let people speak different languages. Say ‘yes’ to shared understanding and ‘no’ to forcing a common language nobody identifies with.
When people write things down in their own words, it captures what they mean to say. It preserves their intent and stands up to being thrown into the mix of finding shared understanding. This is critically important when coordinating a change.
Start with the words of the people who are setting the goals and going on the journey from Point A to Point B. The way they describe Point B will be the way they validate they’ve arrived. In other words, this is the gateway to their adoption of change. Rewording can create a distortion that prevents you from reaching Point B. Facilitate understanding by having conversations where all parties can read the words of the other person. Encourage discussion to get to a shared understanding and resist the urge to rewrite or change the original words.
Pro Tip: Capture and share direct quotes from discussions that encapsulate common understanding.
Tip 3: Leverage a qualified, neutral 3rd party to lead change.
Change can be easy or difficult depending on what it is and who is involved. There is always a conflicting viewpoint, even if it’s only the silence of the status quo.
Advisors with change management skills are invaluable when navigating organization-wide transformation. For the best results, involve a 3rd party from the beginning all the way through to the end. You’ll have a sounding board for ideas and a facilitator with a detached perspective for challenging conversations. That advisor will help move you forward, resolve conflict, keep you on track, and be understanding that change has side effects – both positive and negative.
Pro Tip: Work with a neutral 3rd party whose responsibility is to shepherd change without exerting personal influence.
If you’re a business owner or advisor who could use help navigating change, contact us at info@bizopsolved.com or book an obligation-free Discovery Call.
BizOps Solved works with business owners to make their companies more valuable and their lives better.
