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.
No comments:
Post a Comment