A successful Costpoint implementation isn’t defined by whether the system is live. It’s defined by whether the business is truly ready to operate within it. That means processes are working, data is reliable, users are confident, and the organization can execute day-to-day operations without disruption.
In this article, we’ll challenge the common perception of go-live and highlight what it should be: a transition into a fully functioning, compliant, and reliable operating environment.
What Go-Live Should Mean in Deltek Costpoint
At go-live, a system should be properly configured and ready for use. The system should be fully tested, with processes designed and documented. Personnel should be trained in data entry and system processing. Management should understand how the system supports compliance with government contracting requirements. Go-live should mark the point at which day-to-day transactions begin in the new system. Employees should start entering their timesheets into the system daily, and the focus should shift from checking the system to using the system.
What Operational Readiness Should Look Like
When we say, “ready for use,” what do we mean? First, we mean that standard processing should run smoothly. For example, timesheets can be entered without errors. Vendor invoices can be recorded without issue. Expense reports can be processed, and when the time comes, customer bills can be created, revenue captured, and financial reports prepared. It means the processes the system is designed to perform are ready to go, and any activities outside the system are minimized and clearly documented.
Second, it should also mean that the data entered prior to go-live is ready to be used within the new system. Historical data already migrated into the new system should have been verified and reconciled. We need to ensure it not only ties to the prior system but also that the Costpoint subledgers and general/project ledgers are in sync. There is always data that must be migrated after go-live, which we will discuss shortly, but to ensure operational readiness at go live, data that has already been migrated needs to be confirmed.
Lastly, users need to feel comfortable and trust the new system. There will always be apprehension and uncertainty at go-live, but users should be comfortable with their areas and understand how and why they are doing steps and/or processes. Project managers should have confidence in the project reports and project-related processes (e.g., billing, revenue, ceilings, etc.). And of course, accounting should be able to close the month and trust the resulting financials.
- Clean and balanced trial balance
- Reliable processes and financials
- Accurate project reporting
- Minimal manual workarounds
What Happens AFTER Go Live
Operational readiness at go-live does not mean every migration task is complete. There are two main things that need to be addressed after go-live. First, there is always final data that needs to be migrated to the new system and having a plan to get that data in quickly and accurately should not be ignored. Second, there are many firsts that need to be managed. No matter how much testing and training are completed, there is nothing like the first time something is completed in a production or live environment. Planning and supporting those firsts should not be ignored.
Now you might be asking, “But what would I still need to migrate?” Hopefully, most of the history has already been migrated, especially if you are migrating during a fiscal year. But even if you are going live at the start of a new fiscal year, there is still data that is not available until after go-live and will need to be migrated, verified and reconciled. Having a plan for these final balances is critical so you don't miss data or struggle to reconcile at month-end. You should have tested data mappings, set cut-off dates, assigned who will provide, enter, and review the data for each area or data item.
Any final balances or open transactions that remain outstanding should have an assigned owner and a scheduled migration date. That schedule should reflect when the information is needed for payroll, billing, revenue processing, or month-end close. Each process should have the data it requires loaded, verified, and reconciled before it is completed.
Below is an example of some of the data that is usually migrated after go-live:
- General Ledger Beginning Balances
- Subledger Beginning Balances
- Project Beginning Balances
- Leave Beginning balances
- Open Accounts Payable
- Open Accounts Receivable
- Open Purchase Orders
Now let’s talk about all the firsts we mentioned earlier. Regardless of how much testing is done, processing something in the new system for the first time will be bumpy. As much as you can work on discovery, when processing occurs in the normal course of business, new issues pop up or special cases arise. When that happens during the first time a process is being completed in a live environment, it can cause delays or even panic. Also, it is not just the first-time processing data, but also the first time a new major data item is created. Having support in place and ready can prevent any minor hiccups from becoming major roadblocks.
Below are some of the firsts to keep in mind:
- First Accounts Payable Payments
- First Labor, Leave and Payroll Processing
- First Customer Billings Cycle
- First Revenue Recognition
- First Month-End Close
- First Fiscal Year-End Close
- First New Employee Setup
- First New Project Setup
What Could Go Wrong
You cannot plan for everything, but the more you can plan for potential issues, the better prepared you will be to overcome them. Below are some that we have seen while helping clients navigate Costpoint Implementations and proactive approaches we recommend:
- Implementation Team Members Leave or Change Positions
- Ownership of Processes was Not Defined and/or Enforced
- Users Revert to Prior Processes or Routines
- Data Changes AFTER Migration
Implementation Team Members Leave or Change Positions
It is a fact of business that staff come and go, people change positions, and knowledge transfer is a constant requirement. This can be especially problematic when you have just gone live on a new system. If the key person for a specific area leaves just as go-live happens, or just after, it can leave a major knowledge gap, and processing can come to a halt. Combatting this issue needs to begin long before go-live. It is important to ensure that configuration knowledge and processing procedures are well shared before the system is in use. As you move towards go-live, begin including more users in the testing area. Make sure you maintain updated documentation for processes as they are finalized. Have key implementation users begin training internal resources; have the trainee become the trainer. Spreading knowledge well before go-live and even after, is the best way to ensure the loss of one individual does not derail an area within your implementation or system.
Ownership of Processes was Not Defined and/or Enforced
It is vital that someone from your company owns each area during the discovery, design, configuration, testing, and training phases of an implementation process. Go-live is coming. People are only prepared if they participate and take ownership of their areas. If the key person for an area is unprepared at go-live due to a lack of earlier participation, this could have system-wide impacts. The ramifications of this could lead to major configuration changes and processing delays. For example, Rita oversees payroll but did not participate in implementation meetings. As a result, several key configurations may be missing or incorrect, affecting the accuracy and timely processing of payroll post go-live. Ensure that your personnel are available or have a reliable proxy that can make informed decisions through each phase of the implementation process. Even if they cannot participate throughout the entire process, they need to be involved in testing and training to help mitigate potential misses in the system design.
Users Revert to Prior Processes or Routines
Implementing a new ERP is a big change and is often met with resistance from end users. It is important that documented processes and training materials are available to personnel. The more comfortable people feel with the new system, the less likely they are to revert to prior processes and routines outside the Costpoint system. If people use processes outside of the system, there is now data outside of Costpoint that will inevitably need to be entered into the system. This missing data can cause processing delays and major reconciliation issues. Let’s revisit Rita from payroll. Because Rita did not participate during the implementation phases, she feels overwhelmed and unprepared for the first payroll run in the new system. As a result, Rita decides to run payroll outside of the system. People do get paid, but the payroll information is now missing from the new system. Ensuring that all key personnel participate during the implementation phases and using the “train the trainer” approach will help prepare personnel to feel confident with the new system processes.
Data Changes AFTER Migration
Data migrated to the new system should be as final as possible. If changes occur in a prior system but are not added to the new system, differences can be extremely difficult to identify and resolve. Changes happen, auditors instruct additional entries during year-end, errors are identified and resolved, but if these are not correctly reflected in the new system, the cascading effects can be catastrophic. Let’s return one last time to Rita. Rita provided data containing each employee's pay rates from the prior system. Then the annual pay raises for all employees were announced, and she entered them into the old system, but never updated the data in Costpoint. The company goes live with the old pay rates she provided, and now all labor costs are recorded at incorrect amounts, and expenses could be substantially understated. And if this error is not immediately recognized, it can not only be disastrous for your financials but also take an enormous amount of time to fix correctly. Reconciling and verifying data before, during, and immediately after go-live is imperative. Checking data early and often cannot be overstated. Junk in means junk out. Any changes to data in a prior system should be tightly controlled and clearly communicated to the implementation partner.
Moving from Implementation to Ongoing Operations
As we’ve discussed, go-live is not the end of the implementation process but just a transition point. At go-live, a system should be operationally ready, and your team should be adequately trained and comfortable with it, but there are still things to be completed before the implementation is over. You should have a plan for migrating the final data and support available to manage all the firsts that occur after go-live. Finally, you should have considered potential post go-live issues in advance and put plans in place to mitigate the most common problems companies experience. If these criteria cannot be met, then you might not really be ready for go-live and the next steps in your implementation.
The transition can be considered complete when required balances are reconciled, initial processing results have been reviewed, critical issues are resolved, and ownership of ongoing processes is confirmed. Any remaining items should have assigned owners and deadlines. Less frequent activities, such as the first fiscal year-end close, can have a separate support plan.
Redstone GGI assists government contractors with implementing Deltek Costpoint and recovering from problems after go-live. Our team assists companies whose data was not reconciled before live processing, whose employees lack the training needed to use the system effectively, or whose key team member leaves with much of the system knowledge. Through data reconciliation, user training, process documentation, and support for initial live processing, our consultants help teams address these issues and establish reliable processes for ongoing GovCon operations.
