This video looks at two different ways that you can use your change management process, above and beyond the standard change board and approval cycle.
In this video, I look at the hidden cost of project changes.
Don't you just hate change control? According to a study by Jama Software, 75% of project managers are managing projects with at least 100 requirements. One in five are managing projects with over 1,000 requirements. That's a big project. Here's a summary of the rest of their findings:
Download the full report here.
Jeff Furman, PMP and author of The Project Management Answer Book, has lots of experience running change management processes. And we all know that early changes are cheaper than changes at the last minute. I talked to Jeff about his experiences and what we should all be doing when it comes to good change management.
Hello Jeff. You used to run a large change management system. Can you tell me a bit about that?
Hi Elizabeth, yes, I worked for a brokerage firm in Manhattan with an IT department of more than 1,000 developers (including a wing in London!) Brokerage people will all tell you there is a “life and death” urgency when putting in any software change in their environment, because the traders often need to take advantage of the new code ASAP to process their trades accurately (especially when the changes involve new laws or regulations!) Our company chose a vendor change management solution which could handle the diverse programming needs of hundreds of projects simultaneously, 24x7, and I managed the team that supported and customized this system through several successful upgrades.
That sounds like a complex system, but one that worked really well. Why was the system so good?
A good IT change management system must be user-friendly, as well as customizable and flexible, meaning it can support many types of software changes. But of paramount importance in a financial environment, it also must be VERY SAFE! To that end, our system included a very powerful “automated back-out capability,” meaning that if a bug was discovered after a change went in, all components associated with the developer’s change package could be backed out in one shot, and automatically replaced by the previous versions. This meant that if a developer got a call at 3:00 am EST to pull a change package containing 50 components before trading opened in London the next morning (where it was already 8:00 am) he or she wouldn’t have to scramble to find the 50 prior versions -- the system did that for them.
Was there anything you would do differently if you worked on something like that again?
Two things –
1. Earlier training– What really got people to embrace the system was a customized training program we put together, highlighting the benefits to the developers. If I had a time machine, I would go back and initiate this training even sooner, because as you say about social media tools in your book, “If they can see the benefits, they will use the tool.” There was ironically resistance to change to the change management system, and it didn’t catch on until the training.
2. Customizations with future vendor upgrades in mind -- We had a very large customer-base, and so there were a great many enhancement requests over the years. Beware that the more you customize your system, the more it will take to maintain it over future upgrades, which often need to be done fast. If I could take a second ride on the time-machine, I would push back harder against some of the customizations we agreed to.
What are your tips for good change management?
Stay strong about change approval rights: PMs often tell me they work with systems where people can bypass their process. This undercuts the system and in some cases the success of their projects. A tip for avoiding this problem is to get advance agreement from senior stakeholders that changes will go in ONLY if they are authorized by the designated approvers. This works because it puts them on record for agreeing this is for the greater good of the company, which also gives them buy-in to the rules being enforced.
Customer-focused training: Bring in a good class early, customize it to your environment, and emphasize the biggest benefits to the people who will be using it.
Don’t reinvent this particular wheel: There are many mature vendor products out there, with powerful and robust features, and I would advise that it’s probably a mistake for any company nowadays to try to build their own change control system from scratch.
Jeff's book, The Project Management Answer Book, is published by Management Concepts (Vienna, Virginia)