Posts Tagged best practice
I am exploring the topic of what makes an excellent project manager, potentially for an article on this blog.
Is it knowledge? Character? Experience?
Thoughts and suggestions at any level of detail and however factual or intuitive are welcome!
To participate in this discussion please join me on LinkedIn (http://www.linkedin.com/in/lukeandreski), email me (la[at]andreskisolutions[dot]com) or add your comments below.
In giving this article the title I have given it I might be accused of miss-selling… however, and quite unexpectedly, I find myself, if not exactly excited by, then at least seriously interested in, the topic of project filing.
A significant element of any project manager’s work is to collate, create, review and update documents which relate to the project or projects in hand. For this reason it is important that project documents are filed in an intuitive and sensible way, reflecting both the project management methodology being used and the life cycle to which the project adheres.
Currently I prefer to work with the Project Management Institute’s ‘Project Management Body Of Knowledge’(PMBOK) methodology, with its nine knowledge areas: Scope, Integration, Time, Cost, Quality, Human Resources, Communications, Risk and Procurement. These need to interface with the typical life cycle of the projects with which I am currently involved: initiation; planning; analysis and design; system configuration; data migration; testing, documentation and the transition to operational live running. Then of course there are the pragmatic considerations of information storage and retrieval: What do you need immediate access to as soon as you open a project file? What folders will you need to access most often? Are there other areas of documentation or data which are not covered by the matrix of knowledge areas vs. life cycle? How can you ensure your file structure is intuitive and easy to adopt?
With all this in mind I have devised a project file and folder structure for use with both hardcopy and electronic filing which I have tested against the storage requirements of real project data.
This structure seems to me to work… but is it the best?
Take a look:
The Project File
Folder 1: Stakeholders and Contacts
This folder will include simple contact lists as well as stakeholder analysis and stakeholder management planning
Folder 2: Governance – Charter and Scope
This folder will include the contract, initial scoping documents or terms of reference, the project initiation document or charter, and any further detailed scoping. In other words, all the documents by which the project is initially defined
Folder 3: Project Planning
Once you have established the scope of your project – the objectives, requirements, outline timescales and budget – serious planning can commence, and this folder should contain not only the usual MSP Gantt charts but also meta-planning documents such as your plans for project management, for quality assurance, for human resource management, for communications and so on
Folder 4: Status – Activities Issues and Risks
To include status reports and updates, issue logs, risk logs and schedule variance
Folder 5: Status – Costs
This folder will include budget or project costs and utilisation reports, and earned value or other assessments of value achieved versus expected. The utilisation of third party deliverables should also be reflected here. This area is given a folder in its own right to reflect the importance of cost within most organisations
Folder 6: Change Control
To hold change requests, both pending and authorised. These, in conjunction with the data held in the Governance folder, define the project
Folder 7: Project Coordination
This folder holds the ‘project office’ type of documentation not already covered by the other folders: the agendas, papers and minutes for formal meetings(such as Board and Project Team meetings). Also documentation related to supplier management or the administration of supplier deliverables such as training and consultancy
Folder 8: Project Data
This folder holds the data associated with the life cycle of your particular type of project, e.g.
8.1 Analysis and Design
8.2 Infrastructure and system administration
8.3 System configuration and build
8.4 Data migration
8.5 Testing and quality control
8.6 Procedures, manuals and guides
Folder 9: Phase and Project Closure
To hold documentation relating to the closure of phases or the project as a whole, including the documentation of lessons to be learned
Folder 10: Miscellaneous
…because there will always be some documents which are impossible to categorise or which do not deserve a category of their own.
This is how I have begun to structure my project files. How have you structured yours?
Luke Andreski PMI PMP
I am a project manager with many years’ experience in HR and Payroll system implementations. I am in the process of completing my most recent contract for the housing and care organisation Midland Heart. After a one or two month break I will be seeking a new contract from August/September 2013 onward.
Implementing HR and Payroll systems is a precarious business. Whether you are looking at e-recruitment, training systems, core HR and Payroll, document management, workflow, P11D, talent management or self service solutions, the business environment in which your implementation will take place is complex, evolving, effected by organisational ethos and constantly striving for synergy between the employees’ needs and those of the employing organisation. Throw into this heady mix the divergent temperaments of technologically astute system developers and payroll- or people-focussed system users and the implementation of new software can be quite a challenge…
This is a challenge, however, which offers considerable rewards.
Successful ERP, HR and Payroll implementations can offer:
– improved organisational morale;
– increased employee engagement with the processes and objectives of their employer;
– a shift in the focus of talented staff from admin to strategy;
– consolidated management information;
– devolved and more timely input of data;
– improved business processes;
– more effective workflow
But what is the trick to realising these benefits? What are the ingredients needed to get your system implementation right?
A contract that works
A decisive starting point for your implementation is a well formulated contract with the supplier. Useful features of such contracts include:
– SMART delivery targets
– A detailed and binding confirmation by your supplier of the extent to which they can meet each and every requirement in your ITT
– A supplier-incentivising payment profile
– Penalties for non-performance
– Defined implementation consultancy and support
– An agreed change control procedure; and
– Clear lines of escalation…
If your contract is cursory, vague or simply inadequate, as software and services contracts often are, then you must make sure your project begins with the development of a detailed project charter or Project Initiation Document which both you and your supplier sign up to before work begins. Then, whether you have in your possession a good contract or a good Project Initiation Document, you should keep this in your back pocket at all times – and be ready to call on it at a moment’s notice.
It is essential to ‘work your contract’, making sure your agreed objectives are met and the promised deliverables delivered. This means keeping a tight rein on change control, documenting even honeymoon lapses in supplier performance, and ensuring your supplier is always aware that you expect them to meet both the letter and the spirit of your initial agreement.
Manage your supplier
As the saying goes, keep your friends close but your supplier closer. Throughout any software or service implementation it is important to insist on high level supplier representation at Performance Reviews, Steering Group and Project Board meetings. Your supplier’s representatives will far rather get it right, or fix it quick, than explain, face to face, why they got it wrong!
It is important that you own your project’s deliverables; and it is equally important, if your contract permits this, that you maintain some degree of payment leverage. For most suppliers the bottom line is the bottom line. If at all possible, you need to be able to maintain financial leverage up to the last possible moment, otherwise you will find, once the bulk of your payment has arrived in your supplier’s bank account, that their interest in your project rapidly diminishes.
Rigorous project management
Of equal importance to supplier management is the management of your own organisation. No matter how tempting it may be, organisations must avoid improving upon their original objectives. Stick to the initial scope of the project and you are far more likely to end up with demonstrable success.
Your project manager must manage your internal stakeholders, keep them informed, and ensure that all those departments or teams effected by your project also recognise their responsibilities towards it. Similarly, your project sponsor must ensure executive level participation, and publicise the executive level commitment to the project.
Communication at all levels is a key ingredient of successful projects.
A strong project team
Your project team will be central to your implementation… and should include:
– Senior members of the effected departments empowered to make system set-up or business process decisions without recourse to committee
– Hands-on team members to undertake the non-strategic work; and
– Supplier-provided consultancy with in-depth knowledge of the system and its implementation.
At various points in the implementation you may also wish to include in the team:
– Business process analysis and re-engineering expertise
– An expert on documenting the use of the system
– Dedicated resource for project communications; and
– Super-users who participate in pilot and parallel running.
Further recommendations in regard to the project team are:
– That core membership of the project team should be dedicated to the project full time
– That nominated individuals continue to work with the system after project completion, thus benefitting the organisation with the expertise gained during the project; and
– That a discrete project area is provided for the duration of the project.
A project board or committee should also be convened, inclusive of executive-level representation, senior management from the areas affected (including IT), and a nominated project sponsor.
Other key factors of successful projects
Further recommendations towards ensuring project success:
– Purchase sufficient expert consultancy for your project, but emphasise skills transfer from consultants to employed staff during the implementation period;
– Purchase sufficient system training, and also plan for in-house, cascade training where required;
– Work to a plan and change control any deviation from it;
– Develop test scripts and test rigorously;
– Phase your implementation, allowing time to get each phase right;
– Include pilot or parallel running in any project;
– Educate stakeholders to expect a productivity dip after system implementation, as the new processes bed-in and familiarity with the system is acquired;
– Engage with other organisations who use the new system; and
– Encourage the project team and stakeholders to enjoy and take pride in the project… It’s not every day that you get new toys or the chance to learn new things!
A Challenge Successfully Met
I hope these suggestions and tips offer some little guidance toward ensuring that your system implementation is a successful one. If you have other recommendations for increasing the success of ERP, HR or Payroll projects please get in touch via my blog.
In summary, within complex and forward-looking business environments the roll-out of new software or services is a major challenge… but it is a challenge which your organisation can, with a little planning and foresight, successfully and rewardingly meet.
Luke Andreski PMI PMP
A version of this article appeared in the respected Digby Morgan Newsletter, Human Resourcefulness
© 2013 Luke Andreski. All rights reserved.
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
- 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.
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.
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 2012. All rights reserved