The Money Files

Expected Monetary Value is abbreviated to EMV, so you may also see it called that.

It’s a concept that took me a while to get my head around, but it’s a useful measure to know when thinking about project cost management and project selection.

The challenge I had with understanding EMV is that it’s a calculation about a probability. I prefer to deal in ‘real’ numbers, like payback period or ROI. Having said that, EMV is a tool out there and in use, so it’s worth knowing more about.

How do you calculate EMV?

One of the disadvantages of EMV is that so much of the calculation relies on professional judgement and expert input. In other words, guessing.

EMV is calculated like this:

Probability x (financial) Impact

Let’s take an example.

You have identified a risk with a 20% chance of occurring.

If the risk occurs, it could cost you £500 to deal with it.

The EMV for this risk event is:

Probability = 20%

Impact = -500

So:

0.2 * -500 = -100

You should make sure there is a risk budget allocated of £100 to help offset this risk.

The challenge I have is that if the risk occurs, it is going to cost you £500, not £100, so you won’t have enough. If the risk doesn’t occur, you don’t need any money.

That’s what makes EMV feel very abstract to me, but I understand that it works better across a wider pool of risks. They won’t all happen, so the money you’ve put aside will hopefully be enough to act as contingency for the risks that do occur.

What do you use EMV for?

EMV is a useful measure to help you work out the contingency funds you might need. As we’re talking about probability and the chance of things maybe happening, you can see that there is a strong link to risk management.

You can also use EMV calculations to help determine the best course of action for risk management. If you have two possible ways to mitigate a risk, which one would give you the best EMV result? Do the maths and that helps you with a recommendation for next steps.

You wouldn’t need to use EMV calculations on small projects. It’s really a technique for larger initiatives where you have a lot of risks requiring financial amounts to manage them. It can help you spread the risk budget between risks.

Do you use EMV on your projects? Is there a better way to explain the probability and why it’s OK to not have the full amount of risk budget in your reserve? Or is it just me who finds this concept not very practical?!

Pin for later reading:

In this video I explain what sunk costs are and why they are so emotive on projects, especially when projects are challenged or no longer viable.

I try to give you some background on sunk costs so that when you’re faced with execs who are looking at sunk costs as a reason to continue with a project, you’re armed and ready to at least debate with them about why that isn’t a good idea!

Pin for later reading:

I think it’s important to understand project requirements.

I get that people want to be flexible and work things out as they go. But if you don’t know where you are going, how do you know if you’re on the right track?

It doesn’t matter to me how those requirements are documented. You can write user stories, or put together a waterfall-inspired requirements traceability matrix.

The important thing is that they are documented. The journey you’re on needs a destination.

Of course that destination might change. That’s what change control is for, or backlog grooming. You pick and choose as you go, being flexible and making alterations that mean you constantly add value. But at least there is some goal.

I’m thinking particularly of a project team that thankfully I wasn’t part of, but I know it was very frustrating for the project manager. Their role changed from being a ‘proper’ project manager to being someone who oversaw a team doing lots of small ad hoc developments and changes that felt very much like BAU enhancements, with no end in sight.

He needed to get out of that project, because effectively what had happened was he’d morphed into the role of product owner and the project had drifted into being a live service, without a formal close down and handover.

And I’ve been on projects where there hasn’t been anyone to handover to, so I’ve had to keep the support elements until someone could be made available. That is not fun.

 So if your project stakeholders are more inclined towards drifting to the finish line than working out the map to deliver their vision, then here are 3 benefits of documenting requirements to share with them.

1. A winding journey is a slow one

Do they want to get to the destination quickly or not? Perhaps slow is the correct approach. But in my experience businesses want fast results, with the least amount of money and resource time spent on getting there.

You can’t do that if you are constantly fire-fighting, dealing with changes, doing rework and coping with the misunderstandings and lack of clarity that come from not knowing what you are doing.

2. Better requirements = Better cost management

The same people who are reluctant to help you prioritise what should really be in scope could easily be the same people telling you to do the project cheaply and to keep an eye on cost.

If you know what’s in scope, you can budget better. The more stable your requirements – or at least the end goal – the easier it is to work out what it’s going to cost to get there, and how much you are prepared for that figure to be.

3. Documentation helps formalise the project

