Health Service Executive (HSE)

PPARS Analysis Development of Human Resource Management System for the Health Service.

2/13/2015

1

Executive Summary

The Personnel, Payroll and Related Systems (PPARS) project was created in 1995 following

the health service strategy publication of 1994, to help shape the future of health service and

to pursue the common goals that were required by the different health service agencies to

work more closely together. The PPARS vision was to develop an integrated human resource

management and payroll system which would be used to transform manual operations into an

automated computerised system.

The PPARS project was managed by the CEO of the North Western Health Board (NWHB)

on behalf of the CEOs of six initial participating agencies. There was also a steering group

formed by the CEO charged with the responsibilities for procuring the system. The Steering

Group comprised representatives of each health board and drew expertise from the Finance,

Personnel and Management Services departments of the boards.

The project was initially implemented in association with Bull Information Systems Ltd

(BISL) and subsequently in partnership with Deloitte as project support adviser and IBM for

technical support. At all times the solution was based on SAP software.

However in October 2005, the HSE decided to suspend the further rollout of the project due

to terms of time, cost and functionality. This report will examine the key factors associated

with the failure of the project.

2

University College Cork

MODULE TITLE: IT Governance and Compliance

MODULE CODE: IS6138

LECTURER: Dr. David Sammon

ISSUE DATE: 2015 – Term 2

SUBMISSION DATE: 13th Feb 2015

Group Project

Submit By:

Student Name Student ID

Ismail Hossain 114221879

Brian Murphy 114222980

Brendan McSweeney 114223513

Ross Alan Flood 108593906

Thomas Lane 110345247

3

Contents

1.0 Key Findings Associated with IS Core Capabilities ................................................................... 4

2.0 Methodology .......................................................................................................................... 5

3.0 IS Core Capabilities Framework............................................................................................... 6

3.1 Leadership .......................................................................................................................... 6

3.2 Contract Monitoring ............................................................................................................ 7

3.3 Architecture Planning .......................................................................................................... 8

3.4 Making Technology Work ................................................................................................... 8

3.5 Business System Thinking ................................................................................................... 9

4.0 Recommendations ................................................................................................................... 9

5.0 Summary .............................................................................................................................. 10

6.0 References ............................................................................................................................ 11

4

PPARS Analysis Report

1.0 Key Findings Associated with IS Core Capabilities

Having analysed the PPARS report, we have identified several key reasons which we feel

have contributed directly to the failure of the project. In table 1 below, we have listed these

findings and also identified the core IS capabilities involved.

Table1-1: Key Findings Associated with IS core capabilities.

5

The following pie chart in figure-1 breaks down the scale of failure of each IS core

capability.

Figure-1: IS core capabilities analysis.

2.0 Methodology

We approached our analysis of the PPARS report by breaking it down into the following

sections, which are explained in table-2 below;

Section

Name 0 1 2 3 4 5 6 7 8 9

Brian Murphy

Ismail Hossain

Ross Alan Flood

Brendan Mc Sweeney

Thomas Lane

6

3.0 IS Core Capabilities Framework

The nine IS core capabilities framework as stated by (Willcocks & Feeny, 2006) was used to

assess the PPARS project. Diagram-1 shows how each capability is inter linked.

Diagram-1: IS core capabilities.

Using the IS core capabilities framework as stated by (Willcocks & Feeny, 2006) we

established the following five capabilities were the most relevant to analyse the PPARS

project.

3.1 Leadership

Leadership is one of the Information Systems core capabilities as identified by (Willcocks &

Feeny, 2006) and can be defined as devising organizational arrangements, structures

processes and staffing, which if efficiently managed ensures the cost effectiveness of IT in an

organisation.

A lack of leadership is evident throughout the PPARS project from beginning to end. PPARS

had no clear vision or strategy as the project commenced in 1998 with Bull Information

Systems Ltd being contracted for the implementation of the service for six agencies however

7

in 2002 it was agreed that national coverage of the project was essential and further agencies

were added to the project. SAP was the only software considered for PPARS and was

unproven in the Irish and UK healthcare markets. However SAP would have argued that they

successfully implemented a similar system in Queensland.

Despite the overall confusion of the role of Deloitte, they ultimately performed consultancy

services with the various agencies to support the implementation of PPARS. Overall Deloitte

was in charge of the project preparation review and conducted interviews and questionnaires

in the change readiness assessment which found from a review of seven agencies that no

agency was ready to implement the PPARS system.

Ultimately the constant change in management at the various agencies led to a continuous

change of direction in the project. The budget was based on funding demands rather than

cost analysis of the project, this led to the budget for the project being under estimated at

€9.14 million, also the two year timeframe resulted in an escalation of project costs. Neither

the National Project Manager nor the National Project Team had the authority to direct when

or how the implementations would take place in the individual agencies and decision making

was difficult due to the size and structure of the National Project Team.

3.2 Contract Monitoring

Contract Monitoring is another capability that PPARS didn’t meet and (Willcocks & Feeny,

2006) describes contract monitoring as “Protecting the business’s contractual position,

current and future”. When outsourcing to external vendors or consultants, the

