Friday, April 8, 2011

Analyzing Scope Creep

A major source of trouble with changes is typically that the project manager, in attempts to avoid bureaucracy, adopts an informal process of handling requests for change. Such leads to misunderstanding on the part of the party requesting the change, and before the project manager can undo the damage; the organization is committee to extending the scope of the project but without the additional resources and time to do it (Portny et al., 2008).

I recall a project where my organization set out to create electronic documents to help minimize the use of paper and to streamline some of our internal processes. Doing so would eliminate the time it took for documents to be completed by eliminating the use of mail and having a central repository for all completed documents so that items wouldn’t be lost. This was the original scope of the project. This began as an initiative just for one department. As the project went on and more departments heard about it, the list of forms to be created electronically grew exponentially. In addition to that, people started requesting that documents be created to use for external customers. This expanded scope created a number of issues. There was no change control process created so anyone on the project team was just creating documents with no guidelines. The documents were being generated for use outside the company without being reviewed and cleared by our legal group to ensure no unnecessary liabilities were being created. Lastly, there weren’t enough people resources on the team to keep up with the demand of requested forms that needed to be created.

I recommended that we scale back the scope and focus on one pilot department and a small list of forms. This would allow the group to handle the load and work out any identified issues prior to getting any other departments involved. The rest of the stakeholders weighed the benefits of this versus the disadvantages and decided that was the best course of action to take. Looking back on the situation, if I had been the project manager, I would have clearly defined the scope and all of the initial components of the project. This way all of the stakeholders would have clear and realistic expectations of what was to come and could anticipate some of the next steps. In this pilot it would have been best to outline a plan based on the results to implement the electronic form process in the other departments and allow for a more efficient transition that most, if not all, stakeholders could be satisfied with to meet their goals.

Sometimes projects can get off track very quickly because of poor communications between all of the parties involved, lack of proper identification of what is needed to achieve the groups objectives or even poor project management overall. This can lead to increased costs and failure of the project. However, if other aspects are considered as the scope of the project changes such as budget, other resources and the timeline or schedule of the project, scope creep should not occur.

Avoiding scope creep in not possible; however, monitoring it, controlling it, and thereby reducing some of the pain is possible-if the project manager follows a few guidelines... (Portny et al., 2008)

Reference

Portny, S. E., Mantel, S. J., Meredith, J. R., Shafer, S. M., Sutton, M. M., & Kramer, B. E. (2008). Project management: Planning, scheduling, and controlling projects. Hoboken, NJ: John Wiley & Sons, Inc.

6 comments:

Dreana Marshall-Stuart said...

Hi Nathaniel

I read your posting and it brought to mind a situation I experienced last month.

Three years ago the Officers received Administrative Instructions (Project Scope) that our army was entering a paperless world and therefore all communication should be done via email. All documents were to be sent as an image or .pdf document and the appropriate filing systems are to be created to ensure that documents are stored and can be easily retrieved.

Those of us (60 officers including myself)who were computer savvy saw this as the best thing since sliced bread and oh boy, were we eager to start creating electronic data management systems for our files. So we are up for promotion this year and we were told we had our admin inspection for our respective cadet units and we spent the entire month we had to prepare helping other officers create an electronic data management system as well.

So the week came for inspections and various Captain and Majors were deployed to our units- each one of the inspecting officers – who are from the “old school” – were not the least bit excited about inspecting our filing systems from your laptops. To them it was ‘ show us the paper’!! What paper!! We did not manually file for three years!!! As you can expect we all failed our inspections or were lucky to get half mark.

Like your case, the reasons given for the changes were the same as yours, and like your situation again, everyone was eager to go electronic and it did get out of hand. No one had filed for 3 years and each one of up then had to spent a week ad dozens of reams of paper, printing and filing 3 years of paper work. You cannot the imagine the costs incurred to the army for this. The paperless world is once again "paper-ful."

Segla Kossivi said...

