Queensland

 Health  Payroll  system    

 

A  case  study  on  business  process  management    

and  application  enterprise  integration  

 

Raul  Manongdo  

Macquarie  University,  Sydney,  Australia  

raul.manongdo@students.mq.edu.au

Keywords:     Business   Process   Management,   Enterprise   Application   Integration,   Payroll,  

               Queensland  Health,  Process  Modeling  

Abstract.  In  March  2010,  the  Queensland  Health  implemented  the  first  stage  of  a  planned  
two-­‐stage  implementation  of  its  new  rostering  and  payroll  solution.  This  entailed  replacing  
the  ageing  ESP  Kronos  rostering  system  and  out-­‐of-­‐support  LATTICE  payroll  system  with  
Workbrain  and  SAP,  respectively,  as  part  of  an  initiative  to  introduce  statewide  centralized  
shared  services  to  government  agencies.  The  state  agency  responsible  for  management  was  
CorpTech  under  the  state’s  treasury  department  and  the  prime  contractor  selected  for  deliv-­‐
ery  was  IBM  Australia.  [1]  [4]  
 
The  outcome  was  described  as  a  spectacular  failure  in  many  aspects;  delayed  delivery  by  al-­‐
most  two  years,  at  least  300%  over-­‐budget,  incorrect  payments  to  76,000  employees  and  
performance  issues  that  necessitated  significant  more  investments  to  fix  and  stabilize.[1][7]  
 
Numerous  reviews  from  various  perspectives  on  legal,  public  administration,  audit  and  tech-­‐
nical  were  made,  engaging  subject  matter  experts  and  independent  bodies.    The  consensus  
reached  was  the  failure  can  be  attributed  to  an  ineffective  project  governance,  unclear  busi-­‐
ness  requirements  and  the  few  business  processes  for  supporting  the  project  development  
cycle  were  not  adhered  to  and  knowingly  by-­‐passed  by  all  parties.  [1]  
 
It  would  had  been  better  if  the  existing  business  process  were  discovered,  modeled,  opti-­‐
mized    and  shared  to  all  stake  holders.  This  would  form  the  basis  for  the  ‘To  Be  system  and  a  
more  clear  terms  for  engagement  with  stakeholders  and  external  contractors.    Business  pro-­‐
cess  suite  in  support  of  development  and  implementation  could  have  been  introduced  to  in-­‐
clude  activity  monitoring  and  control.  
 
The  risk  of  failure  could  had  been  mitigated  by  using  a  a  proven  and  well  tested  integration  
framework;  using  a  partner  API  between  vendor  products  or  better  still,  adopting  an  open  
web-­‐based  standards  in  a  Service  Oriented  Architecture.  
  

1 Project Background

In  2002  the  then  Queensland  Government  established  the  “Shared  Services  

Initiative”  the  purpose  of  which  was  to  amalgamate  and  rationalize  government  
services  across  a  number  of  departments  and  agencies  which  had  had  apparently  
been  applied  overseas  to  the  public  sector  with  some  success.    
 
The  government  initiative  was  intended  to  produce  a    

─ Higher  standard  of  corporate  service  functions    

─ Lower  cost  to  government  by  reducing  the  acquisition,  licensing  and  IT  
workforce  cost  
By  
─ Centralizing  IT  management  and  operations  
─ Simplifying  systems  and  business  processes  that  can  be  reused  by  many  
government  departments  and  agencies  
─ Adopting  a  uniform  set  of  business  applications  and  common  set  of  comput-­‐
er  technology  platform.    
CorpTech  under  the  Queensland  Treasury,  was  to  manage  this  initiative  and  in  
August  2007,  engaged  IBM  Australia  as  prime  contractor  for  delivery.  This  is  so  
as  to  significantly  accelerate  the  implementation  time  line  giving  priority  to      
legacy  systems  that  will  soon  have  no  vendor  support,  as  was  the  case  of  the  Pay-­‐
roll  system  at  Queensland  Health  (QH).  [1]    
The  Queensland  government  had    

