Control account plans (CAPs) are detailed plan for each control account. If the term control account isn’t familiar to you, you probably aren’t using earned value management. The CAP is part of EV and it describes the work that goes into each formally defined chunk of the project. The project is broken up into control accounts for the purpose of controlling the work and monitoring earned value.
So if that’s the way you are managing project performance, what goes into a control account plan?
Honestly, if you are working in a formal earned value environment on a project where EV is the prescribed way of managing performance, you probably have templates within the PMO that you can use to create a control account plan.
However, if you are someone who has just started working in a formal EV environment – let’s say, you’re a functional manager who is now contributing to a project using EV – then it might help to know what you are looking at when your project manager hands you a CAP and either asks you to fill it in or expects you to be able to understand it.
The PMI Practice Standard for Earned Value has a small section in about what goes into a control account plan, and if you are new to EV, I recommend reading the standard. It’s surprisingly easy to read and contains worked examples along with plenty of graphs and charts, so with a bit of perseverance you’ll have a decent theoretical knowledge in no time.
Six things for your CAP
So let’s say you’re looking at a control account plan for the first time. What would you expect to see in there?
1. The name of the control account manager
Someone is responsible for the control account. It is normally one person who takes ownership of a control account and ‘runs’ it. They should be named in the document.
2. What work is required
There should also be a section that describe the work to be done. How you do this is up to you, but it needs to be detailed enough to help people understand what’s required. You probably have some other kinds of requirements documentation as well, and I don’t think it’s necessary to reinvent the wheel in the CAP. If it was me, I’d link out to any existing documentation and just include a summary, but best be guided by whatever templates exist in your organization.
Pop your statement of work in the documentation.
3. The dates
Drop your key milestones into the CAP.
4. Work packages
Work packages are derived from the WBS. They should include the scope of the work, the schedule, and the budget for the tasks covered by the control account.
Again, if you’ve got full WBS and work package documentation elsewhere, it seems silly to copy/paste it all in your CAP and you don’t need to.
The CAP often looks like a spreadsheet, with work packages down the side, the key EV measures like PV and AC) in columns next to them, and dates across the top. Drop the numbers into the relevant cells and update the CAP as the work progresses. It’s a way of keeping track of performance over time.
5. Planning packages
Planning packages are covered by the CAP as well. The same approach for the work package applies: include the scope, dates and costs for the tasks within the planning packages covered by the control account.
The CAP should also include the estimate to complete. Time-phase it. This can be included as another row in the spreadsheet, per work package.
As I understand it, the CAP needs to be a living document, updated regularly with the EV metrics like planned value, earned value, actual cost and estimate to complete, so that you can track performance at control account level.
The Practice Standard includes a snapshot of what one might look like, filled in with some of the data to represent a project in-flight. I’ve made my own template in Excel, drawing from that.
However, it strikes me as something that an EV management system could do perfectly well. As long as the structure was set up correctly and the tasks within the control account were adequately identified, there’s no reason why software tools couldn’t pull out the figures and crunch the data on behalf of the control account manager.
If you do need to set it up manually, hopefully you now have an idea of what it should include, but talk to your EVM experts or your PMO and see whether you can create the plan as a standard report from within your EV tools to save yourself a fair bit of time each month.
Pin for later reading
I’ve been working my way through The Practice Standard for Earned Value in an attempt to really get to grips with the nuances of EVM. It’s one thing understanding the high level principles, but another to understand the individual processes and how everything fits together to give you a rounded process.
The Establish Budget process is a way of converting what you need to do the project (equipment, resource availability and so on) to an actual budget that you can track against and use during project execution. Note that at this time we haven’t actually started the project yet, we’re still planning out how it’s all going to happen. Now is the time to plan out how much our activities are going to cost in a way that aligns with the EV principles.
The Practice Standard doesn’t go into a lot of detail about how to document your budget, so you can choose a technique and a software tool that works for you. Typically, EV management systems need a ‘proper’ financial management and accounting tool that links into the resource management software, so a spreadsheet isn’t really going to be enough.
See what provision is made within your EV set up at work and make sure you are creating your budget in the right tool so it can provide information to the software used for reporting and analysis.
There are three inputs to this process:
The RAM takes the WBS and organisational breakdown structure (OBS) and converts that into a matrix that covers who is managing what control account and who is doing what WBS element. You need these control points so individuals are clear about the estimates and resources for everything on the schedule, so it’s really important to get that right.
If your schedule baseline is rubbish, then your EV data will also be rubbish. It’s so important that the inputs to this process are good quality, otherwise all your numbers will be wrong. Your budget baseline and schedule baseline can be iterated together, but they need to be robust and based on decent information so that you end up with sensible reports at the end.
What to do
There are four steps to creating your budget:
1. Establish the budget structure
This means listing out and understanding the different elements that make up your budget, including:
Once you’ve got your structure sorted, you can move on to the next part.
2. Develop the cost estimate
Next, for each relevant component (the work packages, planning packages and the summary level planning budget) develop estimates.
Estimate at the correct level for the element and as accurately as you can. Control account budgets need to be linked to the time frames for the work, so that’s how the progressive elaboration of the budget and schedule come together.
3. Authorise the work
Next, there’s a formal approval step. This gives the control account owner permission to begin the work.
4. Update the budget log
Finally, update your project management budgeting tool to show that the budget is moving from undistributed i.e. not authorised for work to proceed yet to distributed i.e. linked to a control account that is underway.
That might be a very simple exercise because you’ve allocated everything out at the beginning, or you might be approving chunks of work as you go so some budget is held back until it’s approved.
The budget log is just a way to track what’s been approved for spending so far.
The outputs from this process are:
It’s important to note that EVM uses ‘budget’ and ‘funding’ to mean two very different things. The budget is defined in the Practice Standard as ‘a work planning element that is earned’ when the work is completed. It’s not really the same definition as we would use in a non-EVM setting, such as when someone asks you what your budget is for your next holiday, or what you budget for your food bill each week.
Funding is used to mean the amount of money ‘available to accomplish the work’. This is what I would normally consider to be a budget in a non-EVM project where control accounts aren’t part of project performance management. In the EVM world, funding relates to what you are actually authorised to spend on any given chunk of work.
It’s a useful definition because it keeps the earned value part of performance management separate from the money leaving the bank account, and allows you to manage any conflicts that arise, when, for example, you don’t get approval to spend all the money that has been requested for any given control account.
I learned something new on this dive into the Practice Standard today. What about you?
Next time, I’ll be looking at the next process in the earned value management standard, which is determining measurement methods.
Pin for later reading
The Practice Standard for Earned Value sets out the Develop Schedule process, which is simply a way of turning all the stuff in your WBS into a workable plan with timescales. Basically, it’s time to turn the WBS into a Gantt chart.
I guess you could use earned value for non-Gantt chart scheduling, but I can’t get my head around how that would work (tell me in the comments if this is something you do!).
The Practice Standard doesn’t go into loads of detail about how to make a project schedule, as there are other places you can go for that information – like the Practice Standard for Scheduling and also the PMBOK® Guide. However, the particular earned value bits of scheduling are covered in the EV standard, and especially this process.
There are two inputs to this process:
The scope baseline is more than just the WBS. It also includes the scope statement and the WBS dictionary, so it’s the full set of documents about project scope and the full understanding of what the scope is. It’s the exact spec to a level of detail that allows someone in the team to get the work done.
The resource breakdown structure is the comprehensive guide to who is working on the project as well as the other, non-people, resources required to get the job done.
What to do
The Practice Standard is light on the ‘how to schedule’ element, as I mentioned above, but from a specifically EV perspective, here’s what to take into account:
This last part is particularly important because it’s the way the schedule and budget relate that drives the EV calculations. You need the same dates, milestones, assumptions and resources set up in each so the measurement is consistent between both systems. In other words, you need to be sure that the work being done is accurately accounted for so that you are working out the right planned value.
Finally, get your project schedule approved the normal way and it then becomes the schedule baseline, against which you can track progress and monitor performance.
The output for the Develop Schedule process is only the integrated master schedule, as you would expect.
The ‘master’ part of the IMS, as I understand it, is a way of referring to the fact this is the top level project schedule. The control account managers may have detailed sub-plans for their parts, and you might have intermediate level plans, depending on how complicated the project is. But the IMS – the master schedule – is the full picture of everything required to get the project done.
Dealing with changes
As with any aspect of project management, we have to allow and account for what happens when things change. It’s great to have the IMS as your overarching master schedule and performance measurement baseline, but it’s unrealistic to think that we’ll deliver everything perfectly to plan because that isn’t what happens in real life.
So, we need to use the change control process as and when needed, to make sure the whole thing stays aligned to actual performance. That’s not to say you’ll be re-baselining the project every day, but you will keep the schedule up to date with real progress to compare back to the original baseline, and then re-baseline if and when that becomes appropriate.
If you make schedule changes, you also need to consider what that means for the project budget. When using EVM, you can’t get away from the fact that the two need to align – that’s the point of this way of project tracking, after all.
The IMS exists as a way to outline what the team is planning to do and it gives you the logic for measuring performance. It’s important to get it as good as it can possibly be because it’s what future progress will be measured against and it’s used for calculating future outcomes – and you should want those to be as accurate as possible.
Next time, I’ll be looking at the next process in the earned value landscape, which is establishing the budget.
Pin for later reading
I’m surprisingly enjoying my deep dive into earned value management – it’s not a technique I would say I’m hugely experienced in, but it’s something I’m committed to learning more about.
In this infographic I summarise the 5 limitations of earned value:
What other limitations of Earned Value have you come across as you’ve used it? Or perhaps you aren’t using EV because of another limitation that is stopping you from embracing it in your environment? Let us know in the comments below!
The Practice Standard for Earned Value sets out the Assign Responsibility process, which is simply a way of making sure everyone knows who is doing what. It’s important in earned value because you need someone to take ownership for every piece of work – that’s the best way to track at each individual element of the work breakdown structure.
There is only one input to the Assign Responsibility process and that’s the scope baseline.
What to do
Assigning responsibility isn’t a great name for this process, because ideally individuals in the team will volunteer for the responsibility, knowing that it is part of their job role. I prefer to allow people to step into the responsibility rather than forcing it on them, because I think you gain better buy in and results that way.
However, sometimes I have been known to specifically say, “So I’ll write you down as the owner for that task?” and call out someone as the individual responsible, in a nice way.
Assigning responsibility is about more than someone knowing it is their job to do the work. It’s also about making sure everyone else knows that it is their role, and that it is officially documented somewhere. That’s what this process does.
Create an organisation structure for the project. I tend to do that in PowerPoint, simply making a structure chart with names on that I can then drop into the relevant project documentation. You might have to create several ‘layers’ of your chart so that everyone responsible for substantive pieces of work for the purposes of EV tracking has their information documented.
The Practice Standard recommends that you take the list of people responsible for things and map them against the WBS to create a matrix instead of using an org chart structure. That certainly gives you more granularity and makes it very clear who is doing what.
The outputs for the Assign Responsibility process are:
The RAM matrix is a bit different to the traditional RACI matrix because it lists the work packages from the WBS across the top and then the teams or individuals down the side. Look at the relevant intersections and where they meet, put a cross to mark the fact that this person (or team) is responsible for this part of the WBS.
Each X marks a control account: an area of work that is going to be tracked and managed by a control account manager. This is the team leader responsible for doing the work, but CAM is the term used in the world of earned value.
How detailed should you make the plans?
There’s no right answer to this. The WBS and the OBS should be as detailed as necessary to get the job done. Go down to the right level for your project – you’ll have to use your professional judgement for this.
Ideally you are looking for control accounts to be at a level of complexity and scale that makes it possible for them to be managed adequately by one person. Too detailed, and you’ll end up with people responsible for fragments of work and so many control accounts that they are hard to manage in their entirety. Too few and the CAMs won’t truly be able to control the work within them as the tasks will rely on too many people or activities outside of their control.
Plus, think about how much time and energy you and the CAMs have got to dedicate to the admin of running a low-level, detailed plan. Do you really want to take on the management of a lot of tiny things? Isn’t there some saving to be had in combining a few more work packages and making your control accounts sit at the next level up?
Ultimately, you’ll have to make the call but don’t make it too hard for yourself or your team.
You might be thinking: that’s all very good but what happens when things change? Well, things always change, and you have to be alert to that. Respond to changes as and when they happen, using the change control process that you’ve adopted.
Make sure that the CAM impacted by the change (or group of CAMs if there are several) know what has changed and what that means for their work. Update the documentation accordingly. That assumes that you know about the change before the CAM – and sometimes that won’t be the case. They’ll be coming to you with suggestions for changes, so in that case, push them through the change control process and update the rest of the team as appropriate.
The Assign Responsibility process is really all about making sure people know what falls into their remit. If you work with an experienced in-house team, you probably won’t have much difficulty here. If you work with contractors, sub-contractors or external suppliers, make sure that the boundaries of their work are clear – this process helps formalise all of what you should be doing already.
Pin for later reading