Overcoming Fear as a Barrier to Change

Overcoming Fear as a Barrier to Change
At Celent, we often find ourselves helping insurance carriers implement a process of change, whether it’s selecting a new policy administration system, process reengineering, or restructuring the IT organization. Change means more than just a new technology or a new process; it also requires a shift in corporate culture. Even when the IT-side of a change goes well, the people-side of a change can fail. No matter how good a new system is, the project isn’t a success if employees can’t or won’t use it. There are many reasons employees resist change. Annoyance (“learning a new system is difficult and distracts me from my real job”) and skepticism (“the last new system failed so why trust this one”) are two problems. But the biggest barrier–and the most difficult to overcome–is fear. New technology and new efficient processes mean employees fear that their jobs will become redundant and eliminated. And when employees are afraid they will fight change as hard as possible. I recently spoke with the leadership at an insurance carrier who boasted they had not laid anyone off in the history of the company. My initial impulse was to assume this meant they were putting loyalty above creating an efficient business. In the US, it’s sometimes taken for granted that thriving as a corporation means some routine layoffs as operational efficiencies change. But this company instead invested a great deal of time and effort to retrain employees rather than letting them go. Far from being a barrier to change, this corporate attitude succeeded in taking fear out of the equation. Even in a difficult economic time, employees at this company understand that new systems and new processes don’t mean layoffs. While annoyance and skepticism might still be around (and, in fact, might be increased by entrenched training and memories of previous unsuccessful projects), there is less fear. Employees can look at change as an opportunity to gain new skills; end-users can provide feedback and participate in training without worrying that they are making themselves obsolete. And support and participation from end-users is the often overlooked critical change factor that determines a project’s success. I was happy to see this challenge to common wisdom providing such positive results. While not every company will be willing to dedicate itself to this extreme employee loyalty, there is an excellent lesson for everyone. It is often assumed that to remain nimble and efficient, new technologies and processes much go hand in hand with staff reductions or replacements. But, at least for one carrier, a long-standing culture of stability has allowed them to overcome fear and embrace change.

Software Application Testing in Insurance, Part IV: Best Practices

Software Application Testing in Insurance, Part IV: Best Practices
Previous posts about testing Topic 1: Automated Testing Topic 2: Getting Test Data Topic 3: Test Environment Topic 4: Best Practices in Application Testing: It’s been a while since I’ve blogged about this subject, but I think the previous three posts could use some follow up. After talking about the need for testing, getting the test data, and setting up a test environment, we need to actually do the testing. The best practices for software application testing are not easy to set up and maintain, often requiring one or two full time IT resources with a test development specialty (often called a Software Test Engineer, or an STE). Not many technology vendors follow these best practices, let alone insurers, and the expense and effort might not be practical or possible for every insurance company. However, by understanding the best practices an insurer can at least take steps in the right direction. The ideal scenario is an automated system that is able to clean itself to a standard state before and after each test. For example, if the QA team wants to run manual tests for software application ABC, they would run a script that would:
  • Drop all the tables in the database, recreate the tables in the database for ABC, and populate it with the same set of start data.
  • Clear out any existing application code, then get and install the latest application code from development.
  • In extreme cases, the entire test server OS will be reinstalled from scratch, though that is likely unnecessary for this level of application testing.
Later, if a different QA team wants to run manual tests for software application XYZ, they would run a similar process. Both teams are guaranteed a stable, repeatable base from which to begin their testing. By recreating the database and the application each time the tests are run, there is no need to worry about maintaining the database in a certain way, and multiple users can work with the same servers. Preparing to run the Automated System Tests should behave in a similar manner, with the reminder that the order of tests shouldn’t matter. That means it might be necessary to REBUILD the database between some automated system tests. In the case of Unit Tests, the ideal test environment should go one step further. Each unit test (and in many cases automated system tests) should contain its own code to add the data to the database needed by the test. Since unit tests are intended to be very focused, the typical test just needs a few rows of data. After the test is complete, it should clean out the data it just added. Since these are written by developers, there should be an application specific API for helping developers do this quickly, written by the IT resources devoted to test development. It’s a lot of effort, and each IT group needs to determine the level they are willing to go to achieve the best possible test practices. As with the previous topics, however, once the intial set up is complete, following the best practices becomes easy and natural.

Software Application Testing in Insurance, Part III: Test Environment:

Software Application Testing in Insurance, Part III: Test Environment:
Previous posts about testing Topic 1: Automated Testing Topic 2: Getting Test Data Topic 3: Clean, Repeatable Test Data and Test Environment I’ve got a short but important point to add to the previous software application testing topics. A clean test environment makes the difference between valid results and frustrated QA. Running automated or manual tests against the same database over and over cannot guarantee the same results each time. That database changes with each test. I see many insurers who load a database once a week and then have their manual test teams run through a series of scripts every day. When results vary it’s impossible to determine whether it’s a bug or simply because the database contains different data than it did on the previous attempt. It is very important to have a stable, repeatable environment in which to run tests. If a test fails, it’s important to know that the test is failing because of a problem in the code and not because a previous test broke the system. Without a way to easily generate test data and to guarantee a clean environment, different groups that need to test will likely end up clashing in their attempt to utilize the test environment. In a future post I will talk about testing best practices, including more details on creating clean test environments.