Dear ABSY KRDEY.
We frequently hear our customers expressing their concerns about the need to submit a change request for defect repair. Indeed, the interpretation of this topic as described in the PMBOK® Guide may confuse. I'll try to outline my point of view in this post.
1) Does every defect repair require a change request? YES. Surprised? Hold on, explanation follows.
2) Does every change request requires the approval of the change control board (CCB)? NO. Or, more precisely, it depends. Confused? Hold on again.
3) Does every change request trigger the Perform Integrated Change Control process (PICC)? YES. Disoriented? Buckle up your seatbelt; we are going to bust some myths.
According to the PMBOK® Guide, a change request is "a formal proposal to modify any document, deliverable, or baseline." Change requests may include corrective action, preventive action, defect repair, updates. Here, we will focus on defect repair.
Again, according to the PMBOK® Guide, a defect is an imperfection or deficiency in a project component where that component does not meet its requirements or specifications and needs to be either repaired or replaced.
And lastly, Perform Integrated Change Control is "the process of reviewing all change requests; approving changes and managing changes to deliverables, organization process assets, project documents, and the project management plan; and communicating the decisions."
Now, enough with dry definitions. Let's take an example. You are leading a software development project. One of its deliverables is a web interface where users can place orders. According to the specifications, the "Submit" button should be green. A tester finds that the button is red. Is this a bug, or using formal language, a defect? Yes. Should it be repaired? Yes. Well, one may say it depends. But again, let's make it simple. Yes, the defect should be repaired.
How will the developer know that there is a defect and that it should be repaired? The tester will let the developer know. How? By phone, text, email, or maybe will come by the developer's cubicle. Well, again, it depends on the organizational policies, procedures, culture, etc. But again, let's make it simple. How are typically defects reported? Using a defect tracking tool (e.g., Bugzilla, JIRA, Plutora, etc. You name it). What typically happens next? The developer will take a look at the bug, analyze it, hopefully, find the root cause, evaluate options on how to fix it (let’s say, making the button green can be done by hard coding the color or using configuration), and provide the estimate on how long will it take to implement the fix (e.g., 2 hours).
What happens next? Again, going with a simple process, a bugs (defects) review meeting will take place where defects and their suggested fixes are discussed, and decisions made as to what defects will be repaired, what are deferred, etc.
Let's assume our defect gets a “GO” to be repaired. The developer implements the fix, and the deliverable is accepted. End of story. The project is complete. Everybody is happy.
So what happened here? Let's go back to our three questions:
1) Does every defect repair require a change request? YES. The tester has filled out the defect report in the bug tracking tool. The report is a formal proposal to modify the deliverable (the web interface). Aren't you willing to agree that the defect report is a change request? You are not alone. A change request does not have to be a fancy 10-page document. It can be a napkin if this is what the organization accepts. In our example, a defect documented in a bug tracking tool which has the ID, the expected result (green button), the actual result (red button), the version of the software where the bug was found, and all other details are much more than a napkin. It's a formal proposal to modify the deliverable (the web interface - modify the color of the button from red to green on the web interface). So here is our 1st question answered - every defect repair requires a change request.
2) Does every change request require the approval of the change control board (CCB)? NO. Or, more precisely, it depends. Can you imagine a project without defects? Well, it was a rhetorical question. It is reasonable to assume that every project will have defects. Therefore, on a properly planned project, funds are allocated to repair defects. Defect repair consumes project resources, such as schedule and budget. When resources required to repair defects go beyond the allocated funds, every extra defect, or more precisely, its repair will have to be decided on a case-by-case basis. Sticking with simplicity in our example, let's assume the time and cost to implement the change request of fixing the color of the button from red to green fall into the allocated schedule and budget for defect repair. In other words, defect repair would not affect the baselines. Then it is highly unlikely that the project manager will be required to submit this change request to the CCB for approval. Most likely, the project manager will instruct the team to implement the fix. However, if resources allocated for defect repair have already been exhausted, then even this apparently minor defect of the wrong color will likely require a deeper discussion and maybe even the involvement of the CCB. There could be other scenarios where a change request to repair a defect may go to the CCB. Let's assume the web interface is required to support 100,000 concurrent sessions (users interacting with the web interface at the same time). Now let’s assume the tester found that that the web interface supports only 50,000 transactions and then, with every additional transaction, slows down and eventually crashes before reaching even 60,000 transactions. The tester submits a change request (fills out the bug report in the bug tracking tool, remember?). The developer analyzes the defect and realizes that in order to repair it, the entire software module responsible for the web interface performance has to be re-written. The developer estimates it will take two months to implement this change. To make it more dramatic, let's assume the project is supposed to be completed in one month from now. In other words, the baselines would be affected. Not only this change request will have to go to the CCB, but there is a significant risk to the whole project to be terminated prematurely. In general, the change management plan will specify how changes are managed on a project including the level of authority of the project manager to approve changes without the need to involve the CCB. For example, the change management plan may specify that changes of up to $1,000 can be approved by the project manager alone, otherwise, the change request should be submitted to the CCB. So here is our 2nd question answered - not every change request has to go to the CCB for approval. It depends. Right?
3) Does every change request trigger the Perform Integrated Change Control process (PICC)? YES. What did the developer do when the defect was reported? Analyzed the change required, evaluated the options to repair the defect, and provided an estimate. Then, a defect review meeting took place, and a decision has been made to fix the defect. So, the PICC process was carried out. Again, like the change request on a napkin, the PICC process does not have to involve the CEO and all project stakeholders. The way the process is implemented depends on the organization, on the change management plan, on a specific project, to name but a few.
To summarize, every defect repair requires a change request which, in turn, will trigger the Perform Integrated Change Control process, and may or may not require to be submitted to the change control board for approval.
I hope this sheds some light on the issue and helps in your preparations for the exam.
Have a great holidays season.
