Two weeks ago, I wrote about using a mind map to define project scope at a high level. Last week, I wrote about using Post-It Notes and a white board to develop a detailed scope statement based on the deliverables to be produced. This week, I’m going to describe scope maintenance via the change control process, from the perspective of a Change Request. Note that fifteen of the forty-two processes documented in the PMBOK may produce Change Requests, so it’s probably a good idea to have a clear vision of a change request life cycle in mind when you develop and administer your integrated change control process.
According to the PMBOK, any stakeholder can initiate a Change Request. However, some organizations require a Change Request to be sponsored by someone with some level of decision-making authority, in order to avoid inundating the project team with requests that haven’t been vetted for business value. In either case, each Change Request should be documented, and an entry made in the Change Log upon receipt. A good Change Log is an important tool in configuration management – it helps keep track of what changes were requested, what decisions were made with respect to the request, and who approved the decision. Many organizations will have different handling processes and reviewing authorities for different kinds of requests, or those with variously sized cost, schedule, quality, or risk effects, so part of Change Request intake should include recording the classification of the request, in order to facilitate processing.
Once a Change Request has been received and recorded in the Change Log, a reviewing authority should consider the request as soon as possible. Not all requests are feasible, and some may be out of scope. Others may negatively impact information security, regulatory compliance, or raise other concerns. In such cases, the reviewing authority might either disapprove the request without further action, or return it to the requester or sponsor for additional information and justification. Those requests that are deemed feasible and in scope should be “linked” to one or more deliverables, and analyzed for their impact to business benefit, cost, schedule, risk, and quality. Note that the PMBOK refers to “expert judgment” for this analysis; in practice, that probably means the same person who provided the original estimates for that deliverable, or the team members responsible for producing it. The affected deliverables and the estimated impact should be documented, either as an update or an attachment to the Change Request. Some organizations also record “bottom line” estimate values in their Change Log, to facilitate analysis during a “lessons learned” review.
At this point, the request should be routed to a deciding authority, based on the classification of the request and your organization’s standard procedures. Many organizations delegate some level of authority to the project manager, but require requests with potentially higher impact to be considered by a Change Review Board. It is important to act on Change Requests quickly, in order to avoid unnecessary costs or delays in implementation. Decisions should be recorded in the Change Log, and the requester or sponsor notified of the decision. If a Change Request is approved, needed updates to requirements, project plans, contracts, and other project documents should be communicated to the team as quickly as possible. Reasons for rejecting a Change Request should also be documented, both to close the loop with the requester and to facilitate reviews and handling of future requests.
Whatever change control procedures you use on your project, ensure that a change control process document is available to those stakeholders who might want to initiate a Change Request. A good process flow chart, with clear criteria for classifying and reviewing requests, can minimize the number of questions and possible disputes. And since the Change Request is a primary communication medium between the stakeholders and the project team, it just makes sense to describe those procedures from that perspective.
