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 http://www.learningsolutionsmag.com/articles/1012/book-review-leaving-addie-for-sam-by-michael-allen-with-richard-sites
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 http://www.thoughtworks.com/insights/blog/how-control-scope-creep-agile