Archive for category ERP

Managing Your Software Or Services Supplier

A reputable supplier

You are transitioning between services or systems. You have a good contract. You have a strong project team. You have selected a reputable supplier. What could go wrong?

Almost by definition all transitions are subject to increased risk. This may be due to lack of familiarity with the new supplier and their service or software; it may result from ambitious timescales; or it may arise from resource limitations and budget constraints. Whatever the reason, it is certainly the case that something can and probably will go wrong: with the deliverables, with the delivery, with the relationship between you and your supplier.

In Getting System Implementations Right and Prerequisites For successful HR and Payroll Implementations I discuss strategies to minimise the risks within organisations for transitions of this kind. In this article I look at ways to address the risks which arise specifically from your supplier and your relationship with them.

Common weaknesses

As a first step towards the management of your supplier it is important to identify their potential weaknesses. During the sales process you should ask your supplier to assess their own weaknesses, both past and future, and how they intend to address these in relation to any arrangement with yourselves. An independent assessment of your supplier’s weaknesses should also be undertaken through research, trawling the internet and speaking with existing customers. Weaknesses you are likely to find will include:

  • Diminishing commitment once the sale is agreed and the contract signed
  • Poor relationship management
  • Erratic communication, both internally and with their customers
  • Inadequate resourcing, in terms of availability and skills
  • Failings in the product or service delivered
  • Insufficient implementation support
  • Tardy operational support
  • An unhelpful corporate ethos

I will discuss these, and the measures you can take to reduce their likelihood and impact, below.

Perfection itself?

In seeking to manage your supplier it may not be weaknesses solely on their part which need to be identified and addressed. No organisation is perfect, and you will need to mitigate against weaknesses of your own. Examples might be:

  • Insufficient resourcing of supplier management
  • Unfocussed communications with your supplier
  • Insufficient clarity of purpose
  • Inconsistency in negotiating issue resolutions
  • Lack of forcefulness

Mitigating risk

Once you have identified the potential risks inherent in your relationship with your supplier or in their delivery of product or service, you will need to put in place actions or plans to mitigate against these risks.

Supplier commitment and motivation

How can you ensure the continuing commitment of your supplier after the sale has been agreed? Once your contract with your supplier is signed, the charming and effective sales wing of your supplier’s organisation will hand you over, as a new project, to their delivery team. In many organisations what happens next will have little impact on the staff with whom you were to that point involved. The sales team will turn their attention to new prospects and new sales, and your new contacts will have a less compelling (i.e. no longer commission driven) motivation to meet your needs.

You may also discover that you are one amongst many projects which the delivery teams have in hand, and not necessarily one with the highest priority. Larger and more assertive customers will take precedence over smaller or less demanding newcomers; customers with issues will always jump the queue; and your needs as an organisation are now in the hands of people with whom you have not yet developed a working relationship.

Pre-emptive measures to ensure the commitment of your supplier after this handover takes place need to be included in your contract. Ideally, the contract should include:

  • Delivery targets
  • Implementation timescales
  • The supplier’s detailed confirmation of the extent to which they can meet each individual requirement in a contractual requirements document or ‘statement of work’
  • 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
  • Defined skill sets and experience levels for each of the areas in which consultancy will be provided

If any of these elements are missing, then the time to revisit them is now. It is unlikely that your supplier will agree to enhance their contract with penalties for non-performance, but they should be willing to document the levels of service to which they will commit, and the measures they will take should failings arise.

To further motivate them, ensure that senior supplier representatives attend Steering Group or Board level meetings where the progress of the service or software implementation is reviewed. No one enjoys publicly representing an organisation which is providing a poor service, and the supplier’s representative will be motivated to see that the job is done well simply through being faced with the prospect of seeing you again in three or four weeks’ time.

You should also ensure that the supplier recognises that your motives and theirs are congruent. You want their software or service to be successful, and it is useful to emphasise to the supplier your willingness, if the implementation is successful, to publicise this. If your supplier performs well you should make it clear that your organisation will be in the vanguard of singing their praises: a reference site for potential future customers and an example of the best practice use of their system or service.

For most suppliers, the bottom line is the bottom line. You need to be able to maintain financial leverage up to the last possible moment, since, once the bulk of your payment has been deposited in their bank account, your supplier’s interest in you may mysteriously diminish. This applies both to the whole implementation or any part of it. Where possible, never pay for any deliverable unless you are sure that the deliverable you are paying for is one hundred per cent complete. Again, where possible, never pay for completed deliverables if other deliverables which should have been completed from the same supplier or their subcontractors are still outstanding. In addition, you should attempt to delay payments until the end of a period of time sufficient for resolving teething problems. Ideally, the basis for these activities will be confirmed rather than restricted by your contract.

If you are lucky enough to have a contract which imposes penalty clauses for poor performance, make sure these are kept in mind and regularly reviewed.

Finally, connect and communicate with existing users of the system or service at an early stage. Their experiences and support may prove a useful asset in your management of your supplier.

Relationship management

If a supplier is providing you with a product or service over an extended period of time which is important to your business or project, then it is important that you maintain both a good and a firm relationship with that supplier. But a relationship cannot exist where there is no continuity of contact, therefore a degree of contact, determined by the importance attached to the supplier’s contribution to the project, is a key initial requirement to managing your supplier.

It is beneficial if the supplier’s representatives like you, but this is by no means necessary; it is far more important that they feel the need to keep you on-side through providing an excellent service.

For an important supplier this may mean a daily telephone conversation, face-to-face meetings every week or every fortnight, and a senior representative from the supplier attending service review or board meetings every three weeks or month. It is important that the meetings with the supplier be friendly, honest and problem solving, rather than blame directing, but it is also important that the supplier be kept aware that penalties – where available – will be incurred for non-performance or failings in performance. You must also make it known to your supplier that they are expected to give warning of potential failings in delivery or service well in advance, in order that mitigations can be planned and undertaken in good time.

Clear escalation paths need to be agreed for the different types of issue that might arise (e.g. commercial, contractual, service or product), but informal lines of communication should also be nurtured. This can be achieved through attendance of user groups or conferences provided by the supplier, through informal relationship building and through such things as connecting at a senior level via LinkedIn.

A conflict resolution strategy should be documented and agreed with your supplier, and this should include the involvement of managers in both organisations who are not direct participants in the relevant implementation or project, thus permitting greater objectivity when resolving issues.

It is certainly important to keep the relationship sweet; but this is trumped by the need for firmness, honesty and a positive problem-solving approach.


As a general rule it is safe to assume that your supplier, after sales, will be a poor communicator, both internally and with their customers. Sales staff are selected for their communications skills, but mid-level delivery managers are usually selected for their technical or area knowledge – and it is likely your supplier’s delivery team will be drawn from a technical background or from work areas centred on a narrow business focus.

To address this your project manager and other involved managers should be briefed to pre-emptively encourage good communication. Ensure progress reports are shared with your supplier; and request a similar level of communication in return. As noted above, ensure regular contact, by phone, skype, email and face to face. Make sure you have an ‘open door’ policy with your supplier which works in both directions; and quickly escalate your concern if areas of communication appear weak.


At the beginning of your project (ideally during contract negotiations) ask your supplier to advise what consultancy or training is likely to be required at each stage of the software or service implementation, and ask them to provisionally book experienced staff to provide these services at these times. Ask your supplier to be proactive and to pre-emptively assign resource to your implementation, especially if they reach preferred supplier status. After contract signature, follow this through for each phase of your implementation, checking your supplier’s resource allocation for all remaining phases. If this isn’t pursued vigorously you may find yourself being provided with stopgap or inexperienced staff, while the best staff are allocated to other, more demanding clients…

Request the CV or skill set of every person or role the supplier intends to deploy to meet your requirement, and ensure that your organisation is not used as a training ground for untrained staff or recent recruits.

Finally, make sure your supplier is aware of your expectations of their consultants, in terms of behaviour, dress, and time spent on site. Some suppliers may ‘try it on’ and factor the travelling time of their consultants into your working day. Ensure this is nipped in the bud early, before a pattern is established.

Failings in product or service

No matter how good your supplier is, there will always be failings to a greater or lesser degree in their delivered product or service. And no matter how well you get on with your counterparts in your supplier’s organisation, these failings should be closely monitored, documented and communicated. You should never leave your supplier in the position of being able to say, ‘Well, you never told us anything was wrong…’

To support this, you will need a clear requirements specification or ‘statement or work’, which should have been compiled prior to – and used as part of – your contract negotiations. If this is not available, then your project manager and area experts should be tasked with producing documentation along these lines, against which to measure deliverables.

