- About Us
- Customized Programs
- Free Resources
- Georgia Conferences
All of us have been part of an effort that, for some reason, did not turn out as we intended. It could have been something as simple as that new omelet recipe you wanted to try. Why didn’t your omelet look the same as that pretty picture on internet? Or it could have been the 2013 rollout of healthcare, the beleaguered web portal of the Obamacare initiative.
Somewhere along the way, something went wrong with that omelet and with Obamacare’s website. Identifying what went wrong (and quickly) is a big part of what change management is all about.
Whether the goal is to make an omelet or to roll out healthcare.gov, it is important to realize that these products came into existence only after the completion of many individual steps. In the case of the omelet, you beat the eggs, warmed the butter, diced the fillings and so forth. Your future omelet will eventually come from this soup of ingredients.
This soup of ingredients undergoes major and minor changes as you progress through the recipe. The current state of your omelet can be called your “as-is state.” From this as-is state, you make a series of observations and form the “baseline” mental image of your omelet. As you move ahead to the next step in your recipe, you remember this baseline and monitor what the next change does to your effort. You can likely identify a problem faster if you pay attention to what things looked like before.
A lot of change management is simply empirical observation. With a good record of changes and whether the result was positive or negative, the bad outcomes can often be minimized and the good outcomes made more frequent.
In practice, change management has great practical value to the enterprise. Many organizations are subject to regulatory agencies or laws. For example, U.S. hospitals and healthcare providers are subject to the Health Insurance Portability and Accountability Act (HIPAA).
One technical provision of HIPAA is that healthcare providers must safeguard against unauthorized changes to a health record. In this scenario, change management is not simply a benefit but a requirement. For example, if a patient has a documented history of an allergy to penicillin and his record is erroneously updated to report no allergies present, monitoring may help catch an otherwise deadly mistake.
For undertakings that involve many steps or many changes, change management can offer a clear reversion path. The record of change is the “trail of bread crumbs” that gets your product back to a functional state. Let’s say that you are working on an Excel spreadsheet with many embedded formulas, each of which references a specific location in the spreadsheet.
If you start introducing a lot of changes all at once – moving around columns and updating formulas in the spreadsheet – you may find that some of your formulas no longer work. But which change broke your spreadsheet? If you can’t identify the change(s) that did, you may have to redo all of that work.
Another advantage is that it helps preserve institutional knowledge. In large programming projects, for example, the product manager can review the state of the application over time. Each code change or revision is typically checked in to a repository as a sort of archive. The entire evolution of the application project can be observed by looking at these snapshots in time of the code. As a result one can begin to understand the way the product has changed over time – even if the original programmers have long since left the company.
Change management is often unpopular due to the increased overhead it brings. In fact, if done poorly, it can bog down the output of the entire organization.
There is a cost associated with change management. That cost can come from the time it takes to train staff to use the new process. There can also be capital expenditures if the company decides to purchase a CM software application.
Perhaps the most serious challenge to consider for change management is the overhead it may bring. If the process of change management is more onerous than making the change itself, the CM process may need improvement. If change management is not handled in an efficient manner, the new process may not gain acceptance and consistent use. Worse, the rank-and-file staff may quietly lower their output to the business as a way to avoid using the change management process.
Before rolling out a new process or buying new software, the business should identify key stakeholders for the effort of rolling out change management. A project sponsor should be identified that will act as the owner of the project. Together, the stakeholders and project sponsor should identify what needs the project must fulfill to be considered successful. Desirable features can also be included alongside project requirements.
Once the project team is identified and the goals listed, the team should examine what resources should be involved in determining the necessary steps to accomplish those goals. Many goals in the project will likely reveal an interdependency between two groups within the business: for example, the rank-and-file’s acceptance of the change management systems, and the executives’ ability to provide an efficient and functionally relevant system.
Failure to meet such an interdependency can risk project failure. Therefore, it is important that the project team hold conversations with staff outside the project team to determine what an efficient and functionally relevant change management system might look like. This can mean lots of conversations and interactions with entities across the business.
If requirements, interdependencies, and functional concerns are addressed prior to rollout, the business will have an accurate idea of what their change management system will need to be successful.
Nick Harrison has 15 years of experience as a systems engineer. He is currently enrolled in the Western Carolina School of Business, pursuing a Master’s degree in Entrepreneurship. Webmasters and other article publishers are hereby granted article reproduction permission as long as this article in its entirety, author’s information, and any links remain intact. Copyright 2016 by Nick Harrison.
By Nick Harrison