By: Zachariah Merschdorf
Copyright © 2023 by the Construction Financial Management Association (CFMA). All rights reserved. This article first appeared in CFMA Building Profits (a member-only benefit) and is reprinted with permission.
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 the discovery phase 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. The discovery phase 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.
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.).
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.
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.
Asking the Right Questions
If the desired future state isn’t apparent, don’t panic. Instead, lean into the implementation team’s experience with other companies and their industry background to brainstorm ideas. Asking questions of the implementation team throughout the discovery process is a great way to incorporate additional points of view and help reframe the conversation.
Here are some good questions to ask the implementor when the subject matter experts (SMEs) feel lost or don’t know how to approach a segment of discovery:
- What do you recommend?
- What are some common pitfalls you’ve seen other clients make and how can we avoid them?
- How have other clients you’ve worked with implemented this?
- Who else on our team do you think would be good to bring into this conversation?
- How does a decision on this item affect other areas of the implementation?
- Can we change our minds down the road? If yes, how difficult is it to implement the change?
To be clear, the SMEs don’t have to make decisions on the software configuration and/or customization based on what the implementor says. The idea is to generate more thoughts for the team to consider when input may be running dry.
Kickstart the Conversation
Once the team is assembled, it’s time to discuss and isolate the top priorities and concerns for the project. Entering the discovery process with a clear understanding of project goals and what is most important is the key to success. A good question to help narrow this down is to ask: “If you could wave a magic wand, what would your ideal outcome look like?”
If the team doesn’t know what’s most important to them, then they won’t be able to communicate that to the implementation team. If lots of items come up during this process, it can be helpful to categorize them into “nice-to-haves” vs. “must haves.” Trying to solve every problem on the first day in a new system could lengthen the implementation process. The “nice-to-haves” might be discussed as a Phase Two roll out with your implementation team.
Most important, be honest about the current situation when having these conversations to help the team understand where they are starting. If the starting point is unclear, then it is difficult to identify the desired end state. Creating a friendly environment where open thinking is encouraged often helps overcome these barriers.
For example, a lack of detailed and timely reporting may be an issue the team has agreed upon, for which some natural solutions would be real-time dashboards, drill-down reporting, scheduled reports, etc. It’s the implementation team’s job to then identify how to deliver those in the software or provide alternatives with similar outcomes. Essentially, the company is determining current state vs. desired future state and the implementation team’s role is to bridge the gap with how the software is configured and/or customized.
During the discovery phase, it’s important to understand the team’s willingness to be flexible in areas affected by the implementation. Specifically, are there systems or processes that are off the table for modification? The implementation team may ask about changing a certain process and the team has to be able to make the call if that is an acceptable change or not. Although the new system is intended to improve the company’s operations, it’s common to have workstreams in place that the team really likes and does not want to change.
For example, the team may have a solid vendor payment approval process as part of its current cash flow management workstream, but the implementor may recommend deploying a built-in payment approval feature in the new software; understanding flexibility in certain areas in advance can save time and reduce decision fatigue. If the SMEs don’t feel strongly about keeping certain processes, then make sure they are prepared to make decisions during (or shortly after) discovery meetings to avoid delays.
Prepare for Surprises
Even with the utmost due diligence and planning, surprises are likely to occur during the discovery process. Thorough planning and research before purchase should greatly reduce the quantity and size of the surprises; however, having a game plan in place for when surprises arise can be extremely beneficial (i.e., hope for the best, prepare for the worst).
What happens if the software is expected to perform a specific task or solve a certain problem, but doesn’t? This could be due to a number of reasons: a misleading salesperson, those involved with the purchase assuming the functionality existed yet it doesn’t, or simply that the need or function was not considered in the purchasing process. The team should be prepared to collaborate with the implementors on best-case workarounds such as doing something outside of the system, implementing an additional product or module within the system being implemented, or creating a customization (as applicable) to meet the need.
To that end, it’s important to discuss contingency plans before the implementation kick-off, specifically regarding budget and timeline for dealing with surprise situations. So, when a surprise does arise, the team can quickly decide on a path forward. For example, if a missing function can be solved with a $20,000 customization and the team has budgeted $50,000 in contingency funds, then the customization may make sense. But without a contingency budget, the team may be unsure if a $20,000 expenditure is allowable and project progression may be stalled until the expenditure is approved or denied.
The timeline is also extremely important to understand. In many cases, timing can be a bigger issue than budget. For example, hitting a particular go-live date may be critical for certain requirements by a lender or investor; if a customization or other workaround can’t be deployed in time for the set go-live date, then the decision may be made before budget is even considered.
Another surprise that many do not consider when entering discovery is the departure of one or more team members. If a department only has a few people and a team member leaves the company, then the rest of those in the department, including the SME, must pick up the slack until a replacement is sourced. This can quickly erode the time the SME had allotted to focus on the implementation project. Readjusting the project calendar to accommodate the SME’s new schedule can be extremely helpful, as well as pulling in other team members to help facilitate discovery as applicable.
If the staff departure is an SME or the project sponsor, then the effects are usually more apparent. Depending on the situation, it can be best to pause discovery until the team regroups. Also, depending on how far the team is into discovery, it may be required to backtrack on topics already discussed. While backtracking may seem counterintuitive considering the team is already down a person, if the SME who departed made critical decisions regarding the software implementation, then revalidating those decisions is often a useful exercise.
When is the Discovery Phase Complete?
As the team works diligently with the implementors through discovery, when should it end? How much discussion is needed to provide the implementation team ample input to complete the software build-out? While this varies greatly by product and company, more complex solutions that touch multiple areas of a company typically require more discovery time. Similarly, larger companies with lots of end users will require more discovery than smaller companies with a handful of users.
Ultimately, as the software experts, the implementors are the ones to suggest when discovery is complete. A good implementor will provide a rough timeline of discovery duration, assuming the team can participate as required.
However, the discovery phase should be called “complete” only when the implementor has the answers they need to properly configure and/or customize the software to the company’s needs — not after a set time duration or number of meetings. If the SMEs are not in full agreement to end discovery, then the project sponsor should raise the concern to the implementors.
Signs discovery may be ending prematurely include:
- Not discussing all modules purchased or being implemented
- Implementor not asking for documentation related to current processes (e.g., sample reports, workflows)
- SMEs feel they didn’t have a chance to address all problems
- SMEs generally feel uneasy or unclear about the path forward
- Implementor is rushing to close out discovery
On the other hand, dragging discovery out too long can be equally detrimental. Digging into too much minutia and not making timely decisions can create a “paralysis by analysis” situation, stalling the discovery process because the team cannot make decisions effectively. This is why it’s important to select the right SMEs; when SMEs do not have an adequate grasp of their business areas or do not have appropriate decision-making power, it can lengthen decision-making time.
Signs of a Successful Discovery Phase
The ultimate success of any software deployment is achieving the goals set forth at the project’s onset, which depends on many factors — discovery being one of them. A key indicator of a successful discovery process is a lack of surprises throughout the rest of the implementation.
Major surprises, although not desired, should come to light and be addressed during discovery. Having a major surprise arise during testing and validation or, worse, after deployment, is a sign that discovery was not thorough or the SMEs didn’t share all necessary information with the implementors.
Another sign of successful discovery is complete alignment of the SMEs and implementation team on the current problems being addressed. A lack of understanding around what the software is solving for will hinder the SMEs’ ability to properly vet the configurations and/or customizations the implementation team designs. Equally, if the SMEs aren’t clear on what the problems being addressed are, then it’s fair to say the implementors don’t have a great grasp on them either; if the implementors are unclear of the problems, then their deliverables are likely not optimized for the company, even if they pass the SMEs’ testing and validation.
All of this should culminate in the team having high confidence in meeting the go-live date. By addressing all surprises upfront and being aligned on the problems at hand, the rest of the implementation tasks to reach deployment should run relatively smoothly.
Last, and most important, the team should be excited about the new software. If there is a sense of anxiety, chances are the software selected is not appropriate and/or discovery was mismanaged. Discovery can be stressful and tiring as it requires a lot of critical thinking and decision-making, but after a productive discovery phase, the team should have a renewed energy for all the improvements to come.
The discovery phase is a critical step in software implementation that sets the foundation for a successful deployment. By understanding the difference between configurability and customizability, assembling a skilled implementation team, asking pertinent questions, being prepared for unexpected challenges, and determining when the discovery process is complete, organizations can ensure a smoother and more effective software implementation.
About Zachariah Merschdorf
Zachariah Merschdorf is Solutions Architect & Account Executive at Accordant. Zach helps businesses both pre- and post-sale achieve their goals and, if needed, designs custom software to fill gaps between available systems. He has over seven years of Sage Intacct experience across a variety of industries, both as an end user and consultant, and works to design the right combination of products and configurations to reduce stress and increase peace of mind. Zach can be reached at 813-388-0645 and [email protected].