─ 15  legacy  payroll  systems  in  13  different  government  departments  from  

providers  SAP,  Aurion,  LATTICE,  and  TSS.  [9]  
─ QH  covered  15  regionals  districts.    Shared  services  and  the  various  payroll  
district  hubs  manage  the  payroll  system.  [3]  
─ LATTICE  is  used  for  payroll  and  ESP  Kronos  for  rostering.  This  was  imple-­‐
mented  between  1996  and  2002.  [2]  
 
The  LATTICE  package  was  becoming  obsolete  and  support  from  the  vendor  
Talent,  was  to  be  withdrawn  in  2005.  The  Department’s  rostering  and  payroll  
environment  is  largely  paper-­‐based.  Shift  changes,  movements  between  posi-­‐
tions  and  leave  applications  are  all  submitted  via  line  managers  using  paper  
forms.    
2 Proposed Payroll System

The  State  decided  upon  Workbrain  and  SAP  as  the  products  for  the  whole-­‐
of-­‐government  HR  and  Payroll  Solutions.  The  product  mix  used  was  chosen  be-­‐
cause  of  a  proven  core  payroll  solution  (SAP)  and  others  considered  as  best  of  
breed.  

• SAP  -­‐  SAP  HR  Payroll  will  be  used  for  payroll  processing  and  SAP  CATS  
functionality  will  be  used  for  non-­‐rostering  agencies.    In  addition  to  cap-­‐
turing  attendance  data,  some  of  the  information  processed  in  SAP  Payroll  
are  fixed  allowances,  superannuation,  deductions,  taxation,  payroll  report-­‐
ing,  payroll  processing  and  separation  processing.  
 
• Workbrain  –  for  time  related  allowances,  overtime,  penalties  and  other  el-­‐
ements    that  will  be  interfaced  into  SAP.    Its  awards  engine  is  to  be  used  to  
configure  all  time  related  award  conditions  and  business  related  pay  
rules.  Pay  rules  was  claimed  to  be  mostly  done  via  configuration  and  not  
customisation.  
 
• Recruit  ASP  and  SABA.  [5]  
The  HR/Payroll  solution  was  to  integrate  to  key  existing  Queensland  Health  
enterprise  architecture  that  are  mainly  in  SAP.  These  are:    
─ Financial  and  Asset  Management  
─ DSS  (Decision  Support  System)    
─ HR  Systems    

3 Project Governance and Delivery Challenges

3.1 Complexity  of  pay  rules  

The  Queensland  Health’s  payroll  system  was  “uniquely  complex”  [4]  

─ 85,000  staff  were  employed  under  two  different  Acts,  covered  by  12  dif-­‐
ferent  industrial  awards  and  impacted  by  six  different  industrial  agree-­‐
ments,    
─ 24,000  different  combinations  of  pay  created  as  a  result    
─ 3,200  employees  with  concurrent  employment  arrangements.  A  
employment  arrangement  involves  an  employee  having  multiple  positions  
within  QH  at  the  same  time  and  different  employment  conditions  /  enti-­‐
tlements  for  each  position.    
─ Each  fortnight,  1010  payroll  staffs  were  required  to  perform  more  than  
200,000  manual  process  on  about  92,000  form  
─ The  solution  architect  from  IBM  stated  that  the  number  of  awards  isn’t  the  
issue;  it  is  the  complexity  of  the  pay  rules  that  support  a  given  award.  
 
 As  a  consequence,  a  significant  number  of  customisations  were  made  to  
Workbrain  (1,029  customisations)  and  SAP  (1,507  customisations)  and  with  
more  than  130  manual  workarounds.  These  in  turn  introduced  significant  com-­‐
plexity  into  the  administration  of  the  payroll  system  itself  that  impacted  on  sys-­‐
tem  performance.  

3.2 Short  delivery  time  frame:  

The  project  duration  for  delivery  of  the  live  system  was  only  8  months.  In  
contrast,  its  predecessor  system,  LATTICE,  was  rolled  out  in  6  years  done  
through  stages.  [1]  
 
