Scope Creep? When Does it Actually Occur?

To some degree, I would argue every project encounters scope creep.  Does this occur because the project manager is poorly managing change?  That depends on the level of severity of scope creep but I would offer that most small events are merely the act of trying to provide quality customer service.  Maybe one could argue the requirements were poorly discovered and this is the cause of scope creep.  I find this theory flawed; consider this idea:

Once the requirements are gathered, this should produce the “what” that will be built or created.  What follows is scope development and creation of the WBS or work breakdown structure.  Once completed, these components then become the “how” the “what” will be built or created. 

If we follow the above process, poorly gathered requirements would simply lend themselves to one of two things: 1) an end result that does not adequately meet the needs or intent of the client, or 2) the need for numerous additions to the scope through a reoccurring RFI or change process accumulating many change order adds to the contract.  Notice the key component stated in the second item, “change order adds”. 

What then becomes one major component of limiting scope creep?  A properly developed  change management process.  In a previous blog posting I spoke about creating a well-developed, but most importantly, AGREED UPON project management plan that both the client and the vendor agree to houusing the “rules” and methods that will be used to complete the project.  Within this plan, and fairly early in its creation (perhaps as early as charter development) a change advisory board, or an agreed upon person or entity will be assigned responsibility for approving changes.  This provides several functions, but most importantly it creates one point of contact for all changes.  It will also help eliminate scope creep, helps limit the types of changes allowed which could affect overall quality, and it controls financial impact. 

In order for the approving body to provide direction on changes, it must then create a uniform method for analyzing change requests.  Developing a quality change order process, starting with a standard template that helps capture the pertinent information is key.  By gathering the work that will occur, the ultimate change or deviation that will occur, the possible quality change due to alternate materials or production methods, schedule deviations, resourcing changes, and the price impact to the client can all be aggregated into one change proposal. 

By developing this process, the forms that will be used, and the entity that will then review and approve all changes and incorporating them into the project management plan, you are then able to hedge your risk of scope creep before the project begins.  If properly done, the project management plan is presented and explained to the client prior to beginning work on the project.  By thoroughly explaining the change process, a project manager then has set precedent for challenging requests made during the project.  If a request is made by the client, the project manager’s authority to change something is limited through the agreed plan, and allows him or her the ability to reference the change management plan, request the change be formally submitted, and then can rely on the approving entity to provide direction for the change. 

Using proper policy for change will help with numerous items, 1) It will provide the project manager a way to maintain scope control of the project, yet still acknowledge and seek out resolution to a change asked for by the client without simply doing the work to appease the client.  2) It will provide a single point of contact to analyze all changes requested preventing quality degradation and financial impact, and 3) will provide the ability for feedback on potential schedule impact by the adding the additional scope. 

Remember that scope creep is something that started well before the project began.  Without developing the needed components of the project management plan and making sure to present it to the customer and getting all parties to agree to its terms, then the stage has already been set for scope creep.  By defining an approving entity to consider change requests, setting the authority level of the project manager limiting their ability to make changes not included in the original scope, and setting the precedent and expectations prior to the start of the engagement, you manage scope, schedule, budget, and equally important, your customer’s expectations and level of satisfaction. 

Chris Thompson PMP, SSYB