After ten or fifteen years in the field, an ERP project manager has generally seen it all: the client who can't articulate their needs, the go-live that goes off track the day before the weekend, the key user who subtly sabotages the change, the sponsor who changes their mind three weeks before production. This accumulated experience is invaluable, but it conceals a rarely discussed risk: the invisible ceiling of experience. You continue to do your job well, you don't make many mistakes anymore, but you've stopped learning. The danger isn't visible failure; it's routine masquerading as expertise.
The subtle signs of a standstill in progress
This situation does not begin with a crisis. It develops gradually, and that is precisely what makes it difficult to detect.
An initial warning sign lies in the speed of problem-solving: decisions become faster, but also more automatic. The project manager recognizes a pattern encountered before and applies the solution that worked last time, without necessarily verifying whether the context is truly identical. This speed of execution masks a decline in analytical vigilance.
A second warning sign lies in delegation. An experienced project manager naturally delegates more than a junior one, which is healthy. But there is also delegation born of weariness, distinct from delegation based on trust: a task is no longer delegated because the team is deemed ready, but because explaining the same point again has become tedious. What appears to be delegation is actually a gradual disengagement.
A third, more subtle signal concerns functional curiosity. Faced with an unusual client request, the natural reflex should be to try to understand what makes this case unique. However, when expertise is fixed, the reflex becomes, on the contrary, to reduce the case to a known category, even forcing the comparison somewhat, to avoid the effort of a fresh analysis.
Why this risk is amplified in the ERP ecosystem
This phenomenon is not unique to ERP project management, but it takes on a particular intensity there, for a simple reason: the publisher continues to move forward while the project manager can choose to stop.
Microsoft Business Central evolves in waves every six months. New features, modules, and configuration practices appear regularly, and the regulations governing implementations (tax, customs, accounting) also change without warning. A project manager who becomes fixated on their management methodology can unknowingly fall behind on the technical and functional aspects they are supposed to be advising on. The risk isn't just individual: management based on an outdated functional understanding ultimately produces obsolete recommendations, presented with the confidence that comes with experience.
This dynamic is exacerbated by the fact that senior experience inspires confidence, including in the person who possesses it. The more one is perceived as the expert in the room, the less one is challenged, and the less one is challenged, the less one is motivated to update their skills.
The invisible mechanisms that establish the comfort zone
Three mechanisms silently maintain this stagnation.
The first is acquired status. Once recognized as an expert in a field, it becomes uncomfortable to publicly admit a gap in knowledge in that same field. This discomfort leads to avoiding situations where ignorance might be apparent, which mechanically reduces learning opportunities.
The second factor is the workload itself. A senior project manager often handles several projects simultaneously, and the time available to explore a topic without immediate implications (a new feature, a still-experimental practice) is reduced in favor of operational urgency. Stagnation then becomes an almost automatic consequence of the workload, without any conscious decision having been made.
The third is the very nature of the project management profession. Unlike a purely technical role, the project manager function rewards stability, predictability, and the ability to reassure. These qualities, essential for the client, can unintentionally discourage the intellectual risk-taking that would allow for continued progress.
Deliberately restart the learning curve
Moving beyond a skill plateau does not happen by accident; it requires a deliberate decision, and a few concrete levers can be used to implement it.
The first involves periodically stepping outside one's usual scope: accepting an assignment in a less familiar sector, a different type of project, or a less known geographical or regulatory context. Multilingualism and a multi-country profile are natural assets here, provided one doesn't limit oneself to contexts already mastered.
The second approach involves voluntarily placing oneself in the position of a learner on a specific and circumscribed topic (a new Business Central module, a still uncommon configuration practice, the use of artificial intelligence in project management). The goal is not to start from scratch, but to rediscover, on a limited point, the productive discomfort of a beginner.
The third lever is reverse mentoring: organizing, even informally, sessions where a junior employee explains a recent practice, tool, or feature they are more familiar with to a senior employee. This role reversal, far from undermining the project manager's authority, generally strengthens it, as it demonstrates a capacity for learning that is more reassuring than a facade of complete mastery.
Conclusion
A plateau in progress is not a failure; it's a natural stage in any long career path. The risk lies not in its existence, but in ignoring it. An ERP project manager who consciously identifies this moment has an advantage: they can choose to transform a silent stagnation into a point of recovery by deliberately redefining what they haven't yet mastered. In an ecosystem like Business Central's, where the software vendor and regulations wait for no one, this ability to get oneself moving again becomes, over time, a skill in its own right, perhaps the most strategic of all.