Here are Some Ideas for Driving Change Management in a WFH Environment
More and more really useful standards, best practices, and procedures are making their way to the market. Many also are constantly updating changes and revisions that keep them on the cutting edge of the work we are doing.
But with so many standards out there, how do you choose which ones work for you? How do you apply a complex system of processes to your organization to help improve the way you work?
A common thing I encounter when talking to fledgling organizations with a curiosity in implementing an ITSM/ITOM standard is that they have bought the books, taken the courses, and gotten their certificates, but they have no real inclination in how to start.
When we encounter an ITSM standard that provides us with helpful information on processes, we are inclined to want to revolutionize our organization by implementing everything, all at once. This desire to implement it all can actually hinder our progress and lower our rates of adoption, as massive systemic change takes time.
If we are looking at a system like ITIL, we may want to implement incident services, change management, problem management, asset management, and everything else we can think of because it makes sense. All of these items sound like things we need, but if we don’t have any of these processes already in place, it can be a tough thing for even the most ambitious of organizations to do so.
Instead, think of which items you already have; these processes can be improved. Then think of which items you can then do with the least resistance. After that, your organization can then look at some of the ones that require the most work, tooling, process change, or cultural change and add those to a roadmap.
By understanding, honestly, where our organization currently is, we are then much more prepared to consider an organizational strategy and roadmap to get us to where we want to be. Smaller, incremental, changes can then prepare our teams to adapt to these changes and to learn the new processes in a way that makes sense. The quick wins and hopefully beneficial impact of the small changes can then help set up for the success of the bigger things down the line.
A second issue many organizations struggle with when looking at standards is that they think the standard is prescriptive. The standard is the end-all-be-all and the final word. Many of these standards will explicitly state that they are not meant to be used like that, and that they generally work best when applied through the filter of the uniqueness of your own organization. They are generally modular, and come with detailed instructions to get us to where we need to be, but if we have a unique need or something we need to change, there is some flexibility to adapt them to work for that need.
When considering which pieces to take, we can even pick and choose from multiple standards to support our needs. We may use some aspects of an ITSM framework in one area, and some aspects of a Security framework in another. We may use Agile methodology on one dev team, and Lean on a different one. The point of these is to provide us tools and not scripture as to how we can better organize our work. These standards provide us with a shared vocabulary and understanding to make sure we have alignment for informed discussions and strategy building.
While you may never implement Problem Management in your organization, knowing that It is a component of a framework and a tool at your disposal should you ever need it can be just as valuable. This same approach is why learning various frameworks, even at a cursory or foundational level, can be an asset to your teams.
Another common pitfall of frameworks is we all find ourselves susceptible to the sunk cost fallacy, wherein we have invested resources into something that we have learned and keep investing more to make sure it works. This isn’t to say we should drop our efforts at the slightest bit of resistance or organizational change issues; we also don’t need to consider ourselves ‘married’ to a framework just because it’s where we started.
