How to Handle Verbal Demands for Project Changes
Question
Jane, the Director of Sales, contacts you and demands that you add a new feature to the software your project team is creating for the organization.
In the meeting she tells you how important the scope change would be.
You explain to her that the software is almost finished and adding a change now could cause the deliverable to be late, cost additional funds, and would probably introduce new risks to the project.
Jane stands up and says to you, "I am the Director of Sales and this change will happen in the project." And then she leaves the room.
What should you do with this verbal demand for a change in the project?
Answers
Explanations
Click on the arrows to vote for the correct answer
A. B. C. D.C.
This is a verbal change request, and verbal change requests are never implemented.
They introduce risk and cannot be tracked in the project scope.
Change requests are requests to expand or reduce the project scope, modify policies, processes, plans, or procedures, modify costs or budgets or revise schedules.
These requests for a change can be direct or indirect, externally or internally initiated, and legally or contractually imposed or optional.
A Project Manager needs to ensure that only formally documented requested changes are processed and only approved change requests are implemented.
Incorrect Answers: A: Including the verbal change request circumvents the project's change control system.
B: Directing the project team to include the change request if they have time is not a valid option.
The project manager and the project team will have all of the project team already accounted for so there is no extra time for undocumented, unapproved change requests.
D: You may want to report Jane to the project sponsor, but you are not obligated to include the verbal change request.
When a project is being executed, it is common to encounter scope changes. Scope changes can be requested by stakeholders, such as Jane, who may feel that the project's original scope does not meet their expectations. It is the responsibility of the project manager to evaluate the impact of any scope changes on the project's cost, schedule, and risks.
In this scenario, Jane, the Director of Sales, has requested a change to the software project. However, the project manager has identified potential negative impacts that the change could have on the project, including a delay in the project's delivery, additional costs, and increased risks.
Therefore, the project manager should not immediately include the change in the project scope. Instead, the project manager should document the scope change request and evaluate its impact on the project's constraints. This evaluation should include assessing the additional time and cost required to implement the change and the potential risks that the change could introduce.
Once the impact of the scope change has been evaluated, the project manager should discuss the results with Jane and other stakeholders. If the change is deemed feasible and beneficial for the project, the project manager can include it in the project scope.
If the change is not feasible, the project manager should explain the reasons to Jane and other stakeholders. The project manager should also document the reasons for denying the request in the project's change log, which will serve as a record of all scope changes and the reasons behind them.
Reporting Jane to the project sponsor should not be the first action taken. Instead, the project manager should work to find a solution that meets the project's constraints and satisfies Jane's concerns. If Jane persists in her demand for the change and it is not feasible, the project manager can escalate the issue to the project sponsor.
In conclusion, the project manager should not immediately implement the verbal change request but instead evaluate its impact on the project's constraints. The decision to include or deny the change request should be based on this evaluation and communicated to Jane and other stakeholders. The project manager should document all scope changes in the project's change log and escalate any unresolved issues to the project sponsor.
