4 Things to Consider When Planning a System Implementation Project


I am often asked, “how long will it take to implement our new solution?” My stock and somewhat disappointing answer is always – it depends. As with all system implementations, there are four factors that you need to assess to determine how long it will take to implement your core financial solution.


Time is always a key factor.  Sometimes there is an external event or executive decision that sets the date when you need to go live.  If there is not, I always suggest locking in a go live date that seems reasonable and then work with the other factors to determine if the timeline is reasonable.  Some key considerations when locking in a date: 

  • If possible, try to go live on a quarter end   By going live on a quarter end, it makes it a little easier on data conversion and reporting.   Also, if you are publicly traded company, this is especially true.   Publicly traded companies typically report their financials based on quarterly results.  By going live after the quarter, your CFO can report to the street their financial results in your legacy system and have three months after go live to assess the impact of the new system and the data conversion on reporting.  I often get asked about going live on year end – this is another popular option, but it is difficult to pull off.  For one, the calendar includes several major holidays.  In addition, finance and accounting tends to be quite busy at year end from a reporting and process perspective.  For these two reasons, I usually suggest avoiding year end. 
  • Think about your business cycle   Is there a busy season where most of your sales are occurring?  Is there a time when key stakeholders will be otherwise distracted and unavailable to participate?  Some examples are budgeting season, 1099 processing, and board meetings. 
  • Are there other competing projects that might vie for key resources’ time?   Does IT have other projects that are scheduled to go live at the same time?  Can you get external stakeholders time to participate in the project – such as integration with your bank.   By understanding all of the other organizational priorities, you can slot in your project in an appropriate time slot. 


You need to consider both project resources and other stakeholders. It is very difficult to cobble together a project team using parts of your team’s time.  You will need dedicated resources.  Before you think about using external consultants to help guide the project, you should understand the key project resources you will need for the project: 

  • You will need a steering committee to guide the project (typically key finance, IT and other executives). These are part time resources that not only guide the project, but resolve key issues and roadblocks. They are also typically the champions of the project rallying your company and preparing them for the change.
  • You will need a dedicated project manager.  This person should understand not only your business, but how to run a system implementation project. At times, there are two project managers on the project a business side project manager and a system side project manager.  The project manager coordinates the activities of all of the team members, manages the project plan and reports to the steering committee. 
  • You will need a solution architect. The solution architect may be the project manager and/or a key business analyst. The solution architect is the person that has a deep understanding of the business and also the software solution.  They can work easily with users, executives and developers. They typically have a strong understanding of accounting. They sit in the middle of all of the key decisions and help build a solution that takes into account organizational change, process design and system functionality.
  • You will need business analysts. The business analysts typically report to the solution architect and they help implement the solution. They will work on system configuration, report development, testing, training and documentation.  They also are often tapped to play a change management and communication role. If the project is big enough, you may need dedicated change management resources as well.
  • You will need developers.  Many cloud solutions today offer configuration options and user friendly business rule creation tools that don’t require a computer science degree. They do however require a system savvy person at the helm.  True developers may be needed to develop complex reports, build interfaces and assist with data conversion. Some solutions also provide a true development toolkit where you can create your own customizations. 


In addition to these core team members, you will also need assistance from the user community, IT, your help desk and any external entities such as banks, customers and vendors.  You will need to do an impact assessment to determine who needs to be impacted and what role they will play on the implementation.  Many times it is an exercise in informing them of the upcoming change, but other times it involves asking them to actively participate.  For example, you may want your banks to accept ACH payments or you may need your vendors to register in the new solution after go live. 

Once you have your project structure in place, you should determine what resources are available to work on the project in key roles.  As I mentioned earlier, asking people to do this project AND their full time job is a difficult ask.  It is also one of the main reasons why IT projects fail. You do need dedicated resources to assist you with the implementation.  Once you have filled in as many roles as possible with internal resources, you will be left with a list of roles and skills needed to fill out the rest of the project.  This will then drive a budget for external consultants. If the cost of the external resources + the opportunity cost of allocating internal resources (and their cost) to the project is too high, then you need to start playing with the other levers such as time, scope and risk to find the right balance of cost when compared to the other project management metrics. 


Risk is an interesting metric. It is also one that requires some experience to determine the risk level of your plan (time, resources and scope). I have worked with organizations that were very risk averse. One of my customers took eighteen months to implement PeopleSoft GL. The organization was large, however, the project moved very slowly and very deliberately. As a young consultant at the time, I was somewhat frustrated by the slow pace. Once we went live, the CFO gave a great speech at the celebration dinner basically stating that the project was not only a success, but a complete non-event - meaning we went live and there were no issues, zero impact and people didn’t even notice. He said this with a smile across his face. Although the project took a long time and cost a lot of money and internal resources, the fact that it went live without a hitch was the most important thing for this financial institution.

