The Money Files

Time-phasing your budget is not the most exciting part of project management for most people (oh, is it just me??) but it’s so important if you are going to use EVM on your projects. EVM lives and dies on being able to compare PV, EV and AC over time – that’s how you work out whether your project is on track. The performance metrics and reporting are fundamentally based on those measures, so if the data underpinning them is wrong… well, your whole set of EV reports are going to be pretty pointless.

That’s why time-phasing is important. You should be able to pinpoint when the money (and effort) is going to be spent in order to plan out the work. Then your PV (Planned Value, but you knew that, right?) is an accurate representation of the baseline budget and how that is spread over the life of the project. PV is also a major part of the EV calculations, so if you get it wrong, the numbers coming out in your EVM reporting are not going to reflect “real” project progress. And that doesn’t even take into account any errors in capturing Actual Costs.

Normally on projects – at least the ones I’ve worked on that have not used EV – we know the budget, and we might have a broad overview of when that money will be spent. Monthly budget checks allow the team to stay on track, but generally as long as the numbers look OK and we’re still within tolerance of the forecast, that’s enough. In an EV environment, that’s not enough. The budget has to be split over time because that is how you track performance and variances.

Here are some examples of situations where the team might find it hard to get the information correct during the planning phase.

Too many Level of Effort work packages

Work packages are the bread and butter of EV: each work package contains the information to deliver, monitor and control the work, along with time and budget estimates. However, level of effort work packages don’t have any special information: basically, you just split the cost evenly over the work package. This is perfect for activities that are hard to track like ‘project management activity’. I always have difficultly apportioning my time on a project as sometimes it’s more, sometimes it’s less, and I never count the time thinking about the project on the bus or while I’m cooking dinner. It’s hard to truly estimate what it takes to do the project management on a project.

However, if you have work packages that could be tracked differently and are not, because it’s too hard or you are too busy to come up with a better way, then that is going to skew the overall reporting. EV is all about the details!

Accounting for large costs

Let’s say in one work package you need to buy a whole lot of computers. We had to do this on one project and most of the cost was incurred in a single month, because bulk buying is obviously more cost effective than buying PCs here and there throughout the project. I attributed all the costs in the month that we spent the money, but the finance team apportioned the costs across the project evenly based on the depreciation of a capital asset. From then on our reports did not match up. That’s not specifically to do with EV, but it goes to show how different ways of apportioning costs can create an issue with reporting.

If you have a large cost coming up, that’s going to skew your EV reports. Consider the impact that will have and whether there are other ways to reflect that so your performance metrics stay true to reality.

Time management

The simplest situation that creates an issue with EV reporting on a time phased basis is simply not doing the time phasing. For example, you haven’t allowed for there to be more effort required at the start of the project or during project testing, in comparison to the steady state of delivery during the execution phases.

Time-phasing needs to reflect the way that EV is credited to the project too, as not all work packages will use the same approach. I’ve written before about ways of tracking effort, using split milestones (like counting 25% of the work complete as soon as it begins, then 50% when you hit the halfway mark and then 100% when the work is done). If the EV is “supposed” to be phased more evenly than that, you will get blips in the reporting.

That’s quite a simplistic way of explaining it but I’m sure you see what I mean.

Overall the take-home message from today is: make sure your PV is time-phased in an appropriate way that reflects how EV is being credited to the project. Easy, right?

It’s holiday time! I do love December, even though the evenings are now so dark here. Perhaps that’s why it’s so special to be considering things to do to brighten up the mood. Last year was a bit of a wash out in terms of team celebration. We would have normally gone out, and we did nothing (along with the rest of the world). This year, while we’re still a virtual team working from home, perhaps we’ll have the opportunity to organise something a bit more fun. I’m thinking a virtual escape room? There are quite a few that have popped up over the past 12 months and the opportunity to do something together that isn’t work is quite appealing.