A test plan should be developed for every anticipated software release, upgrade, patch or change in service. As a recipient of such changes you should always assume that your supplier has inadequately tested the change. This is a characteristic universally shared by suppliers, no matter how well established or how good their reputation.

Prior to final payment for the implementation of a product or service, check for full compliance with the original agreement or contract. The supplier will invariably treat payment as acceptance, and subsequent fixes, even if implicit in the contract, will be slow in coming or charged as out of scope.

As noted above, where possible, and if your contract permits it, retain financial leverage…


Some elements of a new software or service provided by you supplier – particularly those which involve third parties – will involve significant delivery lead times. At the beginning of your project or implementation request your supplier’s expert advice on the lead times for any key elements of your deliverable which lie on the critical path for delivery. Examples of these might be the setting up of servers or comms, or the delivery of specialist training. Sometimes it will be worthwhile asking your supplier to provisionally book or initiate these activities prior even to contract agreement, if the lead time involved might otherwise delay the start of your implementation.

It is important to assume – in order to minimise risk – that your supplier will be forgetful. On this basis your project manager or other involved managers should generate prompts and reminders to your supplier well in advance of any deliverables on the critical path, and ensure that confirmation of readiness has been received in return.

Rigorous recording of the implementation services (and all other deliverables) provided by your supplier should be maintained at all times, independently of your supplier’s own records. Your supplier, no matter how well intentioned, will certainly bill you for every demonstrable deliverable, but they cannot be relied upon to keep a scrupulous record of deliverables or services they have failed to provide.

Operational support

The above considerations will also apply to the operational support provided by your supplier after your software or service has gone live. A continuing relationship should be nurtured at a senior level; clear communications and reporting should be maintained; and all failings or faults should be documented, reported on, and promptly escalated. The transition from implementation to operational support is similar to that from sales to implementation, with a similar risk of diminishing engagement by the supplier. It is important to proactively address this through your service level agreement and regular service reviews.

Ethos and attitude

Finally, in terms of supplier weaknesses, it is useful to understand, and, if necessary tackle, your supplier’s ethos and attitude. No matter what short term economic necessities are faced by your supplier, it will always be to their long term benefit to keep their customers happy and demonstrate their adherence to the principle that ‘the customer is always right’. Sometimes it is worth reminding suppliers of this fact.

You want the service you have bought… but in fact you want more than this. You want, as an organisation, to be treated well and with respect. You want to be treated as a valued customer, no matter what your financial value to your supplier or your size in relation to their other customers. And you need to make this known to your supplier from the moment you commence contract negotiations though to the end of your contract.


Resourcing the management of your supplier

All of the above activities of course require an investment of time and commitment on your part. This is true of all aspects of a project, and projects succeed or fail on the basis of the resource invested in them and the commitment made to them at a senior level. Your investment in supplier management therefore requires its own business case. If you are dealing with a small supplier whose contribution is minimal, then you may fine tune the resource you devote to managing that supplier. For very large projects, supplier administration may be farmed out to teams or departments who specialise in procurement, contract and supplier management. Alternatively, responsibility for coordinating supplier management may fall to a project manager or other senior involved managers. For smaller contracts or suppliers more junior staff may be assigned this responsibility. But at whichever level you choose to aim your supplier management, this should be a strategic decision on the part of your organisation – and the risk mitigations detailed above should all be considered, even if they are only selectively implemented on the basis of value and cost.

Communicating with your supplier

It cannot be assumed that your supplier’s contacts, once you have purchased their product or service, will demonstrate good or even adequate communication skills. As I recommend above, these skill may need to be provided proactively by your own organisation, and allowance should be made for this.

Forcefulness, consistency and clarity of purpose

Finally, in dealing with your supplier, you need to be clear about your objectives, reasonable in your expectations, unemotional, candid, forward-looking and professional. You should allocate your relationship management to individuals who are not easily overawed by senior supplier representatives. It is important to keep the relationship sweet, but it is more important to approach your relationship with a great deal of backbone, expressing your position frankly and not allowing suppliers to provide a service or product that is anything less than excellent. Excellence is what your supplier will have promised when striving to win your custom and, through rigorous supplier management, excellence is precisely what you should compel them to deliver.


