Androgogic Process to Manage Changes to Project Scope

For Business-as-usual (BAU) requests, we have a process where the client has designated managers that can make or approve a change request. If it involves additional costs, these managers need to approve it in advance in writing. Documentation of the change request depends on its scope. If it is a change to deployed software for example we will update the Software Requirements Specification (SRS) and have the client validate the SRS before doing the work. We frequently use a usecase format with business processes documented in Universal Modelling Language (UML) activity diagrams so that these specifications are accessible to non-technical personnel.

Once the change is scoped, documented and approved, we schedule the work leading to the change release including testing and client facing User Acceptance Testing (UAT) on the test servers. If the roll out impacts students, we will include approved communications in the request details and implementation.

If the change request is of sufficient scope, it will become a project or possibly mini project and so attract the project management methodology we follow {based on elements in the Project Management Body of Knowledge (PMBOK)}.

Project change requests are handled a little differently. Basically where a project exists and there is a change to scope as documented in the project Statement of Work, we document it as a change request. This then goes to the project stakeholder group under the supervision of the designated executive for review and approval. Cost/time/quality impacts are reviewed and any related documents are updated including e.g. the Project Schedule, specification, etc. The change request and its approval are documented in the  project stakeholders status report (we report based on a cycle-based implementation process usually with cycles of approximately 10 business days).

Note also that the domain the change request falls into has a big impact on the process. If it is a software engineering related change, this operates through our Software Development Life Cycle and involves things such as our such as our configuration management system (CVS) , testing processes and so on. If however the change relates to, say, content, then this will most likely fall into one of the managed content production workflows.