Monitoring and Controlling Process Group Process – Perform Quality Control – Mind Map


Quality control – deals with correctness of the deliverable & meeting the quality requirements specified for the deliverable in project quality standards.

Below is the Mind Map of Perform Quality Control process. As usual, I tried putting as much information as possible in each branch in this process map to bring out completeness to it. Hope this will be useful to you.

Perform Quality Control

 

Inset image of Seven Quality Control Tools

Quality_Control_Tools

How often should I validate current project level?


Many managers think that everyday (even sometime hourly) tracking of their real work completed with plans made. This puts more pressure on each one performing the activity to deliver things as soon as possible, as fast as they can. This problem happens because planning of validation frequency was not done as part of the project planning.

Validation has 3 important parameters – 1) Criteria for validation 2) Validation frequency 3) Validation steps

1 – Criteria for validation: Deciding the criteria for validation is important. In some manufacturing unit, criteria can be number of unit manufactured. In some other organization, it is as soon as particular activity finished. As part of criteria it is important to define the Inputs & Outputs for the validation process.

2 – Validation Frequency : How often should I validate current project level against the plans? This question gives you insight in deciding the frequency of validation.

3 – Validation steps : Having too many validation steps makes the project more complex.

The law of complexity says that the level of complexity of any task is equal to the square of the number of steps in that task. Complexity can be defined as the potential for increased costs, increased time, or increased mistakes.[1]

So, it is really critical in keeping the number of validation steps to optimal to get greatest benefits out of it in terms of increased productivity, low project cost and higher profit margins.

References:

1. Focal Point by Brain Tracy

Fishbone Diagram – A Project Management Tool


I thought of writing about this tool, but I found millions of web page result in my search engine! I decided to put a fishbone diagram with links to pages which I found useful to everyone of us.

Fishbone diagrams otherwise called as Ishikawa diagrams (or cause-and-effect diagrams) are diagrams that show the causes of a certain event. In project management, this tool is used in Quality Management & Risk Management processes. Here I depicted causes for ‘PMP Exam failure’ Effect.

 

PMP_FishBone

You can read more about this in following links:

1) Wikipedia – http://en.wikipedia.org/wiki/Ishikawa_diagram

2) Leankaizen – http://www.leankaizen.co.uk/fishbone-diagram-i-ishikawa-diagram.html

3) This one on 5 Why cause -effect analysis: Know the root cause for any problem within 5 whys

Executing Process Group Process – Perform Quality Assurance


This is another process in Executing Process Group. Below is Inputs, Tools & Techniques and Outputs Mind Map for Perform Quality  Assurance which is classified under Quality Management Knowledge Area.

 Perform Quality  Assurance 

Important Note:

* Note# 1: There could be some typo or presentation errors. Please reply back for any corrections.

* Note# 2: You can use this for personal use (like studying for PMP Exam or PM activities). But don’t share this in common forum or web sites. As this one is part of my training guide and project management book.

Preventive Actions


Though Preventive Action term is often used with Quality Management Systems, but it is vital and used widely in all knowledge areas esp. Project Integration, HR, Quality & Risk.

Some processes recommend preventive actions as output and few other processes takes the approved preventive actions as input to bring the project into compliance with project management plans.

Preventive Actions are documented direction to perform an activity that can reduce the probability of negative consequences associated with project risks.
[1]

Preventive actions are recommended in anticipation of possible problems and they are generally output from monitoring and controlling process group. Preventive actions may also include contingent actions taken to reduce the seriousness of a future problem if it should occur. Depends on the nature of responses to preventive actions, sometimes, they may results in a change request.

A simple example of Preventive action would be providing first aid kits in each block of organization and posting list of emergency phone numbers inside lifts.

Project manager and project management team along with all stakeholders need to review recommended preventive actions and debate on the effectiveness and implementation procedures before they are submitted for approval. Only approved preventive actions are later implemented.

Preventive action is a proactive process to identify opportunities for improvement rather than a simple reaction to identified problems. Preventive action include investigation, action, review, and further action if so required and follow Deming’s PDCA cycle.

In Quality management, Recommendation of new preventive actions is done in Quality control process. Preventive action involves action taken to prevent a condition that may exceed established parameters in a manufacturing or development process, which may have been indicated through a QC measurement.

In Quality Assurance process, quality audits confirm the implementation of approved change request, defect repairs, corrective actions, and preventive actions and it may recommends corrective actions.

Taking preventive actions in HR issues reduces the probability and impact of resource problems before they occur. Examples to preventive actions are: training resources beforehand to reduce problems during resource crunch, clarification on roles and responsibilities, project progress and deadlines can increase the team buy-in and reduce problems when they are asked to put extra effort to meet project deadlines.

As mentioned in my earlier post on stakeholder management & analysis, by anticipating stakeholders’ reaction to the project, taking preventive actions can be taken to win their support or minimize potential negative impacts.

Root cause analysis combined with corrective action to help understand the cause of the deviation and potentially prevent recurrence of a similar problem.

References:
[1]. PMBOK® Guide – 3rd edition

Quality is not grade


In general conversation, we use quality and grade interchangeably. But they are not the same as far as Project Quality Management is concerned.

Quality of a product is “the degree to which a set of inherent characteristics fulfill requirements

–American Society for Quality, 2000 standards

Grade is something related to classification of products or services based usually on technical specifications. Grade is based on Scope & not on quality. Example: Various grades of Construction Cements like 33 Grade, 43 Grade , 53 Grade, etc. are available in market.
Different graded items are created with a purpose or requirement and low grade does not mean it is a defective one or low quality one. But low quality product means the product is not meeting requirement and it is defective. And any grade can have defects if it does not meet the requirement.

In software development, limited feature(usually called as demo applications) release and full feature (usually called as full license) release – both can be considered as two different grades of products and not low quality one.

Project manager & the project management team decides the required levels of quality and grade of the product.

More on Project Baselines


In the earlier post, I briefed about definition of baseline and what constitutes project baseline. Now, let us review elaborately on this topic.

A schedule baseline is a project schedule developed from the schedule network analysis used to verify lag and lead time of current project activities against approved deadlines (mainly used in schedule control).

The cost baseline is an authorized budget used to estimate, monitor, and control overall cost performance on the project. Generally, in any organization, a project budget authorization & approval happens in staggered manner(unless it is a small project). So, Cost baseline is developed as a summation of the approved budgets by time period & it is typically displayed in the form of an S-curve.

Scope baseline is used to compare current scope with actual approved scope and decide whether a change, corrective action or preventive action is required (mainly used in scope verification process). Typically, approved detailed scope statement, WBS and WBS dictionary are the scope baseline documents for the project.

The quality baseline records the quality objectives of the project. The quality baseline is the basis for measuring and reporting quality performance as part of the performance measurement baseline. All above 3 baselines are input in identifying quality standards to be followed in the project within the project constraints.

Variance is another term related to baseline. During project execution, variances will require re-baselining (of course update on plans too). These variances can include changes to activity timings, changes in availability of resource, and risks. Such variances may affect the project plan or project documents and may require detailed analysis and development of appropriate project management responses. The results of the analysis can trigger change requests that, if approved, may modify the project management plan or other project documents and possibly require establishing new baselines.

Stakeholders requirements should be clearly understood and need to be incorporated into different plans before these are base-lined.