Avoid these common pitfalls with financial services software adoption

Over the last 5+ years there has been a shift change within the financial services industry away from creating custom software solutions towards adopting packaged off the shelf software and recently towards software as a service and cloud based solutions.

What’s driving this and what it means for the organization is a topic for another article, but avoiding some of these key common missteps will help ensure program success:

  1. Avoid buying a rigid product.  During the product assessment it is important to gather not only whether the package can flex to meet the business requirements but also how this is achieved.  A flexible product will have parameters and configuration that will allow for this, an inflexible product will require true changes in the code base:  know the difference between these.
  2. Vendor and product risk.  A major vendor change (such as dissolution) at the wrong stage in your program can be a critical blow.  Understand what the vendor risks are and mitigate the risks through commercial agreements and contingency plans.  Vendors also need to be transparent with product roadmaps so that the program is making the right decisions for the long-term.
  3. Change Resistance.  One of the benefits and challenges with packaged software adoption is that the package is completely oblivious to the organizational boundaries and how the organization runs today.  The package has probably been designed in a way that makes sense for the system — not in a way that the organization has always thought about this area.  For transformation, a vendor package can be a great source of new ideas and concepts.  The key here is to be open and ready to adopt these concepts even where this might not be comfortable.  Many people cite senior executive support as critical for large-scale package adoption, and this is one of the reasons why:  change advocacy.
  4. Making package changes without assessing the package impact.  This is the vendor’s product.  Really good vendor partners will let you know when you are crossing into dangerous territory with customizations, others will just watch you jump off that cliff.  It’s really important to always assess the impact of seemingly minor changes on the vendor package and to give the vendor an open conduit with which to have this dialogue.
  5. Wrong people in the room.  Most package adoption methodologies include a series of workshops where the business needs are understood and aligned to product capabilities.  It is important that the people in this room have a combination of open-mindedness, lateral thinking, deep subject matter expertise, and an extensive network within the organization.  It is also equally important that the vendor have similarly skilled resources in that room.  This is where the full need of the business and the full capabilities of the package need to come together and both need to be well represented.
  6. Cultural alignment.  The package vendor and the financial organization are going to be working closely together for a long time:  it’s important that they are aligned, have similar values, and share the same level of urgency.  A laid back vendor and a highly excitable organization are not a great fit.
  7. Product Completeness.  If you assess that the product is only 50% complete, don’t be surprised when you build the other 50%  These packages typically evolve based on sequential implementations and functionality that is missing will need to be built on your soil.  Ideally there are commercial arrangements which help compensate for some of the intellectual property, testing and other challenges that will ensue.
  8. Foundational Differences.  Know how the product has evolved and whether this aligns with your needs.  If your selected forex trading platform evolved from a platform that originally traded hockey cards, there will still be some hockey card code in there and many of the founding principles will still tie back to the key concepts in this space.  Knowing how a platform has evolved will also give some insight to some of it’s key foundational limitations.  If the foundation of your selected platform is ERP, other systems will bring that ERP flavour:  that can be a great thing, but it should be considered at the outset and not a surprise.
  9. Dictated estimates.  If package vendors are told what their estimates will be, these estimates will likely be wrong.  It is important that the estimates evolve from the teams that understand the effort and at a stage where enough of the business need and package fit is clear.  Other numbers are purely fiction and based on hope and dreams.
  10. Development thinking.  Package adoption is not software development:  many of the great things that we have learned about developing software to fit business requirements don’t apply here.  By adoption a package, many traditional aspects of software design and development have now been shifted to the vendor and have no place in the adoption of the package.  Activities like unbounded requirements gathering sessions will only serve to create program challenges — as an example requirements need to be considered in the context of the package
Vendors create great software packages for the financial services industry.  Financial services organizations can create great software when they choose to.  Doing both within the same package is a worst case scenario.

9 Responses to Avoid these common pitfalls with financial services software adoption

  1. Great article indeed. The best example of #9 that I have experienced was during a project when a deadline was based upon a birthday of an individual. That takes a good amount of dreaming and ego.

  2. Well written.
    #5 Right people at the right time makes all the difference.
    It is also important how well the participating vendor resources are going to be backed up by their management and help in tailor effective solutions according to the business needs.

  3. One more thing I would add to #4 is that where-ever possible keep customization de-coupled from the product code-base. This way you would avoid being trapped with a unique version of the product and would make future changes risky and expensive.

  4. I would put “Change Resistance” and “Dictated Estimates” closer to the top. I think a lot of companies make mistakes in thinking that a product is less rigid than it really is, but there are situations in which a rigid product can allow for a cheaper and faster implementation as long as the bank is willing to accept all the limitations and standard processes upfront.

    – Ben Winegarden

  5. Great round up of points to evaluate when considering financial software. A top priority for me would definitely be Change Resistant… which things constantly changing in the business environment, software needs to be flexible enough to adapt to you business as it evolves and grows.

Leave a Reply

Skip to toolbar