SAP HR Lessons Learned

A brief review of some common lessons learned when undertaking an implementation or project.

The idea of a perfect project is a rare one. Undoubtedly all projects will succeed in some aspect and they will fail or come up against some issues no matter how large or insignificant they may be.

However, what is important is taking onboard those successes and issues at an early stage so they can be repeated or mitigated in the future.

It is a good idea to evaluate the progress of the project at regular junctures throughout the implementation usually between phases i.e. Blueprint to Realisation. This is just as a measure of how the project thinks it is doing relative to how the project is actually doing. Lessons Learned sessions provide a good forum for doing so. They are also a great way for all members of a project to have a constructive contribution to how the project is running, as different members of the project team will see different successes and challenges from sometimes very different perspectives.

A book or three could be written on the pitfalls of projects but we will cover just a few simple points which sometimes come out of lessons learned sessions.


Without careful, detailed and realistic planning a project, no matter how big or small, will run into difficulty.

So many lessons learned sessions seem to yield very similar outcomes, such as, 'planning needed to be more detailed', ' we needed to be more realistic with the resource available' or 'given resourcing levels can we phase some of the solution we are attempting to implement later rather than completing this for one Go Live' and it goes on.

A plan varies considerably and usually forms a high level phase plan to individual task level plan. It offers a very practical way to evaluate the progress of what activity should be taking place on an agreed timescale. They are used for different purposes and importantly different audiences within the project. The Programme Manager, for instance, will often have little interest in the 500 point task plan to implement Organisational Management and Personnel Administration.

It is a good idea to ensure a high level plan exists of the broad phases and key milestones which will need to be met to see how they fit with the expected delivery dates. These usually take the form of the broad phases of an implementation i.e. Blueprint, Realisation, Testing, Data Migration, Cutover and Go Live

Then breaking these down into their constituent parts if we take the Testing phase as an example planning needs to take place to ensure; Unit Testing, Integration Testing, User Acceptance Testing (UAT), Business Process/Scenario testing (i.e. Day in the life of....), Regression Testing and Stress Testing to name but a few.

Then breaking these down even further, each of these tasks needs to be planned. If we take UAT there is; test script writing, what resource is required to complete this test phase, method of recording scripts and results and acceptance criteria, etc.

The key is then ensuring that when this has been sufficiently planned, there is then enough resource and time to complete the project within the agreed timescales which can mitigate planning coming up again and again as a lesson still to be learnt.

Change Management

We will here look at one aspect which is very important and often comes out of Lessons learned sessions, 'user buy-in'.

Often seen as the first area where resource is cut in the face of difficulties, this can be the biggest mistake. Always in Lessons Learned sessions where Change Management is missing, no matter how successful the project, when the solution is deployed into the wider business, the way Change Management has readied the business for that change will have great bearing on the success of the project. In other words, how much has the business bought into the project and what does the business want to achieve as a result of the project. This is particularly true for those users brought onto the project. These are key users as their impressions will always disseminate throughout the rest of the business and give the business confidence on the ground level.

Before the solution is deployed into the business, while the project is being undertaken, the user population are the primary source of company specific information. This includes how the processes are currently undertaken, who carries out these processes, why do they carry them out and when are they carried out. All this information obviously forms the basis for the blueprint and is gained during workshops.

The feedback in Lessons Learned sessions is often that this information was not readily available slowing the progress of the project and impacting on any carefully organised plans. Where this becomes an issue is once the consultants and consultancy team have moved on site, the project team members often report back difficulties ranging from; attempting to gather information from a sometimes wary user population for Blueprint and Process design, to attempting to gain sufficient information to test company specific scenarios and ensure the solution is 'water tight'.

User buy-in can often be gained by empowering users. Giving sufficient training can provide this. Lessons Learned sessions often feedback that training was inadequate or absent for those working on the project from inside the business or the general user population. There are many different issues that can come up and are often the cause for much discussion, but Change Management must lead in order to integrate the project and the business, and guarantee the long term success of an implementation.


Another aspect which is often of primary concern in Lessons Learned sessions is communications. These activities are usually carried out by a Change Management team.

Are all team members and teams speaking to one another?