implementation of a clear and comprehensive contract can be imperative to the success of the

project while effective monitoring of these contracts is necessary to ensure agreements are

met.

Poor contract monitoring appears to have been a major problem throughout the PPARS

project. This is evident in the original contract with BISL which encountered significant

difficulties. When it became apparent that the time BISL had been given to complete the

project was grossly insufficient a dispute arose over the agreement between the Health

service and BISL. The health service was adamant that remuneration was based on a fixed

price while BISL insisted remuneration was based on a time and materials basis. This led to

the eventual termination of the contract due to the potential legal fees and delay to the project

which would be incurred had legal action been taken. Further contractual problems occurred

with the hiring of eight companies for the supply of personnel for technical support.

8

Normally contractors work to the clients schedule however, the contracts with these

companies did not include any schedule of required work nor did they provide for a clearly

defined deliverable for a fixed price. We also found that entering into short term contracts

with external consultants like Deloitte had a negative impact on the PPARS project.

We have determined that the reason for the lack of sufficient contractual agreements in the

PPARS project can be put down to the failure to appoint an individual or team whose purpose

it was to monitor the contracts and examine vendor performance continuously throughout the

development of the project.

3.3 Architecture Planning

Architecture planning, “creating the coherent blueprint for a technical platform that responds

to current and future business needs” as described by (Willcocks & Feeny, 2006) is a further

core IS capability. A key attribute of successful architecture planning is to create a vision of

an appropriate technical platform. The task here is to design the IT infrastructure so that it is

of maximum use to the company and as such the needs of the end user are a key

consideration.

From the report it is evident that while the users and line managers had some involvement in

the business processes, they had little or no input into the design and implementation of the

system. In fact many of the users complained that, “they were minimally involved in the

design and implementation of the system. There does not seem to have been consistent

engagement by senior managers and, consequently, opportunities for users to get involved

were limited”. This led to the design of a system which actually made life more difficult for

the users and perhaps more importantly, a system which the users had little or no faith in.

Line managers and senior management at local level didn’t believe it benefited them and

there was a serious lack of belief in the system. The report shows that in some sites where the

payroll system has been implemented, the old manual systems are still being used due to lack

of confidence in the system.

3.4 Making Technology Work

Making technology work is another core capability described by (Willcocks & Feeny, 2006)

as “Rapidly trouble-shoot problems which are being disowned by others across the technical

supply chain.” The failure to test systems to see what worked and what further enhancements

where needed to meet user’s requirements in the two pilot sites before rolling out the systems

in other agencies had a negative impact on the project. This could have been associated to be

9

the urgency to get the systems “live” in a two year timeframe. It was also evident that SAP

required specialist knowledge to configure and there was a lack of buy-in to the

implementation of the systems in some agencies.

3.5 Business System Thinking

The business system thinking capability is described by (Willcocks & Feeny, 2006) as

“Ensuring that IT/e-business technologies capabilities are envisioned in every business

process”. Another negative we found in our analysis of PPARS was an inability to

definitively ‘freeze’ the business blueprint or business requirements at a particular point in

time in accordance with best practice.

4.0 Recommendations

We have listed the reasons why PPARS failed above; we will also give our recommendations

in what could have prevented the failure of the project in table-3 below;

Reasons PPARS Failed What PPARS should have done

No clear vision/strategy Management should have agreed from day one that a national rollout of PPARS was essential

in all agencies

Insufficient Timeframe A clear structure in a step by step process rather than a two year timeframe

Budget Under Estimated Detailed Cost Analysis should have been done

Decision Making Vacuum Formed Smaller teams with more experience

Failure to Test System and failure to carefully follow pilot site implementation

strategy

Pilot site investigation to see what worked and what did not work when systems were first

implemented

SAP Software required specialist skills to

configure

Recruited experienced member of Queensland

Health Sector for SAP implementation in Health Sector

Adamant about using SAP Software

Management should have considered the

advantages and disadvantages of other software products before choosing SAP

No User Requirements Gathered Users should have been involved in all stages of project development to avoid an inappropriate system being developed.

10

Poor Contract Monitoring

A contract monitoring team should have been designated to hold consultants to account on contract agreements and ensure all agreed

deliverables were met.

Table-3: Recommendation.

5.0 Summary

We acknowledge that the health sector in Ireland did require an integrated system to pursue a

common goal, but the organisation structure; culture and process variations that existed in

different agencies made the project more complex to manage. Ultimately if the PPARS

project took a more considered and measured approach in each agency than the project could

have been a success and an efficient system could now exist in the HSE. Consequently the

opposite scenario transpired and the project was destined to fail from the start due to the

limited timeframe and underestimated budget.

Finally the urgency to get the project completed as soon as possible led to spiralling costs and

led to a more complex project which was obviously more difficult to manage, if the project

was managed in the manner we recommended in table 3 above than the PPARS Project may

have stood a better chance.

11

6.0 References Willcocks, L. P., & Feeny, D. (2006). IT OUTSOURCING AND CORE IS CAPABILITIES

CHALLENGES AND LESSONS AT DUPONT. IN F O R M A T I O N S Y S T E M S M A N

A G E M E N T , 49-55.