What is going to be more successful – a project with two or three project documents or a project with hundreds of project documents? Unfortunately, there is no “one size fits all” answer to that question; a well-run project may need either and all of the in-between. Projects can vary in size, deliverables, life cycle, scope and that is just the tip of the variable iceberg.
What is certain is that project documentation should be clear, relevant and up to date. This will ensure all project stakeholders are on the same page at the same time. Expectations, requirements, resources and risks should be obvious to all from the outset. I recently asked some of my wider community for tips on project documentation and I have summarized my findings in the blog post below. Enjoy and feel free to add your own tips and thoughts in the comments section too!
Questions to Ask Before you Start Project Documentation
Prior to kicking off the gathering or developing of project documentation, it is important you first have an understanding of why the project is happening and what type of governance the project may require. This will determine how much and what type of project documentation is required and whether you need to gather project documentation or start developing it from scratch. Here are some questions you may wish to ask yourself, the client or your manager:
- What are the goals and aims of the project?
- Has a project like this been completed in the past?
- If yes, are there project documents that were archived from it and where are they?
- Is there a standard project methodology that needs to be followed?
- What technology, if any, can or should be used?
- Who are the key team members and resources needed?
- What is the budget?
- What is the timeline?
- What communication is needed?
Once you have the answer to some of these questions you can then begin to gather and develop the project documents you may need to be successful with your project. It is then vital that you have a single project document repository that the key project members have access to and can search. Another tip is to turn versioning on so you don’t need to manually keep extra versions of the project documentation and you can roll back to a certain point in time.
9 Essential Project Documents
1. Project Business Case
This document will provide the justification for investing in the project. It is really the kick-off document that explains why the project is taking place; the goals, objectives, and outcomes being sought. This document could be a simple email from a client or a 50-page word document that has input from 10 project stakeholders.
2. Project Charter
Perhaps the most important document/contract of them all. It mandates the project, lighting the fire of its existence. The document lays out the high-level scope of work to be completed; the requirements; timeline; investment (resources and budget) required; the definition of done, and project success factors. This document needs to be approved by the appropriate officer(s) in the organization.
3. RACI Matrix
(Responsibility Assignment Model)
No matter the project size, roles and responsibilities should be clearly defined. The RACI Matrix is a great way to define and assign these responsibilities. The Matrix charts who is Responsible, who is Accountable, who is Consulted, and who should be Informed. Mapping this out helps to reduce confusion, distribute workload and increase efficiency.
4. Work Breakdown Structure (WBS)
A work breakdown structure is the core of project planning, resource management and avoiding project scope creep. The WBS is used to organize the work into manageable sections, often measured in time, for example, two weeks. By focusing on the bigger picture, the WBS ensures that no element of the project is overlooked during the planning phase. This, in turn, makes resource allocation much easier.
5. Risk/Issues Log
This is exactly what it says on the tin – a log of all risks and issues the project may face. It is good practice to follow some sort of logging format; name or ID, description, impact, probability, proposed mitigation and owner or person accountable. The RACI Matrix may make reference to the risk too.
6. Project Communications Plan
This will ensure effective communications amongst the project team and stakeholders. Sometimes it’s a simple list of dates with updates or meetings that may be needed. Other, more complex projects require email and document policies; status meetings and automated status reporting; work, status, risks and issues. Having the correct communications plan will help make project decisions more efficient.
7. Change Request Management
This will help keep track of any formal additions or alterations to the agreed upon deliverables from any of the other project documents. Change management is challenging as there is a need to ensure that the change is sufficiently detailed and comprehended by all parties. In most cases, it will have an effect on the project schedule.
8. Project Schedule
The project schedule determines what work needs to be done and when. It is the timeframe for completing tasks and starting others. All work associated with a project should be scheduled. In some cases, it is a good idea to document the planned schedule and the current schedule so that late tasks can be flagged and properly addressed. There are of course tools available to do this in an automated way. BrightWork Simple Scheduling for light scheduling needs and Microsoft project for heavy scheduling needs.
9. Lessons Learned
This is an essential document if you or your organization ever want to repeat the project or a similar project in the future. It will help fast track the next project. Although delivered post project this should be worked on throughout the project lifecycle. Recording findings at different intervals of a project will produce better quality and more factual insights. The format and detail of this document will depend on the project governance and project management culture of the organization. The entire project team should contribute and agree on the lessons learned. There should be clear takeaways and the final step is to share it with the wider team.