The Money Files

In this video I look at 3 things you can do to help calm the overwhelm when the business seems to be changing around you more quickly than you can keep up!

I talk about making sure change management, risk management and day to day operations on projects go as smoothly as possible, freeing you up to cope with whatever project-related changes are being thrown your way.

Pin for later reading:

Done?

Great! It’s time to wrap up your project neatly. Here are some tips for closing down a project in a smooth and measured way.

1. Update your project schedule

I’ve been guilty of not bothering to mark off the final tasks as complete. Who cares about them anyway? You know they’re done.

Stop right there! You should tidy up your project schedule and make sure everything you completed is marked as complete. If tasks didn’t get finished, and that sometimes happens, you can add them to the closure documentation and the operational team can pick them up in future. This has happened to me multiple times and it’s fine. Just add the outstanding work to the handover paperwork and make sure the receiving team knows what to do. Given timelines for projects, it’s often unrealistic to think that every last activity gets perfectly wrapped up with a bow before it’s time to close the work.

It’s important because someone else might look at those files later and think you didn’t complete work when actually you did.

2. Update the risk log

Have you closed off all your project risks?

Some might need to be passed forward as ongoing risks for the operational team to be aware of. But anything that didn’t happen or where the risk has passed – those ones can get closed off on the log.

Anything that is useful to discuss as part of lessons learned can get carried forward to the next point on the list…

3. Schedule and hold a post-implementation review

Where I work, we call this meeting a PIR or post-implementation review, but you might know it as a post-project review, retrospective or something else.

The point is, you get together after the project and discuss what worked and what didn’t go so well.

You’ve (hopefully) been capturing lessons learned throughout the project – this is an approach I advocate in my book, Customer-Centric Project Management. So doing one last review shouldn’t feel like too much work as it builds on what you have already been doing.

Lessons learned sessions are a regular part of what project managers do, so you probably don’t need me to say more about them.

4. Sort out your project filing

Look through your digital files and make sure they have sensible names and the right stuff is in each one.

Someone else might need to review them later, if they are doing a similar project, so make it easy for your organisation to use the knowledge in your documentation. I think companies are bad at managing organisational knowledge, so don’t make it harder for your colleagues!

I sometimes add a ‘start here’ or ‘readme’ file as a .txt in the main folder navigation menu. The aim is for people to look at that first and I can use the body of the file to explain how the folders are set up.

5. Celebrate!

Whoo hoo! You’ve completed the project. Time to say thanks and celebrate how far you’ve come.

Note: even if you didn’t deliver everything you said you would, even if the project is closed down early, it is still worth celebrating what you achieved. Team morale will be better because you’ve taken the simple, easy step of thanking everyone for their contribution. They’ll go on to future projects feeling better about this one, even if it ended up stalling or being closed down prematurely.

If you did deliver something awesome, as I hope you did, enjoy the feeling of completing a worthwhile project!

Pin for later reading:

What I like about the PMBOK® Guide – Sixth Edition is that the language allows for scope to adapt the information to your own environment. For example, the definition of the project risk management Knowledge Area starts like this:

Project Risk Management includes…

which opens itself up to the interpretation that there could be other factors included as well as the ones listed.

In this article, and over subsequent articles, we’re going to look at the Project Risk Management Knowledge Area. Why? This blog is normally about things to do with project financial management, and what’s more relevant than managing risk so you don’t get a massive budget impact? OK, I’m sure you can think of other relevant things, but risk management is definitely a factor in controlling your budget.

Doing risk management on your project involves:

• Risk management planning
• Identification of risk
• Risk analysis
• Response planning and implementation
• And monitoring risk.

The reason why we do it isn’t just to save the company’s purse. It’s to increase or decrease the likelihood and impact of risks (depending on whether they are opportunities or threats) in order to optimise the chance that the project will be successful.

Note: when I first started learning project management, on my first training course, risk was considered as a purely negative event. It’s thanks to thought leaders in the field and the development of the profession that risk is now more widely known to represent both the good things that could happen as well as the bad things. In other words, risk is a reflection of uncertainty, not doom.

Risk is not inherently bad – even the negative risk. We take risks in daily life, every time we cross the road, or take a flight. But we calculate the risk (subconsciously) and do it anyway if our brain tells us that the odds are worth taking.

Business and project risk are no different. The goal of project risk management is to identify the things that might happen on a project and weigh up whether it’s worth doing anything about them. Oftentimes, it is worth expending energy to do something about them because ignored risks can turn into issues and be suddenly a lot harder to deal with.

Levels of risk

There are two levels of risk on a project.

First, we have the individual project risk. Take a risk, assess it, and note the impact it will have on the project. That’s at a very granular level, and while we do a lot of that, and it’s a useful exercise, we also need to look at the bigger picture. That’s the next type of risk.

Second, we have overall project risk. Let’s say your project risks are all assessed as low impact and low likelihood. Individually, each risk isn’t very risky. But now let’s say you have 5,000 risks. That’s a lot of ‘not very risky risks’ and aggregated, the picture looks very different. When you consider how those risks might interact with each other, the picture gets even worse. If one risk happens, it could make others more likely, or more impactful. Overall project risk looks at the whole picture of the cumulative, aggregated position that is created by all the risks.

When you look at the risk profiles of several projects, you can see different trends emerging again. At a portfolio level, you aggregate the risk profiles of all the projects and programmes.

Ultimately, you want risk at any level to be in line with stakeholders’ risk appetite. When a project gets too risky, stakeholders will be nervous. The exposure to the business feels too great. The portfolio management team, in conjunction with the corporate risk team, will take that kind of decision.

At a project level, your role is to escalate up to the PMO, your programme manager or even your boss and let them know about the significant risks facing your project.

That’s the reason we have risk management processes. It makes all this easier. When you have a risk framework and structure within the organisation, you can more easily pass information to the places it needs to go and keep your risks in check.

Next time: I’ll be looking at trends and emerging practices in risk management for projects.

Pin for later reading:

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: