Uncontrolled change is one of the biggest foes of a project manager. That's why a solid change management process can be a project manager's best friend. Putting this kind of process in place enables you to deliver what the customer has requested, in the timeline required, and within the agreed-upon budget. Without change control, the project scope becomes a moving target and you are at risk of missing one or more of your project success factors. The ability to manage and control change, particularly that of project scope, is a key to reaching goals and a typical performance indicator for a project manager. Project change is inevitable and you must be prepared to deal with it when — not if — it happens.
Balancing change management and bureaucracy
One challenge for project managers is balancing the need to control project change while avoiding undue bureaucracy. The question is: Where is the tipping point? Because every project is unique, the point at which change control stops adding value and turns into red tape will vary from project to project.
Some of your stakeholders, or even your project team members, may feel that putting change control in place is your way of avoiding the dreaded scope creep, and that you are unwilling to be flexible and do what is best for your customer and the business. It's important to dispel this perception. Let them know that what you are doing is exactly the opposite: you are implementing an efficient process for consistently evaluating requested changes. If making the alteration is deemed a good idea, then you'll have processes in place to respond when needed.
Top of Page
The project change management plan
To help you respond quickly, a project change management plan describes what happens when deviations occur. It's not intended to prevent change; rather, its purpose is to outline a process that makes clear how change will be communicated, how decisions will be made, and how the project will adapt accordingly.
Top of Page
Putting change control in place
You should put your change control process into effect as soon as you create a baseline for key deliverables, such as business requirements and schedule. The project team and stakeholders — and anyone else affected by changes in the project — should review and endorse the change management plan before you put it into play.
Small changes that have little impact on the overall success of the project shouldn't entail the same rigors as those made to requirements or critical-path schedule milestones. The project change management plan must state when a formal project change request (PCR) is required. For example:
- What are the thresholds for schedule and budget changes?
- Are there changes that always require a change request?
- What alterations can the change management process skip?
One caution here: often it's lots of small-scope changes that do the damage, rather than the big, obvious ones. Consider this when defining your PCR criteria. For example, your change management plan should define change request categories, such as what is major or minor:
- Major changes These should be documented as a PCR. Major project changes:
- Affect requirements or work items on the critical path, delaying significant milestones or the overall project end date by a certain time percentage or duration. Major change criteria should be defined for each project.
- Require additional funding (in dollars or percentage of budget). Again, the amount should be defined for each project.
- Minor changes These routine changes don't require a PCR. Minor changes:
- Don't significantly affect the plan. They don't extend the completion date of milestones or tasks with project dependencies.
- Have no negative financial impact. No project budget variance will occur as a result.
Top of Page
Tips for evaluating change requests
The project change management plan should also include information about how change requests are evaluated. It's vital that the criteria for this evaluation be determined before it's needed so that time is not wasted reaching consensus. Setting these parameters will help balance change with overall business goals and benefits.
Here are some typical questions to consider when evaluating a change request:
- Does this change add to or alter the business requirements?
- Is there a work-around, or is this change necessary for the overall success of the project?
- Does this change require an increase in funding?
- Will this delay the project end date?
- Even though this change may have a negative impact on this project, does it result in significant business upsides that make it worthwhile?
- Does enacting this change now make more sense than delaying it? Will the delay end up costing the company more money in the end?
- Have all the affected stakeholders been considered, and do they endorse the change?
- Are there contractual ramifications to consider? For example, will commitments with outside vendors be unfulfilled because of this change?
Top of Page
Approving project change requests
It's also important to define who can approve — or can't approve — requested changes. It's common to define various authority levels so routine changes can be dealt with efficiently, while significant changes receive the needed level of managerial attention.
When a proposed change affects the scope of the project, you should consider it as a business decision that requires approval from the project sponsor. When scope is not affected, the project team and sponsor may decide that the project manager has the power to approve the change within certain limits. For some projects, change control boards are created and convened on a regular basis to consider and approve change requests. There may be different change control boards in the organization, which handle various types of change requests. For example, a technical change control board might look at technology issues.
One easy way to summarize the guidelines for approving change requests is in a table like the one below, which is based on a sample project:
|Type of change
||Represents significant change in project scope, schedule, or budget
Addition of a new requirement or expansion of an existing business requirement
Schedule delay of more than 14 days or will delay project end date
Requires additional funding of $100,000 or more
|Project change control board
||Represents change in project scope, schedule, or budget
Clarification of business requirement
Schedule delay of fewer than 14 days that does not affect project end date
Requires additional funding of less than $100,000
||Routine change with little or no impact on project
Does not change milestone completion dates
Impact on project budget is less than $X or X%
Top of Page
The big payoff
Project teams are always anxious to get to project execution, sometimes at the expense of effective planning. It's tempting to take shortcuts and assume you'll figure things out as you go. Having a well developed change control process in place, before changes occur, will have big payoffs and better overall project results. Taking the subjectivity out of change control will enable the project team to handle fluctuations efficiently and effectively. A well thought out, detailed change management plan that has been accepted by project team members and stakeholders will save time and money, something project managers never have enough of.
Top of Page
|About the author Jane Suchan is a program manager with experience overseeing enterprise-level business initiatives and developing project management methodologies. Jane lives in Seattle, Washington.