What documentation is essential for every project
Published by Pavel Nakonechnyy on in Project Management.
You want to document every project you’re working on. The question is – what is important enough to write it down. What are the artefacts you may want to create? I work every day on projects that last from less than a week up to a year. I’ve tried different approaches to documenting projects, and here are the things I’ve learned and tested myself.
Essentially, you may pack information about the project in any form, tool or document. The important thing is to write it down in a way you and your team will understand. Therefore, you have to be conscious of what information you want to write down, not which documents you may write because a random guy from the Internet told you. Project documentation is useful for maintaining Stakeholder Engagement.
- Project goal. Try to clarify it as much as possible for everyone to be able to understand it from your description. The useful thing I’ve discovered – a good practice is to copy the basic project description in a couple of paragraphs to every document you write for the project. People usually have more than one project in development at any moment in time. You’ll save everyone’s time if it is easy to understand what project you’re writing about (not only by its JIRA ID).
- Business justification. Why are you launching this project? What are the expected outcomes and success metrics? How will you be able to justify the time spent on this project? Try to keep it in numbers and KPIs. You want to compare actual numbers to predicted ones after the completion of the project.
- Resources required. What will it take to complete this project? That is the moment you may understand that this project won’t be worth it (Work + Required Resources <= Potential results).
Writing is a way of thinking for most people of science. They develop the thought in parallel to writing down their observations. If you learn this skill, it will be a lot easier for you to work on the documentation, as you will subconsciously write down anything that may be of importance to you later. You will see such things better and better with experience.
Putting your ideas on paper forces you to think through your idea and to verify if it makes sense. This is how initial napkin plans become detailed and rock-solid in the end.
- Sub goals, tasks and processes. You want to divide the goal into sub-goals, tasks and processes until they become known and understandable. For example, a UI designer should understand what it takes to design a screen from a mockup. There is no value in a deeper description if the actor knows what to do to complete the task: the steps and the results. You may include required resources such as a mockup screen for him, but you may as well share it via email, for example. Such detailed descriptions more often than not clutter the document for all readers.
Be sure to include all the technical information that might be important for anyone in the project team. It may be either input for actions or a description of the result you want to get (e.g. description of a new API or automated process).
- Methods of testing, scenarios, testers, and approvers. I can’t stress enough the importance of testing the work you do. The best way to facilitate testing procedures across the project team is to include testing in the project documentation. You may think you’ll remember what you wanted to test, but, most probably, you won’t. Your colleagues won’t as well. Make sure to prepare a testing plan and get everyone to agree on its execution before beginning testing.
- Project acceptance. How will you close the project? What will be the criteria for launch? What if someone will be too busy to properly finish the project? These are the questions you want to answer on paper.
With proper documentation Project’s execution will look like this:
Leading a project is an impossible job unless you have the documents to back your actions and, if required, force everyone to take their part.
The documents you may use as tools to achieve listed goals:
| Document | Purpose |
| Action and Issue tracker | Track pending actions and open issues |
| Project Charter | Non-legal agreement between the customer and contractor |
| Project Organization | Overview of people and roles in the project |
| Project Roles and Responsibilities | Description of roles and responsibilities |
| Project Plan | Activities and Timeline |
| Project Budget | Project cost (plan and actual) |
| Stakeholder Matrix | List of stakeholders involved in the project |
| Risks Log | Potential risks and how to handle them |
| Project Communication Plan | Structures communication and meetings in a project |
| Scope Statement/Requirement Specification | Description of customer requirements |
| Change Request Tracker | Track changes to the project scope |
| Test Cases | Railway testing process: both to describe scenarios and track their execution |
| User Stories | Prove project’s usefulness for customers |
| Business case | Prove economic and strategic benefits of a project |
| Project Status Report | Communicate the project status |
| Lessons Learned document | Help with future projects by documenting faced issues and their solutions |
Every project is different and there is no one-size-fits-all when it comes to project documentation. Simple one-page project documentation can be a good starting point. As your project evolves and your documentation becomes more detailed, you may want to split it into separate documents to keep things more organized.
Use different project documentation tools to help you move the project forward, not for the sake of bureaucracy. With experience, you’ll get better at choosing proper documents to serve your needs.