Anatomy of an acquisition

Anatomy of an acquisition

Vendor Alan Osborne walked into the office of BNZ investments and insurance system manager Philip Crosby a few months ago and triggered a series of acquisition steps worthy of consideration at any seminar


Manager systems, BNZ Investments and Insurance.

Recently holidayed: For five weeks in the United States, especially enjoyed Arizona and Louisiana.

Lives: In the Wellington suburb of Johnsonville. “I can get into the CBD in 14 minutes. When I lived in Auckland’s Newmarket it took me 40 minutes to get into the city. Wellington is a nice size.”

Drives: ’91 Corona. “It’s comfortable. But the moment it costs me more than $1000 in maintenance in a year, I’ll flick it.”

Currently reading for pleasure: Lord of the Rings.

Currently reading for inspiration: Business Visions.

Married: With “three non-dependant children and one grandson.”

Charles Dickens could have written a novel about vendor-buyer relationships. In the worst of times, he would have said, it’s the vendor who usually cops a large part of the blame for projects that go off-course. In the best of times, when good judgment, wise counsel and serendipity go hand in hand, the buyer and the seller can live happily ever after.

It was one of the serendipitous occasions when vendor Alan Osborne walked into the office of BNZ investments and insurance system manager Philip Crosby a few months ago and triggered a series of acquisition steps worthy of consideration at any seminar.

Under Osborne’s arm was Princeton Software’s archival database. He knew that this relational database was right up Crosby’s alley, and he knew that Crosby knew it too.

Archiving is receiving intense attention now as the weight of accumulated stored data crushes down on even the most robust systems. Crosby had been planning an upgrade, mulling over a number of options, especially the obvious one of simply beefing up the iron by adding new processing capacity.

“Yes, we had a focus on archiving at the time,” admits Crosby of his encounter with Osborne. “We were looking at the options of whether to buy a package or do it ourselves. We knew about Princeton and saw that in comparing it against doing it ourselves, it was cost-neutral.”

Back to square one for Osborne. He eased up on selling features and went for the benefits. He needed to. Setting aside this cost neutrality, there were other crucial considerations — especially the one centring on the investment and insurance imperative of having “control over our own destiny”, as Crosby puts it. For him, this was the heart of the matter.

Princeton is not exactly bargain basement. It is in the $150,000 to $200,000 bracket. But the cost was clear-cut compared with developing and supporting a DIY operation. Crosby had yet another caveat: How long would the implementation take? Osborne was prepared for the question — having spent most of his working life around big-league financial institutions, he knew that that selling speed/reliability of implementation are a priority.

Princeton took responsibility for implementing the archiving. They had done it many times before with companies bigger and smaller than the BNZ.

The destiny issue

Then there was the destiny issue. Princeton kept looking good. But Crosby needed to be assured that, when it was installed, it did what he wanted it to do rather than what the vendor wanted it to do. In the event, the BNZ investments and insurance contract requires Princeton to be fully responsible for maintaining and upgrading the software under a perpetual licence. Crosby didn’t have the source code, which he often likes to have because of the destiny thing, but he had everything else.

He knew also that Princeton would do anything to avoid a problem site anywhere in the world. This is a characteristic of high-level niche applications package providers because the sheer narrowness of the definition of use rules out any excuses relating to the broad issue of user-instigated specification creep.

For a package such as Princeton, the issue of on-the-ground support does not loom as it does in other fuzzily defined spheres in which there is an immeasurable human element. Osborne, whose ITB Solutions employs just four people in Wellington, did not make and was not asked to make extravagant promises on future support capability. Some support is available locally, of course, but any serious work would be provided remotely from Australia, with anything more serious still from Princeton HQ.

For and against

Before the contract went ahead, Crosby had been mulling over the options. One obvious choice, as stated, was the option of sidestepping software altogether and merely tweaking the servers. Or, as Crosby puts it, “pumping money at the hardware”.

Then he had peered deeply into the costs, hidden or otherwise, of bringing in development staff to customise a DIY product. This consideration was weighed against the value of total ownership of the archival streamlining product.

Crosby’s thinking probably went something like this: “I have studied this problem. I have a pretty good idea how to solve it. I think I can create something fairly unique that can be re-sold within the company and perhaps outside too. But I can’t get a guaranteed handle on the costs. On the other hand, I can buy the shrinkwrap package and thus obtain measured cost. But it’s their product in the end, not ours …”

Osborne’s on-the-table cost of ownership argument carried the day for Crosby. The DIY customising is always tempting, especially to a bank that has the money to develop and own components of its core business. They can justify their decision to exit from branch premises around the nation because bricks and mortar are not a core part of their operations. An archiving product, on the other hand, is much closer to the core business, making it desirable to own it outright.

“I suppose you could say that I am a technocrat at heart,” confesses Crosby, as if explaining his decision to kick for touch with Princeton and forego the thrill of a customising adventure. “Really, a priority is to make sure that in IT terms we never have our head over a barrel.”

The conundrums

Crosby enjoys savouring the conundrums that inevitably come his way. Source code in general terms is one of them. “It’s this business of controlling our destiny. If that means having the source code, we must have it. We have to avoid the situation in which a vendor can force us in a direction other than the one we want to go along. We must always go in the direction we need to go. If we believe we cannot control that direction then, yes, we will do it ourselves.”

Similarly, if Crosby suspects that a shrinkwrapped alternative will lead to an extended implementation, then he will look very hard at DIY. “Time-to-market,” as he describes it, “is an important criterion. My job is to recognise these risks and the alternatives to them.” Crosby’s division is part of NAB’s global wealth management group. This group has an IT axiom that is worth a thousand mission statements. It is that the tech strategy must bend before the business strategy. The business rules, in other words.

Crosby refers to his role as “gatekeeper”, ensuring that what goes through his drafting gate fits the business. If a tech strategy does not easily dock with the business, then that strategy will be discarded and another one found that will mesh. It either works or it does not. It must fit like a standard three-point plug.

Crosby is not averse to describing himself as marriage broker between the technology and the business. “You look back even a few years ago, and there was this attitude: ‘We’ve got the tech for you. Here it is. What do you want to with it?’” Now it’s the other way around. Business decides what it wants. Tech had better come up with the fit.

This is by no means as simple as it sounds, of course. Indeed, looking back, it can be seen that one of the reasons technology bent business to its own demands for so long was that it was much easier that way. Easier for the technology side, that is.

Crosby is not alone in meeting the post-technology imperative. He can fall back on NAB’s worldwide IT think tank known as NAB Global Technology. There are three division: in the UK, in Australia and locally where the branch is known as BNZ Technology and operates out of Wellington’s Grand Arcade.

High-level career

Crosby, who has navigated a 30-year high-level IT career, knows that whatever the support sub-structure may be, it is he who must make the recommendation. He kicked off his career in 1971 with Databank in Auckland. He stayed there for 17 years, moving from operations to data input, programming and systems analysis.

He gravitated to NAB, setting up its New Zealand operation. His next assignment of note was to take apart what he had previously put together, as the NAB and BNZ systems merged after the Australian bank’s acquisition of the previously state-owned BNZ.

Crosby took up his present job at investment and insurance in 1994 and, in doing so, rounded out a career that now encompasses financial services in addition to his background in banking pure and simple.

Financial services adds a new imperative to banking in that it offers products which, if left on the shelf for too long, will perish, simply because someone else — the competition — has got there first. “Time-to-market,” he notes, “is the cost opportunity. It is often where control of your destiny really lies.”

Osborne’s success with Princeton lay in convincing Crosby that he would ensure timely delivery.

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

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.
Show Comments