Project Management

Manage these three aspects of change in your project

You can't predict every change that will happen in your project, but you can manage them as they occur.

It's said that the only constant in the world is change. You can make a great plan, but you can't account for every potential change that may occur. The longer your project is, the more likely you'll be dealing with changes. Since you can't predict every change, the best that you can do is that manage the changes that do happen.

There are three aspects of change that can occur on a project.

1. Scope change

This is the most important change to manage. Scope is defined at two levels -- high-level scope describes the boundaries of the project and the major deliverables to be built; Low-level scope is defined through your approved requirements.

The purpose of scope change management is to identify change and manage it effectively. It also protects the project team from changes made after the commitments to schedule and budget are agreed to. In other words, the project team committed to a deadline and budget based on the high-level and detailed scope definition. If the deliverables change during the project (and usually this means that the client wants additional items), the estimates for cost, effort, and duration may no longer be valid. If the sponsor agrees to include the new work into the project scope, the project manager has the right to expect that the current budget and deadline will be modified (usually increased) to reflect this additional work. This process ultimately brings the appropriate information to the project sponsor and allows the sponsor to decide if the modification should be approved based on the business value and the impact to the project in terms of cost and schedule.

2. Configuration change.

Configuration management is the the identification, tracking and managing of all the assets of a project, and the characteristics (metadata) of the assets. (In some organizations this process is more narrowly defined to mean only the management of the physical assets.) In most projects, configuration management doesn't come into play. However if your project uses or builds a large number of components, parts, artifacts, equipment, and so on, configuration change management could be very important.

3. All other changes.

Your project may experience changes that don't necessarily fall under scope change management or configuration management. These changes can be grouped into a general change management category. For instance, let's say one of your team members leaves and needs to be replaced. This would not be an example of scope change or configuration change. It's a general change. In this case, you may need to document the fact that a resource change occurred, determine the impact of the change, and put a plan in place to manage the change. In many respects, you'll follow a similar process to that of a scope change request.

One of the key differences between general change management and scope change management is that you expect that if a scope change is requested and approved, you will change your budget and schedule to accommodate the change. You should not have that same expectation for non-scope related changes. For example, in the example above when a team member needed to be replaced, there was definitively a change, and there will probably be an impact on the project. However, there is no expectation that this change will result in an approved schedule or budget change.

As a project manager, you should focus on making sure that you manage scope change, which is a primary culprit when projects have problems. However, you should be aware that your project may need to have a configuration management and general change management process as well. Managing all these aspects of change may save you countless hours of trouble.

7 comments
PMPsicle
PMPsicle

Personally, I like to also track two other types of changes which you seem to group under the "Other" topic. The first is a group I term schedule changes ... which is basically those changes forced by slippage or advanced completion. Basically, the changes that I get paid on a daily basis to make/prevent/enjoy. The second are those I call risk-based. Basically, these are changes that are planned for in the risk management plan (if you're lucky and good). While we busily plan for what we'll do if Mr/Ms Grt Coder leaves, we still need to manage the actual change process if it occurs. Good summary otherwise.

senthil.parameswaran
senthil.parameswaran

Most of the changes you have specified comes in 'risks' plans too. Identify the risk before, and try to avoid it if not possible, then there should be process by which to tackle it. Only for project scope management, you require exclusive change management process.

geoff.schmidt
geoff.schmidt

This article is correct at basic level. However, for larger & more complex projects, there are some other considerations... 1. scope changes should in theory be agreed with the sponsor, along with any associated budget and timeline changes, but the approval cycles and/or the bureaucracy surrounding scope change may make this unmanageable for small changes. Separate approval processes may be required for smaller scope changes, eg, they are funded from contingency managed by the PM 2. sometimes it is very difficult to determine what is a scope change versus an 'other' change. For example, an interface is required to an external system that was not identified during the design phase, but is required for successful delivery. It can be moot to make this distinction (a 'miss' versus additional scope) if too much time is taken discussing the difference, rather than applying the change 3. 'other' changes, if large enough to substantially affect the project, by their nature become scope changes regardless of the definitions applied. For example, if the newly-identified interface blows your schedule by 6 months, well, it's going to be a scope change requiring sponsor approval. This is where your stakeholder management skills come into play.... 4. always apply a 'so what?' process to any proposed change, ie, "so what if we don't do it? what's the impact?". No matter if the change is large or small. Too often, especially in earlier phases of the project, unimportant/unnecessary changes are incorporated into projects that add more cost and issues that originally anticipated. All changes should be minimised! Just some thoughts.... P.S. configuration management is a must! It is too easily forgotten, and with dire consequences.

meryllogue
meryllogue

I have a really hard time with the phrase "configuration management." I hear (read) the definition all the time and as soon as I walk away, I have forgotten it. The name does not match its definition, and so it creates a "cognitive dissonance" in my brain, and it rejects the whole kit and kaboodle.

PMPsicle
PMPsicle

The problem, of course, is that everyone and her brother uses the term "Change Management". And everyone uses the term to mean different things. Ask an executive and "Change Management" refers to changing the organization. Ask an HR person and "Change Management" refers to helping people adapt to change. Ask a IT (not IS) person and "Change Management" refers to tracking what equipment is where. Ask an IS person and "Change Management" refers to which version(s) of software is in use. Ask a PM and "Change Management" refers to scope change requests and their effects. Or maybe it refers to tracking plan changes. Or maybe it refers to the process which controls plan changes (scope change is only one of the types of changes that fit in that area). Unfortunately, sometimes you just have to pick a title that seems to work for your audience. And that allows your poor PM to figure out what the H*** you're talking about (since they tend to deal with all of them). In the case of "Configuration Management" it seems to make the most sense to the most people. In most cases you aren't just making version changes (that's a software/IS concept). Rather you're managing the configuration of various pieces and parts (e.g. which make/model/version of hardware, including, in some cases, OS pieces and parts (who's/function/model/version) which go together to create the platform or product. For IS types this is most important with embedded software where different hardware versions and software stacks may also be used. Of course, you could always call it what most of the software calls itself - Change Management. Oops, now what do you call CM for everyone else? My suggestion .... when someone uses an OC/RM/CM/PM/SM/CM/MM term ... ask what they mean by the term and then translate their version into your own terminology and get over it. When you figure out what each audience believes is the "proper" term - use that. (Then provide a definition whenever you use a term in the OC/RM/CM/PM/SM/CM/MM arena so they know what you're talking about - otherwise they're going to presume you're talking about the same thing they would be). Scary thing is ... the only person who actually manages changes is the Sponsor - and that's not even called Change Management (it's called Scope Management). Everyone else is just managing the reaction or effects.

Wayne M.
Wayne M.

I agree that "Configuration Management" is not a descriptive term in most instances it is used, a better term would be "Version Control." In software development, configuration management usually just means using a source control system to check files in and out. In software deployment, configuration management usually means tracking the software and version numbers installed on individual machines. In project management, configuration management usually means applying a version number to documents, getting new versions of documents officially approved, and saving old versions in a specific directory or in a document control system. One really has to stretch the term "configuration" to fit most uses of the term "configuration management." For me, the term "Version Control" comes closer to the reality of what is being done.

YCCcom
YCCcom

I understand exactly where you're coming from. Configuration management is not my particular disconnect but I get you. Make up and auto substitute your own translator/converter terminology.