Project Management Forum - Change Control

Change Control

(Managing Scope / Scope Creep)

Forum Discussion Notes for November 19, 2009

High-level Scope = Defined in project charter that are the boundaries of the project. What functions that are going to be delivered.  This is at the work level. In a project charter, this high-level.

Examples. Build an airplane. Or, bracket it down even finer. The detail depends on the project.

Scope is different than the scope statement.

Scope can be a reminder, at a high-level description of the project whereas the scope statement is much more detailed.

Project Charter = Gold. Grants the authority to the project manager to run the project. Defines the “fine print” of the project, the business case. Defines the roles and authority/ responsibility of the high-level stakeholders in the project. Overall resources are outlined here too. This document is signed off by the project sponsors.

May do this: Analysis / Discovery Phase followed by actual project.

A project plan is created with a project that is feasible, and this includes a very detailed scope statement.

Examples of scope definitions: Verbal. Written on napkins. Written in a charter.

First challenge = getting agreement on the scope among all the stakeholders.

Second challenge = change management.

                Phase the project. Change control moves the requested scope additions to another project phase that launches after the current phase launches.

                Require signatures to investigate or make the changes requested. Add accountability.

Remember: Change has a cost (time, money, quality) to it.

Remember: Change is expected.

Issues:

Clear communication. This is definitely the responsibility of the project manager.

• Initially, make sure the scope is clearly defined, in unambiguous detail among all the parties.
• Later, when a change is requested (when misunderstandings are uncovered or the WBS) the project manager needs to clearly communicate the impacts (time, money, quality).

Rigidly Following the Scope to the Bitter End

• Follow the change control process; move scope components out, to another project.
• Add review points in the project to review the scope, timeline, budget, etc. for feasibility and possibly reducing the scope.
• Create Moscow list (Must have, Should have, Could have, Won’t have) ranking all the scope elements at the outset. Definitely do the Must Haves, and do the rest in ranked order until the project is completely. Quantify the cost for ranking the elements (for example in jelly beans). Look at SCRUM / AGILE.

Change Control Processes

Ex: Agreed upon and defined process to evaluate and approve change.

Make sure to define the process at the start of the project, including who approves the changes.

1. Requires an input (~form) (Ex. Verbal, Paper forms, e-mails) for the request.
2. Review (in no order)
• Review the change.
• Analyze the risks.
• Identify end-user impacts.
• Deployment, training, ongoing support.
• Analyze the costs (time, money, quality) to make the change.
• Identify all the stakeholders impacted by the change.
• Identify impacts on other projects.
• Negotiate and Politick here before the changes are sent for approval.
3. Approval. Ex. Verbal approvals. Signatures. E-mails.
• Change control board / Steering committee, etc. reviews the analysis / reviews of the changes.
4. Appropriate communication of the change.

Document the requested changes (ex. E-mails go into Excel).

• Include the name of the requester and other
• Store the document for all to review. Document in a document repository.