Jonathan, Thank you so much for taking the time to respond thoroughly. I assumed that "we had a clear case of a project deliverable meeting all requirements" based on the text "the project team was given the green light after conducting intensive quality control checks". That's where I must have gotten hung up. The "green light" made it sound like all deliverables were met and we simply had a customer that was getting cold feet or didn't want to pay. Guess I shouldn't have assumed as much.

Hey David -

If we had a clear case of a project deliverable meeting all requirements and the customer simply refusing to pay us for our work, then we'd need to start exploring the resolution options as you suggest. However, in this case we haven't gotten to that point yet - we came to the customer and they said that what we delivered isn't what they need. This could be due to a few reasons:

• Perhaps, desiste our best efforts and intensive quality controls, we didn't hit the mark. Maybe the customer tested the product and identified defects, or maybe we failed to address a requirement. In this case, we messed something up along the way and need to go back and fix it, and that process begins with a change request.
• It's also possible that our deliverables are great, but the customer rejected them anyway because we had both failed to identify a requirement up front. Perhaps we were given latitude to come up with a color palette for the interface of a new piece of software we're developing, and inadvertently chose colors associated with the customer's biggest competitor. It makes sense that the customer would want to change this before accepting delivery, even if nobody thought about it in the design stages.
• And maybe the requirements simply need to change due to other reasons. Maybe the customer is changing its branding guidelines and needs to update the deliverables accordingly, or we are producing parts for a machine and the requirements for our part have changed due to a design change on the customer's end.

Regardless of where the "blame" lies here, we're going to have to go back and change something because the customer has told us that the deliverables aren't what they need. It's certainly possible that we may at some point negotiate with he customer to share the cost of that change, depending on the root causes, but regardless we need to go back and do something differently for the project to be successful, which means kicking off a change request. The change control board can then take that information and look more closely into what we are going to do in response to that request.

Hi David:

The customer would not have rejected the deliverable unless there was a reason to do so. The logical assumption would be a defect or the deliverable didn't quite meet the customer's expectations. If the customer felt the need to reject the deliverable, you must proceed with the change request. This will trigger the change review process where to true impact of the change will be determined. At the end of the day, the customer is the customer.

OK, here's another one I'm struggling with. L05.99.

---

Question 10: Julie is managing a software development project. The project is divided into multiple phases and the completion of each phase requires a customer inspection and final approval. The first project phase has just been completed and the project team was given the green light after conducting intensive quality control checks, as outlined in the Quality Management Plan. However, during the inspection, the customer rejected the deliverable. What should Julie do next?
A.) Issue a change request
B.) Negotiate with the customer to approve the deliverable
C.) Escalate the issue to the project sponsor
D.) Ask the project team to make the required changes immediately
Correct answer is A
Explanation: The rejection may be based on found defects or changes in customer requirements. No matter what the reason is, changes have to be made because the project customer has asked for them. Therefore, a proper change control process needs to be followed and the next logical action for Julie is to issue a change request.

---

There is no indication in the question that the customer is asking for changes, only that he/she rejected the deliverable. IMO the logical thing to do is understand why the deliverable was rejected leading to B (Negotiate) followed by C (Escalate) if negotiations prove unfruitful. Am I missing something?

Thanks Jonathan. Much appreciated!

Hi David -

I think you're getting too hung up on semantics in this situation. Forget for a moment about named terms, and look at what the question is asking: if you need to progressively elaborate on your plan as you go, what is the best approach for regularly re-evaluating your current situation and go-forward plan? In this case, you'll probably want to break the larger project down into multiple phases, and treat each phase as an iteration of the process, so that you can regularly re-evaluate where you are and what you want to accomplish in the next cycle as the picture begins to take shape.

While the exact terms may not line up exactly that way in the PMBOK glossary, I think the plain-language interpretation of the terms holds up just fine in this case and supports answer choice B as being correct.

While it's good to know the key terms listed in the glossary, I'd caution you against treating that as an exhaustive list of the terms you could encounter on the exam. It's more important to understand the concepts behind those terms, as you are likely to see these core concepts presented in a number of different ways and not necessarily verbatim according to the textbook.