BHMI has been in the software development business a long time now and over the years have been responsible for dozens of software development projects for clients. By and large, these projects have been successful – some have been successes in spite of obstacles that should have dictated otherwise. We’ve encountered just about all of the problems and issues that have been well documented in myriads of trade publications and conference papers, ranging from unclear technical or client objectives to wrong technology choices and everything in between. We’ve been involved in custom projects as well as projects built around BHMI products. In recent years, BHMI has focused on client projects using one or more of our Concourse Financial Software Suite™ products. Concourse consists of a set of back office product modules for settlement, reconciliation, fees and commissions, and disputes. Like any other large-scale software implementation project, our Concourse back office projects have to deal with issues and problems and overcome them – this is expected. But we’ve observed an interesting phenomenon over time, and it’s that back office projects have more than their expected share of issues to address. So, the obvious question is, why? Why are financial back office projects more challenging than other payment-related projects? For example, we’ve worked with front end switching projects, and they’re decidedly less challenging than their back office counterparts. Why?

Here’s what we think is the main reason – there are a larger number of client operating groups that rely on results of back office processing. So when you replace a back office system or make changes to an existing system, lots of people are affected. It’s sort of like tugging at the corner of a spider web – the vibrations spread throughout the web. Depending on the nature of the back office project, affected groups can include settlement, billing, cash management, customer management, operations, reconciliation, security, and just about every other basic accounting function in an organization. With this many interested parties involved in a project, the opportunities for conflicting objectives, unsatisfactory communication, and generally poor coordination are magnified. More specifically, how can an expanded payments back office project constituency affect project success?

Back office groups have day jobs. They are focused on running an enterprise, not implementing new projects.

Client back office groups have to execute according to plan to be successful on a day-to-day basis. They are graded on their abilities to perform to schedule and to do it repeatedly. Asking groups to accommodate a brand new line of project activity as part of their job responsibility is inherently creating focus conflict.

Back office groups are forced to operate outside of their comfort zones.

New projects require creative thought beyond existing operations. New projects require groups to work with other groups in nontraditional ways. From a perspective of day to day operations, you do what you do because it gets the job done – this isn’t the same as negotiating new functionality with other groups and having to address ideas that are alien to your traditional experience.

Financial back office software implementations tend to occur deep within the bowels of an organization’s operations.

Financial back office software projects can impact all or a significant subset of an organization’s overall operations. Therefore, greater consideration has to be given to the consequences of changes in operations caused by new implementations. Why? – because the back office operations of an organization will determine if the organization makes or loses money. Greater scope, greater consequences, greater care – all contribute to additional burdens that complicate project activity.

Conflicting objectives arise as back office constituencies strive to accommodate change.

Not all back office groups will necessarily benefit the same from a new back office project. All want new, improved features for their groups, but new features desired by different groups may be different and even contradictory. Getting groups to accept changes benefitting other groups but not their own can be challenging – particularly if the changes complicate their operations. In a nutshell, it can be difficult to buy into change for the greater good that doesn’t include your own group.

Security and privacy issues can be more pronounced in back office operations.

More client groups handling more sensitive data – this basic feature characterizes financial back office operations. Consequently, security and privacy concerns are increased. Because any new functionality has the potential to destabilize existing security conventions, security personnel have to be careful in how new back office software projects are implemented. Implementation procedures may become more complex to address potential security risks, and this can increase inefficiency in project implementation. This characteristic is present in all contemporary software projects, but because the risk of security and privacy breaches increases with the number of parties handling data, financial back office projects tend to be affected to a greater degree.

More integration points increase the complexity of financial back office software projects.

Back office projects have more constituents, all of whom create data as part of their operations or who rely upon it to do their work. More internal and external interfaces plus more processing points equal greater project complexity. More complexity tends to mean more problems, longer project cycles, more resources, and greater costs during project implementation.

So what does all of this mean? How can a financial back office project team consisting of vendor and client personnel protect itself against the problems already noted? Unfortunately, there’s no silver bullet – you can employ all the best project practices you know, and success still isn’t assured. The risk isn’t so much that the project will be a technical failure because mid-course corrections can address technical issues. The real risk is that the project extends significantly beyond the targeted implementation window. This increases the chance that the project gets cancelled – either because the cost becomes too high or the problems that the project was to fix get addressed using some alternative, less painful, means. It doesn’t matter – net result: failed project.

If you can’t assure success, what can you do to at least increase the chances of project success? We’ve found that probably the biggest factor in successful vendor / client financial back office projects is the level of engagement of all affected client groups. Obviously, you need capable, responsible people involved from both vendor and client teams. But as noted above, getting necessary focus and commitment from client groups is not a given. But this is what’s needed for successful projects – especially in the financial back office space.