Prerequisites For Successful HR and Payroll System Implementations

Introduction

Before an HR or Payroll system implementation can begin, a number of important activities must already be underway or drawing to a close. This post briefly looks at the following:

  • The decommissioning of the existing system
  • The procurement of a new system
  • The opportunity for a business process review
  • Other important ‘up front’ success factors.

Decommissioning The Current System

The decommissioning of the current HR and Payroll system can be considered a project in itself. This project should include:

  • A review of the current system’s strengths and weaknesses
  • An analysis of how the system’s weaknesses may be addressed by a new system
  • Consultation with champions of the current system, if there are any, to ensure buy-in for system change (i.e. the initial stages of change management)
  • A cost/benefit justification for moving from the current system; and
  • Decisions on which current system data should be deleted, which should be archived and which data should be cleansed for loading onto the new system. It is best practice within system transitions for the new system be populated only with data that has been checked for accuracy, coherence and integrity. It is also crucial for the implementation of the new system that close attention is given to – and time allowed for – the data mapping process.

The analytical outputs from the decommissioning exercise will feed into the procurement process for the new system and into the initiation and planning stages of the implementation project.

The decommissioning of the current system may be dealt with as a subproject of the implementation project, but it should nevertheless be undertaken rigorously, with the activities described above commenced well in advance of acquiring the new system.

System Procurement

The procurement project will have outputs of central importance to the implementation project. These outputs should include:

  • The initial business case for the system transition, which may feed from the decommissioning exercise
  • A Schedule Of Work or detailed definition of the requirements which the new system and its supplier must meet
  • A contract which includes:
    • Delivery targets
    • Implementation timescales
    • The supplier’s detailed confirmation of the extent to which they can meet each individual requirement in the SOW
    • A supplier-incentivising payment profile
    • Penalties for supplier non-performance
    • Insurance against subcontractor non-performance
    • Defined implementation consultancy and support
    • Defined system and DBA training
    • A detailed Support SLA including escalation points
    • System performance guarantees
    • An agreed change control procedure
    • A supplier/client conflict resolution strategy
  • The purchased software, hardware, database environments, comms, services and implementation support.

It is essential, in addition to the organisation’s procurement team and representatives from IT, that both senior and junior HR and Payroll users are engaged in the selection process. Representation should also be sought from other important stakeholders, such as Finance, Audit and the employees themselves.

Business Process Review

An opportunity which should not be missed when taking on a new HR and Payroll system is that of reviewing the efficacy and cost-effectiveness of the business processes being supported by the system. The business process review should cover:

  • Document and data flows
  • Authorisation processes
  • The practices, codes and calculations used in areas such as absence recording
  • System-related HR processes and procedures in general
  • Departmental boundaries and responsibilities – and whether these should be modified in light of the capabilities of the new system
  • The data required by the organisation and who should have access to that data
  • The standardisation of data formats and codifications throughout the organisation; and
  • Whether all the reports currently generated are needed and what new reports might be required.

Other Important Success Factors

Other precursors to a successful HR and Payroll system implementation include:

  • Commitment to system change by management at an executive level
  • A recognition of the size and complexity of the forthcoming project. HR and Payroll implementations can range in duration from four months for a small company with straightforward pay and employment conditions to nine months for companies with employee numbers in the low thousands… through to twenty-four months for very large organisations taking a phased implementation approach
  • Detailed, up front project evaluation and planning
  • A financial commitment recognising the many factors of a system change of this sort, inclusive of:
    • Hardware, software and comms
    • Project management
    • Expert consultancy
    • Training consultancy
    • Project staff
    • Time taken from HR, Payroll and Finance staff for initial consultations through to testing and parallel running; and
    • Temporary productivity reduction whilst familiarity is gained with the new processes and system.

For an extended discussion of the key features of successful HR and Payroll implementations, please see the document ‘Best Practice for HR and Payroll System Implementations’ on this blog.

Conclusion

Implementing a new HR and Payroll system does not begin when system access is first provided to the project team – or even with the signing of the contract for the new system. A rigorous procurement exercise must first take place, and this should be supported by analysis of the reasons for change, the production of a compelling business case, the production of a comprehensive requirements document and some anticipatory change management.

Undertake these activities and your implementation should get off to a running start.

Luke Andreski

www.andreskisolutions.com

©  Luke Andreski 2012. All rights reserved

