You Have the Tools to Control Scope Creep
The Project Management Institute (PMI) publishes A Guide to The Project Management Body of Knowledge (PMBOK), Third Addition. In this guide, Project Scope Management is described as “primarily concerned with defining and controlling what is and is not included in the project” (p. 103). This sounds simple, but many program and project managers have issues with “scope creep.” Why? Other reasons may exist but, in my experience, the three main reasons for scope creep are incomplete scope definitions, trying to satisfy a client’s requests and what is known in the industry as “gold plating”. For those of you unfamiliar with the term, gold plating can be best described as the addition of extra functionality (i.e. bells and whistles) to the project that is outside of the project objectives defined in the Project Charter.
Suggestions to Address
* Rule #1: Start Your Planning With A Clear, Complete, and Approved Project Charter – We will discuss Project Charters during the Initiating Process Blog later this month. For the purpose of managing scope creep, a well written Project Charter should contain ALL goals and objectives for the project. A Project Charter also needs to be approved by the Project Sponsor(s). You must be extremely clear on where the “goal line” is on your project (i.e. what needs to be accomplished for the Project Sponsor(s) to agree the project is done).
* Rule #2: Refer Back to Rule #1, and Use the Project Charter as Your Compass – Assuming you have an approved Project Charter (i.e. refer back to Rule #1), use the Project Charter as your compass. The Project Charter should have well-defined goals and objectives that should help you determine if the requested additional scope is required (in this version, release, etc.). If the additional scope is outside of the original objectives, ask the Project Sponsor if this additional functionality can be provided in a subsequent version, release or project.