The  implementation  strategy  was  for  statewide  cutover  to  production  in  all  
QH  districts  in  a  single  deployment.  [5]  

4 Stakeholder Management

The  project  stakeholders  were:  [3]  

─ Queensland  Health,  as  customer,  which  had  the  following  subgroups.

o QHIC  (Queensland  Health  Implementation  of  Continuity)  project  team  
with  responsibility  for  managing  the  project.
o QHEST  project  team  (Queensland  Health  Enterprise  Solutions  Transition)  
who  provided  project  management,  business  transition  and  functional  
(HR  and  Finance)  support.  
o Payroll  Stabilization  Project  team.  
o Shared  services  provider  and  district  hubs  who  have  responsibility  for  the  
processing  of  payroll  
─ CorpTech,  in  their  role  as  contract  manager  and  owner  of  the  whole  of  gov-­‐
ernment  payroll  solution    
─ IBM,  in  their  role  as  systems  integrator  and  prime  contractor.    
─ Unions  representing  Queensland  Health  staff.  
─ Department  of  the  Premier  &  Cabinet,  Public  Works  and  Treasury    
In  measuring  the  value  of  its  IT  investments,  the  Department  of  Health  uses  
the  balanced  score  card  approach  but  it  was  clear  that  this  model  was  not  modi-­‐
fied  to  take  into  account  inter-­‐departmental  projects.    Kaplan  and  Norton’s  were  
recommended  as  metrics  for  performance  by  a  researcher.[7]  
To  ensure  proper  implementation  and  mitigate  risks,  the  parties  agreed  on  
the  IT  industry  standard  testing  phases  and  engaged  an  external  auditor,  KJ  Ross  
&  Associates  (KJ  Ross),  to  validate  test  results.    The  auditor  concluded  that  test-­‐
ing  was  incomplete  and  test  exit  criteria  had  not  been  met.  [1]  
 ─ For  systems  and  integration  test  that  IBM  is  to  deliver,  the  auditor  find  a  
high  number  of  outstanding  Severity  1  and  2  defects;  90  test  cases  had  not  
been  executed  an  d  test  cases  could  not  me  mapped  to  Requirement  Tracea-­‐
bility  Matrix  (RTM).    In  addition,  IBM  failed  performance  testing.  
 
─ For  UAT,  QH  identified  805  major  defects,  14  show  stoppers  and  1,007  de-­‐
fects  in  all.      
 
─ For  parallel  pay  run,  none  was  conducted.  
The  auditor  general  in  its  report  concluded  that:  

“Both  parties  ignored  all  the  warning  signs  of  a  project  in  serious  distress.  Ra-­‐
ther  than  reset  the  project  or  take  decisive  steps  to  put  it  on  a  stable  course,  
they  altered  or  lowered  the  thresholds  which  had  been  put  in  place  to  protect  
against  the  very  thing  which  eventuated:  a  system  of  poor  quality  which  was  
not  ready  to  Go  Live.”  [1]  

5 Project Result

Fig.  1.  Source:  David  Klein’s  Blog  –  Anatomy  of  an  IT  Disaster,  July  2010  
 The  cost,  in  terms  of  payments  to  IBM  alone,  is  over  four  times  ($21  mil-­‐
lion)  more  than  the  contract  price  ($6.19  million)  due  to  47  business  require-­‐
ment  changes.  It  took  three  times  longer  than  originally  scheduled.  When  it  went  
live  it  was  seriously  deficient,  causing  very  many  QH  staff  not  to  be  paid  or  to  be  
aid  inaccurately.  [1]  
The  business  processes  designed  to  deliver  the  payroll  each  fortnight  are  
highly  manual.  The  business  processes  involved  approximately  130  manual  sys-­‐
tem  ‘work-­‐  arounds’,  double  handling  of  pay  forms,  retrospective  payments,  ad  
hoc  payments  and  other  associated  adjustments.  QH  estimate  that  approximately  
200,000  manual  processes  are  required  to  process  on  average  92,000  forms  
within  the  payroll  hubs  every  fortnight.  [4]  
Approximately  500  additional  payroll  staff  beyond  that  required  under  
the  previous  payroll  system,  were  required  to  complete  these  processes  each  
fortnight.  In  contrast  with  Mater  Misericordia  Hospital  that  had  a  successful  pay-­‐
roll  implementation  under  the  same  payroll  rules  complexity,  there  was  only  7  
payroll  staff.  The  ratio  of  payroll  staff  to  employees  is  1  to  1000  whilst  at  QH  
Health  is  1:100.  [1]    
To  rectify,  QH  is  estimated  to  cost  the  state  some  $1.25  billion  between  2010  
and  2017.  The  breakdown  given  was  [4]  

