TOWARD A BETTER IMPLEMENTATION OF CHANGE MANAGEMENT (PART 1 OF 2)

In a business world where keeping up with competitors means leveraging evolving technologies, complexity is the order of the day. Systems are growing rapidly more complex in the functions they can perform and the integrations they offer, so keeping your systems, processes, and training up to date are crucial to operational success.

As a way to combat the validation sprawl which comes with increasingly complex systems, risk-based assessment has emerged as the preferred method for ensuring the most critical components work as expected. While the logic of focusing the efforts on areas where customization or application involve or even create high risk, enacting an efficient and useful risk-based program can be the difference between success and failure. Ironically, a poorly-executed risk-based program can introduce more risk than it eliminates.

Studies have indicated that organizational changes are abandoned between 16 – 30% of the time, with nearly half being indicated to be a partial failure, and 53% failing to keep budget or timelines or not fulfilling intended purpose. Some indicate a much higher failure rate of 70%. [i]With such high stakes, properly implementing change management becomes a business need, not just an option.

Setting the Stage

To give the discussion context, we’ll discuss how one company implemented a new process to help manage risk in software implementation. As the software was in the pharmaceutical space, any glitches or errors could have catastrophic repercussions, including affecting patient safety. So thoroughly validating critical components wasn’t just a good development practice, it was ethical.

The new process included several steps:

  1. Customizing a risk-based analysis template to match the individual project’s specifications
  2. Facilitating a discussion among stakeholders regarding the risk of each requirement
  3. Using the final document to guide risk management during the development and testing process

The process was meant to allow the project team to highlight the areas which were most likely to create problems for compliance or safety. As it was a novel project which included developing a new process, creating the tools to facilitate the included tasks, and filling in the knowledge gaps to ensure adoption and compliance of the new practice.

 

The remainder of this article will be dedicated to discussing each of these aspects, and the next article in the series will discuss an alternative approach which would have likely yielded better results.

Deconstructing the Missteps in Planning, Process, Tools, and Bridging the Gaps

Planning

One of the fundamental keys in implementing a new process is involving stakeholders. In their article Change Management through Learning Factories, Dinkelman, Siegert, and Bauernhansl (2014) relate how research has indicated how a top-down approach will encounter more resistance and introduces risk into the change management process. The key pain points include:

  1. Employee Resistance
  2. Lack of process control
  3. Speed at which change is implemented
  4. Unclear goals[ii]

Although some resistance is inevitable, it can be minimized through a bottom-up approach which includes as many people as possible in the process. Although this model requires the investment of more time and resources, resistance to the change is lowered the results are more sustainable.[iii]Predictably, morale suffers when employees realize their voice doesn’t count.

In the case mentioned above, the process was planned by a team of three. Meetings were held to gain input on the process with team leads and feedback was given as to operational impact. However, when the process went live, it was clear that the suggestions made by the team leads went unheeded. Success metrics were not tracked, but the new process became a byword among the operational staff and complaints were frequent. Some employees understood the reasoning behind the change and supported it but were unhappy with the way it was implemented. In either case resistance could have been minimized by being more flexible in the planning process and including employee suggestions.

Process

The second pain point was in the actual process created to develop and implement the risk assessment template (ie risk analysis document). In order to get the risk analysis document customized to the particular project, the entire project management team had to contact one individual. The document creation was a manual process, and sometimes took a few days to turn around. The team was not empowered to get the document on their own.

 

In addition, testing of low-risk areas was not limited as all base test cases continued to be performed, but high-risk areas required additional testing over and above the standard module testing. The result was trying to fit roughly an additional 5% work into already tight timelines.

 

The time invested in updating the document could have been minimized if the template had been created with the proper level of risk assigned for each requirement, based on the software template. Ideally, only the items which were new or customized would need to be assessed. Because this wasn’t done by the subject matter experts in each department which collaborated on the new process creation, different users could assess even low risk items higher than what was needed, thus increasing the testing load. Other, more risky items might not receive the appropriate level of testing.

 

Because the process was not taken seriously, the collaboration on the risk analysis document wasn’t very rigorous. Completion and a QA review was required for the development process to proceed to the testing phase, the discussion lacked the robustness the process was created to engender. Risk was not minimized, and the project did not meet its intended goal.

Tools

Updating the template was also a manual process which could have been streamlined. The template document wasn’t formatted to account for a risk analysis of the software template. Each cell in the matrix, which could expand to 500 or more cells based on project complexity, had to be updated manually to assign the proper category. Automating the process would have streamlined the process and allowed a quicker and less-frustrating turnaround time.

In an article on The Benefits & Challenges of Business Process Automation, Ayesha Khan cites the following benefits of automating processes:

  • Focusing less on small tasks to empower customer service
  • Integrating disparate systems
  • Dynamic task assignment

Although these benefits are attractive, the challenges must be balanced as well, which include:

  • The difficulty of integrating systems
  • Morale suffering due to fear of jobs lost through automation
  • Additional engagement to monitor the automation[iv]

 

The challenges listed would have had only a minor impact in automating the document acquiring task as it would have involved little integration, was not a significant portion of a team member’s role, and the limited scope of the task would require little oversight. However, the benefits would have allowed the creator more time to focus on other tasks and, if automated correctly, the document could have been created without a manual process while the project was being created.

Bridging the Gaps

As a new process, training was a crucial aspect of implementation to ensure compliance, as well as minimizing the time wasted to learn how to perform the tasks. Dinkelman, Siegert, and Bauernhansl discuss the importance of communication when training and supporting staff during the change process.

“Unidirectional media”, such as “newsletters, speeches, and bulletins”, do not offer the ability to dialogue with those affected by change[v]. Instead, the information is directed atthem, rather than presented withthem involved in the discussion. In contrast, “bidirectional media” allow dialogue surrounding the change[vi]. This may include conference calls, classroom/online interactive training, and forum on intranet or wiki sites.

The team in this case did engage in a series of “town hall” meetings which provided some guided instruction through the document and allowed questions. However, a more robust training would have been a mixture of the bidirectional and unidirectional approaches. Key items could have included:

  • A hands-on workshop which allowed those who would be using the document to apply the new process to a test project
  • A process document which outlined the step-by-step application of the new process which could be accessed at any time
  • A knowledgebase which allowed the submission of questions, allowed feedback, and provided evolving information on the process as it evolved and was refined

 

In the next article, we’ll discuss how a “Co-creation” approach to change management would have resulted in a more effective and sustainable implementation of this process.

 

 

[i]Change Management through Learning Factories. p.395

[ii]p.395

[iii]p.396

[iv]https://tblocks.com/blog/2017/08/02/benefits-challenges-business-process-automation/

[v]p.397

[vi]p.397

Leave a Reply

Your email address will not be published. Required fields are marked *