Implementing new software is about bridging the gap between where the business is today and the goals for where it should be in the future. Whether the company wants to move from Excel-based expense reports to an expense management solution or is looking to upgrade to an entirely new enterprise resource planning (ERP) system, the company has identified a limitation in the current solution and decided to replace it with new software.

The first major step in implementing any software is discovery. As an assessment of what role that software could and should play in your organization, it is imperative to understand what processes the software affects, the current strengths and weaknesses of those processes, and the company’s goals for improving them.

This article discusses the importance of discovery in software implementation, including the distinction between configurability and customizability, how to assemble the right implementation team, and determining when the discovery process is complete for a successful software deployment.

Configurability vs. Customizability

While most software comes with some degree of configurability and/or customizability, there is a key distinction in these terms that can greatly affect the implementation time, cost, and final product. Understanding what they mean and their availability within the software is crucial to any implementation.

Configurability means the software can be altered based on already built-in logic. Customizability means the software can be altered by developers or programmers to change the way the software was designed to function by the publisher. For example, when implementing an accounts payable (A/P) solution, some companies may not want vendor bills to be deleted once posted to the system.

A configurable software may have a check box on a setup screen that reads “Check if vendor bill deletion is not allowed.” If this is checked, it would prevent deletion by users.

A customizable solution may have scripting capabilities built-in that a programmer could use to deploy a string of code generating an error message if a user tried to delete a vendor bill. In each case, the end goal is achieved, but in a much different manner.

Pros & Cons

Both configurability and customizability have their own pros and cons. The upside of configurability is that it often makes implementation less challenging and faster. The implementation team can run through the configuration options with you (e.g., a pre-defined pool of decisions to be made) and often set them up for the customer’s validation rather swiftly. The downside is that the company can only tailor the software within the bounds of the configuration options that exist; if a company wants to change a behavior of the software and the configuration was not built in by the publisher, then the customer must work within the predetermined limits.

A customizable system is considerably more manipulatable, as the capacity for adjustments is mostly limited by a developer’s capabilities and imagination. The tradeoffs are decision-making being hampered due to a vast array of possibilities and additional development cost and time to deploy the customization. Furthermore, customized solutions are not commonly supported by the software publisher, which typically leads to higher ongoing expenses to maintain the customization.

Generally, smaller companies favor configurable solutions since they tend to be less expensive, faster to deploy, and have cheaper ongoing maintenance; larger companies tend to favor customizable solutions since they are more likely to be able to afford higher costs and longer rollouts to achieve a more tailored fit. Some software combines varying degrees of both configurability and customizability. Discovery is about determining what configurations and customizations can and should be made to deliver the best outcome for the company. Without it, the software deployed would not be adjusted to fit the companies’ processes, or could be adjusted in a way that is detrimental to the attempted improvements.

Assembling the Team

Discovery aligns the entire team involved, both on the company’s side and the implementor’s side. No one understands the company’s needs better than your team, but it’s likely they have not used, nor do they understand the setup of, the software being implemented. Likewise, the implementors are the software experts, but they do not know the nuances of your business, how it operates, what improvements are needed, etc. Discovery is where the company’s team learns about the product’s capabilities and how it can be tailored to fit their needs, while the implementors learn about the company’s problems and desired improvements. Together, these teams build a blueprint for how the software should be configured and/or customized.

Discovery can have a massive impact on the ROI a company will obtain from a new software solution. So, how does a team prepare for discovery in order to extract the most value from it? What tangible actions can be taken? It all starts with leadership and team organization.

Project Sponsor

For the project to succeed, it’s important to clearly define and communicate who is the internal project sponsor. The project sponsor doesn’t have to bear the brunt of the work, but they should always be aware of the project status and have the ability to distribute resources as needed to ensure a successful implementation. The project sponsor should be a leader of a business segment that is directly affected by the implementation (CFO, COO, VP, etc.).

Project Manager

For large deployments with numerous decision-makers across different facets of the business, consider assigning a project manager. The project sponsor would not have the time to sit in on every meeting with every department, so the project manager can step in as needed. The project manager can make an impact by addressing day-to-day matters and reporting updates regularly to the project sponsor. The project manager is essentially a conduit for absorbing and recording all the information being passed around and then filtering the important pieces to the project sponsor for review.

Subject Matter Experts

The next roles to define are the SMEs who should be fluent in their respective areas of the business and have decision-making power.

In smaller companies, SMEs often span multiple areas (e.g., the controller may be an SME for everything accounting), so define the area(s) affected by the software and identify the key people responsible for running and making decisions in each area. The purpose of this exercise is to prevent having too many cooks in the kitchen, which can dramatically slow down decision- making and delay deployment of the new system. It can be useful to bring non-SMEs into discovery conversations, but this should be done at the discretion of the SME(s) for that area.

Time Management

Finally, it is imperative that proper time is allocated to the project. The implementation team should be able to provide an estimate of the weekly time requirements. If the team can’t dedicate the estimated time necessary to the project, then relay that to the implementation team so they can plan accordingly. Being honest about resource availability and scheduling makes for a much smoother implementation. Plus, having a more realistic deployment date allows for better planning for other operations within the company.