In summary, you can gain the most from your supplier if you manage them closely and strategically. To do this you need a strategy for supplier management in general, and to tailor this to each specific supplier once you have ascertained their strengths and weaknesses. Expecting a supplier to manage themselves to your advantage, particularly if they have large numbers of other customers or clients, is unrealistic. If you approach your relationship with your supplier proactively, planning for the worst but asking for the best, this will give your relationship with your supplier, and the software or service they provide, the greatest chance of success.

Luke Andreski PMI PMP

© 2013 Luke Andreski. All rights reserved.


, , , , , , , ,

Leave a comment

An Exciting Article On Project Filing


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.

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

Leave a comment

Should Project Managers Roll Their Sleeves Up?

Might It Be Necessary?

There’s the project management aspect of any project… and then there’s the required output from the project…

The project manager takes care of the first; and the project team and nominated experts and assistants are responsible for the second.

But what happens when your project simply doesn’t have enough resource to support the required project output? Should a project manager roll his or her sleeves up and help? Is this a good idea? Might it be both necessary and what is expected of you? Or can it lead to disaster?

A Case In Point

The Project

On one of my recent projects, in an organisation I admired and whose staff were already working extremely hard, I made the conscious decision to roll my sleeves up. The project involved the implementation of new a Payroll and HR system and at the outset I realised that the resourcing was rather too low – but that it would be extremely difficult for my client to bring their resource to the levels I recommended.

Keen to support the organisation’s objectives, I therefore chose to provide not only project management services to my client but a wide range of other activities, including training delivery, procedural documentation, business analysis, system administration, requirements analysis, solution design and data migration support. I also undertook any other administration and support activities that needed completing to keep the project on the road.

The project took approximately six months and included the standard features of implementations of this kind: initiation, planning, bespoke design and development, system setup and configuration, data migration, User Acceptance Testing, parallel running and go-live.

Throughout the project I worked at an intense rate, averaging a 47 hour week (excluding holidays), despatching over 3,000 project-specific emails, producing over 100 formal documents and helping my client successfully achieve their desired implementation timescales. But was making such a commitment sensible?

Here is a breakdown of the work I undertook, beginning with the non-project-management-type activities.

Procedural Documentation and Business Analysis

On behalf of the project:

  • I produced procedural guidance for the Finance Team’s maintenance of costing data on the new system
  • I analysed the Payroll/HR procedural interface and produced written guidance on activities permissible for HR during the payroll processing period (reconciling a fairly typical instinct within Payroll for exclusion vs. a robust HR need for access)
  • I analysed Payroll procedures and identified efficient replacement processes on the new system
  • I contributed to the analysis and documentation of an establishment control processes
  • I provided advice and guidance on HR and Payroll procedures in general, with the aim of combining simplicity and cost effectiveness with best practice


On behalf of the project I:

  • Delivered system data structure familiarisation sessions to the project and user teams
  • Produced guidance documentation covering the new system’s data structures, hierarchy and posts
  • Booked training courses, booked rooms, administered attendees, distributed manuals, organised access to laptops etc, for eleven training events

Requirements Analysis and System Design

On behalf of the project I undertook the following activities:

  • Analysis of the costing outputs required from the new system for interfacing to the existing Finance system
  • Production of Business Requirements and Functional Specs for a bespoke interface from the new system to the existing Finance
  • Definition of the interface-relevant Business Objects reports for the Finance team
  • Analysis and documentation of system user types and the menus required for HR and Payroll Operatives Supervisors

System Build and Administration

On behalf of the project I have performed the following activities:

  • Menu setup on the new system
  • Security setup on the new system
  • Setup and administration of all users of the new system
  • Audit setup
  • Online payslip setup
  • Supervision of comms access
  • RTI data checks
  • Setup of User Defined Screens
  • Fault logging and escalation with the supplier
  • Arranging and checking Test environment refreshes
  • Arranging and checking software upgrades
  • Arranging and checking delivery of bespoke software


On behalf of the project I undertook:

  • Detailed functional testing of the bespoke costing interface
  • Coordination of Finance Team data checking
  • Testing of costing interface specific reports
  • Testing of menu, security and user setup
  • Provision of advice and guidance on HR and Payroll testing
  • Testing of online payslips

Data Migration Support

On behalf of the project:

  • I reviewed with the organisation and gained agreement on data ownership and sources for the data migration
  • I administered the collection, formatting and migration onto the new system of cost codes generated by the existing Finance system
  • I closely administered all data migration activities, including version control, format checking and secure transfer (overcoming certain supplier-side weaknesses in this area)
  • I coordinated project team correction of the migration data where required