Comments and feedback welcome!

 

Advertisements

, , , , , , , , , , , ,

1 Comment

Best Practice For HR and Payroll System Implementations

Introduction

HR and Payroll systems are required by all types of employing organisation to support the administration of employees, the payment of employees, the management of employee data and the provision of management information. This need is met in the UK by database and software providers such as SAP, Oracle, Ceridian, NorthgateArinso, Unit4, MidlandHR and many others, offering web and server-based, in-house, partially managed or outsourced solutions.

Over time organisations outgrow the systems they use (or which are used on their behalf) and the transition to a new system becomes essential. Transitions are also compelled by statutory change, software end-of-life, business reorganisation, company buy-outs, technological advance and changes in management focus or direction.

As a result a continuous demand exists in all market sectors for the decommissioning of current HR and Payroll systems and the implementation of new ones.

This document seeks to identify best practice for such implementations, and in doing so I cover the following areas:

  • The implementation project life cycle
  • The project team
  • Project initiation and planning
  • Core HR and Payroll system implementation activities
  • Best practice project management
  • Key features of successful implementations; and
  • Similar types of implementation

Initially I focus on in-house implementations, where a project manager and project team work in the host organisation to implement the new system, and the system supplier provides system expertise in the form of consultancy. I will discuss the implementation as if it is one of a combined HR and Payroll system. These considerations will also apply to the implementation of HR and Payroll modules within an ERP solution.

The Implementation Project Life Cycle

In PRINCE2 and PMBOK the definition of a project life cycle is very similar:

  • Initiate the project
  • Undertake a detailed fact finding and planning exercise
  • Execute the stages or phases of the project
  • Formally close each stage or phase (signing off against predefined success criteria and taking forward lessons learned)
  • Project closure

Both methodologies give a detailed breakdown of how each of these life cycle elements must be executed and controlled to minimise the risks of schedule slippage, cost overspend and unsatisfactory deliverables. The project management activities that bracket the delivery phases of the project – objectives definition, scoping, requirements gathering, planning, learning lessons, performance measurement and project administration – are all about ensuring that organisations get right the fundamental, deliverable-based core of the project.

Given the range of deliverables required from HR and Payroll implementations, it is crucial that a structured approach along the above lines is adopted.

The Project Team

A project board or committee should include executive-level representation, senior HR and Payroll management, an IT manager or director, and a nominated project sponsor. It may also include a senior supplier representative, an employee representative and representatives from affected departments such as Audit, Finance, Training and Recruitment. The latter group may not need to attend all Project Board meetings (or all parts of each meeting).

The project team should include:

  • The project manager
  • A senior HR officer or manager, empowered to make system set-up and HR process decisions on behalf of the organisation (avoiding ‘decision making by committee’)
  • A senior Payroll officer or manager, empowered to make system set-up and Payroll process decisions on behalf of the organisation
  • Experts in the process areas affected by the implementation
  • Hands-on team members to undertake non-strategic work
  • A representative from IT; and
  • A supplier- or third party-provided consultant with prior knowledge of the system and its implementation.

Depending on the size of the project, the team may also at some point include:

  • Business process  re-engineering expertise
  • Experts in documenting the use of the system
  • Additional external consultancy
  • Trainers
  • Dedicated resource for project communications
  • Dedicated Business Intelligence resource; and
  • Super-users participating in pilot and parallel running.

Key recommendations in regard to the project team are:

  • That the core team members are dedicated full time to the project
  • That supplementary resources are assigned to the project on the basis of agreed time allocations
  • That the team includes representation from all areas within which the system will be implemented
  • That, prior to or at the commencement of the project, the project team are trained in how to work together as a team on this kind of project
  • That at least some of the project team members are able to continue working with the system after project completion, perhaps in a system support capacity, thus benefitting the organisation with the expertise gained during the project
  • That a project area or project HQ is provided for the duration of the project, where the project team will be based.

Initiation And Planning

As a minimum, project initiation must include the creation and signing-off at an executive level of a Project Initiation Document, a Project Charter or a Project Brief, on the lines defined within PRINCE2 and PMBOK. The project initiation should also include detailed stakeholder analysis and the allocation of resource for the initiation and planning stages of the project.

As a minimum the project planning stage should generate strategies for controlling the cost, the timing, the quality of outputs and the risks of the project, and provide detailed plans for project execution, communications and control.

