Mapping Risk to Quality Constraint

The PPG continues to discuss  the importance of ensuring risks are documented and analyzed along one of the primary project constraints to improve overall success of the project.

Mapping risk potentials to project constraints benefit the project by allowing the Project Manager (PM) and the project team to better understand the effective utilization these mappings have on achieving the equilibrium of the constraints needed to produce the contracted fit-for-use deliverables.

The below project constraints must work in equilibrium with each other for the project to be successful:

  • Scope,
  • Time,
  • Cost, and
  • Quality

Throughout the project, the PM has the task to find the balance in achieving the project’s objectives while honoring the project’s constraints.  If one constraint is adjusted, the others will be affected.  These constraints are often competing constraints: increased scope typically means increased time and increased cost, a tight time constraint could mean increased costs and reduced scope, and a tight budget could mean increased time and reduced scope. We have all heard the saying:  “you can have it good, fast, or cheap. Pick two!”  As seen in Figure 1, quality sits at the center of time, cost and scope where any change to any side effects it.

 

This column will focuses on the mapping of risks to the quality constraint. As we talk about the final constraint mapping: 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.

MCLMG defines project quality as the “fit-for-use” criteria determined by the project’s business sponsors or customers used to produce the project’s acceptable deliverables. Crucial to this point is that the business sponsors or customers defines the criteria for quality up front for it is these criteria on which the customer or business sponsors will ultimately sign off on the deliverable(s) produced by the project’s activities. There is no universal definition for quality in the traditional frameworks but one mistake many PM make is defining quality within the confines of the project itself.  Keeping a project on budget and on time is not the measurement of quality.  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.

The artifacts that define our projects are: Project charter or Statement of Work (SOW), Work Breakdown Schedule (WBS), schedule, budget, stakeholder analysis, Lessons-learned, and historical archives. Within these artifacts the project sponsor or customer will define their success and acceptance criteria for the production of fit-for-use deliverables for which their signature at project closure will indicate project success.

Based on the above artifacts, the quality metrics should be risk-adjusted for deliverable production. Risk adjustment is particularly important for outcome metrics because our project outcomes are driven not just by quality of our fit-for-use deliverables but the acceptance of our deliverables by the business sponsor and customer.

We have found the implementation of quality activities appears to be an afterthought to most PM. It is 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 or customers.

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.  It is therefore 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 a discussion of the risk or issues expected values (REV) including both the risk cost of impact (RCI), and the risk probability of occurrence (RPO).

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 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 an input to any formal change management process implemented as part of the project’s normal monitoring and management processes.

In closing, the need to ensure that the identified risk potentials have been mapped to the project’s defined quality metrics provided a significant piece to the entire risk constraints adjustment process started with the mapping of the risks to the scope constraint. All the previously discussed and detailed mappings can now be applied and adjusted to each other to ensure that the project’s primary constraints have the ability to achieve the level of equilibrium necessary to produce the fit-for-use deliverables as are contracted for or agreed to in the project’s initialization or instantiation artifacts listed previously in this article. The project’s primary constraints must be seen in their relationships to each other and not as independent parameters since as we have illustrated in the past four columns, project constraints are working together and must be managed in a perspective of equilibrium in order to improve the project team’s ability to achieve project success.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s