Implementing a new information system is a multivariate project that requires strategic planning, clear project goals, and an organizational culture that can evolve with the technology.

Whether it’s a core financial solution, a Human Resource Information System (HRIS), or another type of critical business software, an implementation plan is the key ingredient influencing success.

With all system implementations, there are four overarching factors you need to assess to determine how long – and how effectively – it will take to implement your new technology system.

  1. Time.
  2. Resources.
  3. Risk.
  4. Scope.

Underneath these factors, there are additional considerations to keep in mind, which we’ll explore.

1. Time

An external event or executive decision typically sets the date when you need to go live. If this isn’t the case at your company, lock in a go-live date that seems reasonable amid the other variables on your list. When locking in a date, consider: 

  • If possible, try to go live on a quarter end. By going live on a quarter end, data conversion and reporting are a little bit cleaner. This is especially true for publicly traded companies because they report financials quarterly. 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. Going live on year end is another popular option, but it can be difficult to pull off. For one, the calendar includes several major holidays. Plus, Finance and Accounting tend to be quite busy at year end from a reporting and process perspective.   
  • Think about your business cycle. Is there a busy season when most of your sales are occurring? Is there a time when key stakeholders will be otherwise distracted and unavailable to participate?  Budgeting season, 1099 processing, and board meetings, among many other time-sensitive events, can disrupt best-laid plans. 
  • 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? By understanding all of the other organizational priorities, you can budget your project in an appropriate time slot. 

2. Resources

Project resources and stakeholder resources can make or break an implementation.

It’s very difficult to cobble together a project team using fractional 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, such as: 

  • A steering committee to guide the project (typically key Finance, IT, Operations, and other executives). These are part-time resources that not only guide the project but also resolve key issues and roadblocks. They are also typically the champions of the project, rallying your company and preparing them for the change.
  • 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. 
  • A solution architect. The solution architect may be the project manager and/or a key business analyst. This is the person with a deep understanding of the business and also the software solution. They can work easily with users, executives, and developers and typically have a strong understanding of accounting. A solution architect sits in the middle of all of the key decisions and helps build a solution that takes into account organizational change, process design, and system functionality.
  • Business analysts. Business analysts typically report to the solution architect and help implement the solution. They work on system configuration, report development, testing, training, and documentation. They are commonly tapped to play a change management and communication role. If the project is big enough, you may need dedicated change management resources as well.
  • 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 create 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.
  • Help desk.
  • 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’s an exercise in informing them of the upcoming change, but in other cases, 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. Asking people to do this project AND their full-time job is a tall challenge. It’s also one of the main reasons why IT projects fail.

You 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 list 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, play with other levers such as time, scope, and risk to find the right balance of cost relative to the other project management metrics. 

3. Risk

Risk is an interesting metric. It’s also one that requires some experience to determine the risk level of your plan (time, resources, and scope).

Some organizations are very risk-averse, taking years to implement solutions that could have otherwise taken a quarter.

On the other hand, there are times when a go-live date is simply too aggressive and inflexible. Even when manipulating different levers, a proper equilibrium between time, resources, risk, and scope cannot be found. Barging ahead without finding this balance is an unnecessary risk.

For implementations of this kind, there are a few additional steps you can take to appease as many parties as possible. This is called a “rolling go-live.”

Basically, certain functionality is added after the go-live without sacrificing the quality of the implementation or the efficacy of the tool’s other features. For instance, conversion and reporting might be suitable for a post-live completion. It’s not a favorite approach by any means – for businesses or implementation partners – but it can mitigate critical risk while still adhering to specific timelines.

4. Scope

Scope is the most adjustable lever to meet the desired resource, cost, time, and risk levels. In a financial system implementation, for example, 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. 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 the project scope, and are table stakes to full-scale finance function effectiveness.
  • 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, timesheets, 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. To make the process seamless, 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. It takes time. It requires a 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. Someone at some point in time entered 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. There are generally three types of data you need to consider converting:
    • Trial Balance (TB) 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. (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.
    • 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.
    • Transactions. Best practice is to convert only the open transactions whenever possible (and to close as many of these prior to conversion). In theory, the GL impact of the transactions is in the GL – there should be no need to convert closed transactions. You’re better off converting 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 thorough data points and allow your team to make an informed decision.

For more information on systems implementation best practices, contact Biovell today.

Editor’s note: Updated December 2021