The project had a strong risk factor in that it did not have a clearly written objective yet there was a clearly understood expectation that it needed to fill the gap of knowledge for teacher’s use of email and word processing by offering a hard copy of instruction to use the Microsoft software. As the project began to develop and parts of the handbook were completed it could be seen that it was a good source of professional development for staff. Soon district heads, the drivers, sought to add many additional components and software applications to those being addressed in the manual. The complexity grew and limit of the features to be covered by this handbook were less clear. It was desired that PowerPoint, a Microsoft presentation application, would be added to the list of software in the handbook. There were so many features and plug-ins associated with the program that defining the final list to include required many hours of planning and debating. The focus of the project became less clear and the perceived effectiveness of the handbook dropped. The project lacked what the Portny text calls a change control system which would have helped to Identify alternatives to the changes, triggered communications that would have informed stakeholders better, identified the impacts on the project (Portny, Mantel, Meredith, Shafer, Sutton, and Kramer, 2008).
The project finished up late, but did produce a very helpful handbook that was scaled back to earlier goals of instructing in the use of email and word processing and included an introduction to PowerPoint and presented several URLs for external tutorials on its use.
References
Lynch, M. M., & Roecker, J. (2007). Project managing e-learning: A handbook for successful design, delivery, and management. London: Routledge. Copyright by Taylor & Francis Group, LLC. Reprinted by permission of Taylor & Francis Group, LLC via the Copyright Clearance Center.
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.
Christopher,
ReplyDeleteI can see where this project could balloon out of control. I mean they have written whole books on this subject. Providing clear objectives and goals for this project would have helped keep the scope creep down. Scope management is concerned with, among other things, making sure that the project team does only the work agreed on in the scope statement and verifying that the completed work meets the requirements. Because the project scope will drive what activities occur, it must describe in great detail and without any chance of misinterpretation how the deliverables will be produced (Sherrer, 2008-2010).
Instead of just a set of guidelines for the teachers to use, it sounds like this project was turning into an entire course on Microsoft Office. As a guideline, the project should have included only the minimum the teachers needed to navigate the system. A good change control system would have helped prevent the original intent of using the information as a guide from becoming a complex course delivery system. It was a great idea to add links to extra tutorials instead of including them in the guide. The learner could then research more information on their own if they were so inclined.
Sherrer, J.A. (2008-2010). Project management road trip for the project management professional. Chapter 5. Retrieved 2/5/2011 from http://www.pmroadtrip.com/
Chris -
ReplyDeleteIn a survey by Computerworld (Anthes, 1994) the number one reason of scope creep, which received 44% of the votes, was poor requirements or lack of clarity. I can see how this was an issue here. I also agree that having a change process could have been handy, especially since others were starting to provide input on the needs of the handbook. Gurlen (2003) states that there two types of scope creep: new requirements and modifications of requirements. This definitely sounds like new requirements were being made as you progressed, which could have been attributed to the lack initial clarity. Were you able to go back and create separate handbooks for the items that didn't make it in to the first one?
Anthes, Gary H. (1994, May). No more creeps! Computerworld, 28(18), 107. Retrieved February 10, 2011, from ABI/INFORM Global. (Document ID: 311539).
Gurlen, S. (2003) Scope Creep. Retrieved February 10, 2011 from http://www.umsl.edu/~sauterv/analysis/6840_f03_papers/gurlen/