The Money Files

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:

• Assess the change
• Approve the change – in my experience, if the project team and project sponsor has already approved the change, there are few reasons why the CCB would then block a change
• Schedule the change
• Keep records about changes.

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.

Scheduling changes

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:

• Bug fixes
• Issues that affected customers
• Changes that went in and then didn’t work as expected.

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.

Read more about who gets involved in contracts.

Benefits realisation management is one of the hardest things to do in a project setting (in my opinion) and in this video I explain why. I talk about three things that make it harder and give you a few tips on what you can do instead to help get over some of the challenges. The three things are:

• Low skill levels
• Poor integration
• Poor processes.

Watch the video below and then let me know whether you’ve seen any of these challenges in your organisation!

There is more detail in this article: 5 Barriers to Effective Benefit Realisation that draws on information from Carlos Serra’s PMI presentation on the topic.

It’s time for the sixth and final part of our look at the Scope Management Knowledge Area from the PMBOK® Guide-- Sixth Edition. We made it! Thanks for sticking with me to the end on this one. It’s a process with a lot of moving parts!

You can find the previous parts of this series here:

• Plan Scope Management
• Collect Requirements
• Define Scope
• Create WBS
• Validate Scope

The Control Scope Process

As we’ve just seen, this is the final process in the Knowledge Area. We are still in the Monitoring and Controlling process group.

The point of this process is to manage changes to the scope baseline as you go through the project. The purpose is to ensure you’ve got clarity about what the project is going to deliver. You’ll do this process as you go, at various points through the project life cycle. Basically, whenever there is a possible change to scope. In fact, you might not need it at all, on a simple project where the scope doesn’t change.

That’s possible, but unlikely! I don’t think I’ve ever worked on a project where the scope at completion has been identical to the signed off scope as part of the Project Charter… but I’m sure it does happen.

You have to use this process in conjunction with the Perform Integrated Change Control process. This process ensures the changes and actions go through that process. Plus, Control Scope is also used to manage the changes once they’ve been approved, and because of that it’s got links to all the other Control processes.

Inputs

We’ve got the same changes to this process as we saw in Validate Scope. Basically that means requirements documentation and the traceability matrix is out, and the generic ‘project documents’ is in. Therefore, the inputs to this process are:

• Project management plan
• Project documents
• Work performance data (e.g. documentation about the number of changes received and processed – reporting your PMO might find useful about how the project is handling change, as the frequency and type of change can tell you quite a lot about the stakeholders and how the project is being managed)
• Organisational process assets.

In this context, project documents could include the lessons learned register (because at every point in the project you can learn from what’s gone on before), requirements documentation (obviously) and the traceability matrix.

Tools & Techniques

There was only Tool and Technique in the Fifth Edition: variance analysis.

That’s gone. And now we have the broader term, data analysis. Which includes, surprise surprise!, variance analysis. And also trend analysis which looks at project performance over time. If a project is getting more and more changes as it progresses, that can provide useful information about the quality of requirements or how under control the work actually is.

Outputs

There’s a tiny change to the outputs of this process.

The outputs are:

• Work performance information
• Change requests
• Project management plan updates
• Project document updates.

Organisational process assets has dropped off the list.

The thing with scope changes is that they affect so much. Anything that goes through change control can have a fundamental impact on the project so you’ll want to update all the records to make sure you’ve got accurate notes about what you’re now doing and why.

So you might update the scope management plan, the baseline, the schedule baseline and cost baseline. On top of that, you could be updating the lessons learned register, requirements documentation and that traceability matrix.

Frankly, it’s easier if the scope doesn’t change! But as it is almost guaranteed to change at some point, you need to be prepared to put the work in to update all the documentation and tell everyone what’s now going to be the new approved scope.

And that brings us to the end of this process, and our trip through the world of Scope Management.

Pin for later reading:

It’s time for part 5 of our journey through the Scope Management Knowledge Area from the PMBOK® Guide-- Sixth Edition, although it does feel like once I’ve got through the whole PMBOK® Guide we’ll be on the Seventh Edition, as I know that will be with us before we know it.

Anyhow, today, we’re looking at the Validate Scope process.

You can find the previous parts here:

• Plan Scope Management
• Collect Requirements
• Define Scope
• Create WBS

This will be a super-short look at the process, because there haven’t been many changes and it’s a pretty simple process.

The Validate Scope Process

This is the fifth process in the Knowledge Area. We have moved from the Planning process group to the Monitoring and Controlling process group.

What we’re doing at this point in the project is formalising the process of acceptance. As we’re in Monitoring and Controlling, we’ve got to the point in the project where something has been delivered. Now we have to check whether we’ve delivered the right thing.

Basically, you review the deliverable with the person responsible for approving it, and receive formal sign off. When you’re doing this process in real life, it’s likely to overlap with with the Control Quality process, because you have to check the deliverables match the defined quality standards before you ask a sponsor to sign them off.

So now we know what this process is all about, let’s look at what we need to perform it.

Inputs

There isn’t much that has changed from the Fifth Edition. Instead of requirements documentation and requirements traceability matrix, we just have project documents. No biggie. That means the inputs to this process are:

• Project management plan
• Project documents
• Verified deliverables i.e. ones that have been through the quality processes
• Work performance data – personally I think it’s a bit vague as to why you would need this, but it could overlap with quality requirements and the example given in the PMBOK® Guide is that of documenting number of validation cycles and nonconformities. So you could find it useful in a discussion with a project sponsor, I suppose.

Tools & Techniques

Group decision making techniques has dropped off the list of Tools and Techniques, to be replaced by generic decision making (which includes, of course, techniques for groups to make decisions like voting).

Personally, I can’t think of many (any?) situations where my project quality would be assessed by vote. The deliverable either meets the criteria or it doesn’t. However, the PMBOK® Guide does list voting as a way to reach a conclusion when “the validation is performed by the project team and other stakeholders.”

Alongside that, we also have inspection (as previously in the Fifth Edition).

Outputs

Once again, there are no new or changed outputs to this process.

The outputs are:

• Accepted deliverables
• Work performance information
• Change requests
• Project document updates.

Of these, the most important for me is the accepted deliverables. The formal documentation for sign off of a deliverable is used later in the process for closing down the project, because you can’t close a project if the deliverables haven’t been accepted.

Next time I’ll be looking at the sixth and final process in this Knowledge Area: Control Scope.

Pin for later reading: