Project change control in 4 easy steps
Project changes. Keeping them under control is one of a project manager’s biggest (and most important) jobs. Scope creep can kill a project. Schedule changes can make the business lose confidence in IT. And an out-of-control project budget can wreak havoc on an entire IT organization.
Many organizations employ project change control processes, but they are frequently ad hoc or ineffective. A disturbing 44% of projects are still late, over budget, or delivered with less than promised functionality.
So when my place of work asked me to design and document an “official” project change control process for IT projects, my focus was to make the process as easy and straight forward as possible. I’ve seen beautiful processes get completely destroyed by complexity and remain a pretty Visio diagram, nothing more. A process is worth nothing unless people follow it, and people won’t follow it unless it’s clear and simple (or forced upon them from up high, beaten into them with a stick, which not only is more difficult, but I just straight up don’t like that approach).
In the spirit of clarity and simplicity, I introduce this five part blog post on project change control, illustrating an easy and straight forward 4-step project change control process:
In this blog series, we’ll go into detail on each step in the subsequent posts. In this post specifically, we’ll be covering some higher level change control components.
What Project Change Control Is Not
Project change control is not organizational change management — facilitating change in human behavior as part of an overall business solution.
Project change control is not configuration management — versioning of specific project deliverables.
Project change control is the management process for requesting and carrying out changes to the agreed scope and objectives of the project¹, including:
- Business case
- Technical architecture
A Change Control Board (CCB) considers and approves project change requests on a regular basis. Every project should establish a Change Control Board, regardless of project size. The smallest of projects are still susceptible to scope creep.
Members of a project’s CCB should include representation from the:
- Business unit
- IT Program Manager
- Primary solution delivery organization
- Primary solution support organization
Basis of Decision
An established basis of decision for project change requests will empower the Project Manager to approve appropriate changes, or know when to escalate to the Change Control Board. This basis of decision should be established during project initiation activities.
Here’s an example basis of decision¹:
Is the change unavoidable, or does it increase the overall benefit to the organization?
- and -
Is the project team able to make the change within existing project constraints?
- and -
Is the change best done now?
If the answer is YES to all three questions, the project manager can approve the change, without going to the Change Control Board for approval.
¹ Source: Wallace, Simon. The ePMbook. http://epmbook.com.
In the next post in this series, we’ll dig into the details of documenting a change request (specifically two critical documents required for successful project change control).
There are no comments on this entry.
There are no trackbacks on this entry.