• $1.01  billion  would  be  spent  on  business  as  usual  

• $220.5  million  on  fixing  problems  associated  with  the  existing  system    
• $25.0  million  on  deciding  on  a  future  system.    

In  detail,  the  problems  identified  were:  [1][3][4]  

Inaccurate  payroll  payments.    

─ System-­‐generated  automatic  top-­‐ups  

─ Manual  top-­‐ups  resulting  in  a  double  payments  in  a  limited  number  of  
─ Payment  
cases   of  overtime  to  employees  whilst  they  are  on  leave.    
Defective  or  Missing  Functionality:  

─ WorkBrain  does  not  allow  for  salary  sacrificing  of  retrospective  payments.    
─ Workbrain  is  unable  to  apportion  employee  costs  to  multiple  cost  centres.    
─ Bugs  in  calculating  the  enterprise  bargaining  back  pay  and  superannua-­‐
tion  contributions.    
─ Incorrectly  calculation  of  QH’s  annual  leave  liability    
Integration  between  Workbrain  and  SAP  failed  

─ Long  processing  time  to  send  payroll  information  from  SAP  to  Workbrain  
and  vice  versa.  This  can  be  attributed  to    
“The  sheer  volume  of  transactions  coming  from  WorkBrain  to  SAP  is  enor-­‐
mous.  Consider  if  there  were  10  records  per  person  per  day,  each  pay  would  
have  approximately  (10  records  x  85,000  employees  x  10  days)  8.5million  rec-­‐
ords!  “  [2]  
 
─ Work  Brains  “Multi  View  Scheduler”,  the  agent  that  manages  change  in  
rosters,  crashed  several  times,  casting  doubt  to  the  users  on  persistence  of  
transactions  Workbrain  could  not  diagnose  whether  or  not  data  had  in  
been  lost  that  precipitated  double  entries.  
As  a  consequence,  overnight-­‐processing  runs  took  longer  causing  process  synchroni-­‐
zation  problems.  
Data  from  legacy  (LATTICE)  to  SAP  were  not  migrated  completely  

─ There  were  approximately  20,000  forms  that  were  not  processed  and  
their  associated  transactions  were  not  migrated  across  to  SAP.  Approxi-­‐
mately  5,700  employees  required  adjustments  to  their  leave  balances  re-­‐
lating  to  leave  transactions.  

Data  Errors    

─ SAP  used  a  unique  time  code  identifier  to  process  the  files,  but  files  
created  at  precisely  the  same  second  were  given  the  same  time  code.  This  
meant  only  one  file  with  that  time  code  could  be  processed  and  the  others  
were    left  unprocessed.  

6 Discussions and Recommendations

The  broad  functional  areas  identified  and  exposed  in  this  case  study  that  re-­‐
quired  associated  business  processes  are:  

─ Project  governance  and  management  

─ Business  requirements  definition  
─ Interface  dependency  
─ Subcontractor  management  
─ Change  control  and  configuration  management  
─ Data  quality  assurance  
─ Project  development  life  cycle  monitoring  
Because  of  the  project  challenges  as  described  in  the  previous  section,  QH  
needed  to  be  agile  which  required  an  explicit  understanding  of  the  shared  responsi-­‐
bility  across  business  and  IT  professionals  that  promoted  visibility,  collaboration,  
consensus  building  and  prototyping.  Once  a  governance  model  had  been  agreed  on,  
a  process  activity  monitoring  is  needed  so  that  managers  can  adapt  in  real-­‐time.    
For  the  case  of  QH,  the  acknowledged  short  comings  below  [1]  as  identified  in  
various  project  reviews  could  had  been  avoided  if  an  automated  BPM  product  
suite  was  in  use:  

