I have delivered more than 20 software implementations focused on Governance, Risk and Compliance, and a typical one took three to six months. The clearest sign a project would succeed was how much time the customer spent testing the software before go-live.
These were the stages of each project:
1. Before kick-off
Understanding the project:
- What does the statement of work say, and is it a custom project?
- Who is the customer, and have I worked with them before?
- What are the notes from the sales team?
- Is the project budget reasonable?
2. Kick-off
Meet and greet with the customer, establish good rapport and understand project roles. The questions I asked:
- Who is the team that will be implementing the software, and have they implemented software before?
- Is it all a manual process today?
- Do the project timelines work for them? Any vacations or deadlines?
- What meeting cadence works?
- Is the implementing team happy with the purchase decision, or was it a different team who bought the software? Were there any grievances during the sales cycle?
That last question is easy to skip, but a team that was not part of the purchase decision usually needs more support, especially in testing.
3. System overview
From the sales demo and any custom demos, I established a baseline of what the software looks like out of the box. The goal was to understand what was missing and what questions the customer raised:
- Does the application workflow look similar to their current process?
- Do they have any data right now, and are they expecting to move it into the system?
4. Requirements gathering
This is the bulk of the project. I met the customer each week, going through the application slowly and establishing what worked and what didn’t. All of the changes went into a tracker with time estimates. After a few sessions, we walked through all the changes and got sign-off. Then I reviewed the project hours and budget, and flagged any big requests that could disrupt the project later on.
When projects slipped, it was usually because instead of migrating from their manual or existing system, the customer would see the possibilities of a new workflow and process improvements, and want to push for changes.
At this point, new custom feature requests could come in. The options were:
- See if the change can be done with a workaround.
- Scope out the change and consult with the project manager, consulting manager or sales to see if a change order should be issued.
- If the request is beyond what the system is capable of, raise a feature request and provide alternative workarounds.
Choosing between a workaround and a change order depended on the scope of the change and whether the project was at risk.
5. Build and training
I configured the system, built and iterated, and did show-and-tell mini demos. I also started thinking about user permissions, data upload needs, custom reports and integrations.
After final sign-off, I did a final demo with the smaller implementation team, or a wider demo depending on the customer’s needs. I made sure to record it and create training guides.
6. User acceptance testing (UAT)
This was the most important part of the project: getting the customer to test and validate their requirements. I thoroughly tested what was configured, but the customer needed to test it too, to make sure the software met their business needs.
To help them, I provided best practice test scripts, gave them guidance on how to test and scheduled a walkthrough.
Lots of engagement here was a good sign, and more hours spent testing was an indication of project success. Low engagement usually meant a heavy support load after go-live. Team changes during testing were a project risk too.
7. Go-live
I picked a suitable date and deployed the software, ideally ahead of any reporting cycles, and watched for maintenance windows. I worked with the customer on what worked for them. I found midweek was best, so there was business support the next day.
8. Post-live support
Depending on your company’s practices, it helps to have the implementation team stay on for some extra support while the customer starts using the software. This is a delicate period, as the customer moves from the consulting team to the customer success and support teams. Good hand-off notes that flag what went well and what didn’t make a big difference to the customer’s long-term success.
What it taught me about risk and compliance
Implementations also taught me what an organization should think about before setting up risk and compliance in a new system:
- Preparing your risk registers and controls in one central place.
- How your organization structure relates to your assessment reporting periods.
- Which reports are critical to your risk and control assessments.
And during the project:
- Include the people who will use the software every day in testing.
- Block time in your calendar for testing before it starts.
- Tell the implementation team early about any team changes or vacations.
Final thoughts
Every implementation was different, but the projects that went well had a customer team that stayed engaged from kick-off all the way through testing.
My advice for a new implementation consultant in their first week: really understand the system fully, understand the customer requests deeply and always give options.
I wrote more about how I think about risk in 6 risk questions I use for big life decisions.