Implementing a fraud solution project requires collaboration from various roles on both the vendor and customer sides. However, a fundamental ownership bifurcation is crucial for the project's success: the customer owns the "WHAT," and the vendor is the primary owner of "HOW".

In my more than 10 years of hands-on experience implementing and overseeing the deployment of fraud solutions, I have had a chance to experience various situations and moments that could have been improved upon. Many of these sub-optimal paths or project side-tracks often result from breaking the above-mentioned premise (just to be clear, there are many other reasons why projects might stray from the path, and I might get to them in some other articles).

You might argue that a successful project results from joined participation, ideally genuine partnership, and I would 100% agree. Yet the above premise holds firm in any situation. So, let's break it down a bit.

The customer owns the "WHAT"

Owning WHAT means that the one who defines the requirements is always the customer. This is a fundamental requirement because once the vendor gets to define the scope for the customer - for any reason,

• e.g., customer not being mature enough,

• customer treating the vendor as an advisor,

• customer's staff turnover,

• customer engaging 3rd party consultancy to define the WHAT

• etc.

will ultimately result in the lack of requirements ownership, the customer not agreeing to the delivered objectives (partially or completely), or - what is even worse - agreeing formally but holding a negative perception of the vendor. This is a widespread scenario of how scope creep is created.

This doesn't mean that the customer can't leverage the vendor's expertise or use third-party consultants to help them frame the WHAT, but the customer has to be the one who consciously agrees to the presented scope, fully understands each item defined in the requirements, and firmly stands behind them. Also not very common but also not something unheard of is that the customer's employee who will ultimately sign the delivery completion has to own or at least sign the gathered requirements.

Requirements gathering is a critical part of any vendor's delivery process. While vendors might genuinely try to help customers frame the requirements and link them to their solution, misunderstandings can occur if the customer's team does not fully understand these adjustments. It is essential to be cautious and, if needed, even re-iterate to the customer that the scope and requirements are theirs to define and formulate. At the same time, the vendor might suggest adjustments, amendments, or alternatives.

Sometimes, customers have difficulty formulating precise and quantifiable requirements; other times, they list every functionality they have come across by reading various vendors' proposals and marketing materials. This topic would require a separate article, but here, I will just say that conducting or leveraging the last fraud maturity assessment is advisable. Focusing on the aspects and areas that are supposed to be covered by the intended solution. For example, consider the customer is planning to cover only internal fraud typology. In that case, he will look at the maturity assessment and review the existing gaps, metrics, and KPI values of the as-is state linked to internal fraud. This would allow the formulation of the requirements and improve the rating in the selected areas. Be specific and directly link the requirement and the metric it is supposed to improve when delivered.

If you don't have a full-scale maturity assessment to go back to, try to conduct at least a short, focused assessment for the areas you are trying to cover with the new solution (tough ask yourself if you are sure that deploying this solution to this particular area is really the highest priority item since you don't have a comprehensive fraud maturity assessment to link this requirement to). 

Why is the maturity assessment a must? Maturity assessment will allow us to systematically evaluate the given area, identify gaps, and prioritize them according to their severity or potential risk. Even if you could formulate the requirements without the assessment, it might be almost difficult, if not impossible, to put them into priorities. Priorities are important because once the requirements are captured, the next stage starts - agreeing on the HOW, and here, the priorities might play a crucial part.

The result of this process is a "Business Requirements Document" (BRD). This document should list all the expected functionalities from the customer's perspective. Nevertheless, not every functionality has to be delivered. Also, this document doesn't contain or mention HOW the functionality will or should surface in the final solution, as this would again break the initial premise of this article. 

The vendor owns the "HOW"

Assuming the customer has provided all the requirements, the vendor must review, assess feasibility, and map the requirements to the solution functionality. This process might, and from experience, should not be linear. Some additional discussions between the vendor and the customer are usually required to clarify the requirements so that the vendor can address each one and categorize the requirement as

1. available out of the box,

2. available after customization or

3. unavailable

The reason for the process not being linear is most often the need to move items from a lower bucket to a higher one (e.g., items in bucket 2. to bucket number 1. or those in bucket 3. to bucket number 1. or 2.). The customer and vendor are trying to find an acceptable workaround to ensure maximum coverage of gathered requirements. Only when no further amendments are possible is the final design document prepared, which describes in sufficient detail HOW the requirements will be availed in the final implemented solution. This document constitutes a "Solution Design Document" (SDD).

Ideally, each item in the BRD will have its counterpart in the SDD, with a granular enough explanation of the functionality provided. This is important for both parties, as only a mutually agreed-upon document will allow for the successful delivery of the project scope. This is also why the vendor is the primary but not the sole owner of the HOW. 

Some items from the BRD might not be translated into SDD due to

• low priority,
• deployment complexity,
• effort required,
• etc.

Nevertheless, it is a good practice to capture these reasons and final decisions so that there is a clear record of the project team's agreement on these items in case of any future disputes. This is especially relevant because the moment when BRD and SDD are mutually agreed upon and signed is often months from the day of the project's conclusion.

In one of our projects, the entire business team responsible for fraud management in the organization, including the project sponsor, changed after three months of the KICK-OFF date. In another, the project was shifted from one division and owner to another. So, despite having a proper PM practice, unforeseen challenges might arise that need to be resolved, and it's always easier with a well-documented process during the BRD and SDD phases.

Conclusion: The Path to Successful Fraud Solution Implementation

In conclusion, a clear bifurcation of ownership - customer owning the "WHAT" and vendor owning the "HOW" - is fundamental to the success of any project (especially fraud solutions). This clear division of responsibilities helps avoid scope creep, ensures clear communication, and facilitates a genuine partnership between the customer and the vendor.

Q: OK, but what should we do if we realize the requirements are not well-defined halfway through the project or if the new project owner might require some adjustments?

A: The most straightforward way would be to conduct a mini-assessment to realign the scope and ensure both parties agree on any changes.

By having clear visibility of existing gaps (via maturity assessments) and maintaining open and iterative discussions throughout the project lifecycle, both parties can work towards a common goal: implementing an effective and comprehensive fraud solution that meets the customer's needs and withstands future challenges.

So a few words of advice:

• For Customers: Ensure key stakeholders are involved in the requirements definition process.

• For Vendors: Always clarify and document any adjustments to requirements with the customer.

By fostering a clear division of responsibilities and maintaining open communication, organizations can not only implement effective fraud solutions but also build stronger, more resilient partnerships. Remember, the key to overcoming fraud lies not only in the tools and technology but also in the strength of the collaboration and the clarity of the shared vision.

References:

ACFE & GrantThornton - Anti-Fraud Playbook: https://www.grantthornton.com.tr/globalassets/1.-member-firms/turkey/rapor-ve-aratrmalar/antifraud-playbook.pdf#page=55.14