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?
The first process detailed by the Earned Value standard is ‘Organise Project’. Basically, you can’t run earned value management on your project if your project is a disorganised mess. But it also means more than that: you have to have an understanding of scope so you can split the project into work packages that make sense and can be tracked.
How do you work out the scope?
The easiest way to work out the scope of the project is from the charter: this outlines what you were tasked with doing. The requirements documentation will also have useful information.
However, that’s all likely to be quite high level. To get to work package level, you have to use decomposition. All this means is breaking down big chunks of work into smaller sections until you get to a level where it’s possible for someone to take responsibility for managing the thing.
This is how you create the work breakdown structure: take the high level requirements and decompose them, structure them, into something that gives you a logical overview of what is happening on the project.
You might think it’s not worth starting at the top and breaking it down. Why not start at the bottom and build it up? I suppose either works fine. For me the default would be to start with the big picture because then we make sure that what we build meets that need. There’s a chance that if you start at the bottom and build up, what you actually end up with isn’t quite what was asked for. However, do what works for you: as long as you end up with decomposed work packages (as in, broken down, not mouldy), then you’re good.
The WBS is linear, in that the branches don’t twine together. Once you’re on a branch, you stay on that branch, and all you are doing is breaking the work down further and further. How do you know when to stop? I say that’s a judgement call. The work package size needs to be controlled enough for someone to feel like they can get their arms around it and lead it, but not so detailed that you are creating a ton of WBS paperwork for something that ends up taking a couple of hours.
How to represent your WBS: diagram or list?
When you see WBS info in textbooks, and indeed, in the EV standard, you’ll see it as a picture; a kind of tree diagram or hierarchy chart. Personally, I don’t think in pictures so I prefer to create a numbered list. I love the fact that my scheduling tool of choice will add in the WBS numbering automatically as I create the list. Creating your WBS directly into your scheduling tool is not (in my view) a great practice, but it works for the kind of projects I do as they are generally pretty small at the moment.
Your project is organised
The end result of the first EV process is that you end up with a WBS and some other scope documentation that fleshes out what you have agreed to do, like the scope statement and a plan for managing scope should things change. If you’re going down the route of preparing a ‘proper’ WBS instead of a simple numbered list of tasks – which is necessary if you are handing work packages over to teams to run with – then you’ll also have a WBS dictionary which is the text part that adds detail and colour to the titles on the WBS diagram.
All this forms your scope baseline: the official statement of what it is you intend to deliver. The important thing to remember is that you do not create this alone – just don’t! Scope needs to be created with input from technical experts because you don’t know what you don’t know. Even if you think you are an expert in the subject – or you were at some point in your career – the people doing the work need a say in what they are doing so they can start thinking about how best to do it. Collaboration is your friend: yes, it takes longer but the end result is a project that everyone can buy into, and that will save you a lot more time in the long run.
Setting up your project for success with a solid scope is important all the time, but if you are going to follow the EV standard, it’s essential. You can’t measure project performance unless you know what you should be performing!
Pin for later reading
We need to measure project performance to see if the project is on track.
The graphic below shares some ideas on the different ways you can measure work performance. None of these suggestions is better than any other – they are all appropriate for different projects, environments and levels of project management maturity.
Do you use any of these approaches to measure progress on your projects? Why (or why not)? Let us know in the comments section below!
For more on this idea, and a bit more background on the performance measures, check out this article:
In this video I share 3 tips with you to help you feel more organised for the coming week. These are quick(ish) things to do on a Friday afternoon, or the last day of your working week. I use these tips myself and they help me waste less time overall. I hope they help you too!
Read more here: http://www.projectmanagement.com/blog/The-Money-Files/7537/