Indeed, "sometimes projects can get off track very quickly because of poor communications between all of the parties involved, lack of proper identification of what is needed to achieve the groups objectives or even poor project management overall". I recall the project I am working on: Case 23-Developing Learning Objects for Adult Learners (Ertmer and Quinn, 2007). The project team failed to understand the client's demandands so clearly written, and the project resulted in scope creep. The project team needed to take into consideration the culture in which it used to operate. The PM needed to educate team members on the evolution of the new project according to the demands of the client (Australian Vocational ) to guard them against some predetermined mindsets about how they used to handle similar projects. She needed to communicate clearly the factors surrounding the new project.

The PM would have to develop and monitor a mechanism to enable team members to objectively identify and manage project risks. Consistent risk management and monitoring should surface in all stages of a design project to avoid a poor design project outcome (Yee et al, 2009). S/he would have to communicate clearly with her his client agreed upon project details for a successful project desired outcomes, just as Dr. Stolovitch discussed in the media (Laureate Education, 2011).

References

Ertmer, P., & Quinn, J. (2007). The ID casebook: Case studies in instructional design. (3rd ed.). Upper Saddle River, NJ: Pearson Education, Inc.

Laureate Education. (2011). Video program: “Monitoring Projects”. Dr. Stolovitch discusses how to manage ongoing project activities and overcome challenges as they arise. Retrieved from http://sylvan.live.ecollege.com/ec/crs/default.learn?CourseID=4894953&Survey=1&47=6623504&ClientNodeID=984650&coursenav=1&bhcp=1.

Yee, J., Lievesley, M., & Taylor, L. (2009). Recognizing risk-of-failure in communication design projects. Visible Language, (43)2, 227-251.

Liz said...

Hi, Nate!

Your post is a great example of what can happen to a project when good people get enthusiastic for all the right reason, but without taking the right steps.
Understanding scope creep like you do now, you know that limiting the scope, and defering the rest of the work to a future project is the best course of action. Sounds like back then, even without the benefit of our course resources, you understood that doing a small project really well was more valuable than trying to do it all for everyone.

WebsterDesigner said...

Nathanial,

Your situation was what I would consider a classic example of scope creep. As Dr. Stolovich mentioned in Laureate Universities Video Program: "Creating a Project Schedule" sometimes the Project Manager just has to say, "No!" (politely, of course) and refer to the bottom line.

I think that Dr. Budrovich, in this week's resources also would tell the Project Manager, if the "No!" is overruled, get the change in writing! I think that Ertmer Case Study Number one presents a similar situation when the other grade levels wanted to "horn in" on Gordon and Scott's curriculum project.

Your point about the PM clearly defining the Project Scope is really excellent, too!

Thank you,

Lisa

References:

Ertmer, P., & Quinn, J. (Eds.). (2007). The ID casebook: Case studies in instructional design (3rd ed.). Upper Saddle River, NJ: Pearson Education, Inc.

Laureate Universities Video Programs: "Creating a Project Schedule", 2010

“Monitoring Projects.” 2010

“Practitioner Voices: You Can’t Win Them All", 2010

WebsterDesigner said...

“Monitoring Projects” and “Practitioner Voices: You Can’t Win Them All"

Hollis said...

Hi Nathaniel,

Sounds like you put together a popular project! As you said, the scope creep caused your situation to quickly spiral out of control as more and more groups within the company started jumping on the bandwagon, overwhelming your capacity and jeopardizing the project.

You did a nice job of managing the "change"--back to the original plan! I've been thinking about what we should tell those other people who are interested in having their forms digitized. If the project manager isn't willing to entertain expansions to the scope, we need to tell those other stakeholders why--and try to get them on-board as supporters.

I think I would start by saying clearly that it's a pilot test, and that we're grateful for their interest--would they be willing to lend their support to make sure the project finishes? "Their support" could take lots of forms, from ideological support to manpower or time. Similar, have a visible and trustworthy process for documenting the groups that want to have their forms digitized once the project leaves the pilot stage. Make it clear to these new "buyers" that they aren't being forgotten--it's just not part of the current project to take on new work. That also gives you a bunch of new stakeholders who will be interested to hear it when you report your success at the end of the project.

What are your thoughts?