Phasing, both in functional terms (e.g. initial roll-out of core HR plus Payroll, then Training or Recruitment, then Employee Self Service) and in terms of business area or geographical location, is generally recommended for HR and Payroll implementation projects. It is also advisable within large implementations to undertake initial pilot runs, over and above the parallel running, even within a functional or business area.

Core Implementation Activities

HR and Payroll system implementations will typically include the following activities:

  • System, hardware and comms delivery and configuration – preferably with multiple environments allowing for training, testing, trial system configuration and setup, and parallel and live running
  • DBA setup, with immediately active backup protocols and the ability to restore or copy environments promptly when required
  • Project team training
  • System setup: parameters, tables, hierarchies, rates, calculation formulae and rules, menus, security etc
  • Development and upload of bespoke software, interfaces and reports
  • Data cleansing (assuming data will be migrated from the legacy system)
  • Data migration tests
  • Iterative testing of system setup, bespoke software, interfaces, reports and system functionality
  • Production of user guides and other documentation
  • Training for the users who will be involved in acceptance testing, pilot and parallel running
  • User Acceptance Testing of end-to-end processes, inclusive of interface testing
  • Data migration for parallel and pilot running
  • Parallel and pilot running
  • Remaining user and manager training
  • Phased rollout (by functional and/or business area, with relevant data migrations if applicable)
  • Phase closures and the carrying forward of lessons learned
  • Project completion

All these activities must be actioned in accordance with the project plan and closely monitored for timeliness, cost, quality and risk. Preventative and corrective actions must be taken when necessary to ensure the project remains on time, on budget and ‘on spec’. Guidance for achieving this will be offered by the adopted project management methodology.

I recommend, where both HR and Payroll systems or modules are being implemented within an organisation, that they are implemented at the same time, in order to gain efficiencies in terms of project workload and cost. Where this is not possible, I recommend that the implementation of the HR system or module takes place first. The reason for this is that the system configuration and setup that is common to the two areas is more complex on the HR side (e.g. organisational hierarchy, employee records, absence recording) and it is easier to utilise a subset of a pre-existing configuration than to build a complex configuration on the back of a simpler one.

Best Practice Project Management

Where a proven methodology is already in place within an organisation then I recommend that this methodology is used for the HR and Payroll system implementation.  It is important that the project manager and team use the same ‘language’ as their colleagues, and that the documents, reports and strategy for the project are recognisable and broadly understood.

Where an organisation is not using an in-house methodology I recommend either PMBOK or PRINCE2, with partial adoption of some of the efficiency strategies of Agile.

In addition to a project management methodology, the HR or Payroll implementation will require a protocol for configuration management. This ensures traceability from the initial project objectives through to the final outcomes of the project. Configuration management also ensures that version and change control are rigorously documented throughout the project.

As with the project management methodology, if there is a protocol for configuration management already in place this should be used; otherwise a proven example should be adopted from an external source.

The considerations detailed above clearly apply to best practice project management in general. Activities which the project manager of an HR and Payroll system implementation may wish to additionally emphasise are:

  • Stakeholder management
  • Project communications (including communicating with employees); and
  • Supplier management.

For further guidance in regard to project management best practice, please see ‘A Perfect Plan’, also in this blog.

Other Features Of Successful HR And Payroll System Implementations

The following factors are recognised as contributing to successful HR and Payroll system implementations:

  • Clearly defined objectives and success criteria
  • The participation and publicised interest in the project of management at an executive level
  • Buy-in at all stakeholders levels
  • Allocation of responsibility for the implementation to all the departments within which the system is being implemented
  • The purchase of sufficient expert consultancy, with an emphasis on skills transfer from consultants to employed staff during the implementation period
  • The purchase of sufficient system training
  • Sufficient payroll parallel running, for example two monthly payrolls paralleled over six weeks, with weekly and other payrolls being paralleled  within this period
  • Interfacing the new HR and Payroll system with other systems within the organisation wherever possible to minimise data entry. The new system should become the core repository of employee data. This requirement is potentially met within ERP implementations, offering HR and Payroll modules as part of a larger functional suite
  • Developing in-house Business Intelligence expertise for use with the new system, which remains available to the HR and Payroll teams after the implementation project is completed
  • Educating project stakeholders to expect a reduction in productivity immediately after system implementation, whilst the new processes bed-in and familiarity with the system is acquired
  • Engaging with other organisations which use the new system, and with a system User Group if one exists.