Project Admin and Support

On behalf of the project I undertook:

  • Organisation of project room and facilities
  • Meeting room booking, meeting administration, minute taking, the production of Agendas and Minutes for all meetings

Project Management

On behalf of the project I undertook the following activities:

  • Fact finding and contract review
  • Production of the Project Terms of Reference
  • Production of the Project Board Terms of Reference
  • Stakeholder analysis
  • Production of the Project Charter (very similar to PRINCE 2’s ‘Project Initiation Document’)
  • Production of high level planning for the project
  • Production and maintenance of a detailed project plan
  • Production of Training and Communications Plans
  • Coordination, prioritisation and facilitation of project team activities
  • Production of Project Team action lists
  • Monitoring project budget vs costs
  • Supervision of supplier Application, Business Objects and Data Migration consultancy
  • Chairing of scheduled and ad hoc project team meetings
  • Monitoring progress against plan and escalating where necessary
  • Coordination of bespoke development, delivery and implementation
  • Preparation and presentation of Project Status reports to Board
  • Micro-management of late UAT and early parallel run activities
  • Preparation of Parallel Run and Go Live Sign Off documents
  • Supplier administration including two formal escalations
  • Administration of change control


This long list of activities of course excludes the range of minor or informal tasks, meetings, correspondences and discussions which all project managers must undertake to facilitate any project of this size reaching its desired conclusion.

Through these very diverse activities, and with the help, dedication and commitment of an excellent but small project team, I ensured an on time and under budget go-live for the project. The project was considered a success throughout the organisation. But at what cost?

Benefits and Risks

The benefits of my approach are fairly clear:

  • Costs were kept low by not engaging a range of very differently skilled staff for short-term activities
  • Efficiency was gained by having a small, closely knit team who knew the entire project inside out – reducing handovers, meetings and duplication of communications
  • I maintained close control over the activities I detail above – through doing them myself…
  • A strong sense of team endeavour and achievement was engendered within a small, tightly focussed and dedicated team

But there were very definite risks entailed in this approach:

  • Willingly and voluntarily the team at times worked to the point of exhaustion to meet the project objectives, which is something that cannot be considered best practice project management. This alone introduces the risks of:
    • burnout, potentially reducing the team members’ effectiveness further down the line
    • focussing too narrowly on what needs to be achieved now, with the team and project manager so immersed in the output-based activities of the project that it becomes difficult to see the wood from the trees or to think strategically
    • errors; tired people, or people who are juggling many activities in parallel, are more likely to make mistakes… and there was a definite danger of this in the project I describe here
  • Had I, or any of the team, become unavailable at any point in the project, there was no contingency: the project would of necessity have slipped
  • I became the sole source of expertise in a number of areas rather than this expertise being built up within a project team made up of permanent employees. This was effectively a postponement of cost, entailing identifying individuals to learn what I knew and to assume the responsibilities I had taken on myself

The Outcome

Fortunately, in the project detailed here, we managed to gain the benefits but avoid the risks highlighted above, partly through hard work, stamina and dedication, but also, decidedly, through a degree of good luck. We worked together well. We had the skills we needed. Issues arose, as with any project, but we were able to promptly resolve them. The project was brought in on time and costs were kept down. What more could my client have asked for?

Answering The Question

But this leaves my initial question unanswered. Should project managers, when it may benefit their employing organisation or the objectives of their project, roll up their sleeves and undertake urgent non-project-management tasks?

From the detail I have provided so far, and given the successful outcome of the project, you might expect that my answer would be, ‘Yes. Of course. You do what you need to do to get the job done…’

However, the conclusion I draw from my experiences is rather different from this. I suggest that best practice project management in fact entails the project manager keeping their sleeves firmly rolled down. In the project I describe my decision to become a hybrid project manager / team member / jack of all trades was fortunately successful – but it did expose the project to significant risks, risks that, as a professional project manager, I would have preferred to more decisively avoid.

Project managers should always hold something back in terms of energy and engagement, allowing for lateral thinking, forward planning, the anticipation of risk and the preparation of risk mitigations.

The project team and I did well. In fact I am incredibly proud of our achievement. But I think we could have done even better, and we could have done it with greater security of outcome, with a little more resource, a little more focus on project management in addition to project outputs, and a little more time.

Luke Andreski    May 2013

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

© 2013 Luke Andreski. All rights reserved.


