When developing software, project documentation matters. If you get it right, it can ensure the project is completed on time, under budget, and will be able to be built upon by other projects that come after.

However, documentation is not easy. It stands to be said that in the realm of project management, project documentation is a pet peeve amongst development teams. Project documentation is one of the main reasons that project development methodologies ended up tending to agile in the first place.

Despite the lack of enthusiasm for it, every project should have documentation. From a business case, change request, project update or even a project handover, with the right documentation any project can be effective. Most unexpected changes in a given project can be prevented through being disciplined in your approach to documentation. Here are a few key tips to help you along the way:

It can be easy to get lazy with documentation. Simple documentation such as writing down steps can sometimes be misconstrued when it comes to others reading and actioning them, leading to both errors and delays in project management.

One way around this is to illustrate as plainly and simply where you can. This ensures that the content of the documentation isn’t as dry, as well as being easier to understand. System users also often like having diagrams, pictures, comparison tables and even numbered lists, all of which can be helpful in conveying a message.

One of the most common causes of delays and errors is when members of the project team make small decisions, and do not give a reasoning behind it. A good example of this is when a business analyst chooses to define a user story a certain way, but a developer sees that there are inefficiencies in building this particular user story out, and changes some details along the way.

Regardless of who made the error in judgement, this problem can be solved by a documented writeup of where the change was made, and a reasoning. Even if the reasoning is a simple sentence, as long as changes are accounted for, the development can continue to run smoothly.

A recent term for this is “discovery-based changes”, where a developer may make minor changes when developing if they feel the project will benefit. These changes often feed into a Wiki page hosted on Confluence, which can benefit other projects in the portfolio.

Like any good piece of software, documentation also needs to hold up to rigorous testing. By following the instructions laid out, and testing whether they are easily understood and the result is replicable, the documentation can develop a sense of authority. When change requests are made, documentation can sometimes be placed under scrutiny. It’s important to ensure that when this occurs, your documentation can be looked upon as definitive.

As a project manager, documenting processes is a major part of the role. By driving discipline in your documentation, you can make sure this process is as smooth as possible.