The infographic below shows some things to think about when you are planning festive celebrations for your team, if you intend to do something to mark the end of the year. Over here, we can take a Christmas theme, but if you don’t celebrate Christmas, think about how you can join in with the festivities relevant to you – or just celebrate getting through another 12 months!

My top tips are:

Plan early and get your booking in soon as many people this year will be attempting to organise something to make up for last year when teams weren’t able to get together in the same way.

Think beyond meals out: restaurants are one option but there are other things you could consider as a team, like an escape room, for example.

Send holiday cards to your team and supplier. I have digital templates every year that do the job – message me if you would like them.

Include the whole team. If someone on the team doesn’t feel ready to go out into the world yet and meet up in person, then I believe the team should adjust the celebrations to revolve around activities that everyone can do.

Know your tax: In the UK, there is a limit to what employers can spend on team gatherings for the holidays. Anything more than that and there is a personal liability involved for participants, and trust me, no one wants to get taxed on the “fun” office party. Talk to your manager or finance team if you think that’s an issue for you. In my experience, it tends to be a problem if there is a corporate event and you also want to do something as a project team, as that means some people are effectively attending two events.

Have fun! And best wishes for 2022 😊

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.

In Part 1 of this article I talked about two ways to measure discrete effort: percent complete and fixed formula. Today I’m going to share the other two options: weighted milestone and physical measurement.

As a recap, discrete effort is the name given to the work required for an activity that can be planned, measured and ends up with something specific as the output. If you are doing work that directly leads to the completion of a deliverable, that’s discrete effort.

There are different ways to measure this type of work in a project using earned value management, or even in projects that don’t apply EV measures but still need to track progress (like: all of them). I wouldn’t use discrete effort measurement techniques for every single task on every single project, but they are available to you if it makes sense to use them. This is the benefit of tailoring 😊

Weighted milestone

The first one to look at today is weighted milestone. This is similar to fixed formula in that the value is apportioned to the work as the activity progresses, but it’s based on milestones.

Divide the work package into measurable chunks that are attached to and end with milestones. For example, a work package might include a couple of weeks of design work before a document is created. There could be a milestone at the end of the last of a series of design workshops.

When those milestones are reached, the activity earns the progress based on whatever breakdown you have assigned to each milestone.

So how is this different to fixed formula? It’s different in that it suits longer term work packages. Fixed formula is best for short activities, those that don’t stretch over more than two reporting periods. Weighted milestone progress tracking is an option for when your work package runs longer than that.

Ideally, each milestone should be a tangible ‘thing’ as well: some kind of interim result.

Reporting works best when there is at least one milestone within each reporting period, otherwise you aren’t able to tell if work is on track as it won’t have moved since the last report. You don’t get credit for any deliverables leading up to milestones where the work isn’t completely finished. In other words, it’s the achievement of the milestone that triggers the tick in the box, not the progress against the tasks leading up to it.

You don’t have to equally split the work across the different milestones. The ‘weighted’ part of this way of measuring progress allows you to apportion value across all the milestones. Allocate the appropriate amount per milestone, but don’t worry about limiting yourself to a regular split if that doesn't work for you.

Physical measurement

Physical measurement is a way of tracking progress for things that can be counted. If you are working on something that has a specific, tangible way of measuring in a physical way, then this is the option for you.

For example:

• Number of holes dug
• Quantity of concrete poured
• Number of widgets made
• Number of people vaccinated
• Area of hotel grounds landscaped
• Number of computers installed.

If you can measure it specifically in a real world way, then that becomes your measure. You should agree it in advance so everyone knows how the effort spent will be tracked and reported on.

This is the easiest way to measure performance against a task, in my view. If the task is to landscape the gardens at 3 hotels, which totals 15 acres, of which you’ve done 3 acres, you get a pretty good idea of how much there still is to do. Stakeholders tend to understand this way of measuring straight away.  You can also translate the measure into percent complete if you feel the need to represent it in that way.

Do you use either of these two methods for tracking progess on your projects? If not, why haven’t you tried them yet? I think there is a certain ‘comfort blanket status’ that stakeholders attribute to percent complete as a way of monitoring performance against plan, but if we can get them away from that, then other options provide a different way (and often more realistic way) of measuring progress.

