Most failed software projects fail due to selecting the wrong software for a project’s needs. The root cause is typically not including all the necessary individuals and groups to define the requirements and select the software.

The size of the 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. Subject Matter Experts (SMEs): SMEs from all parties that will use or be affected by the software should be considered for the team. Try to bring in people that are team players, yet represent a wide variety of opinion. Also try to include SMEs with a wide range of experience. Variety in the group will help elicit a wide range of ideas and philosophies to the benefit of the project.

2. Information Technology/Services (IT): This is one of the most overlooked groups, yet has the most impact towards a successful project. Your company might have specific IT standards for databases or technology platforms that must be followed for them to support the software. Additionally, there are newer regulations that impact data security and privacy that IT will require the software to be compliant with. If your IT group is not supportive or difficult to work with, you  might consider hosting the application through a third party provider (i.e. “outsourcing” the IT work). While this is not for everyone, it has proven to be a critical success factor for some.

3. Purchasing: Most EHS Professions do not have the experience (and in most situations, the purchasing authority) for selecting software. The Purchasing group should be looked at as allies. They may have the knowledge to guide your team through the software selection and purchase process. Their role is to ensure you get the best product at the best price.

I always suggest companies “reach for the sky” when defining their needs or requirements. Don’t settle for status quo. List your requirements with no IT or budgetary roadblocks. When going through this process keep in mind the cost/benefits of the new system. This will help you gain budget approval.

Requirements can be broken down into three key categories: functional, technical and reporting.

Functional Requirements: The most effective method of defining functional requirements includes a process flow diagrams and a list of requirements. Process flow diagrams help illustrate each of the steps and interactions between the users, equipment and/or third parties to complete the task at hand. A list of the key requirements for each of the key processes can then be documented in a spreadsheet.

Technical Requirements: Do not underestimate the importance of this step! Many software purchases have been based on the “nice look and feel,” but failed miserably due to the system’s weak technology. Working with IT to define technical requirements, Some items to consider are:

• What is the technology to be used? (Webbased, Client/server, PC?);

• What type of database(s) are supported by your IT group? Does the software need to be multilingual?;

• If web applications are required, must they be 100 percent browser-based?;

• Is the application going to be hosted internally or externally through an ASP (hosting provider)?

Reporting Requirements: Only you know what reports you need out of an application. Rather than looking for a system with a lot of standard reports, consider a system that enables you to build your own reports. Your reporting needs will consistently change; you need a system that will change with you.

Watch out for third party reporting tools. These tools were common in the client/server versions due to their flexibility, but most of these tools have changed their pricing for their Web versions. Most third party web based reporting tools now require a separate license for the web server – which could cost 2-6 times the cost of the EHS software. Instead, look for an application that offers internal reporting tools that can offer a lot of flexibility to meet your reporting needs.

Once all functional, technical and reporting requirements are listed in a spreadsheet, the team can assign priorities to each requirement. The most effective RFI/RFPs include the spreadsheet of requirements with an additional column for the vendors to identify if their application will:

• Meet the requirement “out of the box” (standard in application);

• Meet the requirement as part of implementation; or

• Will not meet requirement (i.e.customization is required).

A well written list of requirements in the RFP/RFI process will be successful in identifying a clear list of vendors that separate from the pack. Most RFP/RFIs have the goal of reducing the number of potential vendors to two or three.

A number of projects never get off the ground due to the Purchasing or Legal Departments.

Most of the time, this issue could have been averted if these departments were involved in the project from the beginning.

It is critical that the project manager maintains communication with your purchasing and legal departments. These departments should have most of the necessary information to move your purchase forward. You should walk your selected vendor through your internal legal reviews and purchasing process, making sure nothing slips through the cracks and you stay on your timeline.

The size of this 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 SMEs;

2. Internal company IT;

3. Vendor SME; and

4. Vendor IT.

Clearly defined roles for the implementation team are one of the most critical items toward insuring a successful implementation project. The most critical role is that of the project manager. This person can work for the vendor or be part of the internal company.

Either way, this person’s number one priority is to track the status of the project and ensure each action item is tracked through completion. There should be 100 percent clarity of the schedule, action items, responsibilities and expected completion dates. A lack of a clearly defined Project Manager is the number one cause for failed implementations.

Testing and training are 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 roll out. 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.

Once installation, configuration, testing, and user training 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.

Properly selecting and implementing software is no simple task. Even the best software will fail when not implemented properly. A well-built team that includes SMEs, IT, Purchasing and Legal can assist EHS Professionals through the software selections and implementation process. FSM

Dave Risi, CSP, CIH, CHMM is a principal with Spiramid, an EHS software provider form Chantilly, VA. With nearly 20 years of experience in the EHS software industry, he is consistently trying to find ways to educate the market on the selection and implementation of EHS software. For more information about Spiramid’s global EHS solutions, visit www.spiramid.com.