Major systems implementations can have significant impacts on the success of an organization and its employees, vendors and customers. If done well, the project can improve transaction speed and accuracy, can elevate customer service, strengthen controls and add value. In previous parts of this series, we discussed the early phase of an implementation project up through the implementation plan. In part five, we turn our focus to the execution of the implementation plan. Every implementation plan is different. This article will provide an overview of some common steps in the execution process and will identify some areas that may have hidden surprises.
If you missed any of the previous parts, they are available on my blog: Not for Profit Beyond the Numbers
Expect the Unexpected, AKA, Be Prepared, Be Flexible
This is the most important rule of execution. A well thought out implementation plan is your map to completing the tasks necessary to bring your new system into use. However, there will be surprises and challenges along the way. It is impossible to consider every potential issue that will impact your plan, so you will need to accept and integrate any unforeseen event. With a solid plan, you will be able to quickly estimate impacts, make course corrections and deal with problems. You must expect that there will be problems and be confident that your team will be able to handle them. So, be prepared with a solid plan and be flexible by integrating new information into your plan without altering the outcome.
Very early in the plan execution process, you will need to hold a project kick-off meeting. The purpose of the meeting is to review the plan with key participants and establish the project team roles and responsibilities.
Agenda items for the Kick-off meeting include;
- Overview of the project charter, purpose and desired outcome
- Identify members of the steering committee and key staff resources
- Introduce Project Manager and discuss role and responsibilities
- Introduce any external team members (consultants, etc.)
- Establish feedback paths if project team leaders are not direct managers of staff
- Project Plan overview, including timing of go-live and any other significant milestones
- Discuss the communication plan internal to the group
- Message from the project sponsor encouraging teamwork, patience, communication and commitment
The steering committee should meet with the project manager on a regular basis to discuss progress on the plan, as well as, any issues that have arisen and change control items. The project manager typically runs this meeting and compiles an update report capturing any action items. Frequency of updates may change over the execution of the plan. The committee may want weekly meetings to start and move to meetings twice-a-week, as go-live approaches.
A critical part of the status update meetings is change control. This is the process used to discuss any significant changes to requirements or to the execution plan itself. As we will discuss in more detail later, your team will uncover issues during the implementation that can impact the timing or order of plan items. Some changes can impact the project so significantly that the project team will need to make decisions as to whether or not the change is absolutely necessary. These items may be moved to a later phase or an alternative may need to be found.
In an integrated enterprise level project, changes can easily impact many functions. Therefore, requests for changes to the plan or requirements should include an impact assessment to all components of the project functions.
Topics That Could Derail Your Plan Execution
No amount of implementation planning will produce the perfect plan. You will always learn something along the way that will impact your execution plan in some way. The following are some of the issues that tend to cause issues during implementation. Discuss these topics with the steering committee and project manager while building the project plan, but don’t be surprised if they pop up again later.
Where better to start than the end? Be sure to have a good discussion on exactly what your proposed go-live date really means. January 1 or the first day of your fiscal calendar are favorites for go-live, but how often does payroll actually start on January 1? Seldom. So, you are going to need to go-live on payroll processing before your Jan 1 target. Same holds if you want to integrate employee benefits enrollment data, so be sure to involve your HR folks when setting your go-live.
Most processes, like AP, can be shifted around a go-live date, but some cannot. Your steering committee should walk through the major and minor functions and processes and make sure that your go-live date is really what you think it is. You should know which functions which will have a harder time reacting to a slip or acceleration in their go-live date.
Customization Versus Configuration
No system is going to work exactly the way you want it to for every process and transaction. With your team’s help, the system will be configured to set it up as close as possible to your needs. Some processes or transactions will not align to your expectations. You have two options. You can change your process or customize the system.
Some systems are expected to have heavy customization, while others, especially Software As A Solution basically forbid customization. How you address this is a function of the system you have procured and the time and effort you expect to put in for ongoing maintenance and upkeep. Customization normally increases the cost and effort to maintain the system, so be very careful when choosing to change the system to match your process.
Legacy Data Conversion
Once the system is configured for use, you will need to enter your legacy master data. (Master data being general information like customer, employee or vendor data.) There are two ways to do this. You can run and automated conversion process or you can re-enter the data manually. Either choice has its challenges, so you should have discussions on this topic early in the process. You may decide to convert some data electronically and some manual.
Keep in mind that you will need to maintain historical transactional records for audit purposes, so you will need to decide how to do that. Some contracts have invoicing requirements that include displaying project-to-date costs, so that the system will need to capture that information. Also consider aging reports for accounts receivable. Review your grants and other agreements for record retention requirements.
The system will not process every transaction exactly as the legacy system did. You will likely need to massage some of your processes to match the new system. This is an area that often leads to customization requests. You should establish early in the process, preferably before the kick-off, a policy that customization will only be considered as a last resort. Again, unless you are working with a system that is easily customizable and are willing to live with the associated challenges.
As you continue with the execution of your plan, your system software is likely to continue to develop. Software typically follows a release schedule which can be fairly certain or not so fairly certain. Know which situation you are in and plan accordingly. Your consultants should be able to give you confidence on the system provider’s track record on releases. This is also something you can discuss with other customers that use the system.
As version releases tend to delay, you may find yourself with a difficult decision to make. Do you implement a fully vetted and stable version, that is missing some new functionality which will require an upgrade soon after your implementation. Or do you implement an version not fully vetted and risk software bugs impacting your implementation plan. Prepare a backup plan, in case the version you are planning on implementing is not available or is not fully tested on your go-live date.
For a Software as a Service system, question your vendor about system availability, access security, and data protection. Have your IT folks or an outside consultant assess system access, backups, disaster recovery processes and conduct penetration testing on the system. As an outsources service provider, the vendor should have a system audit conducted and SSAE/SOC reports available. You and your IT folks should review these reports and understand any issues and mitigations.
Pilots and Training
Testing the system is a critical step in the execution plan and there are many alternatives. Spend time with your consultants identifying how you will handle pilots, testing and training. This is often put off until midway through the plan and can cause problems due to scheduling conflicts and availability of participants.
Every system has to interact with other systems. These connection points are interfaces. They can be a particularly challenging issue because when they are working properly everyone forgets about them. When you are in the middle of your execution plan, you will likely stumble across an interface or two or several that you didn’t think about. Interfaces are also challenging because every system that you want to connect with has a different interface process. The data can move in one way or it can move in both ways. It can be checked, verified and or can generate exceptions, for your system to interpret.
Communications Plan – Updated to org
Your execution plan should include a communications plan. This should include information to employees, vendors, customers and other stakeholders. There should be updates at points along the duration of the project. Often, when the project picks up speed, the communication process suffers and information about the project slows down. Be mindful that staff members and stakeholders who are not part of the project team may interpret this slowdown of data to be an indicator of issues with the project. Make sure that no matter how busy the project gets, the flow of information via the communication plan continues.
The system’s capacity for producing reports is the ultimate chicken and egg issue for any systems project. The system will come with standard reports which almost never match the organization’s particular requirements. The system will also likely have some type of reporting tool for creating non-standard reports. Of course testing all of these reports requires data in the system and data is not normally entering until the end of the project. Reporting nearly always becomes the first focus after go-live. You can be proactive and ensure that you have staff members trained on the report writing tool associated with your system. Also, maintain a prioritized list of reports for the consultants to configure during the project.
Maintaining Focus When Trouble Strikes, Sustaining Momentum
One issue that can devastate an execution plan is a lack of focus when unforeseen problems occur. Major systems projects require momentum if they are to be successful and can be adversely effected by a loss of inertia.
Work the issue together as a team and set some boundaries for the length of time you will spend on a solution. When issues happen, and they will, it is important to stay focused on the execution plan. Take steps to resolve the problem as quickly as possible. Do not allow the project to go off track. The issue may seem unsurmountable at first, but that is unlikely. Work with your consultants, system representatives and reach out to other system users to see if anyone else had a similar issue. Above all, do not look to place blame or spend time reconsidering decisions already made.
Once you find a solution to the issue, review and adjust the execution plan, as necessary. Accelerate other tasks while working on the problem. Remember that a good project plan will have reserves for unplanned issues. So, there is no need for panic. Discuss the issue and resolution with the senior team and update your communications plan.
Execution of the plan is one of the last steps in surviving a major system implementation with your team and your sanity intact. Hold a kick off meeting to get your team engaged and aligned with the plan. Take time early in the project to explore the topics that can negatively impact your project. Expect challenges as the team works through the plan steps. When issues occur, work together to address them without derailing the project. Communicate progress on the project to your organization regularly. Be prepared, stick to your plan, but be flexible and stay focused.
In the next (and last) part of this series we will discuss the steps just prior to go-live and after.
Check out previous parts in this series…
Four – Implementation Planning
Please share your thoughts on this topic in the comments section.
For more information on this or other NFP Leadership topics, follow me or connect on LinkedIn and check my blog, Not for Profit Beyond the Numbers, each week for new content.
1 thought on “Surviving a Major System Implementation, Part 5 – Execution”
Good morning Mike,
This entire series has been exceptionally informative. The only thing I would add to this with regard to ‘Change Control’ / ‘Process Reengineering’ is to document, document, and then document some more. Perhaps it’s implied and considered common sense (but we both know that’s not so common). I’ve been through a couple of these now and each time not enough documentation existed as to exactly what changes were made, where/how they were made, why they were made, and finally any dependencies related to the change (any snow ball effect it may have had on any other critical areas).
I feel it’s imperative this be a mandatory element to any system implementation. I’ve personally experienced situations where many key people on the implementation team leave the company and all of their corporate knowledge goes out the door with them. The next team is left to try and figure out what changes were made and what the rationale was for making them.
With regard to ‘Process Reengineering’ – yes, yes and yes. I almost think you could write an entire article on just this alone. Getting into the weeds – one consideration that comes to mind are decisions related to using any areas or specific fields within a system NOT as they were intended. This is something that often happens when, as you’ve described, you have a system that doesn’t conform 100% to an organization’s processes and isn’t customizable so decision makers choose to use fields or areas for things they weren’t meant to. This typically causes a major domino effect across the entire system – especially when it comes to reporting and billing. Something as simple as using a ‘Name’ field incorrectly can throw everything off; not to mention the effect these things have on future versions/upgrades of the system. These decisions should not be taken lightly and as you stated – as a LAST resort.
So document, document, document – at a granular level – to ensure all those coming behind you have a complete picture of the system and its limitations/improvements. Finally, this kind of documentation will also help with any training manuals for all the actual users of the system.
Thanks again Mike, this series is a MUST READ!
Comments are closed.