Caveat emptor - 'Let the buyer beware'. It applies just as much to outsourcing as any retail situation. Making the right outsourcing choice requires a sound strategy, which for Tyndall Australia's Rob Aalders was: 'The buyer is always aware'Behavioural scientists swear by the virtues of reward and punishment in modifying human behaviour. The father of behaviourism, B F Skinner, believed positive reinforcers like a piece of candy or a word of praise and negative reinforcers like a reprimand or being ignored could be equally powerful shapers of human conduct. It's a view that Tyndall Australia corporate services general manager Rob Aalders - no psychological slouch himself - might well endorse.
In an approach highly reminiscent of Skinner's Theory of Operation Conditioning, Aalders is becoming an expert on the virtues of meting out reward and retribution. And, he says a typically difficult honeymoon period with a new outsourcer has reinforced his decision to adopt such measures. Aalders has also learned - through that initial period of trial and tribulation - some valuable lessons both about the psychology of a successful outsourcing relationship and about the most meaningful performance measures to use when assessing the outsourcer's services.
According to Aalders, defining rewards and punishments, showing he cares passionately whether Service Level Agreements (SLAs) are met, and taking the time to develop meaningful metrics have all been crucial to putting his company's relationship with the outsourcer on a solid basis.
"If you don't show you care, you don't," he says. "If you set an SLA and you don't go down and interrogate progress against it and you don't show you're interested in performance by the outsourcer against that SLA, he knows you don't care and it's very hard for him to care. My view is that if we don't show that we care, we don't care and we deserve what we get.
"And the other thing we have learned is that 'people is people' like 'oils is oils'," says Aalders. "You've got to put in place things that reward people for doing the right thing. You have to tie [in] reward and retribution.
"When we set SLAs we also agreed what the rewards would be and what the retribution would be. That way people knew in advance if they didn't perform it was not going to be a case of me jumping up and down in a tantrum and throwing my teddy bear in a corner. It was going to have an effect on their cheque book," he says.
Moreover, Aalders learned one last thing during the early days of the project - you can invest as much time vetting potential outsourcers as you might in choosing a partner for matrimony, but nothing can guarantee the early days of the relationship will be harmonious.
Focusing its operations on Australia and New Zealand, Tyndall Australia Limited is a listed financial services organisation involved in the areas of risk insurance, funds management, superannuation administration and the provision of personal and corporate trustee services.
Tyndall views itself primarily as a manufacturer of products that assist people with the achievement of their financial and lifestyle goals. It distributes these products through intermediaries. With more than $6 billion in funds under management and administration, Tyndall insures the lives and incomes of more than 120,000 Australians. It has 500 staff across Australia and New Zealand.
It also acquires companies whenever it seems likely they can grow the business, and these acquisitions have created an extremely diverse computing environment.
At the time of outsourcing, Tyndall had two Pyramid SMPs, an IBM RS/6000, AS/400s, HP9000s, Wang VS, the usual nightmare spaghetti of LANs and WANs and was running Cobol, Ingres, Oracle and Universe.
According to Aalders, the sudden surges of work which inevitably accompanied its acquisitions was one of the reasons the company decided to outsource its entire IT operations to DMR. The decision to outsource was made by the executive committee, comprising the six senior managers of Tyndall Group. It also went before the Tyndall board.
After a limited tender and extensive consultation with other companies that had trod the outsourcing trail, Tyndall invited DMR to work with it for three months in a kind of quasi-outsourcing arrangement Aalders called "the honeymoon". This gave Tyndall a transition period where, in effect, DMR was providing the IT management of Tyndall's entire IT department.
The honeymoon was a qualified success; Tyndall subsequently signed a five-year fixed term contract with DMR. Shrewd analyst that he was, Aalders knew any reduction in cost would not be obvious in the first instance, particularly since his company would be paying the outsourcer a margin on the service provided.
Lengthy interviews exploring "the good, the bad and the ugly" experiences of others who had outsourced had also made it clear the first 12 months was almost inevitably difficult for both parties. Aalders therefore entered the relationship under no illusions that all would start off in an atmosphere of sweetness and light.
"Of all the things we learned from those interviews," he says, "the most significant was the need to soldier through the first 12 months before you would start to gain the benefits. Year two would start to look good after a first year of heartache and from the end of year two things would be singing.
"And our experience reflects that. We are now into the start of year two and it's looking a sight better than it looked before. We are now starting to see all those benefits that we had hoped to see. You are talking to a happy company," says Aalders.
The Tyndall experience illustrates the difficulties that can be expected when two organisations, however similar in culture, begin to work together in a relationship as intimate as that of outsourcer and client. Even though Tyndall selected DMR primarily because its culture was seen as so similar to its own, issues such as ownership of the budget and a clash of cultures raised their heads from the start.
"There was an amount of blending to be done," Aalders says. "I think there was perhaps a little bit of misunderstanding by DMR of where we wanted the focus compared to where they were providing the focus. But let me say, there were faults on our side as well. We were not perfect and we have learned to improve our side of the equation as well," he says.
"Such misunderstandings led to a lot of the problems we experienced in the first six months. DMR took over a lot of our people, and those people took time to learn the DMR way of doing things. At the same time, there was a lot of learning to be done by DMR about the Tyndall way of doing things. All in all, there was a lot of experience-gaining to be done," says Aalders.
Both in addressing those cultural problems and determining ways to measure the effectiveness of the outsourcing, Aalders took to heart the words of Paul A Strassman, writing in The Politics of Information Management: "Without verifiable results management promises are only desires."He knew from the beginning that it would be essential to have performance measures if Tyndall was to monitor, control and adjust DMR's deliverables. Such performance measures would be equally vital politically, arming Tyndall with the facts it would need to justify a continuation of the outsourcing arrangement. What Aalders didn't know at the start, although he was quick to learn, was just which measures would be most useful in determining that performance.
The performance measurement process began with getting DMR to measure, under Tyndall's watchful eye, the company's performance levels at the time DMR first came in the door. This gave Tyndall its baseline. Then the company set up what it called a "Straw-Man" Service Level Agreement - effectively a pro forma SLA based on the baseline.
"We told DMR: 'We'll give you six months' - and that was the first six months of the contract - 'in which to test your ability to meet that SLA, and we will not punish you for not meeting it. But at the end of that six months we are going to glue those SLAs in concrete. Then we flick the switch and it's hard ball from then on'," says Aalders.
Trouble was, Tyndall soon found those SLAs were far less meaningful than they might have been, Aalders says.
"We started measuring all sorts of stuff that was irrelevant at the end of the day. I'm a great believer in statistics as providing you with sound ways of setting and recording and projecting performance, and the mathematics of statistics should have been used more effectively in setting SLAs. We should have known what the average was. What the probability of achieving a certain goal was. What the standard deviation was. What the variance currently was.
Those aspects of statistical measures were not applied and I strongly recommend them," Aalders says.
"One of the things we learned was that in the initial round of SLAs we focused on a whole lot of technical measures. The lesson we've learned is that the only thing the business is really interested in is the application working on the desktop.
"They [users] really don't care whether the network works, or whether the disk drives work. All they care about - and very sensibly so - is that the application is there at 7 o'clock in the morning when they come in and that it's there at 7 o'clock at night when they go home," Aalders says.
In short, the detailed measures appropriate to the IT department meant nothing to business management, who only wanted to know about application uptime.
"For the IT management within Tyndall - that is me, primarily - the need is to have the next level of detail so that I can pinpoint where DMR is - or is not - performing, so I can get them to redress the issue.
"We have what we call a 'remedial action escalation' in our SLAs, which goes through a number of steps. For example, from people being provided at a lesser cost by DMR to fix the problem, up to people being provided at no cost from DMR to fix the problem," explains Aalders.
SLAs now cover such items as the hours each individual system is to be available; the response time performance during core times; backup/ recovery times and duration; help desk response for various categories of call; and, very importantly, help desk information on call progress for various categories of call.
Recognising that most people are less concerned about the fact that their PC isn't working than they are about being made to feel nobody is looking after the problem, Aalders also set up a feedback loop. If there is a serious outage, DMR is expected to inform Tyndall on progress every hour. If there is a minor problem with a four-day fix cycle, DMR is only expected to provide a progress report to the person who made the call once a day.
"That information, funnily enough, is probably more important than fixing any problems," Aalders says.
"The other lesson we learned is to keep the SLA's measures simple," he says.
"First, they've got to relate to things that are measurable. You don't want a whole army of people down there with stopwatches.
"We need to keep the SLAs simple so that they are understood by the business people, they've got to be easy to measure, and they've got to be meaningful.
There's no point in measuring stuff that's exciting to measure but that you can't do anything about.
"But I still think the most useful measure has been the one the business demanded, which is the application uptime, because it focused IT on the need to make sure the whole of the system operated perfectly and that no unit of the system was separate," says Aalders.
"I think that taught us all that it's the integrated whole that matters, not the individual components. After all, if you were in an aeroplane, and it was falling out of the sky, you really wouldn't care whether it was the navigation that didn't work or whether it was the guy who forgot to put the oil in at the docks."The same principle applies to application development. When Tyndall starts on any project, DMR provides a project statement that sets out the details of the project, the risks, the benefits, a proposed timetable, estimated cost, and the contingency. That proposal goes to the IT steering committee. If they fail to deliver on that time and cost, Tyndall kicks in with the remedial actions.
Since it can be much harder to apply SLAs to application development, Tyndall will allow a project statement to stand outside those SLAs where the project is recognised as large or risky or difficult to pin down. There is also flexibility in the SLAs used to measure productivity and stability improvements.
"One of the things that we sought from DMR was an assurance that we would see productivity and stability improvements," Aalders says. "So rather than setting the SLAs at the ideal level from day one, we recognised that it might take two or three years to achieve that ideal. We were prepared to say: 'This year we will allow you 98 per cent uptime on that application, but be aware that next year we are going to move it to 99'," he explains.
However in other areas the approach to SLAs is rigorous and extremely hard-nosed. For instance, SLAs are monthly and cumulative. "You don't go away and wipe the slate clean at the end of each month," Aalders says. "We are counting month by month. You can't have a good month and bad month - we take the average of both months." Still Aalders insists that strictness has to be tempered with pragmatism and fairness. "I don't think you can afford to become a martinet, jumping up and down at every little hiccup. There's got to be a bit of commercial reality in the whole process," he says.
Focus groups from both sides manage the SLAs. Comprising three people from business and two from the IT area, these groups meet on a fortnightly basis to deal with enhancements, performance reviews in their particular area, general problem solving and direction and budgetary controls. Each focus group manages its application on behalf of its business unit.
And retribution is always tied to reward. Aalders says commercial confidentiality means he can't divulge the agreed rewards but that they are as meaningful as the punishments and as useful in ensuring optimum performance. He says today, of the 23 systems whose performance Tyndall measures, 22 now have 100 per cent uptime and one has 92.4 per cent uptime. The problems with the latter were largely caused by user failure.
''We have also committed DMR to nearly half a million dollars worth of special projects since they joined us and they have delivered them 10 per cent under budget and on time. I don't know too many IT departments that can put their hands up and say that.
"They've [DMR] also provided the quality resources in a flash to help us when we needed it, on special projects." says Aalders.
So Aalders is a happy man. But there is one performance measure which means more to him than all the others put together. It is the one that assures him his company made the right decision on outsourcing and is on track with its SLAs. It can be summed up in 20 words:"My phone used to bang off the hook, day in and day out, with IT problems," says Aalders. "It hardly rings today."5 Questions to Ask Yourself Before You Outsource::- What are your core competencies?:- How does your IT organisation help enable corporate strategy?:- What IT skill sets will you need in the future?:- Can a vendor provide your currentservice levels at a lower or variable cost?:- Does upper management support your outsourcing decision?5 Questions to Ask of a Vendor's References::- How did you choose the vendor?:- How has the outsourcing relationship helped achieve your business goals?:- In what ways has the vendor met or not met its commitment?:- What value proposition did the vendor sell you versus what it ultimately delivered?:- How has the vendor handled change and conflict?Are They Capable?When considering outsourcing, the first thing to determine is whether the vendors vying for your business are truly capable of handling it.
Look for the following telltale clues that can make or break an outsourcer's chances.
1/. How much experience does the vendor have in your industry? Will you have to teach the basics of your business, or can you leverage its industry-specific skills?2/. Where is the outsourcer making its technology investments? If you're committed to custom development but the vendor is investing in packaged applications, then you are likely headed down divergent paths.
3/. How does the vendor treat its people? If you plan on turning over part of your staff to an outsourcer, you want to know what career paths and compensation it will offer.
4/. Ask about the retention rate of employees taken in from other outsourcing customers.
5/. Can the outsourcer absorb your capital investments? If you've spent a lot of money on systems and software, you want to know if the supplier can use at least some of the equipment.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.