Change Management and Software Engineering: The Intersections

Home » What is Change Management? | Definition, Principles, Process » Change Management and Software Engineering: The Intersections

Image reads: Change Management and Software Engineering: The Intersections: An interview with Linda Parker Gates by Cameron Conaway

There’s often a communications gap between the strategic change management thinking taking place in the C-suite and the software engineering leaders that bring a company’s products to life—despite change management being a critical component to both traditional management and systems engineering.

At the business level, change management is defined as the continuously evolving organizational discipline and processes for actively discovering, developing, introducing, implementing, and maintaining the myriad individual, group, and system-level changes that lead to a desired way of operating. There are dozens of change management frameworks used and loved. They typically serve as a kind of scaffolding, a frame of usually less than ten steps so those managing change can bring structure (or at least a sense of) to what can often feel like sprawling and chaotic effort.

In engineering, change management (often more accurately referred to change request management) is the step-by-step process engineering teams use to map out and trace all stages of a change to a particular system — from the initial request through to the evaluation phase. These frameworks are tactical, often serving quite literally as the step-by-step you need. Here is an example from Professor Marijn Plomp at Vrije Universiteit Amsterdam.

Linda Parker Gates at Carnegie Mellon University’s Software Engineering Institute (SEI) sees change management from perhaps more perspectives than anyone. Linda is both a Prosci-certified change practitioner and a Carnegie Mellon University-certified enterprise architect. With nearly 25 years at SEI, she’s now its software acquisition lead, which gives her the chance to help government agencies build organizational resiliency.

Linda agreed to answer a few questions about her work and the myriad intersections between modern change management and software engineering.

CC: First, deep bows to you for taking the time to help fellow change management practitioners! Let’s get an understanding of the current nature of your work at the Software Engineering Institute. Can you talk to us about what you do and how your change management skills inform your day-to-day work?

LPG: Certainly! Thank you for inviting me to talk with you. I am currently in the role of managing a portfolio of client work that centers on software acquisition. In addition to leading the acquisition work at the SEI, I have served as a Senior Examiner for the Malcom Baldrige National Quality Award. I also co-chair the Government Community of Practice at the Association for Strategic Planning.

My expertise is in strategic planning, change management, technology transition, and performance management. All of these areas intersect in practice and inform my day-to-day work. I find I have to bring insights from all of these areas to most of the work I do because every software problem, particularly one at scale, has all of these aspects to it. And any software solution is ultimately a change management problem because the solution has to be inserted into a social context.

CC: Can you walk us through one change management project you’ve worked on that you feel has practical lessons for today’s rising change management leaders?

LPG: As I mention in my 2017 article Are We Creating Organizational Debt? I have been involved in guiding organizations through a range of organizational changes from small reorganizations to the introduction of new toolsets nationwide. I am currently turning attention to the diversity, equity, and inclusion (DEI) space, which has major change aspects.

While not specifically software related, the DEI work is really interesting. As a nation, we are in a moment of awakening and reckoning with respect to DEI, and many organizations—including technology companies, software acquisition organizations, and government agencies—are preparing DEI strategies. What DEI initiatives amount to, though, is cultural change, and they involve updates to hiring practices, review processes, communication standards, etc. With a DEI initiative, organizational values themselves often have to change. Because of my background, I look at DEI through at least two lenses—strategic planning and change management. On the project I’m currently working on, I am also applying a performance excellence lens to drive a focus on measurement and results.

From a change management perspective, we are developing plans for the successful adoption of an inclusive organizational culture. This involves defining clear goals and measurable outcomes, building processes, training staff at all levels, and creating mechanisms for individual change.

With something as broad and far-reaching as DEI, it is helpful to have some kind of model (like ADKAR or others), but also to remember that any “change” problem requires a multi-faceted solution that may draw on strategic planning, technology transition, or performance excellence frameworks, even psychology or social anthropology.

CC: Linda, you have a fascinating fusion of software engineering and change management expertise. How did you initially get interested in each field?

LPG: I actually started my higher education as an art major. Through the opportunities of a liberal arts education, I got interested in computer science, philosophy, English, and psychology and I landed on a computer science major with a psychology minor.

After working in software development for a couple of years I decided to go back to school and I got a Master’s degree in Architecture (the building kind, not software). I got that degree at Carnegie Mellon, and while I was studying I took a student position at the SEI.

That led to a full-time offer, and though I left Pittsburgh for the DC area after a few years, I’ve been at the SEI for pretty much my entire career. (I got to put my architecture degree to use by being an over-educated client for my own house, where I worked with a leader in the field. It was a very rewarding experience and I hope to do it again.)

