1.4Scope validation and change management

This section does not deal with the definition of "what is scope validation," but rather with the skill of judging how to detect the signs that scope creep is quietly progressing on the ground, and at what stage and how to course-correct. Scope creep, in many cases, does not progress as one large improper change but rather as an accumulation of informal add-on requests that each look trivial on their own, so whether the PM can detect the signs early determines how much damage results.

1.4.1The role of scope validation (acceptance)

• Scope validation (acceptance) is the process by which the customer or sponsor formally confirms and accepts whether the completed deliverables satisfy the agreed scope statement and requirements. It differs in purpose from quality control (the internal activity of technically verifying whether a deliverable is correct); the focus is the acceptance itself, by the accepting party.
• Quality control is normally performed before scope validation (confirming technical correctness first, then having the customer accept it). Submitting a deliverable to scope validation without first passing quality control raises the risk that defects are found on the customer side, dragging out acceptance and damaging trust.

1.4.2Signs of scope creep and how to address them

• Scope creep is the phenomenon in which a project's scope expands informally and incrementally, without going through the integrated-change-control process. It more often progresses in the form of small individual add-ons being tacitly allowed ("might as well add this too," "since we're at it, let's add this feature too") rather than a single large change request, and by the time it is noticed, the original schedule and cost assumptions no longer hold.
• Example signs: "informal add-on requests over chat or verbally are increasing," "work is proceeding without the WBS or scope statement being updated," "individual staff are making case-by-case calls of 'this much should be fine' on their own," or "progress looks on track, yet the list of deliverables due has ballooned beyond the original." The response is to pause individual add-on requests, route them back through the integrated-change-control process, and have the full set of stakeholders reconfirm the current state of the scope.

Suppose you are the PM of a core-system rebuild project, and partway through development, at a progress meeting, one team lead after another reports, "actually, small requests keep coming in from staff on the ground, and we've been handling them each time." The individual requests all seem minor at a glance—"change the order of these input fields," "fix the wording of this message"—but what must be noted is that this is precisely the classic sign of scope creep. Even though the surface-level progress rate (number of tasks completed) looks on track, a state in which only the volume of work has ballooned while the WBS and scope statement go unupdated later surfaces as problems such as "we can't explain why this is taking more effort than expected" or "the test scope no longer matches the original plan." The action the PM should take here is to first instruct all team leads to pause informal add-on handling and compile an inventory of everything handled individually so far. The inventoried items should then be routed back through the integrated-change-control process (record -> impact assessment -> approval), formally judging, even for minor items, whether they need to be reflected in the scope statement and WBS. At the same time, the root cause of why informal handling became normalized should also be examined—perhaps the change-request process felt too heavy for the ground-level staff and was avoided, or perhaps the boundary of what staff could decide on their own authority was ambiguous—and, if needed, a lightweight approval flow for minor changes, as discussed earlier, should be put in place. Sharing with stakeholders the recognition that "each individual response may have been reasonable, but the risk was in accumulating them without going through a controlled process" is the starting point for properly addressing scope creep.

1.4.3Section summary

• Scope validation (acceptance) is the customer's acceptance confirmation, with a purpose distinct from the preceding internal technical verification (quality control)
• Scope creep progresses through an accumulation of small, informal, incremental add-ons and cannot be detected from the progress rate alone
• Upon detecting the signs, the appropriate response is to route individual add-ons back through the integrated-change-control process retroactively and also examine the root cause