 |
| Source: thinkstock.com |
My
personal experience with scope creep is described below with a focus on the
main issue encountered, how stakeholders dealt with the issues at the time, and
how I was able to manage the issues and control the scope of the project.
Background
In
December of 2011 I inherited a project for redesigning an onboarding training
program for a business line of over 2,000 employees located in Shanghai, China;
Geneva, Switzerland; and Indianapolis, IN.
The project was approximately 50% complete and was due to launch in
mid-February of 2012. I was to oversee
the completion of approximately 30 instructor-led training courses which had
been assigned to subject matter experts and also to personally develop 11
web-based eLearning asynchronous modules.
Issue
The
issue that arose three weeks prior to launch occurred when department subject
matter experts began piloting the asynchronous modules and determined that more
detailed information was warranted. They
requested the materials be redesigned for facilitator-led classroom sessions.
Solution
Because
of what had already been approved for the project activities and deliverables,
I was able to communicate with the project sponsor, drivers and supporters the
justification for following the project plan as detailed on the design
documents. As the discussions took
place, piloting and refining of the asynchronous modules continued and all were
launched according to the timeline.
Looking
back at the ease with which the issue was solved can be attributed to the way
in which my predecessor defined and managed the project, for instance:
- There was a dedicated project sponsor.
- Business leaders from each department served as project drivers and supporters.
- The project documentation included an organization tool called a Design Document with detailed information for each of the courses being developed (Laureate Education, Inc., n.d.).
- All tasks were listed and coded with a priority of high, medium, or low
- Top priorities were always handled first.
- Lower priority tasks were delegated (with the project manager retaining responsibility for completion).
- There was an established culture that this project was paving the way for future similar projects and as such perfection was avoided.
- Each Design Document had been approved with the understanding that project would involve two phases. The first phase would launch according to the approved Design Documents, after which evaluative data would be collected to measure the overall effectiveness of the entire program, and then a second project phase would commence to refine the instructional materials as needed.
- There were bi-Weekly status calls with project sponsor, drivers, and supporters.
- There were weekly meetings with those assigned project tasks which provided the opportunity to identify those who were doing well and those needing assistance.
Scope Creep
Reminders
For
the future, it’s important to remember that scope creep is likely to happen,
more so when: 1) the scope and
requirements documents are unclear or insufficiently detailed; 2) the
stakeholders expect something different from what is planned; and, 3)
stakeholders are uninvolved until the end of a project. Planning is always the best solution (Starr,
2010):
STEP 1: At the beginning of a project, document what
is in and out of scope.
STEP 2: Get the scope document approved by all primary
stakeholders (decision-makers).
STEP 3: Upon
receipt of a scope change request, notify all scope signers of the nature of
the request.
STEP 4: Perform
an assessment of the request, specifying the impact upon the budget,
[resources], and/or schedule.
STEP 5: Determine your own recommendation.
STEP 6: Present
the assessment and your recommendation to the scope signers for approval or
rejection.
Be sure to DOCUMENT EVERYTHING!
References
Helms, H. (2002). In defense of scope creep. Retrieved
from http://alistapart.com/article/scopecreep
Laureate Education, Inc.
(Producer). (n.d). Project Management in Education & Training [DVD]. In Monitoring
projects. Baltimore, MD: Dr. Harold Stolovich.
Starr,
J. (2010). Managing scope creep. Retrieved from http://www.slideshare.net/
joanstarr/managing-scopecreep1
a. Great post. Congratulations on the success of the project. It was nice to see how planning and structuring your project lead to a great completion regardless of the interruptions and proposed changes. Your experience just goes to prove how proper planning can prevent the damaging results from scope creep. Deborah Ruriani posted an article that list the steps in handling projects and preventing scope creep and your office did a nice job of following many of the tips Deborah provides and outlines in her article. http://www.inboundlogistics.com/cms/article/outsmarting-scope-creep/
ReplyDeleteLiz
Hi DeAnn…I think sometimes it is just inevitable that scope creep is going to occur. It sounds like you were ready and prepared to handle the issues that arose before you. Scope creep seems to be a pretty common variable in any project. Would you have handled anything differently after taking this course? I look back at my own experience and see so many alternate ways I would handle my situation. I have viewed many websites and blogs looking for various ways other project managers handle scope creep. I found one from a project manager in the United Kingdom I found useful. It is at http://www.projectsmart.co.uk/how-should-the-project-manager-deal-with-scope-creep.html
ReplyDeleteThe author gives some good advice and uses a background in project management to identify the two different types of scope creep (business and technical). I thought you might find the blog useful, and thanks again for the success story. I was getting nervous about project management. It seems so overwhelming and complicated at times.
References:
Thakora, K (2010). How Should the Project Manager Deal with Scope Creep. Retrieved on February 14, 2013 from http://www.projectsmart.co.uk/how-should-the-project-manager-deal-with-scope-creep.html
DeAnn,
ReplyDeleteYour blog supports the fact that when requirements are clearly defined and communicated, it makes it easier to avoid and manage scope creep during the project. Many times, scope creep is only a symptom, where unclear identification of requirements from the beginning of the project is really the cause. In an article entitled “Karl Wiegers describes 10 Requirement traps to Avoid, Wiegers, 2000 speaks about traps to avoid in the original requirements identification which helps to avoid future problems including scope creep.
Reference:
Weigers, K. (2000). Karl Wiegers Describes 10 Requirements Traps to Avoid. Software Testing and Quality Engineering, Vol. 2, No. 1, January/February. Retrieved from: http://www.processimpact.com/articles/reqtraps.pdf
DeAnn,
ReplyDeleteIt sounds as if your predecessor followed so many of the essentials we've been speaking of for the last few weeks. Good documentation, communication, clear responsibilities and follow-ups are excellent ways to prepare for any issues that may arise.
I think that it must be quite common for someone or even a group of team members to want to change or add to the scope after they have begun. We always see things slightly differently after we have started. I wondered if in the case you shared the subject matter experts ever got the opportunity to add what they felt the project needed? Was another project created to redesign the materials for the facilitator-led classes?
It would be a shame to lose the ideas generated by the subject matter experts that could lead to innovation and new sources of revenue for a company (Tyson, 2011). Although scope creep is generally not something we look forward to, it's probably inevitable when dealing with thinking, passionate team members. Your 6 step planning outlined above seems quite useful with the management of scope creep.
Thanks for your post!
Tyson, B. (2011). Bright hub PM. Is scope creep an asset? Retrieved from http://www.brighthubpm.com/resource-management/69354-is-scope-creep-an-asset/.
Hi Sylvia - thank you for responding to my blog. The rest of the story where this project is concerned is that Phase I successfully launched and I was in the process of creating the project plan for Phase II when the location at which I was located was closed and my position was eliminated. The project was in really great hands when I left and it had been determined that one of the asynchronous courses would have a follow facilitator-led session. I am positive things are turning out well for the business unit.
Delete