Blog

​

Dana Shand has been working on SAP projects for 18+ years. In that time she has had a variety of experience from large global and international implementations to small domestic projects. Lately her time has been focused on helping projects that have struggled with finding the right training solutions.

View Dana Shand on Linkedin

​

It is the second day of go-live and you’re sitting with an end User that has requested support. They look at you earnestly and say to your face “we weren’t trained in that”. You stand there and remember the training class that you ran – which they attended, where this was covered in great detail. Then you see at the printed manual, that took six months of time and effort from multiple people to create, knowing the answer is in there also, but there it sits dusty and unopened on the shelf.

So went the first 10 years of my career in SAP Training, repeating myself endlessly to end Users I had already trained, on how to actually use the transactions I had trained them in.

To me this begs the question, where/when is a training budget best utilised in the lifecycle of a project? Should it all be before go-live, all content created and all users trained in everything? Currently that seems to be the standard for projects, however this approach can be short sighted, expensive and ineffective. If the above statement is a summary of my experiences, and a standard feature in the “lesson’s learnt/project debriefs” that businesses conduct post projects, why are so many projects still trotting out the same training approach? Why is training purely based on a pre-go-live approach?

There is a lot of information now about adult learners and how basically, they learn new skills in the following way:

• 10% in a formal classroom setting (like a Pre Go-Live Classroom)

• 20% in an informal/coaching/mentoring type of arrangement (much like Post Go-Live Support)

However

• 70% – is learnt on the job in practical application (this is post project, when everybody has packed up and gone and the only people left are Super Users that have gleaned as much knowledge as they could during their time on the project). This mean the majority of a User’s learnings is coming from internal resources, their own staff that have limited or blinked knowledge of the system and processes from other departments. These poor guys are left to fend for themselves, as the project is finished and budgets are consumed.

So how can a training budget be better utilised on a Project? As mentioned, there is always a significant push to have all Users “trained” before go-live, and then it is considered that training is finished and the team can be wrapped up and dismissed. This fits with a lot of business that appear to have the momentum to change while there is a project in place, however once the project is finished, there is a huge sigh of relief and the business goes back to operating like it always has – people stumbling through the system, not using it as intended, not following business processes, not seeing improvement or ROI for the project.

One way to improve the training aspect of a project would be to better align to the paradigm above (the 10/20% and 70% approach) – to rethink how and when training is deployed in a project lifecycle and how that could benefit a business in the longer term. Don’t get me wrong, training is definitely required, a training team is needed and above all else, content still has to be created. But when and how is really the question.

Over the years I have seen many training budgets squandered and large teams of people that are ineffective or inefficient. There seems to be two issues related here – one is the timing of when to bring on resources and the second is what roles are really required in a training team.

It is also not uncommon for initial project planning and budgeting for a team like training to be done by others with limited or no knowledge/experience of training. These limited plans and budgets are difficult when you inherit them and have to make them work, while balancing the desires of the business stakeholders. Compromise is usually the only way to get through that quagmire, resulting in an outcome that doesn’t meet the longer term needs of a business, but ticks the required “completed” boxes for a project.

All projects and business see training as important and place emphasise on it, as they should, however the emphasise is limited to typically a 4 week pre go-live training delivery window and then training is considered complete and the team dismissed.

But what if a project/business were able to see a longer term picture of training and the real change a SAP implementation brings to a business? What if they could see past the life of the project and envisage their own Users 3 months after go-live, when the majority of a User’s learnings and understanding of the system actually happen?

This would mean a fundamental shift from the “4 weeks pre go-live classroom” training approach which is so common now, to a shift in thinking and instead viewing training as a longer term requirement that also happens post go-live. A shift to more “practical application” post go-live training, assisting people when they actually need to assistance, when they are under pressure for a delivery, or to get an order filled or a machine fixed.

How would that look? How would that be executed and what would the cost be? Until there is a business/ project that can be forward thinking enough to agree to an approach like this, I can’t tell you, I haven’t experienced it. But it is food for thought.