All too often something so simple such as suitable lines of communication to all members of the project team can mean success or failure. Lessons Learned sessions often have members of the project claiming that they didn't know what was happening in other areas or that they didn't think a single long-winded email every week was very effective.

Communication is vital, particularly where more than one consultancy may be involved or more simply if teams are working in different rooms or buildings. Part of the work may be being carried out offsite. Alternatively, those people from the business who have been moved onto the project may not have worked in a project environment before, and may have little or no project experience.

It is important for appropriate methods of communication to be decided early on, and that they are maintained to avoid confusion and misinformation. These can be regular structured meetings where information can be filtered through all levels of the project. Or possibly succinct emails which provides a brief synopsis to the other team members in different areas of the project. Posters of high level activity throughout different phases of the project also give a good summary of activity and progress.

Poor communication to members of a project team can cause time delays, confusion and often duplication of effort. This is all a waste of time and effort.


Here we aren't talking about specific business processes as these vary from business to business, we are talking about project processes, those activities which oil the success of a project. If ineffective processes exist, they can prove to be some of the biggest hindrance and frustration to its team members.

Often project methodology is used as guidance or principles from other implementations are used which are not applicable. Typically these will come up in Lessons Learned sessions. Really this is very simple, do not be dogmatic in the approach to processes on a project and while those in project management may feel they are the best processes, it is listening to the outcome from Lessons Learned sessions which can give invaluable feedback to how the processes can be made even better.

A good example of this can be an overly complicated approval process for moving transports through the landscape after the managed drops of the Realisation phase. Now certainly rigor needs to be applied particularly where there are contractual ramifications for work being moved into a test or productive system. However, nothing is more frustrating when a transport takes an overly long period of time which comes from 10 meetings and 7 forms which need to be filled in as it can stall consultant activity, testing from the business or equally getting a fix into production.

The result of a slow or ineffective process can be stopping the progression from one phase of the project to another, wasting resource time on either the consultant or business side or causing the business undue pain. Obviously this then has an impact on the planning phase and eventual Go Live.

Thnking about the Future

The final point here is thinking about what happens after the project. Once the project gains momentum, attention turns to what happens when the consultants leave site.

For the business this reality may not hit until the latter stages of the project but once it does, a certain amount of fear and trepidation can be seen over the question of 'what happens if something goes wrong, we want to make a change or we want some new functionality?'. If we think about the amount of money that is invested, which will not be an insignificant amount, then looking after and maintaining that which has cost time, effort and money needs to be protected and maintained.

The questions from the business in Lessons Learned sessions about support will not usually come until the latter stages of the project as previously mentioned and what this is often linked to is training and training needs or 'who do I go to if?'. However, both aspects need to be thought of as part of the evolution of the system from day one, as the project itself is only the start of a system lifecycle which over the long term can be 10-15 years with upgrades. So if the project is 6-24 months, then the system will be live without consultants on site for the majority of the lifecycle.

Putting into place a strategy for support at an early stage is vital and will certainly make the business more comfortable in operating post implementation effectively and efficiently, as well as identifying exactly where user training is required and the form and depth of that user training.

The size, complexity and business areas of the solution need to be considered in terms of the strategy for support and implementation from day one. Taking Payroll as an example, the size, scale and impact of the Payroll needs to be outlined for a support and training strategy. Obviously the Payroll process from business to business varies considerably and depending on the business' terms and conditions it can be very complex or relatively straight forward. It is heavily utilised on a regular basis and the impact of it not working is vast. You can instantly see these factors begin to shape the strategy and requirements for support and staff training.

The sharp end of these considerations will be raised by members of the business and consultants and these concerns are regularly raised in these Lessons Learned sessions. Where budgets may be tight as a result of the project, the support requirements need to be considered and 'trimming' the support will usually lead to longer term pain both financially and operationally as is similarly found with Change Management.

Lessons Learned sessions are invaluable if structured and managed properly. All too often it is not learning from the lessons and simply completing the activity because the 'project management 101' manual said to do so which is the biggest lesson not to be taken from the sessions. These can be vital opportunities to save time and money and to encourage good practice and stop bad practice in its steps.

Listen and learn.