, , , , , , , , ,


Getting System Implementations Right

The challenge

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.


The reward

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

–          etc

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

–          Trainers

–          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.

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

1 Comment

Passionate About Projects

‘All in a day’s work’

As a PMI accredited project manager with over twelve years’ experience of supplier-side projects you might imagine that I’ve grown accustomed to my profession and see project management, no matter how complex, as ‘all in a day’s work’. After all, doesn’t boredom inevitably kick in when you do the same kind of work year in, year out?

In the case of project management, nothing could be further from the truth.

Despite the long days and long weeks which I’ve spent on over forty distinct projects I am still passionate about project management – and it is a career to which I remain powerfully committed.

So what makes my profession such an attractive one – and how could it possibly inspire passion?

I will try to explain.


Addicted to competence

Project management is about getting things done. If you have ever tried to do something unusual, perhaps outside of your normal occupation, you will know how difficult this can be. There are always swathes of rules, practices and regulations which you need to consider. People and professions don’t talk to each other, or, when they do talk, they don’t listen – and everyone and their neighbour seems resistant to change. Undertaking any new activity or project can feel a little like walking through mud.

The methods and tools of project management are designed to help you cope with this. They help you initiate a project in a way that gives it some prospect of actually commencing. They help you develop a strategy for reaching your objectives and suggest the means of achieving buy-in for your strategy. They help you pre-empt problems and devise solutions for the problems you can’t avoid. In learning to use a project management methodology you are therefore training yourself in competence –in the art of getting things done… and what could be more enjoyable than that?

Brain work

I have said in an earlier post that two fundamental principles of project management are look before you leap and learn from when you fell. Project management places considerable emphasis on planning and learning, and as such offers an almost limitless arena for exercising your intellect. You need to anticipate what a project will throw at you, prepare plans to accommodate and mitigate risks, assess who will be involved in a project, determine what they must contribute and what they might require in return, prepare schedules, determine how to measure progress, take measures to ensure an appropriate balance between cost, duration and quality, develop reports and reassure your stakeholders that everything is on track or soon will be. Your project will encounter problems – all projects do – but though problem-solving may occasionally be stressful it can also, intellectually, be fun.


Project management offers variety. Almost by definition no project is precisely the same. A repeatable set of activities is a process not a project. Even where projects are very similar, elements such as the location, stakeholders, objectives, budget and risks will vary. And, from the project management point of view, this has to be a good thing… Who wants to do the same thing again and again?



There are of course challenges to projects – and some projects are far more difficult than others. Some stakeholders can be awkward or obstructive. Sometimes you have too little resource or sometimes you simply have the wrong resource. Sometimes everything that could possibly go wrong seems fated to go wrong… But this provides another reason for my liking project management: these very challenges give you something against which to pit your imagination, your intelligence and your honest hard work.


Good project management requires good communication. People need to know what’s planned, what’s happening, where the problems lie and what’s been achieved. All types of written communication are important: emails, letters, reports, newsletters, guides, specifications, charters, logs, initiation documents, plans; and this documentation must be underpinned by effective verbal communication. There’s nothing like speaking to people, over the phone or, preferably, face to face, to ensure that whatever’s been written down is properly understood. So project management is an engagingly social activity with one thing for certain: there’s absolutely no chance of getting lonely (even if at times you’d like to be!).

Participating with people

In a similar vein, and perhaps most importantly, project management is about people. It is always fun to work with people on a shared endeavour. It is always rewarding to identify people’s aspirations and help them discover ways in which both they and the project can succeed. And few things can be more satisfying than participating in a project with a complex range of stakeholders and seeing the project reach a successful conclusion through shared commitment and effort.

In conclusion

Many careers offer some of the features I describe above without being assigned the label of ‘project management’. You may be a manager in a project orientated organisation, or someone who works in a swiftly changing business environment or you may be an independent entrepreneur – but, in reading this, I hope I have convinced you that project management, no matter how it is named, is clearly the career of choice.

Luke Andreski

©  Luke Andreski 2012. All rights reserved


, , , , , , ,

Leave a comment

Prerequisites For Successful HR and Payroll System Implementations


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.


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

©  Luke Andreski 2012. All rights reserved

Comments and feedback welcome!


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

1 Comment

Best Practice For HR and Payroll System Implementations


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.


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

©  Luke Andreski 2012. All rights reserved

, , , , , , ,

Leave a comment