10 Steps to Implementing OSH Software
Most companies that have chosen to do the implementation on their own have not succeeded.
THE article "Eight Steps to Selecting Health & Safety Software," published in the January 2004 OH&S magazine, provided a guide to help you select the best software solution to fit your needs. This article takes the next steps: how to ensure a successful implementation of the software.
Even the best software is ineffective when not implemented correctly. I have seen a variety of procedures used to implement software. Some have worked brilliantly, while others resulted in exorbitant costs and requirements never being met. The purpose of the article is to identify key items that should be addressed during implementation and to provide some of the lessons learned from my experience in OSH software. I have distilled the process down into the following 10 crucial steps:
1. Assembling the appropriate team.
2. Project definition and planning.
3. Reporting.
4. Codes/initial configuration.
5. Integrations.
6. Data migration.
7. Testing.
8. Training.
9. Pilot project.
10. Rollout.
The steps commonly overlap one another and may not follow the exact order shown. Some tasks are optional, though recommended to ensure the success of the project. Consider your specific needs and issues when defining your project plans.
Assembling the Appropriate Team
This is the most critical step to ensure a successful implementation. The size of the implementation team ranges widely based on the size of project and budget constraints. Typical teams range from three to eight individuals from the following groups:
1. Internal company Subject Matter Experts (SMEs).
2. Internal company Information Technology/Services (IT).
3. Application SME.
4. Application IT.
Internal Company SMEs
These individuals are from your company's EHS group and are knowledgeable about the processes and requirements specified when selecting the software. While it is important to have more than one SME providing input, too many SMEs can lead to "analysis paralysis." This results in the project not meeting the deadlines and increased costs. I recommend more than one, but never more than four company SMEs for a typical implementation project.
Internal Company IT
Whether the application is hosted internally or externally through the use of an Application Service Provider, it is critical to ensure the approval of your internal IT Department. I recommend having your IT personnel involved in most of the selection and implementation process. Chances are, these individuals have experience with similar projects and can provide input to ensure a successful implementation.
Application SME
This is the most overlooked yet one of the most critical individuals. Your software provider should ensure or require one of its SMEs be involved in the implementation of its software. These individuals know and understand how best to configure the application to match your processes.
Most companies that have chosen to implement the software themselves have not been successful. The software typically takes longer to roll out and rarely utilizes all of the functionality available. This greatly reduces their return on investment and leads to unsatisfied and frustrated end users. Consultants with experience in implementing software can be of great assistance with managing the project, but most are not as knowledgeable about the software as the vendor's SMEs. Verify the consultants have experience with the specific software you have purchased.
Application IT
Similar to the Application SME, the Application IT person knows and understands how best to configure the application to match you process. The Application IT person can provide training to an internal company IT group and assist in the software installation, data migration and interfacing steps of the project. Having a person with this level of expertise can result in significant time and cost savings.
Project Definition and Planning
What are the scope and goal of the implementation project? Your team must identify which of the processes identified during the selection of the software are to be addressed during the implementation project. For example, if implementing industrial hygiene software, the processes to be addressed might be IH sampling, qualitative exposure assessments, and sampling strategy planning.
Once the processes are identified, items 3-10 listed above should be reviewed for inclusion into the project's scope. A clear scope of work is critical to maintain focus on the goals of the project and combat the elusive scope creep that can result in changing goals and ever-expanding scope of the project. Scope creep is an implementation project's worst enemy; disarm it with a clear scope definition and set of goals.
Define Reporting Requirements
While it may seem odd to start at the output of an application before data is in the system, defining the reporting needs provides a clear roadmap of how the system must be configured. Your company may have specific reporting needs for contactors, subcontractors, or clients (if you are a service provider). Additionally, you may need rollup reports and scorecards to be generated for corporate or top management. These reporting needs greatly affect how the application is configured. This is a critical step that most implementation teams skip or delay until late in the process, which often results in limited use of the application's functionality and unsatisfied users because of improperly configured business demographics or limited security access.
Codes/Initial Configuration
This step has the highest risk of analysis paralysis. While having a complete set of codes or pick lists identified during the initial configuration is the goal, they will inevitably be adjusted during the testing, pilot, and initial rollout phases. I recommend starting with a list of codes from historical systems or paper processes. Discuss and agree on new codes, then move forward. Codes that are incorrect, need adjustments, or are missing will be identified later. Data using old codes from historic systems that are being migrated can be addressed during the migration process. (See the Data Migration section for more details.)
Integrations
When built properly, integrations with other applications can greatly streamline your work processes, improve data integrity, reduce costs, and improve your ROI. Typical integrations for OSH software include human resources, chemical inventory, and laboratory (LIMS) systems.
A quality software provider will have a good interfacing strategy or standard interfaces to utilize during this step. You should rely heavily on the IT folks, but make sure they understand the expected use and benefits of these interfaces.
There are a lot of issues with integration strategies, technologies and processes that simply cannot be addressed in one article. I do, however, want to provide you with a list of common issues that should be addressed:
1. The OSH application should have the ability to map directly to the HR organization structure. Forcing your HR organization structure into a simple 3-5 level hierarchy "tree" is difficult, won't match your organizational structure, and will require a lot of manual manipulation whenever your organization changes.
2. The application should keep histories on the business organization structure, work assignments, and individuals' jobs.
3. The interface should be designed to be self-adjusting. As new business units are added to HR, they should be added automatically to the application.
4. Significant costs and potential for data corruption caused by human error increase if HR changes must be addressed manually.
Data Migration
This is the an optional step in the implementation process. If data is to be migrated from another system, apply the following steps:
1. Define the data to be migrated.
2. Clean the data by ensuring the required data is not missing in each record and the data is in the correct fields.
3. Map each data field from old system to new system (if using loader tool or scripts to electronically migrate the data).
4. Load data.
5. Clean and reload data as needed.
The codes of the historical systems may have to be changed or archived when migrating to the new application. Contact your software provider to determine the options available in its application.
Depending on the number of different systems to migrate from and the "cleanliness" of the data, this step can be a very expensive endeavor. To save expenses, I recommend your internal SMEs attempt to clean up the data before bringing in the consultants and trying to load that data. The time required for a consultant to clean and reload the data will add significant costs to the project.
Testing
Testing is performed throughout the implementation process. Each step should have a testing and validation step to ensure the items have been addressed and validated.
Testing of the software is critical prior to training end users and rolling out the pilot. Most people are skeptical or cautious when learning a new system. A system that has not been thoroughly tested and fine-tuned prior to being released has a high risk of not being accepted by the users.
Training
Training is also performed throughout the implementation process. Your IT and SMEs should be trained on the system at the start of the project. End users should be trained before using the software. When forming the training, keep the following in mind:
1. You have only one chance for a first impression; make sure the system has been thoroughly tested and the instructors are ready to train.
2. Whenever possible, use your real-life data to train end users. They will be more comfortable with the new look and feel when they see the codes/pick lists and data they can relate to.
3. Have fun. Keep the training as entertaining as possible. Find different ways to keep their attention, especially after a heavy lunch.
Computer-based training via a CD or through your intranet can be a very effective tool for remote users. I recommend using a consultant with experience in developing professional computer-based training to save resources and significant costs over time.
Pilot Project
Do not skip this step! A very successful technique to identify errors or necessary changes is the use of a pilot project. Identify a representative or pilot site to test the initial configured software. The feedback you receive is critical to ensuring the success of the new software within your company.
Your responsiveness to address issues raised during the pilot to fine-tune the software's configuration goes a long way toward user acceptance throughout the company.
Rollout
Once installation, configuration, testing, user training, and pilot(s) are complete, system rollout can begin. This process can be site-by-site, module-by-module, etc. depending on your stated priorities. Ensure you have the resources to address the initial support issues that are common during the initial rollout stage. A quick and effective response to the questions and issues raised during the initial rollout helps form the user's first impressions of the system and its success.
Summary
Properly implementing software is no simple task. Even the best software will fail miserably when not implemented properly. You must have the right individuals on your project team to increase the odds of success.
I have identified the most common steps that should be reviewed to avoid typical pitfalls, ensuring the project is completed within the budget and timeline agreed to and not only meets the technical scope, but is well received by the users. If done properly, the entire process should only take a few months, depending on the complexity and size of your project.
This article originally appeared in the September 2004 issue of Occupational Health & Safety.