How to Close the ERP Project Memory Gap [White paper]

By turning scattered project conversations into something you can actually search, so decisions trace back to who made them, and risk gets caught while it's still actionable.

What does this look like on a real program?

ERP projects lose the decisions that matter because the reasoning behind them lives in scattered chats, half-finished Teams threads, and one or two people's heads. No single record holds it together. Eric Lampron, who's run ERP delivery for 25 years, calls that the ERP project memory gap.

Eric's own challenge was the clerical grind: tracking every open item and chasing every loop that hadn't closed. He leaned hard on someone else to hold the details while he held the bigger picture. That worked, but it also meant the project's memory lived inside one person's head.

Swap Eric's name for anyone. Every ERP program has a person everyone gets pointed to. A new consultant joins mid-project, gets told to go find them & burns 3 weeks rebuilding a history that already exists somewhere. Nobody can literally search it because it's stuck in someone's head.

Where does the memory gap hit hardest?

Eric's paper names 5 handoffs where context wears thin fast.

Sales to delivery. Sales spends months learning exactly what worries a client. Almost none of that survives into the signed statement of work.

Onboarding mid-project. New team members get a SharePoint link and a name to go bother. They get the paper trail, not the story.

Recovering a troubled implementation. A new SI walks in and has to piece together months of history from fragments before they can even diagnose what broke.

Steering governance. Risk usually surfaces in workshops and side conversations weeks before it reaches a formal RAID log (the risks, assumptions, issues & dependencies list most programs are supposed to keep current).

Project to support. Support inherits tickets and workarounds with no way to tell a temporary patch from a permanent quirk of how the business actually runs.

Eric goes deeper on all 5 in the full paper. [Download The ERP Project Memory Gap here.]

Why do steering committees catch risk so late?

Risk often starts with small signals: the same question gets asked three times, no one clearly owns the issue or a room goes quiet instead of pushing back.

The team often hears the whisper weeks in advance. And yet, most reporting only captures the scream, when the problem is already loud and clear.

Is this a documentation problem?

Most programs already drown in documentation. Adding more won't help.

A meeting transcript is raw material sitting in a folder. Turning it into memory means being able to ask a question, get an answer grounded in what actually happened & trace any decision straight back to who made it.

If any of this sounds like your program, it might be useful to ask yourself this uncomfortable question:

What happens when the person who knows isn't there, and nobody else can piece together what actually happened?

Eric built this framework for exactly this moment, so if you don't like the answer to that question, you can do something about it.

[Download The ERP Project Memory Gap here.]

Frequently asked questions

What is the ERP project memory gap?

The inability to reconstruct, from real evidence, how an ERP project reached its current state. Programs pile up documentation and still can't answer basic historical questions fast.

Where does ERP project context get lost most often?

5 points: the sales-to-delivery handoff, onboarding new team members mid-project, recovering a troubled implementation, steering governance, and the handoff from the project team to support.

Why do risks get caught late in ERP steering committees?

Risk usually surfaces in workshops and side conversations weeks before it reaches a formal report. Most status reporting only catches problems once they're already loud.

Is a project memory gap just a documentation problem?

Programs already hold plenty of documentation. The gap is failing to reconstruct decisions and their reasoning from that pile when someone actually needs it.