Implementing Your Automated Compliance Management System
This article is the final of a three-part series, “Selecting an Automated Compliance Management Software Platform.”
Part I and Part II of this series have provided best practice guidance for the preparation and selection of your compliance management system vendor. Once you have entered into a contract with your vendor, your final planning and implementation process begins. This article will guide you through some important practices to employ and roadblocks to avoid.
Throughout the implementation of your system, many people will contribute to the outcome. You will be doing a final review of the project scope, collaborating with your vendor on timelines, systems integration, and process workflows. You will be fine-tuning your system and training the organization. The success of the project is determined by the strength of the teams, setting realistic deadlines, ongoing communications, and being prepared for change.
Designate the Core Implementation Team
The core implementation team is comprised of a group of individuals that will be responsible for the day-to-day planning, testing, and hands-on implementation activities. This team requires additional time and resources necessary to work on the project, as well as the authority to make or coordinate decisions that affect the project.
A single person should be identified as the implementation team lead with a second person as a backup. This person is the project manager; communications between the customer and vendors should funnel directly through the team lead as a single point of contact.
Any vendors that are contributing to the system – including the primary platform vendor and the vendor of any other systems – should each have an implementation team of individuals. This includes a team lead for each vendor, as well as a secondary backup.
The implementation team, with the support of key stakeholders, needs to foster belief and trust in the project. Stakeholders should be involved regularly and provide organization-wide communication and updates. Your new system will be a game-changer. You want to ensure that the resulting project meets their needs and enables a corporate sense of ownership.
Unfortunately, many projects have cynics. You may encounter pushback from people who simply don’t like change and can roadblock progress and morale. Discreetly identify them and employ strategies to gain their support. For example, solicit opinions on some features relevant to making their jobs more efficient. Give credit for their suggestions and input. No matter what, don’t be guided away from your core requirements!
Your project scope with priorities identified create a phased implementation approach with clear milestones. Do not try to do everything at once. The phases of the implementation should be two-fold; the functionality should be phased, and the rollout to different areas should be phased. Clearly define the roles and responsibilities of the team members.
Fine-Tune Your System Processes
Although you have documented your requirements and perhaps done some initial process mapping based on your expectations, it’s still very common to make significant revisions with your vendor. The vendor has performed similar implementations (as no two are the same) and has a profound knowledge of what works best and why it works best. After reviewing the processes, more efficient paths to completion can help further streamline the system. This starts with workflow reviews to ensure you’ve captured essential steps and minimized unnecessary steps.
Existing processes/workflows: Clearly document the existing processes/workflows, document any changes that will happen as a result of migration to the new system:
- Document the normal flow as well as all exceptions.
- Include roles and approvals (assignee, reviewer, approver, etc.). Include desired escalations and notifications. Include all permissions.
- Be aware of “hidden” process steps – the things that the users do that are not captured by any existing process documentation. Create a formal process step.
New processes/workflows: Using the same approach, document:
- New workflows and exceptions.
- Key data and its origins.
- Roles and approvals.
- Security/permissions (who can add/edit/view/delete the record).
- The timing of the processes (due dates, milestones, etc.).
- Desired notifications and escalations.
Utilize your vendor’s extensive experience as an enhancement to your work, not a criticism. They are versed in best practices and have a vested interest in the success of your compliance management system.
Scoping Integration & Data Migration
Successful integration requires an understanding of the role of each system; the data required, and the required messaging/exchange between them. Your vendor will help where needed to holistically visualize and document requirements for all data exchange. Never underestimate the effort to move vast amounts of data.
Some requirements to consider for migration (and ongoing operation) include:
- Single direction vs. bi-directional communications
- What communication protocols are supported by each system
- Protocols you will use for the integration
- Identifying who is responsible for interacting with each system
- Required adjustments to achieve the right inputs/outputs
- Who is responsible for getting the data collected and prepared for import
Implementation: Controlling Scope and Managing Change
Throughout the implementation process, it is vital to stay within your scope. You have outlined your work breakdown structure in your product scope and project scope. As you begin your implementation, focus on those parameters to avoid scope creep.
Scope creep is adding any functions, features, or work that is beyond the agreed-upon scope. Scope creep occurs for many reasons including:
- Allowing unmanaged contact between non-designated team leads
- Trying to squeeze in features that are “nice to have”
- Beginning design and development before doing a thorough risk assessment, requirements analysis, and cost-benefit analysis.
- “DIY” programming not approved in the scope
- Additional requests from shareholders who may not understand the complexity of the implementation
It is almost impossible to prevent any scope creep. Scope changes or feature changes will impact the schedule. When it happens, focus on the highest-priority items that make the most sense in terms of what needs to be accomplished now. Table other useful ideas or future requirements for a subsequent project or else risk getting far off track and budget.
Most importantly, implement a change management process to document significant deviations from the planned solution. Formalizing changes will ensure that there is a record of why something has changed and who was involved in the decision to change it. Some customers use a more formalized Change Board – where all must agree on significant changes before implementing them. Change Board approvals can be routed through an automated change management solution.
The first step in testing is to create test plans. Ideally, test plans are made before any part of the system is implemented. The goal is to test individual features of the system to ensure that the desired results are achieved. Multiple types of testing should be included in the test plans, including:
- Unit Testing: ensure that each item behaves as expected. Click on every button, link, menu option, field, etc.
- Assignments: Make sure records are assigned to the correct person and approvals are requested from the right people.
- Permissions: Ensure that users are prevented from doing the things they aren’t allowed to do and that they have the necessary privileges to do what they need to do.
- Notifications: Test that the messages are correct and delivered to the right recipients. Be aware of how many notifications are being delivered throughout the processes – adjust if there are too many or not enough.
- End-to-End Testing: Run simple through complex situational tests to ensure that each process works as expected from start to finish.
Consider testing with different audiences. The core team will become familiar with the system and will know how to interact with it. Testing with sample audiences that are not familiar with the system will provide insight into what works, what may be lacking in on-screen instruction, missing in testing, or causing them to get “stuck”.
All work should be performed in a development environment, and then promoted to a test or QA environment. Only when features have been thoroughly tested and declared operational should they be moved into the production environment.
The development and test environments should be as close as possible to the production environment. Each environment should be backed-up regularly.
If a training management system has not been purchased to integrate with the compliance management system, it’s not too late. First, training tasks can be automatically launched based on events in other software systems. Second, associated training activities are systematically managed and recorded and can be tracked in dashboards that indicate progress, trends, and late tasks. Third and finally, control and visibility keep your company efficient and compliant with regulatory requirements.
Training requirements will vary by role, therefore training courses and materials should be tailored to each like-group of roles. Consider who will need early training in order to test the system properly, and who will only need training once all development has been completed.
To help with enterprise-wide training content, poll early test users that can elaborate on what content might best benefit each user group. However, a common shortfall is training too early. Don’t leave a significant gap in time between training and go-live. Leaving ample space in time can later burden your support resources. Without being able to put knowledge into immediate use, a knowledge gap commonly develops. To help with these gaps, prepare and update training documentation throughout the process.
It may seem obvious, but make sure to test everything and train everyone before trying to go live with any part of the system.
Limit the number of users at first, if possible, to learn from them what gaps may still remain in functionality, permissions, notification, documentation, and/or training. For example, consider rolling out to one location first, starting with power users in one department. A more controlled rollout with clearly defined checkpoints will keep you aligned with your team, your vendor, your stakeholders, and system users.
A successful software implementation is an art form—not only do the technical pieces need to be in place and thoroughly tested, users trained, etc., but an air of excitement must be cultivated to improve adoption of the new system. Despite the best-laid plans, prepare for changes. Managing change is critical from the outset of the project and throughout the life of your compliance management system. An implementation of this size and scope can be challenging, but the advantages of an automated compliance ecosystem is a rewarding end game.