Always Leave a Paper Trail
You are six months into a project. No one agrees on what is supposed to be done or who is supposed to do it. Requirements do not appear to be implemented as they were documented. No one can recall why a decision was made. And a risk you mentioned in a meeting three months ago has now become an issue. You are wondering how you got here. Let's talk about that and see how things could have gone differently.
The way you document key project information is one of the core drivers of project success. An ERP project (and really any project) is too large to assume you or anyone else can just remember stuff. Depending on the topic, producing documentation also gives you the ability to set guardrails and expectations to keep the project moving smoothly, where everyone knows what is expected of them. Put a large amount of effort early on into your documentation storage and organization strategy, thinking about everything you will need to organize. Of course, there are diminishing returns. You do not need to record every conversation that ever happens. Use your judgement.
Here are a few things you should be documenting as they change, happen, or are agreed to. This is not an exhaustive list, but it should paint a picture of what needs to be done.
Organizational and Authoritative Documents
Set the stage before anyone takes the field.
Examples here include your project charter and ways of working. These are documents that set the stage for the entire project. What is the overall purpose? How will people interact? Who is responsible for what? Without these documents created, approved, and reviewed by all, you will experience project governance issues and general organizational chaos.
Requirements
Document them once. Then document every time they change.
Your requirements must be meticulously documented. What people forget, though, is that as the project progresses, the team will learn and the requirements will change, be added to, and removed. The same standards for quality of the documentation must be enforced when this happens. The most common issue in this scenario is making updates on the fly to the system, without making an update to the requirement itself. When this happens, confusion will likely arise when people who were not in the room call out that the system does not meet requirements.
Risks
An untracked risk is a future issue with a slow fuse.
If you or someone else fails to record a risk, or successfully documents it but without a plan for managing it or following through, there is a good chance that risk will become an issue. Sound familiar? It should. It is exactly how the scenario at the top of this post starts.
Decisions
If it is not written down, the debate is never really over.
Your project will have many high-impact decisions made. All decisions, whether made on the spot or tracked to be made later, must be recorded in your project management system. It is a guarantee that at some point down the road, someone will ask why something happened the way it did. Without documentation of the relevant decision, this can lead to serious problems as you revisit the discussion and try to unravel, or prove, what happened.
Approvals
No signature, no green light. Full stop.
This one is obvious but easily forgotten when you are heads-down in normal project tasks. Everything that happens in your ERP project, from configurations and customizations to tests and deployment, must have a clearly documented approval attached to it. There is very little work that would be appropriate to proceed without that approval in place. If you configure or develop without approved requirements, you are exposed to expensive rework and project delays. Equally as bad, or worse, if you move to deploy without approval from user acceptance testing, you risk catastrophic failures.
As ERP project managers who want successful projects, we have no choice but to ensure documentation is constantly maintained. Failure to do so leads to chaos.
It starts with one lazy moment. And before you know it, you have a lot to fix. Stay sharp.
