The Money Files

How do you go from someone high up in a position of authority saying it’s OK to begin the work through to the individual team member knowing that it is OK to start a task?

That’s where different levels of authorization come in. This is important for projects using earned value management, because there are often formal approaches that require formal approval and sign off in order to accurately track performance.

According to the Practice Standard for Earned Value (2^nd edition, 2011) there are four steps that are typically used to authorize the work:

1. The project manager receives authorization for the work to begin
2. The project manager authorizes each manager to begin work (typically, the control account manager)
3. There might be an authorization level which is where the CAM gives approval for the functional manager to begin work with their team, but it depends on the individual processes and the scale of the project
4. The team manager authorizes individuals to get started.

That seems like a lot of authorization, but it doesn’t need to become a bureaucratic of long-winded process. An efficient process wouldn’t take much time at all. You simply need to know who to inform and what to tell them, and the people responsible for doing the work need to have a clear brief of what to do so they can get on with it

The infographic below sets out the flow of authorization, and you’ll see that I’ve streamlined two of the bullets above to make it easier to follow.

How do you authorize work in your organization? Is it as structured as this? Let us know in the comments below!

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.

6. ETC

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

The risk management process is helpful for more than simply sorting out your risks and stopping potential problems (and, I know, capitalising on the positive risks). Did you know it also contributes to managing expectations and dealing with a culture where talking about bad news has everyone running for the hills?

In this video I explore the hidden benefits of risk management and how it can help you keep everyone on the same page. Plus, we talk about how sharing risk info can contribute to a positive workplace culture where it’s OK to bring up worries and concerns.

There’s more in the video.

What do you think about this? What other hidden benefits of risk management have you seen while working on projects? I’m sure there are more unforeseen positives to holding risk workshops and talking about risk with the wider team! Let me know in the comments.

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.

Inputs

There are three inputs to this process:

• The project charter
• The responsibility assignment matrix (RAM)
• The schedule baseline.

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:

• The base budget
• The management and contingency reserves
• Distributed and undistributed budget
• Summary level planning budget
• Control accounts
• Work packages and planning packages.

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.

Outputs

The outputs from this process are:

• Project budget – obviously, because you’ve spent this process creating it
• Project funding requirements – because you use the cost estimates to come up with the overall amount you need to request (you’ll use the budget info for this)
• Project budget log – if you didn’t have a template set up before, you’ll have one now
• Control account plans (CAPs) – basically, a plan for each control account.

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

So you’ve created a great risk log, worked out what your risk responses are going to be and made a plan to get those actions done. But how do you check whether your risk response plans are having the desired effect?

The thing I see a lot of project managers doing – especially early on in their careers – is setting up the action plans for risk management and then not going back to check that the risk is actually being addressed. It’s one thing to ask people to take action. It’s another thing entirely to check they’ve done it, and to make sure that the actions you planned have actually addressed the risk in the way you want.

The thing with risk is that even if you do address it with an action plan, you might still end up with residual risk – potential problems left over after you’ve done your ‘main’ actions. And you need to understand what those residual risks are and what (if anything) you are going to do about them.

Last time in this occasional series on project risk management, we looked at how you implement risk responses. Today we’re looking at the monitoring part: the step in the risk management process where you double-check to make sure that your action plans are effective.

What to look for

The point of doing this process (the Monitor Risks process) is to make sure that the current level of risk exposure, taking into consideration any actions you are doing, is still OK overall. You’re looking for new risks, changes in risk status (because some might be getting more serious or less impactful for your project).

Also look out for:

• What assumptions did you make about project risks that need a review? You might have more information now or you may need to include new assumptions.
• What risk management policies do you have and are they being followed? Would it help to update or revise procedures in some way?
• Are stakeholders still happy with the level of risk? The overall level of risk might change (and often does) as the project progresses because more risks are uncovered and that shifts the balance. Check in to make sure you are still in line with stakeholders’ expectations.
• How much contingency or risk management budget is left? Is it being used in the way that you expected? Do you need to ask for more and if so, how are you going to justify that?

Inputs

The inputs to this process are:

• The project management plan, and in particular, the risk management plan section
• Project documents including the issue log, the lessons learned register, the risk register (because this is where you will have written down what you are supposed to be doing) and risk reports (if you create them – I typically don’t, I just write down the details in a column on the risk log)
• Work performance data and work performance reports – in other words, have the action plans been implemented?

Tools and Techniques

The tools and techniques for assessing whether the action plans have had the impact you expected are going to depend on how you can judge success.

However, there are some common things you can do to review and the kinds of tools and techniques you can use include:

• Data analysis techniques like technical performance analysis (to compare what you have done against what was planned in a tangible way) and reserve analysis (to see how much money you’ve got left).
• Audits - my recommendation is that you get an impartial person to run this for you instead of trying to review your risk processes yourself. Ask the PMO or a trusted colleague.
• Meetings (because who doesn’t love a good meeting to discuss all the things that might go wrong on the project?)

Pick and choose the tools that will let you assess the impact of the risk (again) to see if it’s all squared away or if there is more you can do.

Outputs

The outputs of this process are:

• Work performance info
• Change requests (because your new plans might involve adding or removing tasks to your project schedule, for example, to do a few more risk response actions)
• Project document updates, especially to the project plan, assumption log, issue log, lessons learned register, the risk register and risk reports
• Organizational process assets that might need updating e.g. risk template or your IT system, workflows etc.

Another output is doing the tasks to address the residual risks or any other actions you’ve uncovered to make sure that the risk responses are getting implemented as planned.

This process is something you can do on a regular basis. I put time aside in my diary to do a review of risk, normally once a week as I’m updating my project documentation. Then once a month I’ll try to work a risk conversation into our project team meeting – sometimes we only talk about one or two risks, the ones that are the most important at the time or that are likely to happen soon.

Use your judgement – this process is only there to prompt you to constantly keep your risks and management activities under review. If you keep risks front of mind, you’ll be fine.

Pin for later reading