The Software Implementation Journey of a thousand miles begins with phase zero (James Monaghan)

Congratulations. You have decided to implement some software and want it to be successful. Will it be Agile or Waterfall or Lean or Scrum or something else entirely. While a successful project implementation has its own requirements for running it, there
are numerous things one should consider before kick off.

Has the Target Operating Model been adequately defined?

Rushing into an implementation of new technology has numerous pitfalls but none more common than starting to deploy/integrate a system without considering what the overall bigger picture will look like when it is complete. Far too many projects have wound
up back at the beginning because some key piece of technology wasn’t factored into the overall scheme. With all the fintechs and disrupters in the market today, all will strive to seamlessly integrate with one another, but without a complete understanding
of how you want them to connect and for what reason, you can easily find yourself redoing your Target Operating Model midway through and having to throw away all the effort and resources you have spent so far. It is like trying to build the plane while
flying it or change the car tire while driving it. Typical TOM’s will have a Customer Relationship Management (CRM) type system for the client facing staff to use, connecting to a Client Lifecycle Management system incorporating a workflow and rules engine
to push the necessary tasks to the relevant people to complete data entry/document upload/validation and verification. There may be a Master Data Management (MDM) system which is treated as the Source of Record/Golden copy, but all too often this is a siloed
system of multiple aggregated or integrated data stores with various systems that can update the records. There can be Transaction/Trading/Lending systems with inbuilt or integrated Transaction Monitoring Services. There can be 3rd party providers for data/documents
or news/negative news/screening purposes. All or some of these can be cloud based or on premise systems also. So now again, I ask you, have you considered where this 1 new piece of technology fits into your overall TOM and is it a final version or are you
integrating it into the current setup but plan to change this in future

For all your current systems, how long do you plan on supporting them/keeping them around?

There is a common mistake known as the Sunk Cost Fallacy whereby just because you have spent X dollars/euro/pounds on a system, it is too far along to admit defeat and scrap it. Or that it isn’t broken so doesn’t require fixing. Or that it is too entrenched
in the current systems to be able to remove or replace it. If that is the case, then you have likely ended up with a single point of failure without even realizing it. Modern technology solutions are flexible and should be built for change. Previously mergers/acquisitions
or amalgamation of systems has forced technology to be integrated and the usual process is to simply get it to work. These should be treated as the opportunities that they are to reconsider how something is done and strive for a more efficient way. Second
to this, most new technologies will have or claim to have similar offerings/modules/features such as reporting, dashboards, workflow, case management rules engines, configuration studio. The goal of this is to appeal to the widest audience possible and has
some people thinking “Why do I need to buy X when Y already has that ability?”. But with this in mind, do you really want to turn your CRM into a transaction monitoring system? Or your account system into the gateway for your MDM? Or your MDM as the principal
data entry point. You know you are going to end up with thousands of records with telephone numbers as 12345678.

Staffing/Roles

For any implementation to be successful, you will have your defined roles on both sides of the project. Yours and the vendors. It obviously depends on budget, scope and timeline. You may have a 4 week cloud based implementation that requires 2 staff from
the vendor or it could be 10 phases of 12 week major releases with 2 week agile requirements approach consisting of business/product analysts, developers, subject matter experts, quality assurance testers, all of whom need both junior and senior roles, project
managers for each line of business/region/jurisdiction and a program manager to oversee it all. Throw in a project sponsor and it’s easy to see why enterprise software gets expensive, sometime prohibitively so. This is also before you consider the staff levels
that you need to allocate to match. Don’t forget that your staff members involved in this project will be away from their day to day roles for a considerable amount of time. It’s important to make sure that the vendor staff are experienced and haven’t been
recently hired to meet the demand of your project.

The other consideration is the partnership model. Many established vendors have certified partners, some boutique firms and some of the big 4, who can also be drafted to assist implementations, but come with a price also.

Data Migration

One of the major themes incorporating a new piece of software is consideration of data access and/or data migration. If the new system will be querying your current database or databases as needed, when does it get access, which users have what permissions
to access it, is the access read only or can the users edit or create new records and when they are updating the central record, what systems have priority order for making those changes? What if another system tries to make a change while a different user
of your new technology is currently editing it? Does this now mean that all data edit requests should be routed through that new technology? What happens when all new technologies request the same priority order? These are just for active customer record systems.
What about creating a new consolidated single system? Should you take the big bang approach to migrate all data day 1? Imagine the risks. What about a transition period such as when a review is scheduled, you pull from 1 or many sources to conduct the review
and then post the clean record to the new central database. That would allow migration over a 12 – 18 month period instead. It’s not a one size fits all approach. That’s all before you ever start to consider handling duplicates.

Integrations

When considering adding a new technology to your ecosystem, you have to make sure that it will work seamlessly with your current setup. This has 2 options initially, as either a net new addition to solve a specific issue or as a replacement to an existing system
or systems in place. Either way you want to ensure that it has access to the relevant systems that it needs to for both upstream and downstream consumption. You also need to be confident that all the existing plumbing to the system being retired, can be maintained.
There is also a question about permissioning which consistently gets overlooked. User Access Control to govern what permission users have for the new technology for data that it has access to, while also ensuring that there are no admin permission requirements.
But when you add a newer technology in future, do you need to refine the access control for all historic systems at that point? As with above also, let’s not forget the need to determine which technology has priority order for data changes/updates. Otherwise
how do you make sure that system A makes a change today, system B reverses it tomorrow and system A tries again the following day.

System Access – Infosec Policies

Have you engaged the relevant teams internally to provide resources and access to relevant systems in a timely manner. If you are planning on waiting until the last moment before requesting permission for an environment or access to a database, etc. You
might just find that your target dates are suddenly unachievable.

Purchasers vs Users

Are the end users of the new technology involved in the decisioning process? What is the point of making a decision on behalf of other users, if in the end they decide that what is being built, is not fit for their purposes. The battle between business and
IT is a constant one that occurs everywhere, and swings back and forth in terms of who gets to decide. The design of the system, all too often, is expected to solve every problem, for every user, perfectly. Over engineering the technology to solve for 100%
is admirable but ultimately a resource heavy endeavor. The initial goal should be to solve for the majority and wait until successful delivery before attempting the edge cases. That final 20% or 10% of issues should not hold up the main purpose of acquiring
the technology, but all too often it becomes all consuming. The question to ask yourself is, what is definitively required day 1, and limit your options to a subset as the default answer without is always, always, everything.

So now when we look at what to consider to make a project implementation successful, we need to realize there are more things relevant before we start, which need to be included. These will also impact the decision on what software to select in the first
place.  All that glitters is not gold. Make sure what you are selecting is suitable for all considerations throughout and not solely about a single expected end result.