Change is inevitable and not necessarily bad, but problematic when it creeps
The subject of scope creep is one about which most project team members know and talk, yet few seem to be able to define exactly what it is or acknowledge what to do about it - or when. Change is a natural occurrence and change will happen to virtually every project of long enough duration and detailed enough scope. Most project-savvy organizations have a change-control process with proper identification, approval, documentation outcomes to address change and all resulting implications. Scope creep is more than just change; it may linger undetected until too late, and involve processes which may or may not be adequately covered by your change-control process.
Scope Creep is essentially OOS (out of scope) work, but the 'creep' part adds several additional elements to typical scope change. 'Creep' tends to accumulate slowly and sometimes without the knowledge of the PM, team or stakeholders. 'Creep' has many sources, but it also comes from what you as PM allow and do not allow (knowingly or unknowingly). It can manifest itself in several ways from first not properly identifying what is in scope, and allowing OOS work to proceed, or by snowballing from one or two passing allowances into items of bigger and bigger cost, schedule or resource implications. "We allowed this and this, why not that?" Scope creep, unfortunately, can also result from a "lost in translation" effect when the requesting party and the performing party each make divergent assumptions on some defined element of scope. You know..., 'ass - u - me'.
Change is somewhat conscious although it can be planned or unplanned. Creep is virtually always unplanned, sometimes unconscious and is often happening or has occurred by the time you realize it has happened, and are forced into mitigation (stop it, allow it, take the hit or re-negotiate the SOW, budget, timeline, etc).
Staying on top of scope creep begins first and foremost with an adequately defined and approved scope in the form of a written SOW, linked to budget, time and resources - you cannot identify what's OOS or creeping if you don't know the agreed starting point. This is followed a close second by acknowledging clearly and in advance with stakeholders what is (and in some cases is Not) in the agreed scope and what scope change control process is in place.
One critical technique to effectively managing scope creep is through adequate and frequent communication. Many requestors of scope change do not know that what they are requesting is potentially scope creep, and/or may not have the proper authority to make the change request. Ensure you have a method to flag this while the request is being made and before agreeing to or proceeding with the action (relying on the standardized change control process you established at the start of the project). Many organizations will also have a processes in place to prevent work without prior written agreement, so keep an adequate allowance for delays associated with this too.
Tuesday, February 7, 2012
Monday, February 6, 2012
Scope Change vs Scope Creep (Part 2)
Expect it and plan for it and your project won't be adversely affected by it
Another method to help differentiate real change from scope creep is to track project changes with a log; all changes, big or small, creep or not, actionable or not. Flag each according to a scale meaningful for your project environment; the critical part is to identify what the consequences could be, which to act upon, how and when.
Project sponsors and stakeholders don't want to be 'nickled and dimed', and project managers are not effective by repeatedly going 'back to the well'. If a small, simple request can be accommodated with a few keystrokes or an extra print-out, I sometimes choose to avoid the drip-drip of change requests and just do it. Keep the project goal in mind and aim for satisfaction, but beware the slippery slope of agreeing to too much, too often. It can sometimes help to bundle a few smaller OOS change requests into one change order. The change log can also serve as leverage in moving more quickly to authorizing a big scope change in light of the several smaller changes requested earlier wthout revising the original scope. Remember to take the time to explain the 'triple constraint' between cost, time and quality - at least one of these three major project elements is going to have to give for whatever change in scope is ultimately approved.
Talk about the process in advance with project sponsor/stakeholders so it does not come as a surprise. Every undocumented or OOS request is not necessarily creep. Change is not necessarily a bad thing either, although it is almost always associated with risk and consequence. In the end, the sponsor and stakeholders should be delivered the deliverables they want - your job isn't to talk them into or out of deliverables, but to provide all necessary information (ie, constraints) to allow them to make the best decision possible. As a project is executed you naturally know more than you did when it was originally defined (look up 'cone of uncertainty'). But creep will lead to mistrust and dissatisfaction or blown budget/timeline if not handled properly.
PRACTICAL EXAMPLE: A Form of 'Hidden' Scope Creep
It should be noted that scope creep may not be 'new' or 'added' work, but a result of miscommunication, misunderstanding and/or lack of specificity. Consider a not-unusual situation when part way through execution a sponsor/customer/stakeholder was under the impression that the budget and schedule they approved for "Activity Y" included sub-tasks 88-100. The minimum industry standard is, lets say, 1-87 and 88-100 are perhaps desirable but beyond whatever industry regulatory hurdle that exists.
Upon re-checking, the signed project agreement states something like 'Activity Y will be performed to meet industry standard'. While this can be considered reasonably specific, it could also be sufficiently ambiguous to lead the service-provider to believe 88-100 are not included and the customer to believe that they are. The customer feels these should be obvious and assumed that they were included; all the project PM can reply is that the intended SOW is what was budgeted, unless they want to initiate a change order.
Although the service-provider has a contractual justification to continue to exclude the added project scope, the customer is not happy doing without or paying more and maybe waiting longer. Either way represents a blow to trust and to satisfaction. Now we can't anticipate every assumption, and a certain level of detail will start to become counter-productive - but like many elements of project management, it starts at the beginning and with lessons learned, best practices, proper scope definition, a scope change control plan, and frequent communication.
Another method to help differentiate real change from scope creep is to track project changes with a log; all changes, big or small, creep or not, actionable or not. Flag each according to a scale meaningful for your project environment; the critical part is to identify what the consequences could be, which to act upon, how and when.
Project sponsors and stakeholders don't want to be 'nickled and dimed', and project managers are not effective by repeatedly going 'back to the well'. If a small, simple request can be accommodated with a few keystrokes or an extra print-out, I sometimes choose to avoid the drip-drip of change requests and just do it. Keep the project goal in mind and aim for satisfaction, but beware the slippery slope of agreeing to too much, too often. It can sometimes help to bundle a few smaller OOS change requests into one change order. The change log can also serve as leverage in moving more quickly to authorizing a big scope change in light of the several smaller changes requested earlier wthout revising the original scope. Remember to take the time to explain the 'triple constraint' between cost, time and quality - at least one of these three major project elements is going to have to give for whatever change in scope is ultimately approved.
Talk about the process in advance with project sponsor/stakeholders so it does not come as a surprise. Every undocumented or OOS request is not necessarily creep. Change is not necessarily a bad thing either, although it is almost always associated with risk and consequence. In the end, the sponsor and stakeholders should be delivered the deliverables they want - your job isn't to talk them into or out of deliverables, but to provide all necessary information (ie, constraints) to allow them to make the best decision possible. As a project is executed you naturally know more than you did when it was originally defined (look up 'cone of uncertainty'). But creep will lead to mistrust and dissatisfaction or blown budget/timeline if not handled properly.
PRACTICAL EXAMPLE: A Form of 'Hidden' Scope Creep
It should be noted that scope creep may not be 'new' or 'added' work, but a result of miscommunication, misunderstanding and/or lack of specificity. Consider a not-unusual situation when part way through execution a sponsor/customer/stakeholder was under the impression that the budget and schedule they approved for "Activity Y" included sub-tasks 88-100. The minimum industry standard is, lets say, 1-87 and 88-100 are perhaps desirable but beyond whatever industry regulatory hurdle that exists.
Upon re-checking, the signed project agreement states something like 'Activity Y will be performed to meet industry standard'. While this can be considered reasonably specific, it could also be sufficiently ambiguous to lead the service-provider to believe 88-100 are not included and the customer to believe that they are. The customer feels these should be obvious and assumed that they were included; all the project PM can reply is that the intended SOW is what was budgeted, unless they want to initiate a change order.
Although the service-provider has a contractual justification to continue to exclude the added project scope, the customer is not happy doing without or paying more and maybe waiting longer. Either way represents a blow to trust and to satisfaction. Now we can't anticipate every assumption, and a certain level of detail will start to become counter-productive - but like many elements of project management, it starts at the beginning and with lessons learned, best practices, proper scope definition, a scope change control plan, and frequent communication.
Subscribe to:
Posts (Atom)