10 Things You Need to Know About Process and System Transformation
Throughout my 20-year career in finance at Fortune 500 companies, I gained extensive experience participating in system implementations or process changes. Usually, I was responsible for providing finance function requirements, verifying the corresponding functionality met my expectations, and promoting utilization within the team.
A few years ago, I took over leading a pricing system implementation project to systematize our company’s rebate calculations and create visibility into approximately $1B of gross-to-net spend. This was my first time leading a project where I was not a subject matter expert. As I reflect on the following year and a half, I have created a list of the top lessons I learned through the implementation.
- Consider if the software implementation project should happen now, or if there should be a simplification or process change first to prepare the business.
Looking back on our rebate implementation, we created requirements to systematize ALL rebates, regardless of complexity or coverage. We would have saved money, time, and stress by spending time renegotiating contracts for as many common rebate calculations as possible before starting the project.
- Getting the requirements right is everything. Execution will not matter if the requirements are wrong.
You will have multiple iterations of requirements. As you go through the requirements gathering process, refine the details. You will never get them perfect, and the tradeoff will be if they are good enough for the implementation team to use, while balancing the risks of rework. Beware of requirements that are assumed to be included by the business team – they may assume the implementation team has a baseline of knowledge like their own.
We collaborated with the business team on defining the requirements for system reports. Even though we had made mock-ups and received approval that the reports contained all necessary information, we found out later that valuable information was absent. This led to a big adjustment in the system settings to include the missing information. It is a good idea to ask the business team to specify how they plan to use a report or feature when you are making a mock-up, to avoid such issues.
- Incorporate enough time for user acceptance testing and rework.
The team will find issues as they go through acceptance testing. Some of these items will be problems due to the integration team not fully understanding the requirements, and some will stem from incomplete requirements. Make sure your project plan includes additional time to account for any problems the team finds.
- Know how you will manage change.
Requirements will change, the project will take longer, and cost more than you were expecting. When new requirements are suggested, distinguish between “must-haves” and “nice-to-haves” and prioritize them accordingly. Have a process in place to communicate requirement priorities, timelines, and budget changes. We all like to think that we have the right stakeholders, the right requirements, the right budget, and timeline, and that the risks identified will not materialize. They will, so prepare early for how you will deal with them.
- Ensure buy-in and have a clear definition of roles and time requirements.
You will need an executive sponsor who can communicate goals and overcome resistance from other senior executives. Make sure your business team and subject matter experts are bought in and prepared to spend appropriate time on the project. They are often juggling multiple priorities, which can make it difficult to get them to devote time to requirements gathering and end user testing. Prepare them in advance for what will be needed from their teams.
- Communication is critical.
Set up ongoing meetings with the project leadership and key stakeholders to ensure everyone knows how the project is progressing. Use the ‘update’ meetings for questions or clarification that you need. Remember, you can never overcommunicate!
Do not forget about your end-users who are not necessarily involved in the day-to-day requirements gathering and testing. Periodically show them what is being built – if they can see what new features will be available to them, it increases excitement and momentum of the project. They may even find additional value cases the initial team had not thought of.
- Tie out your system data, make sure you can filter it correctly to system of record.
Complete data integration testing as early as possible to ensure that what is coming through is complete and accurate. Have an ongoing process to validate that nothing is being missed or not transferred. The team will have more confidence in the tool if they know the data it’s using is complete and correct.
- Include end-users in the creation of new processes.
To ensure team buy-in, involve them in the creation process. First, outline the current process and provide a broad overview of the new one. This will allow them to collaborate on the details and take ownership of the process.
- Find & celebrate the wins.
Software implementation can feel like a never-ending slog of requirements refinement, testing, enhancement requests, and reprioritizations interspersed with crises. Focus on milestones and make sure the team takes time to celebrate them.
- Pick the right partners.
Find a partner who has experience in your industry and software. They can use their knowledge to identify “assumed” requirements, mitigate risks, and facilitate communication among teams. Be cautious of partners who promise they can do everything, or that come in with exceptionally low quotes – you will end up paying more eventually.
At Profit Drivers, we use our expertise as practitioners to help you avoid mistakes and save time and money on projects. Follow the link to contact us for a complimentary consultation: https://profitdrivers.com/contact/.
