Your (Lack Off) Training Efforts Can Easily Ruin the Outcome of an Otherwise Well-Executed Project

18. Juni 2019
Kategorien
Newsletter abonnieren

Your (lack off) training efforts can easily ruin the outcome of an otherwise well-executed project

Any system is only as good as how well it is used. If its a CRM, ERP, or any other system, when users don’t know how to use the system effectively the benefits of the new system for your company will be small, or even negative.

So educating and training your employees is critical to the success of a project — you can never over-train employees on a new system.

Unfortunately, it is hardly ever done right. How many of the below statements sound familiar to you?

“The training was too fast and did not allow time for people to move up the learning curve. There was a very small time window between training and go-live.”


“The training was not supported by written procedures or reference materials — the project team thought some online ‘help’ files would suffice; they didn’t.”


“I think the training team thought they did a great job as their end-of-session evaluations showed good results, but the real measure was the subsequent level of demand on the ‘help desk’ and that showed the training failed to meet the needs of the business.”


“The training was system-operational based. It was too limited. We did not know the business context, the opportunities, why the changes were required, etc. We were just told, this is how you do it now. The business change was ignored in the training scenario, yet this was the most important bit.”


“There were no ‘sustain’ activities, so people quickly reverted to their old habit patterns; often working around the new system to create the old processes as closely as possible. Equally, the new employee’s onboarding training was ignored. We tried to give them the implementation training but found it was inadequate for people new to the firm and its processes.”


“The new systems introduced new disciplines. Correct account codes needed to be entered at source, purchase orders needed correct part numbers on them before they could be sent. These and many other ‘disciplines’ were introduced as part of the system but without any pre-emptive education or communications. They were therefore seen as examples of the new systems’ complexity and increased workload. The downstream benefits were neither known nor considered. As a result, the system got a bad name as ‘too cumbersome’.”

We are all aware of it, and yet we somehow refuse to spend sufficient fund, focus and time on employee education and training.

In a nutshell: In order for your next project that introduces a new system to be a success, make sure that training is a priority.

Tags

Das könnte Sie auch interessieren

Scaling Agile: SAFe

2. November 2015

This is the fourth of six articles on approaches that try to help to scale Agile. For the introduction to this series please read the first article Scaling Agile: Nexus Framework. The second article is about Disciplined Agile Delivery (DAD) and the third about Large Scale Scrum (LeSS). This article will present the Scaled Agile

Weiterlesen

Scaling Agile: LeSS

29. Oktober 2015

This is the third of six articles on approaches that try to help scaling Agile. For the introduction to this series please read the first article Scaling Agile: Nexus Framework. The second article is about Disciplined Agile Delivery (DAD). This article will present Large Scale Scrum, or LeSS. The creators of LeSS, Bas Vodde and

Weiterlesen

Product Backlog Stories …

26. Oktober 2015

Last few weeks I had a few experiences around Product Backlog Items and user stories that made me write this article. Let’s start with a simple observation: many teams I have worked with and people I have met still have the notion that every Product Backlog Item should be in the form of a user

Weiterlesen

Scaling Agile: DAD

21. Oktober 2015

This is the second of six articles on approaches that try to help scaling Agile. For the introduction to this series please read the first article Scaling Agile: Nexus Framework. This article will present Disciplined Agile Delivery, or DAD. Contrary to for example Nexus or LeSS, DAD is not Scrum, it wants to be far

Weiterlesen

Scaling Agile: Nexus Framework

19. Oktober 2015

This is the first of six articles on approaches that try to help to scale Agile. One of the most popular Agile methods is Scrum. Scrum is a very simple framework that describes an one iteration, one increment, one team product development effort. The framework leaves the more complex application of Scrum to the user.

Weiterlesen

Estimating with Wideband Delphi and Monte Carlo Simulation

18. Oktober 2015

During the LeSS training in Berlin last week with Craig Larman he mentioned the best estimating method he knows for any big software project. Wideband Delphi with Monte Carlo Simulation. I agree with him on this one hundred percent. This article will explain what Wideband Delphi and Monte Carlo Simulation is (Part 1 & 2),

Weiterlesen

Budgeting a Scrum Project

11. August 2015

A few weeks ago, I took the training for «Agile Estimating and Planning» with Mike Cohn on FrontRowAgile.com. The training was very good and I think it’s an excellent start for all estimation and planning-related questions. But even after this training, it is still unclear for many on how to make the leap from estimations

Weiterlesen

Scrum Project Success Metrics

30. Juli 2015

Last week I was reading „The 2015 State of Scrum Report“ from Scrum Alliance. In February 2015, Scrum Alliance surveyed almost 5000 people about their use of Scrum. The survey respondents make up a diverse group, representing 108 countries and 14 industries. They reflect a range of functional areas, including IT software development, product development,

Weiterlesen
Previous