February 2, 2010
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:
- Accurate reflect that there has been a change to the contracturally agreed on specifications/requirements. I think this is the best ‘excuse’ to ‘enforce’ this process with the customer.
- Recognition/approval to potential impact on timing and budget. Your developers should be made (painfully) aware that agreeing to changes, cost money. Regardless of whether they can be accomodated (in the timing allowed), you are adding value – and that should be captured and recognized.
- Sets precedence for further changes – If you ‘blindly’ accept changes, then it is harder to get it stopped once it gets going. The customer is apt to say, ‘Well, you made these other changes (which may have been bigger). Why not this little one more?”
I also advocate that Customer Change Notifications/Approvals. Even if you don’t intend to charge the customer, the change should be documented, the cost of that change estimated and included on that notification, as well as a separate spot to indicate charge to the customer (even if it is zero).
A couple other reasons
I got feedback from the audience that there are a couple other reasons to follow this process:
- Change may just not be worth it – By formalizing the process, you give the customer (and/or your developer) to determine that it just isn’t worth the ‘hassle’ to make the change – including documenting it and getting the necessary approval. In that case, you’ve probably saved yourself some time and effort.
- You might just get paid for it. Must admit that I’d probably hadn’t given this one enough consideration. So, you may just want to present Change Notification with the charge included and only zero it out if the customer pushes back. Even then, you established that you are providing extra value to the customer.
What say you?
Getting the feedback from my presentations, reminded me that I should do a better job in these blog posts to ask your thoughts and opinions. Do you have a formalized Change Management process? If so, what do your find effective (or not)?
June 1, 2009
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.
Remember 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.