PMP · Question #1392
An agile team recently started working on a project for a financial institution. The project sponsor is concerned that an agile approach will not provide enough support for the organization's…
The correct answer is B. Meet with the compliance team and make sure that their requirements are covered in the. To mitigate the risk of an agile approach not supporting compliance standards in a financial institution, the project manager should proactively engage with the compliance team to integrate their requirements into the project processes.
Question
An agile team recently started working on a project for a financial institution. The project sponsor is concerned that an agile approach will not provide enough support for the organization's compliance standards. In order to mitigate this risk and avoid problems, what should the project manager do?
Options
- AEnsure that the peer review process also covers compliance requirements, creating a second
- BMeet with the compliance team and make sure that their requirements are covered in the
- CLiaison with the compliance group, making them responsible for understanding the requirements
- DPropose using a compliance review board that will be responsible for approving all product
How the community answered
(31 responses)- A10% (3)
- B71% (22)
- C16% (5)
- D3% (1)
Why each option
To mitigate the risk of an agile approach not supporting compliance standards in a financial institution, the project manager should proactively engage with the compliance team to integrate their requirements into the project processes.
While peer reviews are valuable, simply creating a 'second layer' for compliance might make it an add-on rather than an integrated part of the process, potentially adding overhead without full integration and potentially missing early detection of compliance issues.
Meeting with the compliance team ensures that their specific requirements are understood and incorporated directly into the agile development process and definition of 'done,' embedding compliance from the outset rather than addressing it as an afterthought. This proactive integration prevents issues and ensures alignment with organizational standards.
Making the compliance group solely responsible for 'understanding the requirements' shifts a core project responsibility away from the project team and manager, who are ultimately accountable for delivering compliant products.
Proposing a separate compliance review board for approval introduces an additional, potentially slow gate in an agile process, which could impede rapid delivery and feedback loops without fully embedding compliance into the daily work.
Concept tested: Risk mitigation, regulatory compliance, stakeholder engagement
Source: https://www.pmi.org/agile/agile-practice-guide
Topics
Community Discussion
6B is correct. Agile teams still need to fold compliance into their definition of done and backlog items, and the only way that happens is if the project manager sits down with the compliance team and translates their standards into actionable requirements the team can build to. A and D create gatekeeping overhead that kills velocity, and C tries to offload ownership onto a group that is not delivering the work. You own benefits realization end to end as the PM, so you bridge that component interdependency yourself rather than tossing it over a wall.
Agreed on B, but worth adding that once compliance requirements are in the backlog they need to be treated like any other story with acceptance criteria and estimates, not silently slipped in as zero-point line items, otherwise the team never actually accounts for the work and velocity becomes a fiction.
B is correct. Agile doesnt exclude compliance, you just have to fold those requirements into the backlog early, and meeting with the compliance team ensures nothing gets missed when stories are written and prioritized.
B is right but Ill add that in my lab I tagged every compliance story with a red label in Azure DevOps so they visually pop in the backlog and nobody accidentally deprioritizes them during sprint planning.
B is the right call here because in agile you fold compliance into the definition of done and backlog items, you dont bolt it on after. Meeting directly with the compliance team early means those requirements get baked into user stories and acceptance criteria from sprint one, which is exactly what a risk averse sponsor needs to see. I had this exact scenario on my exam last spring and almost picked D because a review board sounded formal enough to satisfy a financial institution, but then I remembered that agile favors collaboration over gatekeeping. D creates a bottleneck and pushes compliance to the end, while B keeps it embedded throughout the
Agree on B for the embedding point, but the program-level angle here is that compliance as a non-functional requirement needs governance integration across all components, not just baked into individual sprint backlogs, otherwise you get consistency gaps between teams.