─ Accountable  Officer  responsible  for  the  overall  governance  and  successful  

completion  of  the  whole  project  was  clearly  identified.  There  were  too  many  
bodies  and  many  people  involved  in  decision-­‐making  and  the  governance  
structures  had  changed  several  times  on  both  QH  and  IBM.  
 
─ Clearly  defined  business  requirements  and  adequate  documentation  and  
agreement  of  business  requirements  that  could  had  miminimsed  the  47  
change  request  that  increased  the  cost,  complexity  and  delays.  
 
─ Scope  of  the  interface  of  payroll  with  enterprise  system  is  clarified  and  
agreed,  and  not  raised  when  it  was  too  late;  raised  in  February  2009  when  
the  Go  Live  date  was  September  2008.  
 
─  Compilation  and  storage  of  documents  on  business  process  compliance  
from  governance  bodies  that  were  lacking  including  documented  and  ap-­‐
proved  terms  of  reference.  
 
─ Senior  managers  and  top  government  officials  could  had  been  alerted  earlier  
pertaining  to  the  following  activities:  
o Business  Activity  Document  was  not  being  acted.  
o Requirement  Traceability  Matrix  was  not  being  accepted.  
o The  system  and  test  results  were  not  to  standards.  

Business  Process  on  Process  Definition,  Discovery  and  Optimization.    

 
The  author  believes  that  identification  of  business  process  and  the  inter-­‐
action  between  them  is  a  prerequisite  on  engaging  external  vendors  and  merits  
to  be  a  separate  and  significant  government  project  in  itself.    IT  could  have  facili-­‐
tated  the  BPR  through  extensive  modeling  of  process  and  information  sharing.      

Simplify  existing  Business  Process  

The  current  business  practice  was  acknowledged  to  introduce  data  inac-­‐
curacies  and  processing  complexity.[3]  

• The  system  allowed  historical  form  submission,  going  back  up  to  six  
years  in  some  cases,  which  required  the  payroll  system  to  retrospective-­‐
ly  adjust  pay  and  entitlements.  
  
• Timing  of  pay  dates  essentially  required  line  managers  to  estimate  like-­‐
ly  hours  to  be  work  by  staffs  for  2  days  on  any  given  pay  period.    

Identify,  consolidate  and  model  existing  business  process  

They  could  have  leveraged  on  past  experience  and  resources  from  prior  suc-­‐
cessful  IT  payroll  projects  in  the  same  area:  [1]  

─ Department  of  Housing  with  Accenture  as  the  provider  

─ Mater  Misericordia  Hospital  which  was  recommended  by  the  Auditor  Gen-­‐
eral  
A  previous  attempt  was  made  to  do  this  but  was  turned  down  and  senior  gov-­‐
ernment  officials  chose  WorkBrain  in  the  hope  of  reducing  the  overall  time  for  
completion  of  this  prerequisite.[5]  

Share  Application  Knowledge.    

BPM  promotes  creation  of  a  community  of  experts  and  build  knowledge  repos-­‐
itories.    Like  any  legacy  systems  that  had  undergone  several  changes  and  imple-­‐
mented  in  many  ways  by  various  payroll  hubs,  the  As-­‐is  System  may  not  be  well  
known.[3]  

─ The  application  knowledge  is  held  at  the  various  payroll  district  hubs.  
─ Ties  were  severed  due  to  the  centralization  of  whole-­‐of-­‐state  payroll  system.  
─ Project  has  no  visibility  outside  of  those  directly  involved  in  the  project.    

