Project Team Training: A Crucial Step When Implementing Software Packages

The ERP project kickoff took place on Monday. On Wednesday, the project team opens the software package for the first time and tries to map procurement processes onto screens it does not understand yet. Six weeks later, half the configuration decisions will have to be redone. Project team training exists to avoid exactly those six weeks.

Statistics cited come from public reports by Gartner, Panorama Consulting and Prosci; training durations are benchmarks drawn from PlanAxion's practice.

Gartner predicts that by 2027, more than 70% of recently implemented ERP initiatives will fail to fully meet their original business case goals, and that as many as 25% will fail catastrophically.

Why is project team training crucial when implementing a software package?

Project team training is crucial because that team will make hundreds of configuration and direction decisions over several months, and nobody decides well with a tool they do not know. Implementing a software package changes how people work. The team steering that change must be the first to understand the tool.

Training can be approached from several angles: productivity tools, methodology, working in project mode, the software packages being implemented. This article focuses on software package training, the kind with the most direct impact on decision quality.

The context justifies it. According to Panorama Consulting's 2025 ERP Report, less than a third of organizations reported an intense focus on organizational change management. Gartner lists low end-user adoption and a lack of understanding of the organizational change required among the most frequent causes of ERP implementation failure.

When should project team training on the software package begin?

Training should begin immediately after the project kickoff meeting, because it creates momentum and makes it easier to align business needs with the functionality the package offers. Every week of delay is a week of workshops run blind.

Starting early pays off in several ways. Team members get familiar with the technology before they have to make calls. In workshops, they then recognize the functions being discussed. And they spot the gaps between what the package does and what the organization wants much sooner.

That is one of the concrete deliverables of a successful project kickoff meeting: a training calendar that starts the following week.

Participants often feel overwhelmed by the amount of information they receive. That is normal, and retaining everything is pointless. What matters at the start of the project is being exposed to what is in the toolbox, not mastering every tool.

What kind of training does the project team receive, and how does it differ from end-user training?

The project team receives encyclopedic training covering the full range of available functionality, whereas end users receive, just before go-live, training targeted at their own tasks. The two trainings share neither the same objective, the same timing nor the same audience.

End-user training meets individual needs. Its goal is for each person to maximize the potential of their key role in the processes that concern them. Project team training aims at the big picture: understanding what the package can do in order to decide what it will do.

During these sessions, participants alternate theory and hands-on exercises in the package. They ask highly relevant questions that often go beyond functionality. Those questions are really about direction choices the team will have to settle during implementation. Good practice is to log them and answer them back at the project office, not in the training room.

Here are the benchmarks we keep in mind when building a training plan:

• More than 70% of recently implemented ERP initiatives will fail to fully meet their goals by 2027, and as many as 25% will fail catastrophically (Gartner).
• Less than a third of organizations report an intense focus on organizational change management (Panorama Consulting, 2025 ERP Report).
• 7 times more likely to achieve objectives for organizations with excellent change management (Prosci).
• 79% versus 27%: likelihood of meeting objectives with an extremely effective sponsor rather than an extremely ineffective one (Prosci, Best Practices in Change Management, 12th edition).
• 3 to 5 days of encyclopedic training per major functional module for the project team, starting within two weeks of kickoff (PlanAxion benchmarks).
• 2 to 4 hours of role-based training for end users, within the four weeks before go-live (PlanAxion benchmarks).

Who should deliver the project team training?

Training is usually delivered by the software vendor or one of its partners, sometimes by implementation specialists, but experience shows it is better to rely on training experts. Teaching a software package is a different trade from configuring it.

The cost of this training is high, and it is worth it. The sessions are powerful accelerators: they give the team the knowledge it needs to decide throughout the project. Nobody becomes an implementation expert overnight. That mastery takes years, across several projects.

Training does not replace that experience; it lets the team work intelligently with the people who have it.

This choice lines up with Prosci's research, which shows that organizations with excellent change management are seven times more likely to achieve their objectives. Training the project team is the first change management action of an implementation, long before any communication to end users.

An untrained project team does not make fewer decisions: it makes the same ones without understanding them, and redoes them six weeks later.

How do you build a training plan that fits the budget and the schedule?

A good training plan covers every topic relevant to the project scope, drops the sections of the material that fall outside it, and accounts for logistics and budget constraints from the start. It gets prepared before the kickoff meeting, not after.

Drop out-of-scope modules without hesitation: training a Quebec team on US payroll because the module is in the standard catalogue wastes two days. Also plan the training environments, the exercise data and the real availability of participants, who are often still half-buried in their day jobs.

Team training is only one piece of the setup. The rest belongs to change management that goes well beyond a communication plan: a visible sponsor, equipped middle managers and reinforcement after go-live.

What does an untrained project team really cost?

An untrained team costs weeks of configuration decisions to redo, workshops run without knowing the tool and, in the end, a solution that recreates the old system inside the new one. Next to that price, a few days of training per module is the most profitable investment in the project.

Frequently asked questions

When should the project team be trained during a software package implementation?

Immediately after the kickoff meeting, ideally within the following two weeks. Early training mobilizes the team, familiarizes it with the technology before design workshops and makes it easier to align business needs with the package's functionality. Waiting until the end of design to train the team amounts to designing blind.

What is the difference between project team training and end-user training?

Project team training is encyclopedic: it covers the full range of functionality to enable informed decisions during implementation. End-user training is targeted at each role's tasks and is delivered just before go-live. Both are indispensable, but they have neither the same audience nor the same timing, and they should never be merged to save budget.

Who should deliver the software package training?

The vendor or one of its partners usually delivers the training, and implementation specialists sometimes do. PlanAxion's experience shows it is preferable to use training experts, for whom teaching is the core trade. Configuring a software package and teaching it are two different skills, and the second is rarer than people think.

Why does change management matter so much in an ERP implementation?

Because failures rarely come from the technology. Gartner predicts that more than 70% of recently implemented ERP initiatives will fail to fully meet their goals by 2027, and cites low adoption as a frequent cause. Panorama Consulting notes that less than a third of organizations focus intensely on it. Training the team is the first step.