Key documentation of the project

 
Many companies do not pay due attention to documentation, because it takes a lot of time and the client is not always ready to pay.

But if the project is quite voluminous and the period of its implementation stretches for years, then it is still worth revising your approaches and fixing everything that happens to the project.

 

After all, there is no guarantee that the project manager will not turn around and leave, that the client will not retroactively abandon his previously voiced ideas. 

 

That is, you always need to be on the alert.
Consider the minimum set of documents that should be on each project:

1. Project Charter – fixes the partnership between the contractor and the client. The charter is usually developed by the project manager. The purpose of creating a document is to confirm the launch of the project, to give the project manager authority in using the company's resources, in planning, executing the project and controlling it.
2. A project management plan is a document that describes in detail how the project will be implemented, how the monitoring and control of both individual stages and the project as a whole will take place.
3. Business Requirements Document (BRD) – Details the business decisions for a project, including documentation of the customer's needs and expectations. As a rule, they are based on the use of User Stories (short and simple descriptions of features).
4. Technical task (specification, SOW) - a specified set of requirements for the product, approved by the customer and the company by the contractor (functional requirements that must be implemented by developers so that users can perform their tasks within the framework of business requirements).
5. Stakeholder Map – each stakeholder is described: surname, name and patronymic; position; degree of influence; the degree of importance; "state" of the stakeholder (Work with stakeholders); what he is responsible for in the project, as well as a list of issues that can be discussed with him; communication channels; contact details;
6. Matrix of the influence of stakeholders on the project (Work with stakeholders);
7. Communication Plan Matrix – contains: the type of information that needs to be shared with stakeholders (Status Reports, Status Updates, meeting results, etc.); the purpose of communication; who is responsible for the delivery of information; who is the recipient; the method and format of providing the necessary information: phone call, e-mail, videoconference, message in the channel, report, presentation, etc .; at what frequency and at what time it is necessary to provide information;
8. Project Schedule – a list of control events and dates of their implementation;
9. Meeting Notes (Kick off Meeting, Planning Meeting, Stand-up Meeting, Retrospective) – fixation of the results of any meetings that relate to the discussion of issues related to the project.
10. The matrix of responsibility for the project is a fixation of the degree of responsibility of each team member for the implementation of certain functions.
11. Risk Register – contains information about the identified risks of the project, as well as a list of possible measures to respond to risks. The document reflects: number; date of deposit; the name of the risk; detailed description; who is responsible for risk management; Points of vulnerability (root causes); the likelihood of risk; the degree of influence on the project; risk mitigation strategies; risk trends.
12. Probability and Impact Matrix (Risk Matrix) – includes risk assessment criteria, namely: the level of damage from the realization of risk and the probability of occurrence of a risk event within a certain period of time. At the beginning, a risk exposure scale is drawn up (using the example of "cost": a slight increase in cost - a very low impact indicator (0.05), an increase in the cost of <10% - a low impact indicator (0.1), an increase in cost of 10-20% - a moderate impact indicator (0.2), an increase in cost of 20-40% - an impact rate of high (0.4), an increase in the cost of >40% - a very high impact indicator (0.8)), then the probability of risk occurrence and the expected one are determined, then the probability of risk arises and the expected risk value (the product of probability on impact). And such an analysis occurs for each risk.
13. Risk Report – a document containing information on the sources of total project risk, the results of qualitative risk analysis, quantitative risk analysis, risk response planning, risk response and risk monitoring.
14. Risk Log – is filled in only if you had to use the risk register and follow the recommendations that are described in it. The document reflects: number; Date of occurrence; the name of the risk; detailed description; who identified; who is responsible for the elimination; priority; the degree of influence on the project; Recommended actions status; closing date.
15. Issue Log (Incident Report) is the documentation of an event that disrupted the normal operation of any system (process, etc.), and how this situation was handled. The document records: the number of the incident; Date of occurrence; Name detailed description; who identified; who is responsible for the elimination; priority; the degree of influence on the project; Recommended actions status; closing date.
16. Change log (sometimes called Change Requests) is a record of requests to change any functionality of the product. A change request often occurs when a client wants to add or change something, after all requirements have already been agreed upon. Such a change may include an additional feature, customization or enhancement of functionality. Since change requests are outside the scope of the agreement, this usually means that the client will have to pay extra for the implementation of this functionality. As a rule, Change Requests contains: the name of the project; request number; the name of the request; the date of the request; a description of the requested changes; the reason for the changes; the impact of changes on: existing requirements, work schedule, project cost.
17. Weekly Project Status Report – once a week: achievements for the past week; last week's outstanding tasking; the challenges the team faced last week; Change Requests numbers that were released during the week; plans for the next week; Upcoming Milestones (not all mentioned, but the next 2-3 stages); new risks; indicators for key metrics (Monitoring and control of the work performed on the project).
18. Documentation from testers (Test Plan, etc.).
19. The User's Guide is a document that assists the user in the operation of the system.
20. The Administrator's Guide is a document that assists not only in the operation of the system, but also in its installation and configuration.