Adopt  an  Electronic  Rostering  System    

 
BPM  advocates  capturing  information  digitally  at  the  source  and  links  required  
to  decision-­‐making.    Ernst  &  Young  recommended  the  use  of  electronic  rosters  
for  QH.  [4]  Rosters  are  the  primary  input  for  payroll  for  use  by  line  managers.    
Human  intervention  is  required  though  for  breaches  in  award  conditions  that  
are  best  resolved  at  the  time  of  creation  and  at  the  source.  The  expected  benefits  
of  its  adoption  are:  

─ Increase  the  accuracy  and  timeliness  of  rosters    

─ Decrease  the  time  taken  to  resolve  pay-­‐related  enquiries  
─ Decrease  the  average  number  of  roster  amendments  
─ Reduce  the  incidence  of  award  breaches.    
Use  a  proven  and  tested  integration  framework.    
 
The  interface  architecture  between  WorkBrain  and  SAP  is  questionable.    
“The  Integration  between  the  2  systems  is  wrong  -­‐  as  WorkBrain  rostering  is  
writing  directly  to  SAP  (using  flat  files  to  pump  data  into  SAP)  rather  than  us-­‐
ing  the  timesheets  as  the  intermediary  entry  mechanism  first.  SAP  Payroll  sys-­‐
tems  are  effectively  bypassed  by  using  WorkBrain  and  a  bespoke  system  for  
payroll  calculation  and  generation.”[2]  
The interface is classified to be a custom API at the data store level. It applies
only to the two integrating applications for this particular case and hence can-
not be reused reused for other purposes. The framework is also characterized
as tightly coupled, which is inherently unable to rapidly adept to change.

Proposed  application  and  integration  framework    

Service  Oriented  Architecture  
The  services  envisioned  are:    

─ Analytic  engine  for  determining  applicable  award  conditions  and  pay  

─ Entry  
rules   of  scheduled  rosters  
─ Entry  of  timesheet  and  adjustment  to  rosters  to  reflect  actual  hours  
─ Identification  
worked       of  breaches  in  award  conditions  and  conflicts  with  
scheduled  rosters  
─ Support  for  a  Payroll  Portlet  
─ Support  for  integration  to  existing  SAP  ERP  enterprise  systems.  

Integration  Framework.    
 
An  integration  platform  that  can  be  considered  is  SAP  NetWeaver  [8]  which    

─ Seamlessly  integrates  to  existing  enterprise  applications  from  the  same  

vendor.  
─ Claims  to  adopt  open  standards  and  SOA  enterprise  integration.    
─ It  is  only  or  internal  use  by  QH  and  adopting  a  simpler  and  less  heavy-­‐
weight  framework  like  RESTful  API  is  preferred.  

A  Message  Oriented  Middleware  using  XML  format  can  be  considered.    

─ Workbrain  predominantly  uses  XML  and  Java  and  there  are  many  middle  
tier  options  available  in  Java  (e.g.    RMI  ,  CORBA)  and  XML  is  a  universal  
standard.    
 ─ Payroll  applications  are  normally  processed  in  batches,  real  time  pro-­‐
cessing  is  not  presumably  not  significantly  needed  and  asynchronous  
message  transfer  will  suffice.  
─ The  middleware  can  also  mediate  for  differences  in  data  and  interfaces  
requirements  of  participating  applications.  
For  a  vendor  neutral  product,  the  open  source  enterprise  service  bus  can  be  con-­‐
sidered.  

Use  of  Cloud  Services.    

 
As  QH  and  CorpTech  are  unlikely  to  possess  the  expertise  for  on  premise  
private  cloud  computing  and  have  no  resources  to  develop  that  capacity,  an  out-­‐
sourced  cloud  services  has  the  potential  to  reduce  costs.  Integration  as  a  service  
hosted  on  the  cloud  is  recommended.  

Self-­‐service  portlet  for  payroll  matters  and  use  of  mobile  devices    
─ The  portlet  can  be  used  to  enter  time  and  attendance  and  provide  payee  
feedback  loop  to  detect  process  dysfunctions.    
 
