1. Planning According to the Quality Management Plan
All stakeholders must have established communication paths
Each party involved in the project must have defined channels and mechanisms for communication. This ensures timely information exchange, decision alignment, and process transparency.
Example:
In a project for implementing a corporate IT system, communication channels must be established between the customer, the development team, the testers, and the support service.
A communication matrix is created:
- customer → weekly report;
- development team → daily stand‑ups;
- testers → defect reports in the task‑tracking system.
All interaction activities must be included in the project schedule
All forms of communication—meetings, approvals, reporting, reviews—must be integrated into the overall project schedule. This makes it possible to account for their impact on timelines and resources.
Example:
If the project includes weekly status meetings, they are added to the schedule as separate tasks:
“Status meeting — every Friday, 10:00.”
This allows the team to track duration and participant involvement.
Each activity must have defined type, templates, and dates
Every interaction is formalized as a task with a clear type (e.g., meeting, review, discussion), established document templates, and specific time frames.
Example:
Activity type: “Quality control meeting.”
Template: standard meeting minutes form.
Date: every Tuesday at 15:00.
This ensures consistency and simplifies preparation.
Work completion must be documented
All completed quality‑related activities must be recorded with appropriate documentation. This provides evidence of task completion and enables quality control.
Example:
After a quality check, an acceptance certificate or inspection report is created.
If a tester finishes a test plan, they upload the document into the system and mark the task as completed in MS Project.
All stakeholders are analyzed for quality requirements
Each project participant must be evaluated to identify expectations and quality requirements so they can be reflected in project documentation and planning.
Example:
- the customer requires stability and performance;
- the development team requires clear technical requirements;
- operations require ease of maintenance.
These requirements must be captured and included in the schedule.
All stakeholder quality requirements are considered
Requirements from all internal and external participants must be included in the schedule and taken into account when defining product quality criteria.
Example:
If the customer requires load testing, the schedule must include:
“Load testing — 40 hours,”
“Results analysis — 16 hours.”
All corporate quality requirements are considered
Corporate standards, policies, processes, and organizational norms must also be incorporated into planning and quality criteria.
Example:
If the company requires a mandatory security audit, the schedule includes:
“Vulnerability audit,”
“Code fixes based on audit results.”
All quality assessment criteria are included in the product description
The product description must contain a complete set of criteria that determine whether it meets quality requirements.
Example:
- functionality confirmed by test cases;
- performance confirmed by JMeter measurements;
- requirement compliance confirmed by a traceability matrix.
These criteria are recorded in documentation and checked in final phases.
All quality requirements include quality control activities
Every quality requirement must be accompanied by specific control procedures to verify compliance during project execution.
Example:
If there is a requirement that “the interface must work without errors,” the schedule must include:
“UI testing,”
“User usability session,”
“Defect retesting.”
2. Planning According to the Risk Management Plan
All risk groups must be analyzed during identification
During risk analysis, all possible groups—technical, organizational, external, resource‑related, and others—must be reviewed to ensure a complete assessment of the project.
Example:
Risk groups: technical, financial, organizational, personnel.
Each is analyzed:
- technical — library incompatibility risk;
- personnel — risk of losing a key specialist.
All stakeholders must be analyzed when identifying risks
Each project participant must be assessed regarding risks arising from their actions, constraints, or involvement.
Example:
- customer: risk of delayed feedback;
- contractor: risk of insufficient experts;
- users: risk of resistance to change.
Each risk must have mitigation activities
For every identified risk, actions must be defined to minimize negative consequences if the risk occurs.
Example:
Risk: delay in receiving data from the customer.
Mitigation: add a buffer to the schedule + provide a backup data source.
Each risk must have probability‑reduction activities
The project must include preventive measures that reduce the likelihood of risk occurrence.
Example:
Risk: errors due to insufficient requirement detail.
Preventive action: additional requirement clarification sessions.
Each risk must have impact‑reduction activities
If a risk does occur, its impact must be reduced through predefined actions included in the project schedule.
Example:
Risk: system performance degradation.
Action: regular load testing each sprint.
Conclusion
These recommendations help create a predictable, transparent, and manageable project schedule that accounts for both quality and risk. The examples show how each requirement can be implemented in practice, converting abstract guidelines into concrete tasks.
