PMP · Question #915
An organization is transitioning to an agile project delivery approach. Each project is structured as a Scrum team. A project is in the initiation phase. In one of the workshops, a business subject…
The correct answer is D. Add the legal department to the list of stakeholders and contact them to discuss the project. Upon discovering potential legal constraints and an overlooked stakeholder, the project lead must immediately add the legal department to the stakeholder list and directly engage them to understand the implications.
Question
An organization is transitioning to an agile project delivery approach. Each project is structured as a Scrum team. A project is in the initiation phase. In one of the workshops, a business subject matter expert (SME) indicated that the project may have legal constraints. The legal team was not identified as a stakeholder in the project brief. What should the project lead do?
Options
- AAsk the solutions architect to contact the legal department and create the epic(s) in the product
- BAdvise the SME that there are no legal requirements identified in the project brief and continue
- CAsk the project sponsor to contact the legal department and identify the legal impact.
- DAdd the legal department to the list of stakeholders and contact them to discuss the project
How the community answered
(24 responses)- A8% (2)
- B17% (4)
- C4% (1)
- D71% (17)
Why each option
Upon discovering potential legal constraints and an overlooked stakeholder, the project lead must immediately add the legal department to the stakeholder list and directly engage them to understand the implications.
Delegating stakeholder communication to a solutions architect is not the project lead's primary role, and creating epics without direct legal input is premature and risky.
Ignoring potential legal constraints and dismissing the SME's valid concern is irresponsible and could lead to severe project failures or non-compliance.
While the sponsor might eventually be involved, the project lead should first take the initiative to establish contact with the newly identified stakeholder and gather initial information directly, as this is part of their stakeholder management responsibility.
As the project lead, it is crucial to immediately identify and engage any missing key stakeholders whose input can significantly impact the project, such as the legal department when potential legal constraints are raised. Adding them to the stakeholder list and contacting them directly allows for a timely discussion to understand and address any legal implications before they become larger issues.
Concept tested: Stakeholder identification and engagement
Source: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok/stakeholder-engagement
Topics
Community Discussion
8Confirmed D on exam last week. The moment a new stakeholder surfaces during a workshop, the project lead adds them to the stakeholder register and reaches out directly. A is wrong because legal constraints are not the solutions architect's call to chase down, and C defers basic stakeholder engagement to the sponsor when the lead can handle it. B is the trap, since the project brief is a living artifact in agile, not a reason to ignore a newly identified risk.
Good catch on B being the trap, and I would just add that reaching out directly also matters because a newly surfaced stakeholder often carries requirements nobody has captured yet, so the sooner that conversation happens the less rework later.
D. Stakeholder list is living, not locked at brief time. Confirmed on exam.
I went with A here, and honestly it makes the most sense to me in an agile context. The solutions architect is the right person to bridge a technical or compliance constraint into actual backlog items, and creating epics is exactly how you capture something like legal impact so the team can see it and plan around it. The PMI mindset on these seems to favor concrete action over escalation or just updating a document, so reaching out and translating the concern into work feels stronger than looping in the sponsor or simply adding a name to a stakeholder register. The legal constraint surfaced, so capture it where the team
Grace, I think you are mixing up roles here. Are you asking whether the solutions architect owns translating compliance into backlog items, or whether that is really the product owner's job? My understanding is D is correct because when a legal or regulatory constraint surfaces, the right move is to escalate to the sponsor so they can decide on scope and priority impact, not to unilaterally start creating epics. Can someone confirm I have that right?
Going with A here. In an agile setup you want to get those legal constraints captured as epics in the backlog early so the team can see them, and the solutions architect is the right person to translate that into actionable work items.
D is correct here. Legal and regulatory constraints belong in the nonfunctional requirements, not as epics, because they define the qualities the solution must satisfy rather than discrete chunks of deliverable functionality.
Going with D. New stakeholder surfaces, you engage them directly, right?