Customer not satisfied

Discussion in 'PMP' started by _49203, Aug 15, 2019.

  1. _49203

    _49203 Active Member

    Joined:
    Nov 22, 2018
    Messages:
    36
    Likes Received:
    5
    Hi @timjerome,

    I would sincerely appreciate your assistance with the questions below.


    1) A Project Manager has made a major release in the project. The customer tells you a week after the release that he is not entirely satisfied with the deliverable. What should the project manager do NEXT?

    Continue with the next deliverable to finish the project on time
    Discuss the customer concern and resolution with the senior manager
    Ensure that next deliverables have enough features, which the customer would like to have, to exceed his expectations
    Do a scope verification of this deliverable to see if it satisfies project objectives

    Correct Option is D


    >>I went with B here since I figured: 1) option B meant analyze first, and 2) this was occurring several steps after scope verification. Is the word "release" here synonymous with "acceptance of deliverables?" Thank you.

    2) You are a project manager for a project in the execution stage. The current Schedule Performance Index (SPI) and Cost Performance Index (CPI) for the project are 1.2 and 1.1. The project performance is well within the baseline. The defects found during the internal testing for the last deliverable were well below organization limits. However, the customer does not seem to be happy with the project's progress. What should be the FIRST thing the Project Manager does?

    Start managing the project as you gain more insight into day-to-day responsibilities
    Meet with the project team to understand open issues in the project
    Conduct a meeting with the customer to understand his concern over the project's progress
    Improve the project schedule and cost control measure so that SPI and CPI reaches above 1.5
    Correct Option:C


    >>I did select option C here - but I'm a little confused because in which of these situations should we "analyze first?" The question #2, Option B also seems plausible because the defects are below org limits AND the project progress is ahead of schedule. Thanks in advance.

    3) After a major milestone release, some of the key stakeholders are not happy and complain that their requirements are not met. To ensure their approval for the release, the project manager should have involved them in the process:

    Project Management Plan Development
    Identifying Constraints
    Validate Scope
    Schedule Management
    Correct Option:C


    >>Which language here implies that the stakeholders were not involved in the Validate Scope process? It seems the most logical answer considering the options but why is option A incorrect? Thank you.

     
    #1
    Last edited: Aug 15, 2019
  2. tim jerome

    tim jerome Well-Known Member
    Trainer

    Joined:
    May 15, 2015
    Messages:
    1,928
    Likes Received:
    553
    Note - when I receive multiple questions like this, it will take more time to work through the entire forum questions. I don't mind, as long as everyone understands and remains patient with the process (grin). I want to ensure what I'm saying isn't misleading against the source material, and is founded in something I can justify through more than my personal opinion.

    /*
    1)
    B is a little worrisome since you are not analyzing with a formal PM role. C concerns me, since it looks at a future release, and not the current one (these issues have a tendency to build on each other). A looks a bit like blindly moving forward, and D only looks at correctness, not completeness. However, D is a step in the right direction.

    I was tripped up by 'release' until I realized that this is a single project with multiple releases; I was thinking down the path of post-transition issue management for a few seconds.

    I'd much rather go to the team, and take the issue up directly with the stakeholder who voiced their concern.
    */

    /*
    2)
    Much like above, we fall back on ethics. but first, let's talk about analysis.

    We go to the team in order to analyze and gain support from our experts.
    We go to the sponsor to advise and recommend.
    We go to the stakeholder WHO RAISED THE ISSUE in order to resolve the issue quickly, at its source.

    Generally, the only sequence you can rely on is to go to the team, then the sponsor. I guess one could say you could go to the stakeholder with the issue, get their concerns, then go to the team, but I can't find and don't remember any source material that supports this - it's purely opinion. I'd advise to test this out on other questions to attempt to find a pattern. It works pretty well for me with random questions. If I find a citation, I'll save it for future discussions.

    Again, this is solved using references from the code of ethics. How did I know this was ethics? It's the right thing to do. It ensures respect, an active support for truth, visibility (honesty), and when applied to all, generates fairness.

    */


    /*
    3)
    There are two major areas we use requirements - in verifying the deliverable (control quality), and validating the deliverable (acceptance/validate scope). We verify for correctness, and we accept for completeness. A does not test or verify - it PLANS.

    We sign off on deliverables in validate scope, and we inspect against our quality metrics (i.e. control limits, specifications) in control quality.

    Since we don't have a quality process in the list, we must consider the scope process here.
    */
     
    #2
    AS12345 likes this.

Share This Page