Preface – by change control process I’m referring to managing changes to software and not the process of promoting those changes into production. The latter is configuration management (to me anyway) and that process is independent and critical no matter how changes are decided. Check out the concepts of DevOps for ways to link development and operations together.

Does any of this sound familiar?

“We need a formal change control process.”

“We need a form to document all changes.”

“We need the change control board to approve any change before the team starts work.”

Does it sound good or bad? On the surface it sounds fine, right? After all there’s nothing wrong with having a process, and a form isn’t necessarily bad, and a board…what a great way to make sure everyone is on the same page. Right?

Change control traditionally is a project management process for managing change. Any good PMP will have you fill out a change control form containing the requirements of the change, impact to the project, risk, etc. That form is then submitted to the CCB that may approve or disapprove the change. If the change is approved, the PM incorporates the change and impact into the master project plan. Repeat.

What organizations need to be mindful of with this approach is that even with the most formal of processes, the best form (even an automated one), and an engaged CCB…sometimes the main issues causing the problems aren’t addressed. Sometimes, a form won’t fix the problem.

These issues may include:

  • Lack of trust between management and development team
  • Lack of trust between between IT and the business
  • Lack of communication between stakeholders
  • Lack of product vision
  • Lack of tolerance for changes once requirements are identified
  • Lack of empowered decision makers

Do any of those issues sound familiar? If so, you are not alone. Many organizations that I have supported over my career have struggled with how to effectively, yet efficiently manage the change process. This struggle is often a primary driver behind Agile adoption.

Let’s look at the Agile Manifesto and break down each phrase as it relates to change management:

Individuals and interactions over processes and tools
Process and clear roles and responsibilities are very important, but they aren’t as important as actually talking to each other. The concept here is to communicate MUCH more and stress LESS about the process. Retrospectives (with product owners and their stakeholders) should be held regularly to identify what is working and what is not when it comes to managing change. And keep the process simple and don’t try and get it 100% right before you start using it. Get it going and use the retrospectives to implement changes as needed. A RACI analysis is a great way to determine who needs to be involved and how.

Working software over comprehensive documentation
If you deliver software faster (ideally 30 days or less), and deliver the most important functionality first…then I bet that change form becomes less important. Most people prefer to see and touch working functionality anyway versus reading about it in a requirements document. You can have a form if you need to (or a SharePoint list or use a tool like Jira), but it should not be the focus and it should be as light weight as possible (think barely sufficient). The tool you choose or form should make things easier…not harder. The added benefit of delivering more frequently is that when a requirement changes (notice I didn’t say if) and the application needs to change, you’ve only spent a short amount of time working on it.

Customer collaboration over contract negotiation
Collaborate continuously with the customer and ensure there is a shared understanding of the desired functionality and when that functionality will be delivered. The goal is to deliver value to the customer, not deliver what was written down in a requirement document drafted a year ago. And never forget that value is defined by the customer (the business), not the development team and not the IT management team.

Responding to change over following a plan
Fight the urge to immediately say “no” or “you’re changing your mind already!” Agile organizations embrace change at all times – even late in the development process. It’s critical that development teams trust that the business is asking for changes because they are IMPORTANT to them. A team’s job (and IT management) is not to judge the importance of their requirement, it’s to understand it and make it happen as quickly as possible. This is not saying that changes late in the game don’t impact scope – of course they do. It’s the Product Owner’s job to understand the impact of changes on other items in the product backlog, and communicate those impacts to stakeholders. It the PO’s job to say “of course we can change this if it’s more important than the other things in the backlog, but we can’t do everything without impacting cost. What is most important to you?”

So, where to start?

If you teams are using Scrum, then you are well on your way as Scrum has great change management processes built right in. The key with Scrum is to have an empowered Product Owner that knows how and when he/she needs to gain higher level approval for changes. If you have a mixed environment of waterfall and Agile methodologies, or anything in between, then it’s likely best to start with an honest assessment of what issues need to be solved. Do you really need a form and a new process, or are there others issues that need to be addressed as well?

A next step is to understand how requirements are gathered and approved for the system (or each system if you have multiple development projects going on). In Scrum, this is the process of maintaining the product backlog. During this step it’s important to realize that not every change process has to function exactly the same. It’s not practical to manage a $50 million dollar ERP the same way as you manage changes to a $500,000 simple web application. Remember the barely sufficient concept I discussed earlier. Barely sufficient means different things depending on the scope of the project. Don’t fight this – embrace it and choose a process and documentation that makes sense for the project. Remember that these are simply tools to develop working software faster, not things that add value to the business. Whenever possible use automation and stay away from stand alone documentation like Word documents on a common drive. Why? Word documents can’t be sorted, filtered, etc. and they are a pain to maintain because they quickly become out of date. They also have a way of being too long…and guess who will read them? You guessed it – no one. If you have SharePoint, keep your backlog in a list. If you have Jira, then use Jira. Keep things simple. Keep things prioritized.

If management needs a view into requirements, then host product backlog or product roadmap review meetings to share this information. Ideally, this information is already available for anyone to see, but if not then there is nothing wrong with hosting a meeting or two (perhaps every quarter to review the roadmap) to keep leadership informed. However, it’s critical for leadership to realize that these backlogs and roadmaps have already been prioritized by the customer.

Finally and probably most important is to just START. Start…BUT…realize that things will change and ensure regular retrospectives are taking place to make adjustments when they are needed. Embrace these changes and your end product will be much more valuable than if you don’t.