HSBC: developing a different way

How HSBC streamlined its application development by dismantling the silos that had developed across the business and focusing on specific skill sets

Finding ways to optimise developer productivity and increase the effectiveness of the development process are obvious goals for any organisation eager to boost efficiency and reduce expenditure. This is what HSBC, one of the largest banking and financial services groups in the world, has been attempting to do over the past few...

years, by rethinking the way it runs its development operation.

The company, like many financial organisations, builds and maintains virtually all of its own applications in-house, although it also makes limited and selective use of packages from third-party suppliers in non-core areas, such as HR administration.

HSBC's application development work is undertaken on a virtual team basis, with UK personnel collaborating with programmers located in other parts of the world, such as India, China and Brazil, on a wide range of projects and initiatives. However, HSBC has a policy of employing remote staff in-house, rather than hiring labour from third-party offshore providers.

Richard Dunlop, chief operating officer of HSBC's technology services group in Europe, says that by 2004 the IT department had become keen to find a means of increasing its operational efficiency levels, not least because of the competitive threat posed by external service providers such as outsourcing suppliers.

Eliminating overlapping roles

"Our challenge was that the IT organisation had built up over time in parallel with the way the bank had grown by acquisition. This had led to the creation of multiple separate IT organisations, or silos, which supported end-to-end processes for individual businesses. This meant we were not getting the economies of scale that we should have from employing 2,000 developers in the UK," Dunlop says.

The company had already introduced a global architecture in the early 2000s, along with common standards, infrastructure and policies in line with its "build once, use many times" strategy. The aim of this strategy was to implement and support systems worldwide more quickly and cost-effectively.

But the problem in development terms was that there was still too much overlap between roles in various teams, which all supported different parts of the business. Therefore, the decision was taken to dismantle these silos and organise staff into groups according to their specific skill sets, both on a UK basis and worldwide.

Unfortunately, the first attempts at change were inconclusive. "We did not get the value that we thought we would," Dunlop says.

The issue was that the initiative was never fully accepted. "To a certain extent, people were just paying lip-service to making change," says Dunlop. This meant that, although the approach worked for certain pilot projects, it failed to take root in the wider development organisation.

Driving value from shared services

However, by early 2006, the organisation was convinced that it could drive value from the approach, says Dunlop. This was not least because a parallel decision had been made to introduce a shared services model to provide technical services for the UK and the rest of the group.

This made it easier to create global pools of expertise in the shared service centre, specialising in presentation technology for front-end systems, mainframe or host technologies, head-office systems as well as cards and international business.

"The basic premise was to break up development silos and eradicate generalist roles. Having generalists works well if you operate on a small scale, but there is a lot of wastage on a large scale, and we were in danger of becoming specialists in nothing and generalists in everything," Dunlop says.

Driving staff skill levels

A further benefit of focusing resources around specific skill types is that it enables cross-fertilisation of ideas to take place more easily, and also makes it simpler to target training resources where they are most needed. "Because the focus is on managing technical resources, you drive up the skills levels and professionalism of those technicians, which, in turn, enhances productivity," Dunlop says.

He believes that the secret is ensuring that the right skills are in the right place at the right point in the future to meet customer demand, providing an increased capacity for change. "The objective is not to reduce resources, but to employ them more effectively or retrain them into new roles as necessary so as to increase the amount of work that can be done," says Dunlop.

Another important piece of the puzzle was to create a pool of relationship managers who would act as account managers, becoming an interface between business analysts and project managers on the one hand, and end-users and regional IT services companies on the other.

"You basically take someone who was doing half a dozen jobs and, on the basis of, say, their relationship management skills, assign them to the business so that their sole focus is on managing the account. By concentrating these skills in one unit, you can put all of the requirements for all of your customers into one place, which eliminates duplicate requests and allows you to build once, use many times," Dunlop says.

The key attraction of this approach to the business was that it now had a single point of contact with the IT department, which was important given that structurally the organisation was going through a period of change.

"When we were aligned in silos, it created disruption if the ownership or business focus changed. But we created a buffer, where we could continue to operate with a relatively small number of customer-facing staff. Although they might be realigned if the business was, it did not affect too many people, only some of the business analysts and those at the front end," Dunlop says.

This means that the business receives consistency of treatment and more professionalism in the way that its accounts are managed, and the IT department benefits from more focused requirements and the elimination of duplicated requests. The development process, meanwhile, gains efficiencies of scale, Dunlop says.

But he warns that such reorganisation is not a minor task, particularly because of the change involved. "The most difficult step is changing people's roles and responsibilities and gaining acceptance around that.

"It is important to explain the reason why change is important if people are to accept it, and for them to understand the element of competitive threat - that is, some of the technology suppliers outside the bank may be cheaper than us, so we need to become more efficient."

Securing buy-in, delivering value

This involves a lot of underlying planning to set objectives and future direction, before involving staff in working out the precise details of how things should work, to ensure their co-operation and buy-in.

"You do not tell people that you plan to change their mindset. Instead, you have them undertake those tasks that make it necessary to do so. But it is important to clarify to staff where they are going and introduce change into their lives over time in a planned way," Dunlop says.

"It is an evolutionary thing, so if someone can look back in 12 months' time and see how much things have changed without them having realised it, you have got to where you wanted to be without too much pain."

It is also important to bear in mind that the IT department is unlikely to get this right first time, which means that a feedback mechanism has to be in place to enable a process of continuous improvement.

Another important activity is to communicate with the business what is taking place and the expected benefits of the move, so that personnel have the opportunity to validate or improve suggestions.

Measuring and benchmarking activities are also useful to demonstrate that the IT organisation is being effective from a cost and productivity point of view. This not only helps to gain buy-in, it shows that the development team is providing value for money.

Introducing new processes

HSBC is 18 months into its journey, and Dunlop believes that if it measures itself against its original objectives, it is about 70% of the way there. "The goalposts obviously keep moving as the model changes, but we are now challenging accepted norms and introducing new processes rather than continuing to improve existing ones," he says.

This means that the IT department is in a position to work in partnership with the business by proactively providing it with information that it can use to drive costs down and improve the bottom line.

"For example, we can analyse the efficiency of individual transactions and business events in terms of technology consumption, and tune them to make them more effective. We can also look at the effectiveness of product selling or pricing and identify inefficient transactions, so that the business can decide whether it should re-price something, remove it or keep it as it is," Dunlop says.

The next phase of the initiative is to tweak the existing model to boost developer productivity still further.

"We have got the right organisational structure and processes in place, so the real focus now is on getting more bang for buck in terms of developer productivity, especially because we operate a disaggregated model where individuals are located in different parts of the world.

"It is about looking at how much resource is being applied to different tasks, and it is all part of the process of continual improvement," Dunlop says.




This was last published in November 2007

Read more on IT jobs and recruitment

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchCIO

SearchSecurity

SearchNetworking

SearchDataCenter

SearchDataManagement

Close