Similar Implementations

It is clear from the above that best practice for Payroll and HR system implementations will also apply to the implementation of other, similar systems, such as T&A, Pension, Finance, Recruitment, Training, Document Management and ERP packages. There will of course be changes of emphasis and the business expertise required by the project team will differ with each system or module.

Many of the practices detailed here will also apply to the implementation of partially managed or fully outsourced solutions, with the main difference being that the supplier will have to undertake much of the project work rather than the customer who is receiving the service. With suppliers who regularly undertake outsourced implementations the project will be more of a repeatable ‘process’ and therefore should entail less risk. However, new risk is engendered for the supplier through the supplier’s lack of direct experience of the client organisation’s internal working and the resultant increased need for fact-finding. The outsourced customer also inherits the risk of not being in direct control of the implementation and of not retaining or gaining system and procedural expertise should the outsourcing fail.

Conclusion

In conclusion, best practice within HR and Payroll system implementations mandates a closely planned and managed project with considerable commitment from the involved organisation. A successful project will demonstrate many of the features detailed above and offer the ultimate rewards of greater productivity, greater access to system processes and data, and the improved engagement of staff and employees with the objectives of the organisation.

Luke Andreski

www.andreskisolutions.com

©  Luke Andreski 2012. All rights reserved

, , , , , , ,

Leave a comment

The Perfect Plan

 

Two fundamental principles which underlie project management methodologies such as PMBOK and PRINCE2 are:

Look before you leap

and

Learn from when you fell.

These principles are elaborated into complex project management ‘envelopes’ surrounding what might be thought of as the delivery activities of the project – the aim being to ensure that these activities are accomplished successfully.

On this basis, I would suggest that the following list details the ideal project management envelope, into which the considerably more detailed delivery elements of any project can be inserted.

Project Assessment

Preliminary meetings

Determine project authority and status

Confirm Project Brief

Authorise Project Initiation

Project Initiation

Initiation Kick-off

Review Project Brief, Bus. Case, Contract, SOW

Identify existing processes and standards

Review political / organisational environment

Stakeholder Interviews and Analysis

Stakeholder analysis

Stakeholder interviews

Produce stakeholder list

Identify and Coordinate Project Initiation and Planning Resource

Agree Resource Reqs for Initiation and Planning Phase

Acquire Resource

Administer Resource

Develop, Sign-off and Publish Project Charter

Develop project charter

Publish draft project charter

Project charter review

Sign-off project charter

Finalise project charter

Sign-off project charter

Project Launch

Plan project kick-off

Project kick-off meeting

Project Planning

Develop Outline Project Management Plan

Project Requirements – Detailed Definition

Develop, Sign Off and Publish Detailed Scope Document

Develop Detailed Project Scope Document

Review Detailed Project Scope

Sign Off Detailed Project Scope

Publish Detailed Project Scope

Develop Work Breakdown Structure

Develop work Breakdown Dictionary

Develop, Sign-off and Publish Detailed Project Plans

Develop Project Schedule

Define Activities

Sequence Activities

Estimate Resource

Estimate Duration

Develop Project Schedule

Estimate Costs and Confirm Budget

Develop Human Resource Plan

Develop Communications Plan

Develop Project Risk Management Plan

Identify Initial Project Risks

Assess and Prioritise Risks

Develop Risk Response Proposals

Develop Risk Management Plan

Review Project Plans

Sign Off Detailed Project Plan

Publish Detailed Project Plan

      

Execute Project Phase 1

Establish Team and Infrastructure

Acquire Full Project Team

Set Up Team Infrastructure

Develop Team

Manage Team

Phase 1 Activities and Deliverables

Perform Work Activity 1

Deliver Work Activity 1 Result

Perform Work Activity n

Deliver Work Activity n Result

Phase 1 Monitoring and Control

Monitor / Control Activities 1 – n

Verify Scope of Activities 1 – n

Control Phase 1 Quality

Control Schedule and Costs

Control Risks

Close Phase 1

Lessons Learnt Meeting

Document Lessons Learnt

Update Project Documents

Sign Off Phase 1 / Authorise Phase 2

Execute Project Phases 1 + n

  

Project Closedown

