Do you have a formal Change Control Board (CCB)? If not, this is the perfect time of year to be thinking about levelling up your processes and putting new ways of working in place to formalise the way change management is done across projects, programmes and the portfolio.
A Change Control Board is simply a group of experts that represent different organisational departments and who oversee both the process of change management and the different changes being put forward.
At a project level, your CCB is a group of people who know the project well and who can assess project-related changes, but at some point if your project is making changes to the live environment, like most IT and business change projects do, the change will need to be submitted to the wider, department or organisational CCB.
The role of the CCB is to:
How it works
In our CCB, the functional lead or the project manager had to present the change. We had to talk about what it was, why it was useful and what it solved, and then make the case for whether it was a priority fix or not. If the change was considered a priority, it could go in the same day (mostly). If it wasn’t, it could be packaged up with a bunch of other small changes and go in the next release.
That made it easier to communicate changes to the end users.
Discussing the change
First, the change should be analyzed and discussed to see whether it has impacts beyond what the project team can comment on. The Change Control Board is convened to do that. I think the CCB is a really useful group and we relied on it in my last job. Our CCB looked at operational and project changes so the team could see the impact of ‘normal’ changes as well as the project-related ones.
I think it’s important that the CCB is made up of a cross-organisation group. It’s too common for changes (especially IT changes) to go in and for there not be a full understanding of the business impact somewhere else down the line. Complex ERP systems like SAP make that more likely, so a group of functional consultants getting together to discuss changes before they happen is a good thing.
I’ve had some changes rejected by the CCB because they didn’t have enough information to make an informed decision, or because something else was going on and they needed to wait on that, or because there was a change freeze. There might be many reasons why your change doesn’t go through.
The CCB can also schedule changes. There are normally scheduled windows to put changes in, especially in the live IT environment. That helps the support teams and the users know what is going to be different and what to look out for when they next log in.
Scheduling as a team also ensures that conflicting changes don’t get put in on top of each other. For example, if my project is updating the list of available categories in one part of the system, and another team is also updating that part of the system but taking away the category feature (that’s a bit extreme, but you see what I mean) then those conflicting changes can be discussed and overseen in an appropriate way.
It might involve putting them live in a particular order, or prioritising the changes so that one piece goes in this time and the additional change is put in next time.
I remember being told a story of a change in a data centre where engineers were working on cabling and flooring on both sides of a server stack. Without the support of flooring on both sides, the server stack toppled over! That’s the importance of making sure that changes are managed in a scheduled and sensible way.
We also had an emergency change procedure for anything that could not wait until the next release. On the SAP projects, for example, mostly things could be scheduled in a batch and changes pushed through on a fortnightly basis. But sometimes it was important to fix an issue straightaway without waiting until the next release. For example:
All of these are emergency fixes to live systems that wouldn’t be appropriate to delay, and they are all issue-related, not nice-to-have features.
How does your CCB work?
Q1 tends to be a time when new budgets are approved and that means we’re starting to see requests for contracts with suppliers trickle through the PMO. It always takes a few weeks for budgets to get released, even if the intention is to start the work in January. By February, project teams are ready to get started, knowing that any further delay in the admin is going to put pressure on their ability to deliver by the dates from the business case. And that’s why all the supplier agreements seem to be floating around at the moment.
The infographic below talks about the major groups/people involved in putting together and approving supplier contracts for new third parties, but it’s the same people involved in renewing deals and reviewing an existing supplier to see if we want to give them more work.
As with any internal process, this is probably a bit specific to certain environments and types of contract, and you might not see all of these roles in your business.
Equally, there might be some other key positions that have a part to play – I know that in one set of contract negotiations for a multi-million software project, my project sponsor attended every conversation, along with the technical architect. And just as well they did too: it created a great sense of common purpose and everyone was on the same page from the beginning.
Take the suggestions below as a starting point for opening up the conversation with your colleagues if you are creating new supplier agreements, so you can make sure the right people are involved from the start.
Your sponsor has asked you to get the work done faster… who hasn’t been in that situation?! That’s one reason why you may want to crash your project schedule, but there are others. In the past, I’ve written about 7 reasons to crash the schedule, and in this video, I pick out my top 5 to discuss in more detail. I talk about schedule compression (obviously), when part of the project has the potential to put the overall project at risk, when you’ve got a fixed deadline, when the team is needed for other work and when there’s a general delay which affects your ability to hit your expected deadlines. Crashing can help in all of those situations, used sensibly. Engage professional judgement before you go for it!
What are your thoughts on crashing? Personally, I try not to do it too often because it’s a lot of effort and it doesn’t always give you the results you were expecting, but it is a useful skill in the toolbox for predictive project managers, so it’s worth knowing when you would consider to use the technique.
What spreadsheet package do you use? Personally I use Microsoft Excel, although I do have Numbers on my iPad I case I need to look at a spreadsheet while I’m out and about. I sometimes use Google Sheets for personal projects as well, but I’m not massively comfortable with it.
Regardless of what tool you use, spreadsheets are a huge part of life as a project manager. Whether you are exporting data from an enterprise project management tool, creating a budget forecast or using filterable lists as a way to manage tasks, risks or issues, spreadsheets have so many uses in project management.
Here are some tips to make using spreadsheets easier – all tried and tested by me and colleagues over the years!
1. Add Notes and Comments
Add notes to your spreadsheet so you know how the formulae work and what estimates were based on.
You can do this by adding a separate tab to record notes, if there are a lot of them. I record the way I formulated an estimate for the budget, and what the figure includes, plus any assumptions around resource time and so on.
For short notes, I add them as a comment on the relevant cell. This is the easiest way to note when a cell was updated, or to record what was in the cell before you changed the estimate to be something else.
2. Add Version Control
Learn how to do version control on your documents (where version control is not added automatically by your software). Then add a tab to the spreadsheet showing a table with version control numbers.
When version controlling a spreadsheet, don’t try to add an incremental version number every time you update something. That would be time consuming and not add any value. Instead, do a major version update every time something substantial changes, such as changing major formulae or rebaselining. You’ll get a feel for when it’s important to create a new version.
3. Freeze the Top Panes
Project management spreadsheets can get quite large. In Excel you can freeze the top and side rows so that you can scroll through the spreadsheet and the headers stay in place. It makes reading and moving around a big spreadsheet much easier because you don’t lose the column and row descriptors.
4. Lock Cells
Use the functionality of your software package to lock cells that you don’t want other people to update. For example, in a status tracking spreadsheet, you might have cells that you need to have populated with ‘Open, Closed, On Hold’ etc.
You can fix the spreadsheet so that only those options are permitted. You can also lock cells so they can’t be changed, which is helpful if you have a form and you only want to allow people to enter information in certain places.
5. Add Conditional Formatting
Conditional formatting means the cell colour (or whatever section you choose) updates based on a rule. For example, if the contents of the cell is a number less than 50%, make the cell turn red. This is achieved using a red background fill. You can change the text colour, or use other formatting rules.
This is helpful when you have a large data set and you want to instantly draw people’s attention to figures that are outside the acceptable norms. You can colour code information as red, amber and green by setting up conditional logic once, and adding that formatting.
What tips do you have for making it easier to use spreadsheets? Share your best advice in the comments below!
Pin for later reading: