IT's Job Description

What is the job description of the IT department in an insurance company?

In the author's experience IT organisations fall into one of two molds:
- Quiet and Reactive
- Loud and Aggressive

Quiet/Reactive
Reactive IT teams take the approach that their job is generally to wait on the business to explain what they want. And whatever the business asks for is what they will be given - often even if it is clearly not the correct thing to do.

This results in an ad-hoc sprawl of systems, with little thought given to systems architecture at a business level. In one recent example I worked with a company that had over discrete 250 applications. This in a company with a total of 270 staff. In part this was a result of serial migrations between core policy administration systems. Every time a migration was carried out, the company decided that they had made the wrong system selection choice. This led to further development of the system being halted while a new system was selected. But because business does not stop while system projects are completed, the company ended up instituting a myriad of piecemeal solutions to each small processing requirement or requirement. And because the IT team did not "own" the overall architecture, this sprawl was allowed to grow to an unmanageable and expensive level.

Reactive teams also wait for the business to define requirements for new products and features. This often leads to a significant level of dissatisfaction or distrust between business departments (Operations, Sales, Marketing, etc) and IT. Business teams are not experts in defining what they need in the language or level of detail needed by IT. When an IT team does not take an active role in extracting detailed requirements, the business frequently ends up with a sub-optimal result and is understandably unhappy. And who will they blame?

Aggressive/Loud
Loud teams tend to take a more proactive approach, and if the team has the right combination of technical expertise and knowledge, can be very successful. However this needs to be carefully balanced. In one company, the IT team would attempt to take complete control as soon as a business unit had enunciated a general requirement. Because of the aggressive personalities involved, IT often attempted to tell the business what they could and could not do. Naturally this led to a certain level of resentment, and a general view that IT was always difficult to deal with.

The advantage over the reactive approach is that the end result (after the difficult negotiations) usually ends up working as agreed. But by that stage the damage to the relationship has already been done.

IT's Job Description
What approach should IT take? How can we summarise the notion that IT is a fundamental part of the operation and at the same time incorporate a more proactive or aspirational aspect?

A straw-man job description for the IT department should comprise two key points:

1. Keep the lights on
2. Build growth / revenue for the organisation

IT's first responsibility is to keep things running smoothly. This is the BAU part of the job - make sure the servers are running, the network is up, security is in place, and the applications working correctly.

The second part is to recognise that there is value that IT can add to the business. IT can be proactive in defining requirements for a change, but this needs to be backed up by a mindset that understands the impact (restriction or enhancement) on revenue.

Any new initiative triggered by IT must be described in terms of the growth or revenue that it will bring to the organisation. Otherwise how would anyone in the business understand what is being proposed, and why would they approve it?

Much of the nature of the IT department's mindset will come down to the approach taken by the CIO. And to one level or another, CIOs generally follow the two stereotypes described above. For more on this, refer to CIO Magazine's article where CIOs are classified as either builder or maintainer.