Unfortunately, I can't disagree with anything you wrote. It is important that they get this right for so many reasons,…
Change Your Change Management
By Tyler Smith
Does your organization have a solid change management system in place? Hopefully for most, the answer is yes. In large-scale IT projects, it is essential that a well-constructed system of checks and balances for each system-affecting change be in place, as well as a forum for the discussion of each change that has a material effect on other pieces of the project.
However, due to overhyped fears of errant build moves, change management often becomes an organizational behemoth, larger and more threatening than the worst government bureaucracy and capable of effectively killing the desire of any analyst to make any change.
When the change control warps to such a state that analysts dread getting up and going to work because they know that every software improvement they make will cost them an exorbitant amount of time in the approval process, the project runs the risk of losing talented staff (if not in body, then in mind).
Having worked on a variety of EMR projects over the years, I have seen everything from no change control to a change ticket process that required a PhD to navigate the nuances and still left no one feeling fulfilled when the update in question eventually reached the live environment. Many times it isn’t just the process — it’s the outdated change management software that is used at these organizations, which causes the confusion and lengthy timelines. I’m not going to name names but anyone who has worked in these projects knows what I am talking about. These ancient enterprise change management software suites make the worst-performing EMR seem user-friendly.
The real loser in this dreaded combination of micromanagement and crappy software is the loss of productivity and creativity. If an analyst spends more time getting a change through than building it, that is not necessarily bad. Some simple changes require lots of analysis to see the broader system impact.
However, if every change requires a time effort 1.5 times or greater than the time spent to perform the actual configuration, that is a serious issue. You are effectively sacrificing productivity out of a fear of your analyst being incompetent or too short-sighted to see/think through the effect of their change. In effect, your organizational policy is stating, “We trust you to make changes in the system, but no we do not think you have any degree of comprehension of what these changes mean.”
Therefore, as organizations stabilize and try to determine how to get the best work from their full-time teams, I would highly suggest taking a look at your change management process and change management software vendor and see if the process and software really align with the other organizational initiatives you promote within your IT team.
Here are a few suggestions for moving forward:
- Simplify. Cut down the change management process and software to the most necessary components. For example, do you really need to have seven different fields where a description is entered? Do the technical specifications ever need to be entered more than once? How long do these meetings need to be and do all changes need to be presented in such a forum? How many people need to attend? Trim the digital and process components. Every step whether in the software or in the change meeting/presentation process is like the dreaded extra click for the provider. Eliminate documentation processes that are redundant, in addition to required fields that do not serve a purpose.
- As you simplify the governing structures, try giving analysts more control and in doing so see how little processes you actually need in place to maintain order. If analysts have the mental capacity to perform build tasks, they can probably handle taking on a degree of higher level organizational thinking regarding the impact of their change.
- Do not allow the change control process to be constantly updated unless those changes are removing redundancies or irrelevant steps. Adding additional rules and processes often confuses analysts and these updates rarely serve their intended purpose.
- Eliminate the standalone change control team altogether and make a committee formed from actual team members. It is OK to have a PM if the organization mandates such a structure. However, analysts who solely sit in a change control cube and who are not building in the system can never have a real world view of the software. These team members are essentially reactive (which means that in order to feel they have a purpose, they need to make the jobs of others more difficult, for better or worse). It may be a stretch to say that a change control team is a form of featherbedding, but the roles within it should be looked at with care as to the greater purpose they serve and their need to be full time.
- Finally, if you can, scrap the medieval change control software and use the most minimally time invasive platform to document and present change and keep a record for the future. An Excel document may be enough. If the change control is linked to the help desk ticketing software this may not be possible without getting a new help desk software, but add this to the analysis.
Reducing change control staff and processes may not be pleasant. However, the long-term gains in efficiency and creativity that you will see in return from your analysts will benefit the end users of the software far more than the negatives of a temporary overhaul.
Tyler Smith is a consultant with TJPS Consulting of Atlanta, GA.