I get it, writing project documentation isn’t fun, sexy or deemed important by tech teams. Why create project documentation when there is valuable coding, bug fixing or project planning to be done?
But not by not creating written documentation, this could cause headaches and frustrations in the future. For example, if a new developer or project manager comes into the team and a project has already been started, the new member will need to get up to speed. Of course, it is always best (in my opinion) to have someone run through the project, but not everyone has time to spare. This is where project documentation is key. Having clear, written goals and deliverables makes it easier for team members (old and new) to remember the key points of a project.
Project documents don’t have to be for internal usage, they can be used for clients. These might be project communication plans and scope statements.
Communication plan
A communication plan is a simple method that dictates when a stakeholder will be contacted, their relation to the project, why they will be contacted (i.e. weekly status update) and by what method they will be contacted.
Scope statements
This document briefly outlines the project’s deliverables and the items that are out of scope and that could be added to future releases, as well as the goals and objectives for the business.
Documentation is important as it provides key information that is critical to a project’s success. It is easy to think that we will remember everything that is meant to occur in a project. But, we can only remember so much, especially if we are working on multiple projects simultaneously. That is why it is important to write things down.
Ideally, there should be some form of documentation at the various stages of the project lifecycle and these should be updated when necessary.
Everyone should have access to some form of project documentation.
Without documentation, a developer could simply make a head start on a project without knowing the reason behind the project. They will need to know the answers to the following questions:
- What are the user stories?
- Who is the target audience?
- What are the brand guidelines?
- What are the correct font sizes?
Whilst these might seem basic, they are often left out and can cause a headache if they aren’t clearly defined from the start.
Writing documentation for developers does not mean it has to be an in-depth technical exercise. However, the clearer the instructions the better. If you can provide developers with exact font sizes, and color hex values, then you will save a lot of headaches in the future.
End user guides
Lastly, user guides are something to consider. I have read something that states if something requires a user guide then it isn’t easy to use. However, sometimes it is good to have a written guide so that users can refer back to it when required. This will save time contacting project/product/account managers and developers if a user is unsure how something.
As the saying goes, a stitch in time saves nine.
