Don’t Get Stuck in Demo Land

It is no secret that companies like to ‘try before they buy’ when purchasing software. This holds true for companies of all sizes, whether a large fund administrator implementing a costly enterprise system or a more modest single family office looking for a simple portfolio accounting solution. Understandably, companies routinely request Proof of Concept (PoC) and Proof of Value (PoV), and oftentimes they do so with little understanding of the difference between the two. Or more alarmingly, without first identifying their company’s goals and what defines success for them.

According to Alex Ivanov, CEO and founder of FundCount, “Before 2021, approximately 70% of FundCount’s prospects requested a PoC/PoV before making a system purchase decision. That year, we introduced the managed implementation approach to guide single family offices through implementation with a comprehensive due diligence engagement. We also launched our guided implementation approach to help fund administrators and multi-family offices go live on FundCount within 90 days. With our sandbox environments available pre-contract, very few prospective clients now see value in a PoC or PoV.”

Distinctly Different Approaches

Proof of Concept and Proof of Value are often used interchangeably, but the process each represents is very different. A PoC validates that the software will work and do what it says it will do. For example, a PoC may prove that the software is properly programmed to compute NAV.

PoV takes it a step further. It not only proves that the software does what it promises, it shows if it will work in your unique environment to deliver the results – and value – you expect. Using the NAV example for comparison, a PoV demonstrates how the software aggregates information from disparate entities in your ecosystem to compute net asset value, and how it might minimize the need for time-consuming manual input.

Both Proof of Concept and Proof of Value are Inherently Flawed

Neither option is without its own flaws and neither can offer you the best way to assess whether the software can work for you under your own real world conditions. Some of the reasons for this include:

• Square peg, round hole: PoC and PoV requirements are written from specifications that are based on current workflows in your system. This limits a firm’s ability to understand what the new system can do. Transitioning from manual processes that rely on Excel spreadsheets to a modern accounting system with a real-time general ledger, for example, constitutes a major change. It’s simply not possible to reconcile workflows between your legacy system and the system you plan to replace it with. As a result, PoC/PoV cannot accurately capture how the system you are evaluating truly works or the value it brings.
• Implementation realities: The greatest challenge firms face with any new software project comes with implementation, not system functionality. Projects are highly complex and many data requirements can’t be properly addressed by either a PoC/PoV. As a result, they are simply glossed over. Moreover, PoC/PoV don’t provide an accurate picture of a vendor’s expertise or customer service, two critical considerations in any software decision.
• Visualization blindness: A PoC/PoV is applied in a controlled environment that typically allows only selective features and a handful of reports to be trialed. It is easy to be influenced by functionality and “sexy” reports with impressive visualization capabilities, but is there substance behind the visuals?
• Scope creep: Many times, the evaluation process simply drags on without ultimately providing you with any value the exercise was intended to deliver. Many times, companies end up requesting an ever-increasing number of sample reports only because these reports are so new and so different that they open more questions than they do answers. Scope creep is exacerbated when a firm doesn’t have a clear and tangible measure of success when they go into the evaluation process.
• Lack of commitment: Running a PoC/PoV requires a certain level of commitment. Holes in the data or missing dependencies can easily compromise results of the exercise. In spite of the best of intentions, you may lack the time, resources or expertise needed to gather required information.

Industry Trends and Statistics

This all may seem quite unsettling, but don’t worry, all is not lost in your quest to make sure you buy the right system for the right prices from the right provider. The shift from traditional Proof of Concept and Proof of Value to more dynamic evaluation approaches is becoming increasingly prevalent. According to recent industry studies, approximately 60% of organizations now favor pilot programs and detailed demonstrations over Proof of Concept and Proof of Value. This transition is driven not only by the flaws mentioned above, but also by the need for more accurate assessments of software performance in real-world conditions. There is an increased understanding of the need to reduce the risk of unforeseen integration issues and to ensure a smoother implementation process.

A successful software implementation isn’t merely about validating features through a PoC. It’s about understanding how the solution integrates into your operational framework and supports your long-term goals. This sentiment is shared by many industry experts who advocate for a comprehensive approach to software selection, focusing on long-term value rather than immediate testing results​.

So, How does One Properly Evaluate a New System?

If asking for a PoC or PoV is not the best way to assess a software solution, what is? According to research by McKinsey, “In a wide-scale transformation effort, improvement initiatives need to be piloted in selected units before they are rolled out across the whole organization.” Moving from manual processes or legacy systems to a modern accounting solution is indeed a significant transformation.

FundCount helps clients achieve this objective in a number of ways.

1. FundCount Sandbox: Costing $899 with consulting support, the Sandbox is designed to give potential clients hands-on experience with the software pre-contract. Users can perform out-of-the-box functions with preset demonstration data or, to a limited extent, their own data. While the Sandbox is not suitable for a “mini-implementation” or more complex tasks requiring configuration and customization, it reassures prospective clients that the software will meet 90%+ of their basic needs and requirements and that they will enjoy using it.
2. FundCount Managed Implementation Approach: Designed for Single Family Offices, which are usually the most complex clients in terms of entity structures and the number of different asset classes, this approach brings clients and FundCount together in a mutual Due Diligence Engagement. This engagement objectively assesses the client’s current state, its future state with FundCount, the transition process, and proactively identifies capability gaps and how they will be resolved. The outputs of a Business Requirements Document, Implementation Project Plan, and carefully informed costed implementation ensure that both FundCount and the client are aligned. This shared knowledge leads to a smoother, more effective implementation with a significantly higher probability of on-time and on-budget delivery, minus the surprises or unplanned scope creep and cost escalation that can otherwise be expected.
3. FundCount Guided Implementation Approach: Designed for Fund Administrators and Multi-Family Offices, this approach commits to getting the client live within 90 days. It achieves this by committing to a limited scope deployment, saving time and money in the long run. By isolating part of your business—one entity, a group of entities, a single fund, one client, or whatever makes sense for your firm—and getting them live quickly, our clients gain valuable experience and knowledge of FundCount. This allows them to onboard further customers more quickly and cost-effectively than with a “big bang” approach.

With our sandbox environments available pre-contract, very few prospective clients now see value in a PoC or PoV

Why FundCount’s Managed and Guided Implementation is Better Way to Make an Evaluation

They help you accomplish several things that testing via a PoC/PoV cannot do:

• They enable you to integrate all dependencies and explore the full capabilities of the system rather than wasting your time testing a watered-down, hand-selected group of functions.
• They provide the opportunity to re-engineer a portion of your business, discover what you didn’t know and use that knowledge to streamline implementation across other groups of entities or clients.
• They let you stress-test implementation and customer support, providing an accurate window into what you can expect from the longer-term relationship.
• They enable you to gain a thorough understanding of the system, assess the value it delivers and validate whether it is a good fit before committing to wider deployment.
• They provide the opportunity to identify implementation issues or gaps and iron out the kinks on a smaller scale, which will make the full rollout faster and easier.

After all is said and done, if you decide that the software is not the best match for your needs, you will have invested only a modest amount of time and money. That is much wiser than betting-the-house on an all or nothing approach, which leaves many organizations unhappy with their selection or burned by implementation failure. More importantly, you can walk away from the project with greater knowledge and a clearer understanding of what you are looking to accomplish and the type of system you need.