As the final constraint mapping involves quality and acceptance metrics it is not intended to be the least important – quite the contrary. The quality constraint of projects is probably the most misunderstood and mismanaged of all the primary constraints. While the amount of research and written dissertations on quality is copious and available, for project management specifically, most project managers seem to miss the target.
In short, project quality can be simply defined as the “fit-for-use” criteria determined by the project’s business sponsors or customers used to produce the project’s acceptable deliverables.
As opposed to the current understanding of project quality definitions and activities, quality criteria must be determined and accepted during the initiation phase of the project and not at the end of the project’s lifecycle as described in most project “bodies of knowledge” during the scope verification process.
Parameters: Project charter, WBS, Schedule, Budget, Stakeholder analysis, Lessons-learned, historical archives
Determinations: Risk-adjusted quality metrics for deliverables production,
The implementation of quality activities appears to be an afterthought to most project manager, we have found, that it usually left almost entirely to the assigned quality manager / analyst team member. Quality as defined above must be the focus of every project team member since it is the production of “fit-for-use” deliverables that will achieve the quality benchmark as determined by project sponsors. So mapping risks and issues to quality metrics provides the additional clarity as to the impact that risks and issues will have on the ability of the project to produce acceptable deliverables.
First, in order to achieve this clarity the quality metrics must be well understood and accepted by both the project sponsors as well as the project team. The risk and issues identification at the point when the quality metrics are being defined is usually somewhat embryonic in development. So it important to execute this risk / issue mapping to quality metrics process repeatedly over the project lifecycle usually after major project milestones or achievements have occurred. The mapping process of risks and issues to quality metrics thus begins with an discussion of the risk or issues expected values (REV) including both the risk cost of impact (RCI), and the risk probability of occurrence.
Having completed the initial risk analysis to produce the REV provides the earliest indications of the associations between identified risks and issues and the quality metrics that define the project’s deliverables. These indications will illustrate the associations that if a particular risk becomes a reality, its REV will have this potential negative impact on this specific quality metric. The project team members that must be involved in these discussions include the:
- PM (project/program/portfolio) management
- Risk manager/analyst
- Business manager/analyst (BA)
- Key risk owners
- Quality manager/analyst
- Business sponsor and key customers
As a prelude to these discussions, the quality SME (quality manager/analyst), risk SME (risk manager/analyst) and BA should provide an initial mapping and impact analysis of each risk or issue and its potential to prevent the production of “fit-for-use” deliverables.
Once the initial analysis is completed by the smaller, more mobile group (quality, risk, and BA), the preliminary determinations are presented to the larger group listed above for their discussions, modifications, and ultimately affirmations of the quality impacts. The approved determinations of this group are instantiated as the risk-adjusted quality metric mappings for the project as a whole, and must be disseminated to the rest of the project team and stakeholders.
We suggest that at this point a quality metric artifact such as a quality metric tracking tool or quality metrics traceability matrix be implemented to provide the project historical logging of the now risk-adjusted quality metrics throughout the project’s lifecycle. This quality metrics traceability matrix is now a parameter to any formal change management process implemented as part of the project’s normal monitoring & management processes