Managing Scope Creep

Several years ago while employed at a higher education institution, I was included on a project team responsible for converting a face to face course to an online course. At the time, we knew nothing of the term instructional design and were recreating the course from a poor design. An overseas firm was contracted to do the site and content. Two things were wrong with the first course created: 1) the site was not what my boss wanted and 2) they did not include the content. They provided a skeleton for my boss to populate. My boss, who was obviously not pleased with the result, handed over everything to his in-house team to recreate. This time, he wanted us to include the content for each module on the site and create a design that he was comfortable with. This began our project.

I cannot honestly state we had a project plan, budget or any of the documents that our course text suggests should be in place before the project starts (Portny, et al., 2008). However, we were given a task to create a website to host the content and to include the face to face course content on the site. The development team created a wireframe that was accepted, and so we began work.

Though we had no documentation to guide us, we knew what we were working to accomplish. Our efforts were focused on creating the accepted wireframe, which admittedly was not much effort. The challenge was, our boss was a dreamer. As often as he could, he would present us with additional functionality to include on the site. When the design was mostly done for the website, we were again hit with a request, this time, to add a unifying image on each page and as part of the content. He wanted a bus. I believe he had some ideas what the bus should look like but had difficulties explaining that to us. We spent some time trying to locate the right bus then making changes to the site to include the bus in the design. We had the same challenges when we tried to prepare the content for the website. The team was extremely frustrated with these changes and even started to drag our feet because each day we anticipated more changes.

In retrospect, I believe what the project needed more than anything else was a project manager. The PM would then manage the requests for changes and have these documented using his change control systems (Portny, et al., 2008). This implies that other documentation such as the project plan would also be in place. The PM would communicate with the client and other stakeholders, negotiate a final position, and then let the team know the client’s needs. Furthermore, the right resources were required for the project. There were three web developers assigned but not one instructional designer. One web developer played the role of graphic designer. We all tried to get the content just right but having no experience in this area was a drawback. Close monitoring of the projects tasks and their duration as well as reducing the number of changes required to the product would have gone a far way to complete the project faster. The brilliant ideas the boss supplied should have been carefully documented. Those that were practical and could be included without affecting the critical path could be considered for implementation. However, others should have recorded for future updates to the course and site.

References

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.