On the flip side, I have had customers tell me that they want to go live by this date. In these circumstances, I work with them on scope and resources; however, many times I cannot find the right balance between the three to go live with minimal risk. I then begin to talk with them about the concept of risk and plan out things that we can implement after go live - - conversion, reporting, certain functionality, certain regions. I call this the “rolling go live”. It is not my favorite approach as it often comes with risk and frustration in the short term. However, if the client wants a certain scope in a certain timeline, it is my job to let them know we can do it – but it will be bumpy!


The fourth lever is scope. Scope is something that is typically most easily adjusted to meet the desired resource, cost, time and risk levels. In a financial system implementation, here are some of the key scope design decisions. For each decision, you should determine a level of effort in man hours to complete each component:

  • Financial Data Model – this is really a key design decision and the first step in planning your project. It combines an understanding of historical data, system capabilities and reporting needs (operational, management, financial, and external). What does your account structure look like? What dimensions do you need? When will the account and dimensions be used? What business rules are associated with the dimensions? What workflow drives off the dimensions? These are all key questions that go into project scope.
  • Functionality – this is really understanding what parts of the system you want to implement. Some organizations decide to go big-bang while others might start with the basics and then roll out functionality over time. Both options have their pros and cons and will have a direct impact on time, risk and resources/cost. This is an area with tremendous flexibility when planning your project.
  • Users – this is understanding who will be using the system on go live? Is it just the core financial user? Do others need to use the system on day one to enter purchase requisitions, time sheets, expense reports, run reports, and approve transactions? Do external entities such as vendors, customers, and sub-contractors need access? By adjusting the functionality and footprint, you can greatly alter the scope of your project.
  • Interfaces – how many systems does the new solution need to interface with on day one. You should build a solution map with your new financial solution in the middle and then add systems that interact with the new solution as points that circle around it – like planets to a sun. For each solution, you should understand the information and process flow between the systems. Many times a business process will hop across multiple systems. In order to make the process seamless, you should develop a plan to determine which systems are automated and which ones will be semi-automated (e.g. spreadsheet upload) or manual. You should also think about data ownership. In addition to transactions these systems will share data – such as vendors and customers. Which system owns the data on add and update? By mapping out these interface and data models, you will understand your scope.
  • Conversion– data conversion is always a tricky subject. Data conversion takes time. It requires significant understanding of how the old system processed data and how the new system processes data. The other simple reality is that your old system has wonky data. Trust me, it does. Someone at some point in time put in an invalid transaction, or your system has a bug that creates an anomaly, or someone had to do a mass data correction to get your reports to work correctly, but did not follow the exact business rules of your system. This makes data conversion cumbersome. It takes time to unearth these oddities and assess the impact. When I first bring up the concept of data conversion, most CFOs say – we want it all. That is fine, however, there is a cost. We usually start there and then try to find a happy medium. There are generally three types of data you need to consider converting. First, there is trial balance data. A good rule of thumb is three years of historical TB data rolled up by Year, Period, Account and other key dimensions. So you won’t see individual transactions but the sum of the transactions (Hint – if you have multiple entities this is even a little more complex when you take into account exchange rates, intercompany transactions, eliminations and CTA). This usually provides more than enough data to run historical financial reports. Remember your account structure and financial data model will be changing so this is typically not a one to one mapping. Second, there is reference data or entity data. This tends to be customers, vendors, accounting, items, dimensions, etc. The typical rule of thumb is to convert only the active ones that are needed going forward. This sounds great, but you may need to convert old values to support your TB and transactional data conversion. Lastly, you will need to convert transactions. The best practice is to only convert the open transactions whenever possible (and to close as many of these as possible prior to conversion). In theory, the GL impact of the transactions is in the GL – there should not be a need to convert closed transactions. It is just too hard (see wonky data comment). You are better off converting the open transactions such as vendor bills, receivables, billing schedule, installment bills, revenue recognition schedules, and expense reports. Even converting open transactions can take time and requires a large amount of reconciliation effort. By limiting data conversion to what is essential, you can greatly reduce time, cost and risk.

Bringing It All Together

After determining the four levers, you now have the basis for a plan to take to the steering committee. Be prepared for pushback. They will probably not be pleased with one or more components. It may cost too much or be too long to implement. It may not have the impact that we wanted because of the scope selected. This is normal. You can then work with them because you have documented all of the facts above and can adjust any one lever and understand the impact on the other three. By having all of this mapped out before you start the project, you can come to the table with well thought out data points and allow your team to make an informed decision.


How to Integrate CECL with CCAR and DFAST, Part 2
5 Steps to Prepare Your Organization for the End of LIBOR
Related Posts
Is It Time for Business Leaders to Move Away from Excel?
Is It Time for Business Leaders to Move Away from Excel?
Strengthen Your Cybersecurity Posture with RPA
Strengthen Your Cybersecurity Posture with RPA
Benefits of an RPA Strategy that Considers Cybersecurity
Benefits of an RPA Strategy that Considers Cybersecurity