Roles of PMO organisations

A Project Management Office (PMO) is not an uncommon feature of middle to larger insurance organisations. The PMO is often associated with primarily IT projects, perhaps because of a history of poor execution on the part of IT, or due to the significant size of the a programme that the business intends to complete. In other situations, the PMO will be spread across both business and IT - for example to establish a Shared Services function. In any of these situations, the nature of the PMO tends to be either to coordinate and report, or to take full ownership of driving the change programme. Which is better? It depends - on the stakeholders both within and outside of the PMO team.

The Coordinating PMO
The coordination model has PMO collecting status information from individual project managers, and creating management reports.

In order to do this effectively the PMO will normally implement some level of standards (templates, procedures) that make their life easier by ensuring consistent information.

PMO will gather information from each individual project manager, maintain centralised folders or repositories of plans, reports, milestone charts, and issues lists.

However the PMO will not normally be proactive in taking decisions about individual projects, instead escalating to stakeholders.

Business case preparation is usually left to the stakeholders or staff outside of PMO. In fact the PMO staff will often lack a good understanding of the business domain.

In one example organisation, the PMO team did not have any staff with any significant level of understanding of Financial Services, or IT. As a result they were unable to contribute to creation of business cases, not knowing what needed to be considered or how the project would benefit the business. The PMO function became a convenience for the rest of the business - a team that would write the status reports, manage the files, and other project administration tasks.

The Directing PMO

In a directing model, PMO has a much higher level of accountability for delivery of the programme results. The objectives of the PMO are defined in terms of the business benefits, and responsibility is shared with the business leaders. The PMO leader (Programme Director?) takes a much more active role in the change programme. He/she sets strategies, timelines, and pushes responsibilities onto the business members.

Which is Best?
If the business is characterised by strong leadership, then PMO will naturally play a more supportive role, taking away much of the administration while the business owner retains control of the direction of the programme.

If the business team does not have strong leadership, then PMO has the option and probably the responsibility to step into the vacuum to drive the direction and exection of the programme.

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.