Change Management

Nothing wreaks havoc on project schedules than customer requests for changes. I know it’s probably never happened to you, but I’ve heard from several Alliance Partners that customers occasionally want to add or change the requirements for a system. And developers, particularly less experienced ones, are often prone to agreeing to such changes in an attempt to please the customer and avoid confrontation.

So, it’s a good idea to establish a clear policy on what constitutes change and how it is to be dealt with. The most emphatic statement is ‘anything’ that deviates from the project specification. That certainly minimizes the temptation of your developers to make unauthorized changes, but most feel that it unnecessarily slows down the decision making process. But, at a minimum, a change is anything that affects the project scope or requirements. Some also include any change that affects schedule and budget.

Change Orders and Customer Notifications

Next question, when should you require Change Orders? Only when the customer is to be notified? There is some argument that all changes be documented to help reinforce with your staff the affect of such changes.

You institute a Change Order process to document such changes. The policy should also address when customer notification and approval is required. Some feel that customer approval is only required when there is an additional charge. But, I recommend customer notifications/approval for all changes to requirements, budget, or schedule. In each case, you should assign and include the cost for that change, even if you zero the charge out (in another column). That way, you are reinforcing with your customer that you providing the additional value at no charge. So, if your customer comes back with additional changes, it is easier for you to draw the line and ask for an additional charge.

Closing the Loop

Finally, make sure change management process is comprehensive. Change Orders should generate an action item to update the project documentation, the project schedule, and the project budget. Billable changes should be tracked through finance and included as a requirement before a project can be closed.

Change ManagementRemember these? Found this when I did a Google search on change management. Not exactly what I was looking for, but couldn’t resist including the picture.


4 Responses to Change Management

  1. I had a conversation around this very subject today where my colleague insisted that any deviation from the current project plan had to be treated as a ‘defect’, which has a defined review and approval process.

    I agree with the general direction of your blog that it is better to over inform the customer about the impact of requirement changes than not. A change order should be required for any change that impacts the schedule, requirements documents or budgets.

  2. Paul, don’t forget to fully leverage the PMO to augment personal skills.

    I like the attention to PR; this is critical to public projects. There is a real shortage of positive public sector project success stories.

  3. […] Reasons for Change Management During an presentation about Project Management Practices that I recently gave at the UK Alliance Day, we were discussing the reasons for a good change management process. Some of these, I’ve mentioned in a previous post: […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: