I have yet to meet a person who gets excited about creating documentation on an ERP software project — or any project for that matter. It generally falls into the same category as tracking time. When everyone is so busy doing the work, they don’t see the reason for documenting what’s being done.
As projects become more intense and budgets become tighter, project leadership starts to look at what could be cut and often says, “We know what needs to be done. Let’s save time and money and skip documentation!”
While that might seem like a productive decision at the time, such a short-sighted quick fix ignores the potential for miscommunication in the future.
Have you ever had an employee leave – voluntarily or involuntarily – where the wealth of knowledge they had wasn’t shared? Have you ever encountered a communication gap between what you asked to have done and what was completed? Have you had projects that continued to grow and had no barriers on what was agreed to be done – time, scope or budget?
Documentation helps provide a record as to the why, what and how behind decisions, development and implementation. Documentation on projects should never be negotiable; it is for the benefit of all parties — including the client, users, vendor and future partners.
Many types of project documentation can be created depending on the size and complexity of the project. However, these four key artifacts should always be created, regardless of the size of the project:
1. Statement of Work or Work Order
This is the formal agreement between the client and vendor as to what the scope and budget of the project is. This document should address the goals of the project and confirm who is responsible for what. Whether a statement of work or work order is used depends upon the size and complexity of the project. A statement of work is used for larger projects while the work order is a less formal document for smaller engagements.
2. Requirements List
This is a list of functionality that the client needs the system to do and is included within the scope of the Statement of Work or Work Order. This document is used as the blueprint for configuration and setup. It is also used in conjunction with test cases to help validate when the design is complete.
3. Functional Design Document or Technical Design Document
This is the outline of the design behind the configuration or customization. This document helps explain how the system is set up and why it is set up that way. It also contains relevant details in the event of any future upgrade or change.
4. Test Cases
This is a document that details the scenarios to be performed to test the system/ process based on the requirements. Test cases not only need to be created; they also need to be executed, defects fixed and retested until the test is considered successful.
We would love to think that our employees will stick around forever and be able to regurgitate discussions years later or that miscommunication won’t occur. The reality is that they are not and it will. To minimize risk to both the client and the vendor, documentation is the best way to pass along knowledge to future stakeholders of any project.