Or perhaps this article should be called: 5 pitfalls that can happen when EVM is not implemented the way it should be!

Here are 5 things that can go wrong when an organisation chooses to implement Earned Value Management as a way of working for project performance tracking.

1. There is low organisational support

Possibly: there is no organisational support outside of the PMO. EVM is very much an enterprise-type solution so everyone needs to be on board. The whole organisation needs to know what it means for them as individuals and as a team – and you should try to bust the myth that it’s all complicated maths.

In reality, most of the tools now do all the heavy lifting for you, so there’s no need to be hands on with the maths. However, the project delivery teams are going to need to understand the inputs and outputs to the formulas so they can interpret what the numbers are saying. That’s the secret: it’s making sure the wider team understands that the move to EVM is all about creating a set of essential measures to track performance and improve project control.

2. Thinking of EVM data as the answer

EVM data is simply a representation of current project performance. It’s not a decision in itself. It’s not a set-in-stone forecast that tells you what is definitely going to happen.

The team can still adapt and change, mixing up what they do to shape future performance, preferably in a positive way. The data should be seen as decision support information, helping the team make the right choices about what to do next in order to get the best results for the project.

3. There are poor or no decision-making processes

Pitfall #2 brings us on to this one: EVM implementations struggle when the organisation has poor (or no) decision-making processes. There should be some way of managing decisions as part of project control. Decisions and management responses to situations should be structured and repeatable, not knee-jerk. Proactive action taking is better than reactive ‘let’s just do something and cross our fingers’ type decisions.

EVM data is good, and helpful, and informative but if the project leadership team don’t have the power or ability to do anything with it, then the data is just a set of pretty reports no one ever looks at. Decision makers should be looking for patterns, documenting decisions made and their outcomes so that future decisions can be shaped by today’s lessons learned and building credibility by using the information to improve project performance in meaningful, predictable ways.

4. Limiting EVM to a small group

When EVM is implemented, we talk about it being a whole enterprise thing, and that everyone needs to understand what it is and the value it brings to the organisation (as discussed in Pitfall #1 above). But making it ‘a whole enterprise thing’ actually goes far wider than a communication campaign.

When EVM is implemented, it’s important that the whole team is able to see, input, act on and engage with EVM numbers. They should be responsible for their part of the system. In other words, it’s not a good idea to limit the people with hands on experience to a small sub-group of project practitioners in the organisation. It’s ineffective to ask project managers to provide time sheet information, for example, to the gatekeepers who then load it into the system and provide monthly reports in PDF format.

That leads to a couple of problems. Practitioners feels like they aren’t truly included in the EVM and will probably disengage from it. For them, it becomes one more set of data points to submit to someone else for reporting; something that happens outside of their sphere of influence (or interest). It also creates a culture of auditing, where individuals feel that their work is dissected by people who lack hands on experience. EVM shouldn’t turn out to be a ‘them’ and ‘us’ experience in practice. For best results, it really does need to be a whole team process with plenty of input from everyone. Basically, it needs to become ‘how we do business round here’.

5. Not creating a common vocabulary

Of all the various aspects of project management that require specialist jargon, is EVM the worst? I think it could be. There are all the acronyms (PV, EV, SPI, etc) and formulas. There are control accounts and control account managers (which must make control accounts very important if they have their own managers), plus the terminology that goes along with the WBS.

The benefit of all this jargon is that when it is understood by everyone, it provides a common and clear way of talking about the same things. You avoid the misunderstanding of schedule vs plan, for example, because there is a common language with terminology that means the same thing to everyone. That’s powerful. It’s also good for decision making because clarity of understanding helps execs make the right call.

Next month I’ll be looking at a few more pitfalls from EVM implementations that are not done in the best possible way, but meanwhile I’m interested in your views. What have you seen go wrong with EVM rollouts in the organisations where you have worked? Let us know in the comments!