In summer of 2022, didn't Oracle say they were going to rewrite their pharmacy module in 6 to 9 months?…
Readers Write: Change Your Change Management
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.
Every CIO in the country needs to read this.
This guy is clueless.
Thank you Anonymous for your deep and thought provoking analysis…
Tyler is right on. Organizations need to empower their analysts to make improvements. I don’t think anyone goes into a technical field thinking they would be spending a significant amount of effort just getting their changes approved.
But what of my pretenses that it might affect people on a broad scale, or might circumvent professional review that actually matters, and that my self-anointed professionalism may supersede well-thought-through mechanisms meant to avoid havoc. Putting change management into a spreadsheet that avoids audited control systems – how can that possibly be a good idea? note: if your Change Control system isn’t auditable – you might as well just write things on napkins.
In the real world – change control matters. (perhaps, just because it’s hard, doesn’t mean it’s not worthwhile.)
Taken to the extreme: would anyone want a loved one to fly on a plane that was produced with a loose regiment of free-form activities and authorized to fly based on documents written across the back of a napkin? Or is it just considered a good thing – that healthcare systems aren’t as significant as airplanes?
Agree with Richie. I’ve experience a ‘wild wild west’ type of environment all the way to an overly structured-headache inducing one. There is a middle ground and the tools provided are what should be looked at. My hospitals process is pretty streamlined, but the tools are a headache – so much clicking in useless fields to get a change entered, and then different places to track it. No ability for all-in-one tracking. About 50% of the time the bureaucracy around the change takes longer than the actual change. Also…new hires into applications are right out of college (cheap labor) – to get them to think beyond their cubicle is impossible right out of the gate…I can’t imagine them having the ability to just make changes whenever they want…some requests are mind-blowing with their lack of experience.
@richie and @Petey I advocate simplifying the change management process at organizations where it has become a detrimental bureaucracy and getting to that middle ground (which you mention @petey). I believe that getting to that middle ground can be partially accomplished by ensuring the processes are not overly burdensome and the processes are so, I beleive they should be trimmed or cut. In no means do I think that change management should be completely eliminated or that a Wild West approach is a good idea. Apologies if that was not clear and thanks for the feedback!
A big whoopie-doo right now in certifications is CMMI (which is sorta funny, CMMI isn’t a certification…) as it promotes that organizations define the ‘way’ they do things. I bring it up because it aligns with what’s typically desired when “what works” matters most to an organization – not the other way around where what is “done” matters most.
I may know the smallest company to ever achieve a CMMI Development Level 3 rating. So I may also think that CMMI is just not for most organizations – it’s a mind-warp for legacy developers, hard-to-grasp for wannabes, and (like most everything) works best when pursed with an almost religious fervency. Simply stated: if the organization’s top leader(s) don’t (can’t) swear allegiance to an unknown God-of-a-methodology, it’d suck to try CMMI. Without psycho-commitment CMMI devolves into clap-trap chases for ratings – as if just ‘doing things’ is more important than any underlying achievement (think: sex without love). Just to say, some love it because bad systems wither when one’s organizational map is built around eliminating them. Unfortunately, it’s my humble (I lie, I’m cocky) opinion that if an organization has issues with its change control system, it’s likely got bigger issues than change control.
who is this guy? He desires simplicity- but the writing is anything but simple or elegant. Not to mention out of touch with the reality of the situation.