X
"Is the fear of failure stopping your organisation from Innovating?"
09 May 2017

"Is the fear of failure stopping your organisation from Innovating?"

A look at some of the delivery models available to innovation leaders in financial services

Competition is driving the need for companies to innovate faster and innovation has increased the value customers expect. As one service provider gains market share others will innovate to better their respective offerings. Today people can change cell phone contracts, banks and gym memberships with a click of a button and because customers of today are more informed than ever they will move when they feel they can get better value elsewhere.

 

Investing in project teams with the right skills and experience to get the job done often requires the decision maker to “stick their neck out”. This seems to be a cultural phenomenon where logical, calculated decisions to invest in projects and project teams are still seen as very risky and as a result, these decision makers are encouraged to proceed with extreme caution (or to not proceed at all). Again, it’s a cultural choice to accept and even prefer no progress rather than a failed attempt at progress. Perhaps it’s this cultural attitude that gives such a concept its own name: “innovation”, as opposed to innovation simply being the norm, in which case the concept wouldn’t need a name, it would just be normal. Anyway, to avoid digressing onto a philosophical tangent the point of this article at least is that there are various options to be evaluated when it comes to deciding how best to innovate. As suggested in last month’s article, bad past experiences lead to biased opinions and often cloud judgement when it comes to deciding how best to deliver and the ‘safest’ (read ‘cheapest’) option is most commonly selected. Ironically the option that requires the least investment is rarely the safest. Below is a list of some of the options available to innovation and project champions. Each option has its pros and cons and again the point if this article is to emphasise that the most suitable option should be logically selected based on the task at hand rather than organisational policy or a personal opinion:

 

5 innovation delivery options:

  • Traditional outsourcing: Engaging with a 3rd party (often offshore) to develop a set of signed off requirements and paying only for the delivery of these clearly scoped requirements
  • In-house: Employing full-time staff to provide a skill set and paying for their time regardless of their delivery.
  • SaaS: Software as a service or out-of-the-box solutions can be licensed and now days offer very niche requirements in the aim of reaching exploratory markets at lower cost.
  • Equity Partnerships: Entering into a partnership with another business, usually via the purchase of equity. 
  • SME-sourcing: This model allows businesses to leverage off the 3rd party and gain insight and understanding in relatively unknown or complex environments. SME-sourcing is usually a premium model that is suitable when dealing with subject matter in which the project organisation lacks expertise.

When diving a little deeper into these options it’s easy to see some of the advantages as well as shortcomings of each model:

 

Traditional Outsourcing:

Expertise, cost cutting, enabling core business functions, and solving capacity issues are the primary reasons companies outsource and this has been proven by the steady increase in outsourcing of late. There are definitely benefits of outsourcing certain specialised functions to a partner that has dedicated focus and resources, especially non-core functions. In the case of outsourcing custom software development, it is ideal when you have a set of clear, simple, documented, requirements. When this is the case you can take advantage of the following benefits by contracting with a reputable outfit, whether they are based onshore or offshore:

 

  • Cost Certainty - An experienced partner should be able to cost-fix the solution
  • Short term - Lower risk commitments and contracts
  • Liability - The ability to transfer the responsibility of delivery to the 3rd party through the clearly defined scope of the contract
  • People Management – Often this option will allow you to deal with a single point of contact who in turn manages the outsources team allowing you to avoid many of the headaches introduced by manages teams of people

 

In-house:

Employing your own developers is a suitable option when you believe that the software you build will be heavily influenced by the culture of your business and vice versa. Typically, traditional Financial Institutions have reasonably large IT teams which comprise of some software developers but in reality these teams are minute relative to the size of the organisation and usually spend their time maintaining existing solutions rather than innovating. In smaller businesses started by entrepreneurs that come from a software background, there is a tendency to favour an in-house development team while more business oriented leaders prefer not to have to deal with the diva style demands made by most high-quality developers. The obvious examples of companies that thrive with this model are those that build software primarily to sell it rather than building it to use for themselves. When succeeding with this option you may realise benefits through:

 

  • High-quality product - The ownership of delivery at an individual level can result in high-quality product
  • Passionate input - This can be tricky to manage if misguided but in general entrepreneurs encourage passion and enthusiasm from their staff
  • Context and collaboration - This is increased through sitting in the same space as the rest of the product, sales and management team

 

Software as a Service (SaaS):

As a rule of thumb, if you can find an Out-Of-The-Box platform that caters to your needs, go for it. It will most likely be more cost effective than a custom build and the solution providers should generally have a lot of subject matter expertise than can help your team through various business challenges. Of course, you won't own the IP which is fine unless you are intending to compete against the OOTB solution providers. Often these solutions require a fair amount of customisation and most providers will allow this but usually at a premium, therefore it needs to be a good fit to be worth it. The obvious wins when using an OOTB solution include:

 

  • Convenience -  Through the use of plug and play these solutions can be up and running very quickly
  • Cost effectiveness -These providers often offer a monthly service which is a great way to prove a concept or test an MVP before investing heavily into it
  • Business focus - The team can focus on the business rather than on what needs to be developed

 

Equity Partnerships:

When a FinTech, or another tech startup, has achieved success in winning a portion of the value chain or perhaps shows great promise to do so through their IP those businesses that risk losing that portion of the value chain often show interest in partnering with the FinTech. Essentially, this comes down to the question of Return on Equity and tends to make sense when the ROE exceeds the costs involved in the acquisition. The immediate benefits include:

 

  • Return on Equity: If the FinTech succeeds there will likely be increase in the value of the investment made
  • IP exclusivity - The acquiring business will usually reserve the exclusivity of the IP usage which can provide a competitive advantage
  • Speed to Market - By purchasing the IP of the FinTech, the acquiring business is usually able to leap straight to offering the value proposition to their clients, perhaps with some white labelling effort, and skip the entire development process
  • Publicity - When a well reputed financial institution shows the level of confidence required to invest in a new tech this, in turn, raises the public's confidence in the tech

 

SME-sourcing:

Sophisticated or complex business models often result in difficulties for product teams in arriving at clear, signed-off business requirements which are not susceptible to change. A common occurrence in these scenarios is that software is specified, scoped, delivered and then it is not used, or at least not used as intended. Partnering with a team that specialises in vertical-specific software development, for example, a FinTech specific development company can mitigate the above mentioned risks. For a bit of a premium of course. When engaging with Subject Matter Expert software partners you may well enjoy the following benefits:

 

  • Speed to Market- By contracting a specialist development team to work with the product team, the capacity can be scaled up as needed and dedicated 3rd party resources are mandated to focus on delivery
  • Immediate start - The SME software provider will most likely have libraries of code and components which can be used to get started and there is very little time spent in either transferring knowledge or training
  • Waste avoidance – Through expertise requirements are challenged and project work is often de-scoped, thus resulting in the avoidance of waste through good understanding of subject matter
  • Flexibility - By acknowledging that not everything is well understood up front both parties are able to agree that scope changes are inevitable and thus part of the deal
  • IP/products - Often the SME software partner will have access to their own IP, products or licenses which can often bridge the gap between business problems more quickly than developing something new

 

 

To conclude, business should invest time in understanding their business’ needs and based on those needs the most appropriate delivery model should be adopted. ROI should always be the driver behind the decision, however, when calculating the ROI one needs to be realistic in terms of the upfront and obvious costs as well as the unknown and long-term costs and benefits. It’s worth spending the time and effort in understanding this and it is vital to enlist the services of a partner who understands this and moreover a partner who will challenge your logic when implementing a custom solution.

Written by Nicolas Watson and Jeremy Hart

Related