The key factor on scope creep is how we manage changes in the scope. I for one have experienced both the
good and bad experiences of scope creep. With creating websites I always allow
a buffer in case other projects interferes with my workload. It pisses my boss
off when I tell a client that their website can be done in 10 business days
when it can really be done in 2. The reality is, I’m always anticipating scope
changes even before and during a website is being built out. So be kind and
confident that if you accept changes, anticipate their kindness and respect to
you. Just like the roofing incident, anticipating these problems comes from
experiencing these incidents in pervious jobs. According to Gurlen, “Scope
creep more frequently occurs during the later stages of a project, such as
programming and testing, than during the earlier stages, such as design. Changes
may happen in the later stages as the project team gains more knowledge of the
problem and solution. Scope changes can be
numerous small changes or can be a fundamental design change.” What must be
avoided are ongoing changes that are free of change, unless it was a task that
was mistakenly made by you, then in that case, the client can make the request
to have it fixed. My previous supervisor has always said, “It’s easy to get the
80% done, and the hard part is the last 20%.”
Ref: http://www.umsl.edu/~sauterv/analysis/6840_f03_papers/gurlen/
As defined from the PMBOK (4th edition page,
125), uncontrolled changes are often referred to as project scope creep. The
article provided on today’s discussion was excellent, and we can also find
another example here: http://www.my-project-management-expert.com/scope-creep-example.html.
The article explains that as project managers, we must try and avoid scope
creep. Especially in the private sector. If we allow it to happen so much, we
can lose our jobs, and potentially, our careers as project managers. Even if it
is in the IT world, there is no UNDO feature like what we do on our computers.
