Thursday, 4 August 2016

EDUC6145 Analyzing Scope Creep

Developing an online help system for our new learning management system experienced scope creep for a number of reasons.

The statement of work did not sufficiently detail the requirements for the online help system.  The initial project planning needs to include a scope statement along with product requirements.  Creating an online help system is far too generic and means different things to different people.
image source:  http://yourprojectmanager.com.au/managing-project-scope-avoid-scope-creep/

As we designed and built the prototype and demonstrated functionality to the stakeholders, they began asking "what about this" or "can we add that" and every time a new version was presented, there were more requests made.  There was no process or documentation created for change requests -- it was primarily verbal suggestions made during demonstrations or a quick email request.

In the future, I would ensure proper planning occurs before any work on the project begins.  The planning process would also define how change requests will be processed, including the need for approval before any change is introduced.




1 comment:

  1. Vida,
    I like that you called for a defined process for requesting change in future projects. I think this is critical and further controls any issue of scope creep. Our text discusses change control boards (Portny et al, 2008) and while I think your project is far too small to necessitate a control board, I find the idea highly effective. For instance, in my current organization I am tasked as the designated Salesforce trainer which has subsequently pulled me into representing my department on the innovation team. This team, which is essentially a change control board, implemented a process where enhancements could be requested to the system, reviewed, presented to the steering committee, approved or denied, and then implemented after a short technology sprint of development.

    Following this process, we have implemented a mechanism where changes are requested, vetted, approved or denied, and then built into the system. It allows us to streamline and document change requests, compare them in a cost of delay and ROI meetings, and then approve or deny based on need and impact.

    Do you think something like this would benefit your organization?

    Best, Dennis

    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.

    ReplyDelete