When I joined the SEI it was the heyday of process improvement. I really learned about the soft side of software from some of the best minds, and it allowed me to bring that left-brain and right-brain stuff together. As process maturity work (CMMI) was transitioned out of the SEI and into the field, I got involved in technology transition and from there, change management and then strategic planning. They’re really all related.

CC: What do you see the primary intersections between each?

LPG: Software engineering is just a domain in which to apply change management principles. But software engineering in particular is a rich field for change management because it’s rapid-paced and it scales from very small projects and problems to grand-scale roll-outs. But you could say that of healthcare, education, and other domains as well.

There are so many opportunities to bring change management to software problems. Every small improvement or major innovation is only impactful when it is used. So I am always looking at change management as a way to make software efforts successful.

CC: What lessons can today’s managers of organizational change learn from those in engineering, and vice versa?

LPG: I think the big lesson on both sides is that the technical solutions and the “people” solutions go hand in hand. What I get to see up close all the time is that a grand technical solution loses power quickly if technology adoption isn’t tended to.

Conversely, the solutions to these “soft side” issues are best tackled methodically. I use a lot of the problem-solving skills that engineers use to craft a good strategy or technology transition plan. But I can’t tell you how often I hear very knowledgeable and thoughtful engineers struggle with the difficulty of addressing the “soft side,” and thus the full scope, of a technical solution.

CC: As a change management leader, what misconceptions do business and technology leaders have of change management?

LPG: That it is costly and unnecessary, or it can at least wait. There is a broad misconception that change management is an isolated set of activities that comes late in the process of building solutions. And while change management can and should be distinctly planned and executed, I like to think of change management as a lens through which I can look at problems and solutions all along the way.

CC: In your latest article at the SEI blog, Show Me Agility, Agile Strategy Execution, you wrote that “both staff and leadership should be empowered to detect changes in the environment.” Can you expand on this a bit? How can this idea of empowerment be made real?

LPG: The ability to detect relevant changes in the environment is based on a broad understanding of organizational goals, the ability to recognize the strategic context, trust in the impact of specific expertise to the work, and transparency about internal and external operating environments.

For the DEI work I described above, this means that everyone is trusted to understand internal and external factors that impact DEI plans. For senior leaders, that might mean understanding the impact of executive orders pertaining to DEI or keeping an eye on organizational measures (hiring diversity, staff satisfaction, etc.).

For managers it may involve an awareness of the diverse perspectives expected in technical or client domains or specific projects. For individual contributors, it might mean recognizing shifts (positive or negative) in inclusive behaviors in the workplace and being empowered to speak up about what they are seeing.

Transparency and good communication practices are key factors as well.

CC: It seems COVID-19 has caused many enterprises to see change management as a continuous process rather than as “use it when we ‘need’ it.” How else do you see this pandemic (and the attention it’s brought to agile methodologies and organizational resiliency) changing change management—and operational effectiveness in general?

LPG: Agility has been at our heels for quite a while. In the software world, the necessity of agile practices is well established. What has been slower to take hold has been the understanding that with agile software development practices comes a need for organizations to change their operational and oversite methods to interface with and facilitate agility.

I think the pandemic has done a lot to reinforce the need, and also to demonstrate that we can not only be agile, but we can change. And pretty quickly at that! Overall, people are starting to understand that change is constant, but also that we can handle it better than we thought.

One caveat: In my Show Me Agility blog I talk about about putting agility into practice. One of my major points is that with agility comes an even stronger need for having an overarching goal that everyone understands. That’s really important.

I think of the Oscar Wilde quote from Lady Windermere’s Fan (made familiar by Chrissie Hynde in “Message of Love”), “We are all (of us) in the gutter, but some of us are looking at the stars.” Agility is a wonderful and necessary concept, but it is critical that we don’t see it as a reason to be reactive.

CC: Lastly, what advice would you give to students of change management, those who may have just started learning about the field?

LPG: Two things.

First, think broadly. No discipline is as powerful on its own as it is when its integrated with other fields of thought. I believe in the power of teaming people from different disciplines whenever possible to solve a problem. Make friends with people who have different perspectives!

Secondly, build your own toolkit. Don’t rely on one method, one approach, or one way of doing things. Draw on models, methods, tools, templates from multiple sources and keep examples of anything that you’ve seen work well (or well enough). I am a big fan of creative reuse.

Thank you for the opportunity to chat. I’ll be keeping my eye on this space and look forward to seeing what you do here.

*End*


Other Resources