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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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