Here goes a pattern.
You are a newborn fintech or a well-established incumbent aspiring to a digital payment ecosystem or an e-money service in a region. Your vision is taming individuals, merchants and businesses flocking into the service with liquidity and ever-growing service penetration into the unbanked.
You have set up your basic IT and operations teams, hired a group of fabled consultants to steer the project and service on interim basis. The green light from the local regulator is there and the EMI license is in full swing.
One element is yet to be solved – acquire a software platform.
The interim product owner forms a nice two hundred-page Business Requirement Document (BRD) with all the nice details to role definition, operations, financial products and 3rd party service integration laid out.
You trigger an RFI and then an RFP process for the lucky shortlisted. The demos are run, smiles and nods go around. Confident checkmarks against your requirement lists are backed by relevant disclaimers.
Finally, the D-day comes, and one lucky vendor is the chosen one.
A couple of months is spent on legal circling before a Master Agreement is signed with million-round figures inside. You had to hire a legal counsel with a top-notch RP as the vendor puts quite a fight to some clauses, especially its liability, payment schedule and Service-Level Agreement.
You have triggered acquisition of massive hardware based on the vendor-supplied Bill of Materials and (great if not) some hefty Oracle Enterprise Edition licenses.
The journey gets on with a scoping session driven by your vendor. Months are spent in numerous workshops to analyze and comment on the BRD (see above). Your desire to move forward is stalled by the vendor insisting to put “all the details to the requirements together”, as well as a number of other key deliverables, such as a project plan for the next X years, escalation and communication matrixes and other oh so necessary outcomes.
The teams are immersed in the project waterfall instead of trying out market hypothesis. In daily communication, the “P” word (process) has replaced the “S” word (solution). Your patience is wearing thin as you are getting farther and farther from the market needs and deeper into project dynamics, for which your team does not have neither capacity, nor competence at this early point. The vendor promises training down the road.
What is worse, the vendor starts coming back with Change Requests for each and every “deviation”, which to you seems only a natural adaptation as you keep marrying market requirements with the high merits of the software platform. You are showing your dissolve to the vendor, who shows the signed contract in return.
The vendor gets more hooks in you as the expensive hardware has been acquired and the first payment has been made. You also notice that doing only the very necessary has replaced the initial rigor. The escalations along the agreed “multi-level paths” receive a reassuring response focusing on “collaboration processes” with no traceable follow-up.
This multi-factored sea knot of project organization, coming-along politics, requirements, deliverables and hardware is getting only tighter sprinkled by the delusional progress.
The project eventually comes to its ending, as there is neither no budget, no emotional capacity to restart.
Your board makes a hard coup-de-grace decision to stop.
This journey has been seen quite a number of times with enterprise-grade heavy software vendors. Here are our tips on how to avoid that:
| Step 1. Study the local regulations and requirements to licensing in the region. Focus on the AML (Anti-Money Laundering) and personal data protection. Extract the necessary requirements for your service. Step 2. Put together a market hypothesis to the service. Select key functional and non-functional requirements (scalability to the projected volumes, performance, localization) to the software. Step 3. Select a SaaS service that meets your key regulatory and market requirements. Agree on a trial or a minimal subscription fee package that will not break your budget, also going forward according to the projected volumes. Step 4. Launch the service early for “friends and family”. Validate your market hypothesis, collect user feedback, validate end-to-end viability of workflows with 3rd party services. Establish a user group, keep working with enthusiasts. Step 5. Expand the service into the market. Keep the service and your team lean and focused, keep validating hypotheses for any service before massive rollouts. Track against simple yet representative service metrics. |
Talk to us about the industry experience and your particular project. Get in touch via [email protected], we are happy to share advice.
