A city IT charter marks every future wish-list feature for a permitting system as “in scope” with no priority or phase. What risk does that create?
Select an answer to reveal the explanation.
Short Explanation
Stuffing every wish into “in scope” is like saying the grocery cart has no bottom. Without priority or a boundary, creep is almost guaranteed—and the charter stops protecting the team.
Full Explanation
Scope that includes an unbounded, unprioritized wish list fails to set a controllable boundary and heightens scope-creep risk. A city IT charter that marks every future wish-list feature for a permitting system as “in scope” with no priority or phase invites uncontrolled creep. Claiming it guarantees predictive success by capturing every idea early fails by concept: capturing ideas can feed a backlog, but declaring all of them in-scope removes the boundary predictive (and adaptive) control depends on. Claiming it converts the charter into a completed operations runbook fails because a charter authorizes a project; stuffing it with every future idea does not finish operations documentation. Claiming it removes the need for stakeholder engagement forever fails because unbounded scope increases—not eliminates—the need to negotiate priorities with stakeholders. Exam caveat: CAPM distinguishes a product backlog of candidate work from authorized in-scope work; wish lists belong in prioritized backlog or future phases, not as an infinite charter boundary. Operational check: move unprioritized wishes into a backlog or roadmap, authorize a bounded initial release in the charter, and require change control or backlog prioritization before expanding the boundary.