─ Mobile  devices  such  as  tablets  and  phones  can  be  used  to  upload  time-­‐
sheets.  Actual  hours  worked  can  then  be  entered  immediately  leading  to  a  
more  accurate  and  timely  data.  

7 Conclusion

Dr.  Mansfield,  who  has  considerable  experience  and  qualifications  engaged  by  
QH  for  the  review  of  the  failed  QH  Payroll  system,  summarized  his  finding  by  
stating  that    

“There  was  plenty  of  active  oversight  of  the  program.  However,  successful  
governance  is  not  just  about  having  processes,  but  about  how  governance  
processes  and  tools  are  used  to  get  the  result.”  [1]  

The  ‘As  Is’  process  was  widely  acknowledged  as  complicated  and  needed  to  be  
discovered,  simplified,  consolidated  and  shared  to  stakeholders  to  provide  as  a  
foundation.    Hence,  the  ‘To  Be’  process  is  as  a  consequence  not  clear  and  not  
shared  to  stake  holders  to  ensure  effective  delivery  and  mitigate  risks.  The  de-­‐
fined  industry  standard  on  quality  assurance  was  knowingly  by  passed  by  all  
parties,  leading  to  a  system  that  was  defective,  inefficient  and  costly  to  develop,  
operate  and  rectify.  
The  need  for  an  effective  business  process  on  governance  is  made  more  
critical  due  to  the  short  delivery  time  frame,  unclear  business  requirements  and  
unclear  project  governance.  Results  could  had  been  better  achieved  if  current  
processes  were  identified,  optimized  and  extensibly  modeled  using  of  existing  
industry  Business  Process  Modeling  tools  with  accompany  BPM  suite  of  products  
for  its  development,  rollout  and  operation.  
The  spectacular  failure  of  this  project  caused  the  Queensland  government  
to  abandon  in  January  2009  its  centralized,  whole-­‐of-­‐government  shared  ser-­‐
vices  approach.  The  design  and  implementation  of  a  new  payroll  system  for  
Queensland  Health  (QH)  was  the  only  remnant  of  the  shared  services  initiative.  
[1]  

References:  

1. Richard  Chesterman,  Payroll  System  Commission  of  Inquiry  Report,  31  July  2013  
2. David  Klein,    Anatomy  of  an  IT  Disaster  -­‐  How  the  IBM/SAP/Workbrain  Queensland  Health  Payroll  System  
Project  Failed,  13  July  2010.http://ddkonline.blogspot.com.au/2010/07/anatomy-­‐of-­‐it-­‐disaster-­‐how.html  
3. KPMG,  Queensland  Health  Payroll  Implementation  Review  Interim  Report  –  Stage  2,  18  May  2010  
4. KPMG,  Review  of  the  Queensland  Health  Payroll  System  31  May  2012  
5. Bond,  Darrin,  Exhibit-­‐171-­‐BOND-­‐Darrin-­‐Re-­‐Comments-­‐regarding-­‐the-­‐use-­‐of-­‐Workbrain,
http://www.healthpayrollinquiry.qld.gov.au/__data/assets/pdf_file/0014/203117/Exhibit-­‐171-­‐BOND-­‐Darrin-­‐
Re-­‐Comments-­‐regarding-­‐the-­‐use-­‐of-­‐Workbrain.pdf  
6. Department  of  Health,  Information  Sheet  -­‐  Queensland  Health  rostering  and  payroll  environment,    
http://www.health.qld.gov.au/ohsa/docs/6-­‐5.pdf  
7. Omar  M.  Ali  ,  IT  Governance  in  Shared  Services  in  Public  Sector,  University  of  Southern  Queensland,    
8. SAP,  SAP  NetWeaver,  April  2014,  http://en.wikipedia.org/wiki/SAP_NetWeaver  
9. James  Hutchison,  Computerworld  –  CorpTech  called  to  account  for  shared  services  failing,  7  Juy  
2010,http://www.computerworld.com.au/article/352346/corptech_called_account_shared_services_failing