Lessons Learnt Meeting

Document Lessons Learnt

Contracts Closure

Administrative Closure

The central purpose of all of this detail is to support the key delivery activities. The supposition of project management methodologies such as PRINCE2 and PMBOK is that phases 1 through 1+n will be delivered successfully – on time, on budget and ‘to spec’ – if a framework along the lines detailed above is rigorously applied. This is something with which I largely agree. However, a further and, I believe, utterly crucial requirement for project success is this: no project will be successful without enthusiasm for change, a powerful commitment to the project objectives, and a concern for the people involved in the project and affected by it.

Luke Andreski

www.andreskisolutions.com

© Luke Andreski2012. All rights reserved.

, , , , , , , , ,

Leave a comment

Agile, PRINCE2 and PMBOK

Introduction

This post briefly reviews the similarities and differences between PRINCE2, PMBOK and Agile, and suggests that best practice can be derived from elements within all three methodologies.

The Similarities

PMBOK and PRINCE/PRINCE2 are project management methodologies; Agile is a software development methodology that can be applied to some projects.

Similarities between all three methods are:

  •  They each provide a set of tools, techniques and templates for managing projects – avoiding the need for re-invention.
  • They each aim at tackling common and problematic project characteristics:

–          Accelerated change

–          New or unique deliverables

–          Limitations on resource or budget

–          Delineated timescales.

  • All three methods seek to reduce the risks inherent in undertaking projects: unsatisfactory deliverables; overspend; schedule slippage.

Key Differences

PMBOK and PRINCE2 are similar in offering a highly structured template for project administration and control. They differ in that:

  • PRINCE2 is more prescriptive in terms of project management outputs: e.g. baseline documents; configuration records and logs; reports.
  • PMBOK offers more guidance on the tools to be used: e.g. earned value analysis; three-point estimates; stakeholder matrices; information gathering techniques.
  • PRINCE2 emphasises the need to regularly review the business case for the project. PMBOK assumes that the business case is external to the project, once the project has been initiated, and that it is not in the control of the project manager.
  • PRINCE2 offers guidance for corporate as well as project management whilst PMBOK concentrates on the techniques, tasks and responsibilities of programme or project manager.

Agile offers a very different formula to both these methodologies.

PRINCE2 and PMBOK strongly emphasise the importance of planning, as per Deming’s ‘Plan, Act, Check, Do’ or Boyd’s ‘Observe, Orient, Decide, Act’. Agile, however, works on the assumption that the deliverables may be too complex or unknowable to be planned for up-front. More suitable, perhaps, to smaller projects with multiple deliverables, Agile (or Agile With Scrum) suggests a less formal project structure, with the project manager (or scrum-master) facilitating an iterative process of short development cycles or sprints. Each sprint, which must produce completed deliverables, may be as little as two weeks in length.

The key themes of Agile are: visibility; inspection; adaptation.

Agile can be characterised as encouraging self-micro-management by the individuals involved in performing the work.

Adopting Best Practice

I would suggest that PRINCE2 and PMBOK are on a par in terms of offering structured, detailed and comprehensive project management methodologies. I would favour PMBOK on the basis that it is less prescriptive and therefore more flexible, and to me, at least, PMBOK seems more intuitive: a clear and well thought-out formulation of good practice and common sense.

From both methods I would take forward:

  • Scrupulous planning
  • Rigorous project control
  • Clearly defined roles
  • An emphasis on communication
  • Clear and validated deliverables.

From Agile I would loot:

  • Quick-win deliverables where possible
  • An emphasis on team and individual initiative
  • Protocols for meetings, such as the ‘scrum meeting’ where each project team member has two minute to answer three questions:

–          What have you achieved on this project since the last scrum?

–          What are you planning to achieve by the next?

–          What if anything is preventing you from meeting your commitments to the project?

Conclusion

The PMBOK, PRINCE2 and Agile methodologies have each gained large numbers of practitioners around the world. This is because each offer compelling methods for dealing with the administration and management of projects. It therefore seems likely that best practice will eventually be defined as an adaptive hybrid of all three schools of thought.

Luke Andreski

https://andreskiprojectmanagement.wordpress.com/

www.andreskisolutions.com

Feedback on any of my posts and the issues they discuss is very welcome.

© 2013 Luke Andreski. All rights reserved.

, , , , , , ,

1 Comment