Is a Change Request Required for Defect Repair?

As you study for the Project Management Professional (PMP)® exam or even during your practice as a PMP® credentials holder, you may end up questioning if a change request is required when a defect is found in a project. That seems like a complex question but has a very simple answer – Yes. You may be wondering if that still holds true if it is a minor fix? For something that would be a small quick repair? Something you are not even sure needs to be fixed or even impacts the project? How about if the defect repair would take less time than filling out the change request form? The answer is still…Yes.

How do we get to a yes, each time? Let’s take a look at a few definitions within A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edition. First, as you probably know, it is the Perform Integrated Change Control process that governs everything concerning changes on a project. Per the PMBOK® Guide, “Perform Integrated Change Control is the process of reviewing all change requests; approving changes to deliverables, project documents, and the project management plan; and communicating the decisions.” (pg. 113).

What is a change request?

A change request is a formal proposal to make a change on the project, and per the PMBOK® Guide “may be a corrective action, a preventive action, or a defect repair” (pg. 93). Defect repair, in turn, is “an intentional activity to modify a nonconforming product or product component” (pg. 96). Lastly, depending on the policies and procedures of your organization, you may need to gain approval for change requests from a change control board (CCB) which is defined by the PMBOK® Guide “as a formally chartered group responsible for reviewing, evaluating, approving, deferring, or rejecting changes to the project and recording and communicating such decisions” (pg. 115).

Ideally, projects would be completed without any defect repairs being needed, but since that is fairly unrealistic, projects typically build in some time, funding, and resources to deal with repairs that are needed as the project progresses and at the end once final testing has been completed.

Let’s take a look at a practical example. You are leading a software development project. One of its deliverables is a web interface where users can fill out a form and submit it using the “Submit” button. According to the specifications, the “Submit” button should be green. A tester finds the button is red. Is this a bug, or using formal language, a defect? Yes. Should it be repaired? Likely yes. One may argue it depends. But for the sake of simplicity, let’s assume the color of the button is one of the acceptance criteria. If the deliverable is not accepted, the defect should be repaired.

First things first – how should the tester notify the developer there is a defect? It depends on the organization’s policies and culture. The tester could send an email, make a phone call, or even visit the developer to discuss what they have found. How are defects typically reported and tracked? Through the use of defect tracking tools such as Bugzilla, JIRA, Plutora, etc.

Once the developer is made aware of the bug (aka defect) they then can analyze it. Hopefully, they are able to identify the root cause, can provide options to fix it (such as using configuration or hard coding) to make the button green, and are also able to provide an estimate on how long it will take to correct the defect.

When the developer has completed their analysis, what happens next? The basic process calls for a bug (defect) review meeting to be held where each bug is discussed along with their suggested repairs, impact on the deliverable and other factors, and a decision is made to approve, reject or defer the suggested repairs. Assuming the repair is approved, the developer will implement the fix, and the deliverable of a green “Submit” button will be accepted. Everyone is happy with the end result.

Does every defect repair require a change request?

Let’s take a look again at what has just happened here in the context of the primary question: Does every defect repair require a change request?

The tester has filled out the defect report in the bug tracking tool. That report was a formal proposal to modify the deliverable (the web interface). A formal proposal to modify a deliverable is the definition of a change request. A change request does not have to be a fancy 10-page document, it can be a napkin if that is what your organization accepts. A bug tracking tool described in the scenario was just an example of what could be utilized to submit a change request in instances when a defect is found. The change request in our example documented the expected result (green button), the actual result (red button), provided a unique ID number for the defect, and any other details an organization wishes to track. Whatever tool is used, we hope it is clear now that a change request should be submitted each time a defect repair is required on a project.

Does every change request require approval of the change control board (CCB)?

Another related question is: Does every change request require approval of the change control board (CCB)? This answer is not so simple, as it depends. A defect repair requires resources and often impacts a project schedule, each of which can add costs to the project. When those costs require funds beyond what was established for the project, or if allotted funds for defect repairs have been exhausted, then a CCB is often consulted for approval. Some organizations require the involvement of the CCB for all change requests. Others do not have CCB at all, and in that case, often additional approval beyond the project manager’s one will likely be needed if the change request to repair a defect will require additional funding. In some cases, the change management plan may specify that changes of up to a specific amount of money (for example, $10,000) can be approved by the project manager alone, otherwise, the change request would need to be submitted to the CCB for approval.

Does every change request trigger the Perform Integrated Change Control (PICC) process?

Finally, does every change request trigger the Perform Integrated Change Control (PICC) process? Yes, it does. In the example above, the tester reported the defect, the developer analyzed the defect and provided a suggested correction with estimated time to repair. A defect review meeting then took place to decide if the suggestion would be accepted. What has just been described matches the definition of the PICC process where changes are submitted, reviewed, and decisions made. Like with the change request that can be submitted using a fancy tool or just a simple napkin, the PICC process does not have to be extremely formal and involve the CEO and all project stakeholders. The way the process is implemented depends on a variety of factors such as the organization itself, the change management plan, and even the specific project.

Conclusion

The thing to remember is every defect repair, no matter how small or inconsequential it may seem, requires a change request. Completing a change request triggers the Perform Integrated Change Control process, and depending on the organization, the change request may or may not require to be submitted to a change control board for approval.