Menu
Menu
Technically Correct

Technically Correct

Companies are increasingly hiring CIOs with non-technical backgrounds in areas such as marketing and finance. As head of the Technology, Operations and Property division at the Commonwealth Bank, John Mulcahy was cut from that cloth. He speaks about the advantages a non-technical CIO brings to the jobCan it be an advantage for a CIO not to have an IT background? At the Commonwealth Bank, John Mulcahy has shown how.

After two years Dr John Mulcahy has moved on from being head of the Commonwealth Bank's Technology, Operations and Property division (the position is now held by Russell Scrimshaw, see "Common Ground" on page 18) to become head of Banking and Financial services. As the bank's most senior IT executive, Mulcahy had an IT budget of $5 billion over 10 years, a staff of 1500 people and a team crucial to both the bank's effective operation and its new product development. Yet he had not previously been responsible for IT nor was he a banker, as his predecessor had been.

Rather than being a hindrance in the IT area, his past became an asset. Mulcahy dismissed the jargon, elitism and insularity that all too often develop among IT specialists and took a no-nonsense approach to delivering IT solutions to the bank's needs. Not one to be blinded by science or magic, Mulcahy insisted that IT decisions should be truly commercially driven. The seeds of Mulcahy's approach were sown in his background in project management in the property industry. Mulcahy had begun his career as a civil engineer. After a period as a consulting engineer and in postgraduate studies, he joined Lend Lease as a project manager. Over 14 years with the International Property and Financial Services Group, he managed the Civil and Civic project management and construction subsidiary, property investment for MLC Property Fund Management and Lend Lease's Property Investment Services division.

During this time Mulcahy developed his general business skills, a reputation for planning for the future and an understanding of running businesses as commercial enterprises.

These were attributes which the Commonwealth Bank wanted in its processing divisions, including the Technology, Operations and Property division.

Commonwealth Bank managing director David Murray approached Mulcahy to transform these areas from cost centres into commercial enterprises. Mulcahy's brief was to make them recognise the changing environment.

"The divisions had to become commercially driven; in other words, they had to understand the commercial realities of life, operate as profit centres and have benchmarks of productivity improvement and performance," Mulcahy says. "We set the profit level low. Nevertheless, it created a thinking where [the divisions] understood the levers and drivers of their business. But just as importantly, [people in the] businesses [units] who bought services began to understand the implications of the decisions they made."While having responsibility for three areas, Mulcahy spent most of his time on IT. This meant he had to learn more about technology. He knew he needed to know enough to be able to ask penetrating questions and add value to the technology division.

"I'm sure I never understood the detail of the technology in many instances, but I was able to understand the major issues, the points of concern and the things that others were grappling with on the technology side," Mulcahy says.

"You do have to try and understand where the technologists are coming from and understand the issues they are grappling with, as much as you expect them to understand the issues you are grappling with from a commercial business perspective."Mulcahy built up his understanding through asking IT staff personally to explain matters to him, and through hands-on involvement in projects and issues, particularly some major projects. These included a substantial lending project, the application of Windows NT to the bank's branch platform and associated branch platform projects.

"In some instances this required [IT] people to take more of a helicopter view," Mulcahy recalls. "I was able to say, 'isn't there another associated bit over here?'. That is my training -- understanding the interrelationship between projects."While expanding his own understanding of technology, Mulcahy also expected IT managers to communicate with him in lay language. His approach was forthright: "Don't try and confuse me with your technical jargon. We pay you a lot of money to talk to me in standard commercial terms. And if you can't do that then someone else should. Basically, you're paid money to talk in standard commercial terms and to explain."As technology changes rapidly and is so important to businesses, Mulcahy believes it is incumbent on business leaders to understand the opportunities and capabilities of technology in business terms.

"There really needs to be much more of an application by both parties to understand each other's business," Mulcahy says. "In many instances, the business leader is so scared that they just believe whatever the technologists tell them. The technologists never understand the business so they just take a Rolls-Royce solution or an inappropriate commercial solution and run down a technology path."Mulcahy is critical of the amount that can be spent on overspecification of technology, when a smaller investment could have achieved the same result. Too often in the past, he believes, business units specified their needs and the IT group agreed to meet those needs, without either party understanding the trade-offs in value to the organisation that were involved in this "order-filling" approach. When this happened, neither party confronted the options and prioritised them in terms of the return on investment, so there was basis neither for a compromise in expectations nor for the time and cost needed for delivery.

Mulcahy sees the presentation of options as a responsibility of technologists, while business leaders need to push for more information about choices. This isn't always easy for business leaders to do, Mulcahy believes, "because people are frightened to ask dumb questions".

"If someone gives them a piece of jargon, instead of saying: 'Well, I don't really understand that', they say 'Oh, OK'. Business unit leaders get scared of technology, and technologists -- given their druthers -- will not understand business. They enjoy technology," Mulcahy says.

This is where Mulcahy's project management background proved useful. Project managers are not expected to be experts in all areas under their management.

Mulcahy wasn't afraid to say that he wasn't an expert, but was confident enough to ask a "dumb question" and to insist on getting an answer in lay terms. The expert who cannot provide information in lay terms is at fault, not the project manager, Mulcahy argues.

When he joined the bank, Mulcahy and the top 40 IT executives met in a series of workshops over six weeks, with representatives of business units also presenting their views of the IT division's performance. There was some surprise at criticisms levelled at the IT division, which Mulcahy especially attributed to the small interface between senior staff in the IT area and the business units, and people's tendency to be polite to each other.

There was also recognition that undeserved criticism from business units is a problem in itself. "Even if they [the business units] are wrong, if that is their perception then we [the IT division] haven't done a very good job," Mulcahy says. "We are responsible for making sure that they have the right perception."The workshops brought out the view that the IT division hadn't attempted to be the bank's solutions provider but rather had provided technology support.

