Just like death and taxes are inevitable - so is Scope Creep. It will happen; you can count on it. Scope Creep is a source of many headaches and nightmares for a Project Manager (PM).
What is it?
Scope Creep: [Is] “the uncontrolled expansion to product or project scope without adjustments to time, cost, and resources." (PMBOK, page 562) That's a reasonable definition; however, for those of us that have experienced the many varieties of scope creep, this description just doesn't go far enough to give a full picture of this creeping. Before we go any farther, we need to be clear on one point: scope creep is in regards to changes to the product's scope, the deliverables, design, or specifications that were NOT channeled through the change control process prior to the change or creep taking affect. All scope creep is change, but not all change is scope creep. Now let's get back to the intentional versus unintentional creeps.
How does it happen and how is it caused?
There are many causes of scope creep: lack of communications; lack of commitment to the scope; lack of due diligence by the leadership and management team (to include the PM and Sponsor); unclear or under-defined scope of project in terms of expectations, details in the design, specifications, requirements, features and functionality; an immature project team and stakeholders group (to include the client, customer, users and sponsor) in regards to project management methodology as well as contract management and contractual requirements.
Scope can rear its ugly head in many ways and in many forms: I tend to group them into two categories - the intentional creeps and the unintentional creeps.
- Intentional scope creep is anytime someone within the project's workforce, sponsor, users, clients, customers, team members, and any other stakeholder, knowingly alters something in the product in regards to features, functions, design or specifications without using scope management and the change control process. This happens all too often: A user or someone from the client/customer group goes directly to a project team member or anyone who is performing a work activity and asks them, or tells them, that they want the task performed differently, maybe they want a different part installed, or a different or additional feature added to the project and neither the requester or the team member/worker refers and channels the change through to the PM. Instead the change is implemented by the team member/worker without taking into consideration the affect the change will have on the scope, the cost, time, etc.
- Unfortunately, in many cases, these "intentional creeps" are generated by a request or dictate by a user/employee of the client/customer that is not accountable for the project costs and schedule, as well as resources to include the workers. I don't say this just to be negative of the user/employee; however, it's a matter of certainty that in especially long projects, users, clients, customers, sponsors and even project team members tend to change their minds about particulars within the project and will want to make those changes happen without getting approval first. There are a lot of people in the world that hold to the old saying that goes: "It's better to ask forgiveness, than to ask for permission." Change in a project can be okay - but it must be managed first, before it is implemented
- Unintentional scope creep happens when someone within the project's workforce, sponsor, users, clients, customers, team members, or stakeholder makes a decision or takes an action that, without intending or realizing it, affects the project by altering the product scope to include features, functions, design or specifications, regardless of whether the change is good or bad. These unintentional scope creep events are often the result of an on-the-spot decision when a problem and a quick solution is required, or when materials, pieces and parts are not available when needed and someone substitutes an item or resource to complete the task, without fully verifying that the replacement item still meets the scope requirement.
- An example of a common unintentional scope creep occurs when materials, parts and products to be used in a project are ordered and managed through a procurement office that does not fall under the control of the PM. The procurement agent receives a list of items or maybe specifications and a budget estimate for those items. While the procurement agent is researching and searching for sources or sending out bid requests, he or she sees an opportunity to save some money and accepts a part, material, product that meets the budget projection but not the project-product scope requirements. The procurement office may not be read-in on the importance of the specifications or how and why the change control process works. They may be price-cost driven over and above design and specification requirement. The PM needs to be integrated into the procurement process, even if only to review and verify that items or services to be purchased meet the project/product requirements. In this way, if there is a discrepancy, the PM can get in front of it and not have to react after the fact.
When it happens, how does it affect the project?
Scope creep will affect one of more of these project areas: Work Breakdown Structure (WBS), time, cost, resources, and quality as well as the project process rarely spoken of, the customer's expectation. Schedule and time will be affected in varying ways. The obvious effects are increases in total schedule time requirements. An individual task may require added time, or functionality may be affected to the extent that the product no longer meets the original and approved scope. A "creep" event can also decrease the duration of either the task or the total project time line when something has been removed or altered. Unapproved, unanalyzed, and unapproved changes can cause detrimental alterations to the sequencing of the work schedule itself. This situation can even cause an added reworking loop or seriously alter the critical path of the project.
What is a reworking loop? If a creep event results in the need to perform rework or added tasks, new activities may need to be added to the project schedule looped around the original task. These loop backs must be integrated into the time and duration estimates as well as the dependencies of the follow-on tasks to determine the long range affect and the impact on the critical path.
What is the critical path (CP)? The CP is that line of activities in a network precedence diagram or project schedule with the most critical time schedule, having the least flexibility of start and completion times; in other words, if task on the CP runs late, the entire project is at risk of running longer than planned. Any unplanned and unapproved changes, scope creep, that occurs on the CP can cause havoc to a project schedule. It's also possible for these "Creep" events to cause the CP to change to a completely different line of dependent tasks as a result of the affect to the schedule's time table (more on Critical Path Method in a future another article).
How do I stop Scope Creep from happening?
The starting point is a well-defined and communicated Scope Statement. Without it we really don't have a good anchor set for knowing what "Done" looks like. And, we can only know what "Done" looks like, if we clearly define what our project is to deliver in the form of product(s) or service(s); this is how we know when the project or product is successfully delivered. The PM, the project team, and yes - even the sponsor are responsible for the scope management plan.
The second, point is to develop and communicate what and how the change control process will work-and why it is important. There is a lot of up-front educating of the team and all stakeholders involved in the project in order to effectively and efficiently control the scope and any "creepy crawly" events during the life cycle of a project.
How will you know when or how will you discover or keep up with the potentiality of scope creep? Lessons Learned: Remember these four tools:
- MBWA - Management By Walking Around: As the name implies, the project manager should observe the work being done in the performance of tasks and activities; verify that the actual pieces and parts used in the creation of the product meet the design and specifications; that through regular talks with the team members, workers, users and other associated stakeholders, discern whether or not anything with the project has changed that had not previously and was appropriately planned and approved by the sponsor, the change control board, and the (you) the project manager. Make use of your great project leadership skills.
- QAC - Quality Assurance Checks: Just as MBWA tries to discover the health of the project and any unplanned or approved scope creep in an informal way, quality assurance checks or inspections are planned and formalized inspections that can be inserted throughout the project schedule. Let me qualify that statement just a bit: the purpose of QA is performing formal compliance assessments of the product against the design and specifications and product scope; however, it's not out of place to conduct a formal QAC at a random/unplanned point in the schedule if the PM feels it appropriate; or, if there is the suspicion that the project has skewed of its course in terms of requirements and scope.
- CCM - Change Control Management: Change control. Keep the change control process, the means, method and tools, forms or what have you, in front and available to everyone in the project's sphere of influence. A CC must be a part of every project status performance meeting. Review what has transpired since last, what change requests are still in process, those that have been approved, and those that have not, and inquire from the group as to anything that has changed that was not presented through CCM. When a change is approved let the group know how it impacted the project in terms of time, cost, quality, and resources. You (the PM) should use this as an opportunity to educate the team, clients, customer, and sponsor on the impact of a change so that they may learn how unapproved change affects the project.
- Regularly Scheduled Project Status and Performance Meetings: This is a no-brainer. As stated above in reference to QAC and CCM, openly review what has gone right and what has gone wrong in the project to date. Avoid letting it turn into a he said - she said debate. Stick to the facts, the impact and the corrective actions. Use your leadership and team building skills.
It is advisable to conduct two different Project Status/Performance Meetings:
- The first meeting is with the project team, SMEs, and appropriate client/customer users in order to gather all the relevant information regarding the projects state of health.
- The second status meeting is with the Sponsor and contract authority (if appropriate) to provide the general project health information and gain any decisions needed for further the continuation of the project. Often times the sponsor is a senior official in the organization and may not want to sit through a status meeting with the entire team. Talk with the sponsor and see how he or she wants to be briefed and in what format. Lastly, I refer you back to the MBWA paragraph above.
Make this a matter of routine: use it to gather project status and work progress information as well as identifying any potential trouble spots on the horizon. A meeting can be one on one; you are not limited to how often you can communicate with the team, the client/customer, users or other stakeholders.
Scope Creep can create havoc to a project in many ways: it can result in failure to meet the original approved product scope requirements; it can add cost, cause unnecessary rework, extend the schedule unnecessarily and create heartache and arguments between the project team and the client/customer and the sponsor. However, that being said, a PM would be quite lucky not to have at least one creep-event during a project; more than not, there will be several events during the project's life-cycle. This is a very challenging area for the PM - and yet, you, the PM, should consider it just an extension of the change control and risk management processes. Keep your eyes and ears open, ask questions often and plan for the inevitability of change.