Cheat Sheet for Successful Outsourcing

Historically, bank’s IT division has been the place where innovative product ideas generated by business people are supposed to turn to life.

However, anyone who has worked in a bank knows that many development projects never fully achieve the initial goal. Interestingly for us, we have noticed the percentage has even increased in recent years.

Fortunately, it has occurred to a lot of businesses that there might be more intelligent ways to create and maintain IT systems than the “keep everything in-house” approach. However, many companies remain, especially in the banking sector, for whom outsourcing the whole process still seems very uncertain. Not to talk about using SaaS model services.

Instead the tendency is to hire a number of consultants from outside who actually do not need to take any responsibility for the project outcome.

This uncertainty seems to be rooted in general risk aversion as well as in lack of understanding both their own end product or solution as well as the process of building the systems.

Having dealt with both creating and implementing new and often radically different technological systems for financial institutions over the course of 20 years, there are quite a few things we’ve learned along the way. Most probably these could prove useful to those on the other side of the negotiation table as well.

We have created a nice little checklist to help you plan outsourcing for building your new fantastic product.

1. Talk to possible vendors early on.

It’s more than OK to approach a vendor or two even if the product idea is still in its very early stages. This helps to not just get or build the best product but to get the best product for YOU in a specific time frame and business environment.

When talking to vendors describe the product you’re launching or problem you’re solving not just what you want them to build.

Describing to the vendor the final solution and its features is not the way to kick off a collaboration. It’s best to start with sharing your end goal or describing the problems you are aiming to solve. Whenever we have worked out the final solution together with a client, it has been a success. Whenever we have just built a quick technical solution without being given the bigger picture, the result has been mediocre.

2. Make sure your whole team knows what product you’re launching or problem you’re solving and is ready to work on it together.

Almost none of the development projects we’ve seen over the years have been just IT projects. There is always a need for both, the business as well as the technological side to fully collaborate. The best teams have interdisciplinary people on board. Keep in mind the whole spectrum of competencies in your organization and make sure to not overlook the ones closest to the client as well — customer service and marketing.

3. Find a true champion inside your company to lead the whole process.

Vendors always prefer to talk directly to the person from inside the company — a person who has skin in the game and knows the problem inside-out, equip him with the budget and decisioning-power and let him act as the true champion.

4. Make sure she has capabilities and time to really understand the product/problems/challenges.

5. Define success.

The trend seems to be that general planning or product strategy is often left very broad with few details. To the extent where to analyze and build is the whole plan. This leads people to expect that development methods offer answers to a long list of questions that are actually strategical not technical.

6. Be realistic about the product-budget relationship.

If the budget is cut, then the definition of success needs to change. This almost never happens. Most companies expect that if the initial budget is cut, the outcome can still be the one they aimed for in the beginning. It’s not too rare to cut the budget in midway and in this situation it is especially important to be smart and open to making the best out of the situation that is uncomfortable to all stakeholders.

7. Be open to using different software development processes.

Agile is not necessarily the answer to every single project at hand. Choosing the best possible method helps to keep the first things first and avoid dealing with the nitty-gritty. There is nothing wrong with agility or scrum per se, but often, in bigger companies, these methods are being deployed at every project and by everyone without analyzing if the method is suitable for this particular situation. Starting from the wrong end is nothing but a fantastic way to make you feel like you’re moving toward your goal while in fact, you’re not.

8. Build trust. Among your team. And with the vendor.

If you feel that you cannot trust your partner, think about why and address this problem early on. The worst case scenario for any professional service provider is being asked not to think. And strangely, in past years we’ve seen that the issues around trust are on the rise and often connected to the question of power and hierarchy.

* * *
Written by: Kadri Sundja

We use cookies to track visits to our website. You can also decline tracking and no data is forwarded to third parties.