Is it really a project, or is it a piece of BAU continuous improvement?

If it’s truly a project, you should know it has a start, a middle and an end. You might not know exactly how you are going to get there. You might manage the work in different ways, with different methodologies or approaches. But ultimately, you know it’s going to finish.

Without documentation, it’s not clear to me whether it’s a real project. If you can’t articulate what you are doing, and your sponsor isn’t prepared to put it in writing, then that’s a red flag for me.

You can still put things in writing, however informally, and caveat them with saying things might all look different once the work starts or whatever. But having documentation increases engagement and makes the project work more formal. Which in turn makes it easier to get resources to commit to doing tasks.

Whether you are preparing for the Project Management Professional (PMP)® exam, or one of the other many project management certifications you can do, good prep helps you succeed.

The infographic below shows five tips for preparing for your project management exam. These aren’t the only examples of good practice for exam prep, but they are the things I try to live by when I take exams – although it has been a while since my last classroom experience!

Remember why you are doing this: professional certification exams are hard. In one of mine, I had to write essays – it’s not often your work exposes you to situations where you have to handwrite for so long. You’re putting yourself through it because it’s worth it, for your professional development.

Write down your study plan: having a plan only works if it is visual and you can see it. We’re project managers, this part should be easy!

Take enough breaks: I feel guilty when I’m not studying when I know I have an exam coming up, but you need to be balanced and take time off too.

Sleep well: I have trouble doing this at the best of times! But do try to make an effort to get an early night the evening before your exam.

Treat yourself afterwards: You’ve put a lot of effort into getting to the exam itself. In the PMP® exam, you’ll know instantly if you have passed or not. Other exams require you to wait until the paper has been marked and you are notified afterwards. That can be quite a nerve-wracking time! Plan something else to do to take your mind off waiting, or to celebrate and wind down immediately afterwards. You’ve earned it!

Whether it’s raised eyebrows and eyerolling or a full-on shouting match, projects are a conflict-inflicted environment!

You could be on the receiving end of the conflict because team members or stakeholders have fallen out over something. Or you could be contributing to it, having to address an issue such as not having enough money to complete the work.

As a self-confessed conflict avoider, I have always wanted to get conflict dealt with and out the way as soon as possible, so we can all get back to work. Here are 3 options for diffusing conflict situations on a project.

1. Take the heat out of the situation

One option – one of my favourites because it’s not confrontational – is to help everyone calm down a bit.

Oftentimes, a problem doesn’t look so bad with a bit of distance, and the heat disappears from the conflict.

The simplest thing to do here is to draw a line under the conversation, take a pause, and say you’ll come back to the conflict-causing topic at another time.

Remember to actually address the topic at that time, though, otherwise you just cause seething resentment in the team members who want to air their views and haven’t had the opportunity to.

If you are one of those people who can diffuse tension in a room with a joke, go for it. I’m not, so I wouldn’t risk saying something not very funny and making the situation worse, so I opt for calm voices, and a short pause in proceedings.

2. Agree

It’s so difficult to be rude or argumentative to someone who agrees with you. I don’t remember who I learned this from as a retail assistant in a busy shop while I was at college, but it certainly works with angry customers.

If you aren’t defensive, they stop fighting. It’s no fun arguing with someone who isn’t arguing back and who appears to actually be on your side.

Obviously, this isn’t going to work in every scenario. You can’t agree with a construction worker who is choosing not to wear protective gear on a building site and causing a fuss about it.

But in some situations, this is a good technique to try. You can always move the discussion along and use other techniques if necessary.

3. Say you are sorry

Again, this isn’t a solution appropriate for every project conflict situation. However, you shouldn’t be above saying sorry. If the mistake is yours, own it. Sometimes that’s all people want – for someone else to accept the issue happened and to own up to it.

I’ve been in meetings where I’ve taken the blame for something the project team did (collectively) as I’m the one who is responsible for the successful delivery. And we didn’t deliver. That’s on me. The body language of the person with the complaint changed significantly after I said sorry. The discussion moved on.

These 3 techniques aren’t going to win you any peace treaty awards, but for day-to-day small gripes and grumbles on a team, they are easy things to try. What’s your best tip for keeping the peace on a project?

Pin for later reading: