Certification Insider

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.

(Click to download MP3...)

It's hard to juggle everything on your project. And just a glance at your company's project management methodology can make you despair about getting it all done.

But if we take a page from agile development, adding tools from behavioral psychology to Pomodoro, and incorporating pragmatic prioritization, you’ll be able to build a personalized time management system that fits your own working style. Come out of this interview with a manageable system for yourself and the tools to help your team members manage their own time and priorities.

This interview with Kim Wasson (LinkedIn Profile) was recorded at the exciting Project Management Institute (PMI)® Global Conference 2018 in Los Angeles, California.

In the interview, we review the key components of a good time/priority management system, the smorgasbord of tools available, and we discuss how to create a tailored time management system and advise team members on ways to manage their time and priorities.

(This interview was originally published on The Project Management Podcast.)

(Click to download MP3...)

Is your company thinking about setting up a PMO and nobody, not even you, have the experience to do it?

That is not a problem.

Our guest today is Hussain Bandukwala (LinkedIn Profile). He is the organizer of the PMO Virtual Summit and PMOs are his passion. He writes and speaks about them. And in one of his articles, he says that even if you’ve never done it before you can still set up a PMO in 100 days.

We discuss how realistic this is, what skills a PMO leader needs, the mindset needed to do this in 100 days, and then we’ll take you phase by phase through the process of setting up your very own PMO in 100 days.

(This interview was originally published on The Project Management Podcast.)

(Click to download MP3...)

Last year at the Project Management Institute (PMI)® Global Congress 2017 in Chicago, Illinois I recorded about a dozen interviews. They have all been published over the past year and you've probably heard some or all of them. But what you don't know is what happened once each interview was complete.

I pressed the recording button one more time and asked each of my guests the following question: What business management skills are essential for today’s project manager if they want to become more and more involved in strategic projects for their organizations?

And today you are going to get all the answers. In one nice mashup. Here are all the presenters in the order you will hear their answers

• Andy Kaufmann
• Betsy Stockdale
• Laszlo Retfalvi
• Justin Fraser
• Jen Pfaff
• Sarah Gallagher
• Kim Wasson
• Darryl Hahn
• Jeff Kissinger
• Niraj Kumar

Oh, and spoiler alert... the answer that I received most often was "Flexibility".

(This interview was originally published on The Project Management Podcast.)

(Click to download MP3...)

This interview with Niraj Kumar (LinkedIn Profile) was recorded at the lively Project Management Institute (PMI)® Global Conference 2017 in Chicago, Illinois.

We share insights gained from leading teams in the aftermath of the 2016 flood, called the worst Louisiana disaster since Katrina. Learn how our guest led teams through devastation around them and reacted to a life-altering situation, yet stayed true to the mission to serve the community.

You will hear how the team leaders collaborated to ensure that the critical tasks get done, operations keep humming, and the affected customers continue to receive service.

(This interview was originally published on The Project Management Podcast.)