Phases of a Digital Solutions Project

A project to select, configure, and implement a new digital tool can be a long and complex process. A general understanding of the process of implementing these projects can help staff that do not have an IT background (such as environmental or health and safety personnel helping to support selection and implementation of a software tool) understand the steps of the process. This article describes a general or best practice approach to digital solution projects. For specific cases, there may be good reasons to deviate from these steps or approach them in a different order.

1) Determine Need – Being able to clearly define the need for a new software tool is the first step. Some examples could include replacing an existing system that can no longer be supported or lacks key features or implementing an entirely new tool where no robust digital solution currently exists. When the need is not replacing an existing system, clearly understanding what goals you are trying to achieve and what business processes the software should support is key. For example, the goal could be to streamline a manual process that is prone to errors – you might determine that this software should support an environmental compliance calendar, including routine tasks and alerting someone when a due date is approaching or if a task deadline is missed.

2) Define Requirements – Requirements are more granular and specific statements of what the software should do. Requirements are important because if the system design and configuration meets the requirements, then the project is considered successful by IT standards. Requirements form the basis of robust system selection, as systems that cannot meet critical requirement should not be selected for a project. Here are a few tips for defining strong software requirements:

• Work with a variety of stakeholders – not just IT, administrators, or end users; make sure all stakeholders are represented in the requirements gathering team.

• Select the correct-sized group – if groups are too small they may miss requirements while groups that are too large may struggle to reach consensus and agree on requirements.

• Include IT for security/integration requirements – Company IT groups often have security requirements for all software. A system should not be selected that cannot support security requirements. If the system will integrate with other software, IT groups often build and manage these integrations and may have requirements around standard protocols the software should support.

Not following these best practices can result in unplanned costs due to missed requirements!

3) System Selection – Once requirements exist for the project, with each labeled as “must have” or “nice to have,” it is time to start developing a request for proposal.

• Target group of likely vendors – creating an RFP and responding to one takes significant time for both the company sending and reviewing the RFP and the vendor responding to it. For efficiency, it is best to target specific vendors that are likely to be able to meet the requirements. To identify this group, you could contact a consultant familiar with digital tools such as ALL4’s Digital Solutions Practice or review impartial third parties’ descriptions of different software capabilities.

• Format requirements to maximize success – Asking if something can be done in a configurable, off the shelf solution may cause a software vendor to say yes, but it can only be done with significant effort and customization, which may prove costly. This type of question and its answer are often misleading to the team selecting software. There are ways to write and format RFP questions to receive more helpful data from vendor responses.

• Have vendors demonstrate tool capabilities – Giving vendors a script they must follow when they demo their tools allows you to compare systems more evenly because they are all showing the same set of features. It also avoids the software vendor demonstrating only the strengths of their tool.

4) Design – After the software system is selected, detailed design begins. This takes the requirements that were previously designed and translates them into features and a configuration using the tools and features of the selected software. New requirements may also be uncovered during this process. Any gaps or situations where the requirements cannot be directly met by software features or configuration should be addressed with a gap closure or workaround.

5) Configuration – Depending on the level of configurability of the software and how close the requirements aligned with the tool out of the box, this can be very minimal or very involved.

6) Load Your Content (if applicable) – This step can be minimal for certain types of tools (for example, event reporting) or a very high effort for others (environmental compliance tasking based on regulatory requirements or air emissions calculations).

7) User Acceptance Testing – This step involves testing of configuration and content to confirm everything works as expected, followed by configuration and content adjustments to correct anything found to be defective. User Acceptance Testing (or UAT) is the user’s chance to validate that the delivered product meets the project requirements.

8) Go Live– In order to prepare for Go Live, configuration and content must be put into the digital tool’s production environment, where end users will access it. Users must be given user accounts and any features such as Single Sign On must be turned on. Once all of these tasks have happened, the system is live.

9) Training of End Users – Once the tool is ready for end users, clear communication and training is needed to ensure that end users start using the tool. Although this step happens at the end of the process and can be overlooked, it is critical to increase user adoption of a tool that the company may have spent years selecting, configuring, and preparing to use.

10) Ongoing Maintenance and Support – This could take the form of periodic enhancements, such as adding new fields or reports, or evergreening system content to reflect new regulations, updated permits, etc. It could also take the form of updating system integrations as the software the systems are integrated with change to keep data moving in and out of the system.

The ALL4 Digital Solutions team has experience supporting every step of this process from determining a need to ongoing maintenance and support. We have helped clients implement tools from simple compliance calendars or data dashboards to comprehensive multimedia environmental and safety information and compliance management systems. If you want to learn more about how digital tools can fulfill your information or compliance management needs and what tools might best meet your requirements, please contact Julie Taccino at jtaccino@all4inc.com or 281-201-1247.