Inspiration for Students of Instructional Design and Technology

Scope Creep: Why Fight It?


Scope creep is unavoidable, say our textbook authors (Portny, Mantel, Meredith, Shafer, Sutton, & Kramer, 2008). However, it can be controlled by the project manager through a formal change control system. If the project manager, however, informally permits changes to scope, the project will be in jeopardy. Changes to scope will require extra time and resources, which require changes to the budget and timeline.

Still, if something is unavoidable, why would we try so hard to avoid it? Scope creep sometimes occurs because customers or team members identify desired improvements as the project progresses (Portny et al., 2008). It may also result from “lack of proper identification of which products and features are required” (Lynch & Roecker, 2007). Having spent many years in the IT industry supporting software development projects, scope creep has been the rule, not the exception, and it’s usually caused by one or both of these reasons. Still, I wonder: Is it realistic to think you can perfectly design any project up front—be it a software product or an e-learning course?

Is scope creep a failure to plan, or is strict adherence to the original design a failure of imagination?

I once supported a project that delivered a hardware and software solution to our customer. We had project managers on our side and theirs. We had business analysts who tediously compiled a requirements document that exceeded a hundred pages. Yet, as the project progressed and new releases were tested, the customer realized that certain needed functionality was lacking. We were prepared and dutifully created a new Functional Specification document and a corresponding Change Control agreement. Our project followed a “waterfall” systems development life cycle (SDLC), comparable to following ADDIE in a linear fashion. Therefore, any changes were tedious, time consuming, and stressful to the team.

Instead of fighting the inevitable, why not plan for and embrace change as part of the process? That’s what an Agile development process does for software development, and rapid prototyping methodologies do the same for instructional design. With this more realistic approach, “many things that might have been scope creep under a waterfall SDLC aren’t a problem” (Yatzeck, 2012). Yatzeck describes Agile as a flexible process that starts with a high-level design and fills in the details during development. The plan includes a 20-percent contingency for “unknown unknowns,” and swapping out one thing for something else of comparable impact to the project is OK.

Yatzceck (2012) sums up the difference as follows:

An agile project is actually much less vulnerable to scope creep than a waterfall project, simply because it is built to support the need for change. Agile requirements are pointed towards “what the business will need at delivery time,” where waterfall requirements inevitably point back towards “what the business thought it needed at project charter time.” (para. 12).

So, how does Agile apply to instructional design? At last year’s ASTD International Convention and Exposition, I heard Michael Allen present his model for developing instruction. In his book, Leaving ADDIE for SAM: An Agile Model for Developing the Best Learning Experiences, he describes a successive approximation model (SAM). This model adopts prototyping and iterative cycles in the design and development phases and avoids the “analysis paralysis” that plagues the traditional linear version of ADDIE.


Source: Neibert, J. (2012)

So, fellow IDs, why not toss those Change Control forms and accept change as not only an inevitable, but valuable, part of the instructional design process?



Lynch, M. M., & Roecker, J. (2007). Project managing e-learning: A handbook for successful design, delivery, and management. London: Routledge.

Neibert, J. (2012, September 19). Book Review: Leaving ADDIE for SAM, by Michael Allen with Richard Sites. Retrieved from

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.

Yatzeck, E. (2012, August 14). How to control scope creep in Agile. Retrieved from


Comments on: "Scope Creep: Why Fight It?" (1)

  1. Great point, if the project manager permits changes then the scope could definitely creep indefinitely.

    “Is scope creep a failure to plan, or is strict adherence to the original design a failure of imagination?”

    Great question and this is a tight rope to walk. This fine line can feel very paradoxical. Experience can help foresee potential problems but if some extraordinary instance takes place scope will creep and we must find ways to adapt and deliver

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Tag Cloud

%d bloggers like this: