A Robust Method for Creating a Change Request to Solve a Product Defect

PMBOK describes five process groups for project management: initiating, planning, executing, monitoring, and controlling, and conclusion. The planning process group refers to the formulation of the project management plan, which contains all planning documents, like schedule, cost, risk, stakeholders, etc. 

After planning, all project managers aim to execute the project management plan continuously without changing any component of the project management plan; however, the project's reality is entirely different. The project may have the following causes triggering a change in the project management plan: additional requirements made by customers or defects found during validation tests in the control quality process, for example. Any request to change the project management plan commands for a change request.

Today, I am going to write about a robust process to create change requests when defects found during validation tests of the Control Quality process. 

What is a Change Request?

A change request is a document describing the problem statement, affected products, root cause, and solution proposal in detail. Every company has its own change request template. Get it with your company and begin updating it while you are researching for the best solution. 

Change Control Board (CCB) will evaluate the change request and decide if the project management plan should include this change, accepting or declining it, respectively 

What is the Problem's Root Cause, and How to Identify it?

Root cause refers to the reason why the problem is occurring in your project. You can understand it like a switch: if turning on the "root cause," the issues happen, and if turning off the "root cause," problems disappear. 

Root Cause Analyses (RCA) is a problem-solving engineering method that identifies the root causes of problems. 

RCA has four steps:

1. Explain the problem precisely;
2. Build a timeline from the usual situation up to the time the issue occurred;
3. Differentiate between the root cause and other causal factors. There are some procedures you can use depending on your case/project, but I will apply the Ishikawa diagram below [1];
4. Update the Ishikawa diagram with investigation outcomes. 

How can you Create an Ishikawa Diagram?

Considering that it is an unusual issue, and nobody knows the root cause in advance, you should schedule a brainstorming meeting with the project team to recognize every potential root causes. You should explain the problem in detail to the team, asking for possible root causes, and updating each segment of the Ishikawa diagram with it. Next, assign someone to perform tests verifying each probable root cause with an agreed due-date. You should forward a meeting minutes to everybody, sharing this action plan, and using it to follow up later on. 

After some investigations, the root cause is fully determined. Immediately you can refresh the Ishikawa diagram with the results summary from the research made by your project team. 

What is the Best Solution Based on my Project's Constraints?

Now, you can schedule another meeting with the project team to identify potential solutions for the defined root cause. I recommend you write every solution proposed in a weighted decision matrix similar to the picture below [2]. A decision matrix has every solution described in separate columns and essential project's constraints detailed in lines - like cost, lead time, quality, impacts, and so on. Note that it is necessary to include a weight for each project's constraints.

Review the decision matrix table with the project team, and define who will provide data to fill up the decision matrix. You should assign an activity to everyone and align a date for their response. After that, you can send a meeting minutes to everybody, sharing this action plan, and using it to follow up later on. 

The next step is to complete the decision matrix with the collected acknowledgments and propose a solution to the problem based on your project's understanding, the team's recommendations, and the solution weighted winner.

Submit a Change Request

Immediately, after updating all the fields of the change request template with the exceptional information you have received earlier, make sure you filled each space with accurate information, and submit it for CCB approval. If CCB approves it, then you will have to update your project management plan accordingly. If CCB rejects it, you should update only the change request table status. 

Bibliography

1. Seeds of Laboratory Quality. Fishbone Diagram: The Meat of Root Cause Analysis. https://seedsoflaboratoryquality.com/2018/06/01/fishbone-diagram-the-meat-of-root-cause-analysis/

2. Info Nautics. (2017). Make The Right Decision Using A Decision Matrix. https://www.infonautics.ch/blog/decision-matrix/

I hope that this article could help you to succeed in your next project issue, and if you like my article, please thumbs up and give your comments below. I would love to answer you. Have an immeasurable day!