Recognising the problem helped bring about a solution. The IT division shifted its focus away from providing services towards managing the provision of services. In fact, this new focus and the IT division's commercial orientation resulted in the bank deciding to outsource the provision of IT services (see "When Worlds Collide") "We decided that because of particular circumstances -- our scale and so forth -- we could provide those services more effectively by managing EDS to provide them," Mulcahy explains.

Now that he has moved to another business unit of the bank, Mulcahy sees he is better able to understand both the bank's business and the implications of technology on the business. He is conscious of the way that business units often blame IT departments for problems that began with units, especially when they initiate IT developments before they have settled on their requirements.

Mulcahy believes that IT groups sometimes damage their reputation by moving too early in response to business unit requests. They try to cope with premature specifications and start a project too quickly. Then if the business unit changes its requirements, the IT group is criticised for the time and cost taken in turning around to meet the new requirements. "Someone has a bright idea and wants someone to start work on it," Mulcahy explains. "Before you know it, you've got a team of 10 working [on it] and the person with the original bright idea is still mulling it over.

"I try to make sure that people in our business units don't ask for things before they have thought them through themselves. I bring a discipline to the businesses that says: 'Don't go asking someone to do something until you have clarified in your own mind what you are really trying to achieve'.

"I came from the building industry, where you can't just change your mind when people are actually building and spending money, based on what you specified.

It doesn't mean that concepts have to be solidified, but you need to make sure you don't get the team of 10 when what is appropriate is the team of one."Mulcahy also believes that business units often have poor project management practices, with people setting deadlines without understanding what is possible. "If you do 'hope scheduling' and say 'I want it by the 30th of June', you waste a lot of money and you still won't have it by the 30th of June if it's entirely inappropriate and impossible," he argues. "If people don't respond, and say it's not possible, they will waste a lot of your money pretending that they are going to try to achieve it for you."In good project management, business units clarify their requirements and ask experts about feasible deadlines. On this basis they can negotiate to see, if necessary, whether the project can be speeded up. The need to gain input from other expert sources has become even more important as projects are increasingly cross-disciplinary: with the involvement of marketing, sales and systems development specialists, for example.

"If you estimate the cost on your lonesome, without getting the cross-functional team together to explain what you are trying to achieve, how it should be defined, what resources are needed and what realistically it will take, you will never have a realistic estimate," Mulcahy says.

But will a new generation of IT-savvy business managers bridge this gap in understanding? Mulcahy isn't overly optimistic. He says that if two graduates emerge from university with comparable business and technology understanding, over time the business-focused person's IT understanding can fade as technology changes, while the technology-focused person would be going down his or her specialist path.

Still, there is hope. According to Mulcahy, when there is a constant flow of people between parts of an organisation, IT specialists can gain experience outside their discipline. The two-way street opens IT people to the broader business knowledge of others, giving them a career path outside technology and more influence over the wider organisation.

When Worlds Collide

There was a world of difference between the public sector framework in which Commonwealth Bank staff had worked in years gone by, and the disciplines of outsourcing specialist EDS that made it a force in IT services around the world. Yet John Mulcahy's efforts to bring a commercial focus to the Commonwealth Bank's IT operations had gone some way to bridging this gap -- laying the foundations for EDS to become supplier of the bank's IT services and the new employer of most of the bank's IT staff.

"We saw the changes that had taken place as a stepping stone to go even further towards the commercial environment," Bob Healy, director of Technical Infrastructure at EDS Australia, recalls. "There are a lot of opportunities ahead of us, using the base that John had established." Before the bank signed its agreement with EDS, staff had gone through substantial changes in both culture and practices. They had come to appreciate the need to migrate to a commercial environment and were conscious of costs and cost recovery. Internal transfer charging was in place and business units interacted with IT groups in a commercial way. At early staff meetings, Mulcahy always presented the process of commercialising the bank's IT operations as the primary reason for establishing the EDS relationship, Healy recalls.

For staff, this made the outsourcing decision easier to understand. They could see it as part of a change that had been under way for a year and a half and consistent with the bank's approach to IT management rather than a cost-cutting measure.

However, the shift to delivering services according to contractually agreed levels is challenging for many staff, Healy says. In the past, a staff member could individually determine priorities for action, without reference to the business context. Now actions are determined under service agreements and staff must make decisions on that basis.

Despite the earlier contrasts, EDS employee surveys indicate strong satisfaction among staff who formerly worked for the Commonwealth Bank. "We have ingrained in the staff the intent behind the partnership," Healy says.

"There is a lot of evidence that people think differently and that a marriage of cultures has been fostered."Helpful HintsCommon mistakes non-technical CIOs should avoidDon't fall out of the business-side loop once you cross over to IT. Make sure you know what the senior executives' IT needs are and they know what initiatives are under way in IT.

Don't become too obsessed with the bottom line. A narrow cost focus can stifle creativity and potential. Get to know IT and the projects that are under way before starting to eliminate costs.

Don't underestimate the technical challenges of the job. That attitude not only can alienate the IT staff, it can backfire with the senior business executives, who want the CIO to clearly articulate how a technology trend can advance the business.

Don't fall out of step with the business' strategic direction. Remember that your business knowledge can degenerate quickly and that you need to maintain your credibility with the business side by staying on top of the business.

Make an effort to network. If you stay too isolated, being a CIO will become a very lonely job. You need people you can call weekly to discuss ideas and technology.

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!

Error: Please check your email address.

More about Commonwealth Bank of AustraliaEDS AustraliaIT PeopleLend LeaseMLCProvision

Show Comments

Market Place

Computerworld
ARN
Techworld
CMO