Almost every troubled ERP project I have looked at had a moment, months before go-live, where someone could have seen it coming. The uncomfortable part is that the warning was rarely hidden. It was written down. It was in a requirements sheet that nobody could explain, a process map that only described half the business, a decision log that stopped getting updated in month two. The signal was there. The problem was that everyone in the room treated those documents as admin. Boxes to tick so the project could keep moving, not evidence to be read.
I want to write this one for the owners and CEOs, the people actually paying for all of it. Because there is a quiet advantage sitting in front of you that most of you are leaving on the table.
You do not need to become technical to run a safer ERP project. You need to learn to read documentation as evidence about whether the project is really under control, or only appears to be.
Documentation is not the deliverable. It is the diagnostic.
When your team or your implementation partner produces documentation, the instinct is to judge it on whether it looks complete. Is the template filled in. Is it formatted well. Did we get sign-off. That is the wrong question, and it is the question that lets projects drift while everyone feels productive.
The better question is what the documentation reveals about your readiness. The research keeps pointing the same way. When Panorama Consulting audits ERP projects that have gone sideways, the fixes are almost never about better paperwork. They are about organizational readiness, governance, and change management. Documentation matters here because it is where all of that becomes visible. It is the place where readiness either shows up on paper or quietly fails to.
So instead of asking "is the document done," I have learned to ask three things across the life of a project, from selection through go-live. What did the act of writing it down reveal. Does it connect to anything. And does anyone actually own it.
What gets created tells you what you do not yet agree on
The first time a team tries to document its current process in plain language, something interesting happens. They argue. Two people describe the same workflow in two different ways. A step that everyone assumed was standard turns out to run three different ways depending on the customer. A number that finance reports turns out to be calculated by hand in a spreadsheet on one person's laptop.
That is not a documentation failure. That is the document doing its job. It surfaced the fact that the business never actually agreed on how it works. If your team cannot write down how things run today without a fight, no software is going to fix that. You are looking at a process clarity problem, and the document just found it for you, early, while it is still cheap to deal with.
So when you watch documentation getting created during selection, do not look for polish. Look for friction. The friction is the finding.
What connects tells you whether scope is under control
This is the part most owners never see, and it is where the money leaks.
Every customization, every requirement, every "the system has to do this" should connect back to a reason and forward to a test. There is a line that runs from a business need, to a documented requirement, to a design decision, to a test that proves it works, to a person who got trained on it. The discipline of keeping that line intact is called traceability, and it is one of the oldest ideas in serious business analysis (the IIBA builds it into the BABOK for a reason).
You do not need to read the documents to use this. You need to ask one question in the room: show me the line. Show me why we are building this customization, which requirement it traces to, and how we will know it worked. When the room can answer cleanly, the project is connected. When the answer is vague, or when a feature exists because someone "thought we needed it," you have just found scope creep before it hit your invoice.
A disconnected document is worse than no document. It gives everyone the comfort of paperwork without any of the control.
What gets managed tells you who actually owns the project
Here is the most valuable document in any ERP project, and the one most likely to be neglected: the decision log. Not technical. Just a plain record of what was decided, by whom, on what date, and why.
The reason it matters becomes obvious about eight months in, when a dispute appears. The vendor says you approved a scope change. Your team remembers it differently. Without a decision log, that conversation is two memories arguing. With one, it is a record. The decision log is not bureaucracy. It is the thing that protects you when the relationship gets tense, and it will get tense.
While you are at it, watch who holds the documentation. If the only complete picture of your processes, your decisions, and your configuration lives inside your implementation partner's files, you have quietly outsourced the memory of your own business. The day that partner leaves, or the relationship sours, you are starting from nothing. Ownership of the documentation is ownership of the project. Make sure it is yours.
A short honesty check, because more documentation is not the goal
I want to be fair about the other failure mode, because it is real. Documentation can become theater. Binders nobody opens. Templates so heavy that filling them in becomes the work, while the actual risks go untracked. I have seen teams feel completely safe behind a wall of beautifully formatted documents that described a project that was already in trouble.
So the test is never volume. The test is whether the documentation changes a decision. If a document never makes anyone stop, rethink, or say no, it is decoration. The useful ones are the ones that occasionally ruin your day by telling you something you did not want to hear. Those are the ones worth protecting.
A simple way to read any document they hand you
If you want one thing to carry out of this article, it is this. Whenever someone hands you something on the project, a requirements list, a process map, a status report, a configuration summary, run it through five quick questions. You can do all five in about a minute, and none of them ask you to understand the technical content.
Clarity. Can I follow this without someone sitting next to me to explain it? If a document only makes sense when its author translates it out loud, the thinking behind it is not finished. Clear documents come from clear thinking. Confusing ones are usually hiding confusion.
Connection. Where did this come from, and where does it lead? A requirement should point back to a business reason and forward to a test that proves it works. If you cannot see those links, you may be looking at something that will get built for no traceable reason.
Custody. Whose name is on this, and does that person work for me? Every important document needs a named owner on your side, not only the vendor's. If your team cannot tell you who owns it, the honest answer is that nobody does.
Currency. When was this last updated? Open the history. A document that stopped changing three months ago usually means the project stopped thinking about that area three months ago. Live work leaves fingerprints.
Consequence. Has this document ever changed a decision? This is the hardest one and the most important. If it has never made anyone stop, push back, or say no, it is decoration. The ones that matter are the ones that occasionally cost you something.
Clarity, connection, custody, currency, consequence. Five words, all starting with the same letter so they are easy to remember in a meeting. You do not need to read the system to ask them, and the answers will tell you more about the health of your project than most status reports will.
What this means for you
You are not going to read the technical documentation on your ERP project, and you should not have to. But you can read the signals, and the five questions above will get you most of the way there.
Two moves are worth making proactively, before the documents even arrive. Early in selection, ask to see your current process written down in plain language. If it does not exist, or it lives only in one person's head, that is your first finding, and it has nothing to do with software yet. And before any customization gets built, ask for the line: the business reason, and the test that will prove it worked. No clear line, no build.
None of this requires you to learn the system. It requires you to treat the paperwork as what it really is. Not overhead. Evidence.
When projects go badly, I am rarely surprised once I read back through what was, and was not, written down along the way. The documents were trying to tell someone. The only question that ever mattered was whether anyone was reading them as a warning, or just filing them as a chore.