Finding ways tooptimise developer productivityand
increase the effectiveness of the development process are obvious
goals for any organisation eager to boost efficiency and reduce
expenditure. This is whatHSBC, 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.