The Money Files

In the Northern hemisphere, we’re going into hibernation mode. The weather might be getting colder but the deadlines are hotting up as we approach year end. It’s always the same: leadership teams trying to get projects done before the end of the year, often for no real reason other than it’s an arbitrary date and it lets everyone start fresh in January.

However, if your financial year finishes in December, there could be good reason for trying to get everything done.

At this time of year there are also other distractions: people taking time off for holidays and the festivities. Here are 6 practical strategies that you can start using on your project to finish the year strong.

1. Plan for the holiday exodus

Map out who’s away and adjust your project timelines early. One of the problems I have found on projects is that I am not always told who will be on holiday because the individuals working on the project do not directly report to me. Check in with their line managers or ask each individual directly about their plans to be away over the holiday season.

2. Freeze your scope

Literally. Stop adding features or deliverables! When you get change requests, put them on the back burner until the new year. That will protect the capacity in the team in order to complete the work that you already have in your work stack.

3. Front-load work

Get critical tasks done before festive chaos hits. Even if you are not expecting chaos, you could still be caught off guard by key stakeholders being out of the office or decisions taking longer because decision makers are not around.

Try to get decisions documented and agreed as early as possible so that your team is not held up.

4. Automate handovers

Prep notes, shared docs, and checklists. If you have anything to hand over this season, make sure you're doing the prep work for it now. That also means making sure your project filing and archiving is up to date. Saved down any attachments from emails tidy up your SharePoint channels and make sure everyone is using the document storage the way that it should be used.

5. Celebrate early wins

Bring in treats or plan some virtual thank-yous for the team. This year my project team is celebrating in November because December is too busy and it's hard to get people to have the opportunity to meet up. If that feels like it will be the same for your team, consider moving any festive celebrations earlier in the year or pushing them to January. January often has the benefit of being cheaper as well!

6. Plan your restart

Schedule a January reset meeting before everyone disappears. Whether that is a lessons learned from a project before you will forget what happened, project scoping or a quarter one planning session, book the time now before all those recurring meetings start dropping into calendars. While you are at it, set up your steering meetings, any other governance meetings, regular project team meetings and anything else that needs to be in the diary on a recurring basis so that your team project sessions have protected time as you go into the new year.

What else do you do at this time of year that helps you keep everything on track to end the year in a good place?
 

I know we’d all like to rely on our PowerBI or Tableau reports, or whatever data source you use for tracking business metrics, but those reports are only as good as the data that goes into them.

That goes for our project management tools as well. If you’re looking at a resource chart trying to work out how to manage capacity over the coming weeks, you’d better be looking at the right inputs. When the underlying data is wrong, it can throw off your scheduling.

But why is data wrong in the first place? No one goes into work and knowingly types in incorrect figures just to make your day difficult. If you’re worried about the integrity of the data, or you want to do an audit check, or even just highlight the importance of getting it right to your team, here are some places you can look.

Human error

Let’s start with the most obvious: Incorrect data input by project team members can lead to inaccuracies in schedules, budgets, and resource allocation. Manual errors in data processing causes more headaches, in my opinion, than anything else.

While we’re on the topic of how humans type things in, let’s talk about inconsistent data formatting. Without standardised data entry methods, inconsistencies such as different date formats or unit measurements can impact data integrity.

Software Errors

How much downtime does your project management tool, or any other data repository that you use, have? How often do you have to raise tickets?

I heard about one team who had been successfully navigating around a bug in the system they used, and talked about how they were managing as if it was a badge of honour – don’t do that! Raise a ticket with the right support team and get it fixed. You never know what kind of impact a bug is having behind the scenes.

Even the best project management software may experience a glitch from time to time that could mean you lose data or it gets corrupted. This can happen when you are syncing data or updating project information, for example importing a spreadsheet from one system to another.

Sometimes we also see issues where multiple users are trying to access or modify the same document or data set where version control hasn't been used. That gives you multiple versions of the same information and no one knows which is the correct one.

External factors

Sometimes it's factors beyond your control that cause problems with data. If you have a network failure, for example, and you're in the middle of doing a data sync, that might affect the inputs. Even hardware failures, the blue screen of death, or losing a USB stick can cause problems (not that you store anything on external drives, right?).

Data integration

In my experience, one of the biggest issues with making sure your data is correct across all systems is how the interfaces work. If you are building interfaces between various systems you have to make sure that the testing is adequate. Whether you are integrating your project management software with financial planning software or a resource management tool or whether you are taking project data out of a scheduling system and putting it somewhere else, it has to be accurate.

Another issue is where the data is being exported from one system in one format and needs to be in a different format for another system —this is particularly relevant with dates.

Identify which system is the single source of the truth and make sure the integrity of that is maintained.

What other issues do you have with data integrity and how do you get round them?

It’s the time of year where people are thinking about how well projects are performing. (Actually, isn’t that all year round?) Which means it’s health check and ‘look back’ time for lots of project managers as they evidence what they’ve done all year and how it has made a difference.

A health check is a useful thing to be thinking about as it shows how the project has performed and what areas you might want to focus in on as you move into 2026 – for this project or for other projects.

However, I know a lot of project managers avoid them because they feel like they will uncover too many skeletons in the closet – there’s too much scrutiny on what might have gone wrong. No one wants to intentionally put themselves in a position where poor performance or bad choices might point the finger of blame at them.

Putting that aside, if you can reframe a health check as a positive way to reinforce what is working and focus in on what is not, they are a useful exercise. As a team leader, you can talk to your team about running reflection sessions to dive into how the project is going.

When to do a health check

There is no ‘right time’ to do a health check but here is when I would be scheduling one:

• Mid-project reset
• Change in leadership/sponsor
• Post-crisis or post-pause

Or at any other time where it fits your governance model.

What to cover in a health check

In a health check, you’ll be looking at scope, schedule, budget, risks, stakeholder satisfaction, team morale and anything else you think might be relevant to help understand project performance.

Tools and templates

You probably have all the right tools and templates already. Check out your PMO document library for:

• Simple scorecard
• RAG review
• Short-form survey that you use with stakeholders and team members to get feedback

How to run it

Keep it short and constructive. You don’t need to spend ages planning for it, or ages holding it. The notes and write up should be short and to the point, highlighting areas to continue and areas to switch up and try something new.

Involve neutral facilitators if needed. Sometimes (I’d say all the time) we are often too close to our own projects to be able to see what is going on in an objective way.

Use it to align and re-energise. The whole experience should leave the team feeling lighter and more able to focus on what is coming up for project milestones – it’s not ideal to leave with a huge To Do list of improvements that you won’t have time to implement. Aim to get two or three things out of it that you can do easily to help the team move forward and improve project performance. Any more than that and chances are you won’t ever reach the end of the list. You’ll spend more time trying to implement process improvements than delivering the project, and that isn’t a good result for anyone.

Remember: Work with the team to reframe health checks as maintenance, not judgment. They should be something that easily slot into the project schedule and are a positive experience with some great learnings that you can implement quickly.

Leave the deep dives for full-on audits and keep quick health checks part of your retro routine!

You probably work in an organisation that has a lot of data. We have customer info, staff info, prospects and leads, marketing data, utilisation data - you name it, there’s probably a view in your data analytics tool for it.

But the data is only useful if it’s truly believable. And that’s where data integrity comes in.

What is data integrity?

Data integrity refers to the accuracy, consistency, and reliability of data throughout its lifecycle, from initial collection to final archiving or deletion.

For projects, that means making sure that project-related data (e.g., budgets, timelines, tasks, resources, and deliverables) is reliable and uncorrupted at every stage of the project.

Actually, that’s the easy part. It’s the data yours project uses and creates that is trickier. Migrating data from one system to another? We had a whole workstream dedicated to data clean up on one of my projects. Capturing new data as a result of this project? Where does it go? How does it get incorporated into existing reports or new dashboards?

And then there’s the disposal. When you decommission a product or software tool, we have to make sure data is removed, archived, made searchable or deleted according to the prevailing restrictions on data storage.

Why data integrity matters

Data awareness should be part of the fabric of your project. Ask yourself where it is coming from and where it is going to. What’s the lifecycle of a piece of data – can you map it?

On a project, we use data to assess progress, allocate resources, and make adjustments, so we need it to be reliable because data errors can lead to poor decisions. That’s the same in other areas of the business too. The data inputs and outputs of our project need to work effectively so that decision makers get what they need.

Data integrity means we can hold people accountable. Whether it’s tracking benefits, performance, deadlines… knowing that you can trust the baseline is important.

When you’ve got confidence in the data, it builds trust with stakeholders and internal or external clients, assuring them that the project is on track and meeting objectives.

What I’ve noticed is that it’s pretty easy for data to not be accurate. Test data slips in and needs to be deleted. A report has a field missing and suddenly your formula doesn’t count anyone in the north – small things like that make big differences.

What to do now

It’s one thing to agree that data integrity matters, but that’s just lip service unless the team comes together and takes it seriously. Small changes help create an integrity mindset:

• Agree naming conventions
• Use version control
• Set clear ownership for who is responsible for each dataset.

Create a data workstream on every project, and include relevant milestones, such as checkpoints for data validation during testing and user acceptance phases.

Think about how you’ll monitor ongoing data quality too, so this can be included in the ops handover at the end. Maybe the BAU team want automated checks, exception reporting, or something else. Talk to them about how they will use the data going forward and build that into your schedule.

During the project, a monthly review of key project data elements and fields can highlight issues early – for example, we do a scan through of risks to see when they were last updated, and overdue milestones flag themselves automatically, which is very handy! What can you do to build data integrity throughout your project and ensure it sticks once the project is closed?

I’ve only recently come across using sensitivity analysis in business cases, but it’s really helpful when you want to test how changes in key assumptions (like costs, timelines, benefits) affect the outcome of a business case. In particular, when you think that you might have over-egged it and you want to de-risk the business case.

Used effectively, it helps identify which variables matter most and how robust your investment case is. Which is want CFOs and finance team decision makers want confidence in, right?

When sensitivity analysis is useful

Sensitivity analysis as a technique is useful:

• When there is uncertainty in cost or benefit estimates
• For high-value or high-risk projects
• To prepare for board or CFO scrutiny
• To support decisions between competing options.

OK, so now you want to know how to do it. Here’s how we incorporated it into one of our business cases.

Start with a base case (your standard forecast). This is your ‘normal’ business case, the one you prepare before the project gets submitted for approval.

Next, vary one key input at a time (e.g. +10% cost, -20% benefits).

Look at the impact on outcomes like NPV, ROI, or payback, or whatever financial measures you use.

Tip: use ranges or scenarios (best case, worst case, likely case) when you present the results back because at this early stage it’s very unlikely that you have defined and finalised costs and benefits so a range gives more flexibility.

What variables can you test?

We used risk and applied a blanket: what if we only get 25% of the benefit because of reasons… That de-risked the benefit that we were claiming and brought the number down to something that felt achievable. Because no one minds if you over achieve on your benefits case!

But you can be a bit more scientific. Here are some variables you can plug into your model.

• Project delivery time (for example, +3 months delay)
• Implementation cost (e.g. +15% cost increase)
• Customer uptake (e.g. -20% of customers user it)
• Productivity gain (e.g. +/- 10% time saved)
• Exchange rates, inflation, resource availability etc etc.

We put the data into a slide at the back of the business case to show that even if the benefit was de-risked significantly, the business case still stood up. If you’ve gone through several variables, you can present an overall most likely case, where you combine variables like an increase and cost and a delay in delivery (because that’s realistic, right?). Highlight where small changes make a big impact,  these are your critical assumptions and the areas where you really need to focus if you want to hit your original expectations.

Does it work?

Well, sensitivity analysis is only part of a model where you can show how you got to your workings and why you think your forecasts are accurate. If your base business case is rubbish, any analysis based on that is going to be rubbish too.

I like it because it’s easy and simple and you don’t need to run complex scenario modelling or use software. For example, what happens if we are late? Run the costs forwards 3 months and take 3 months of benefits realisation out of the business case and see whether that still gives you a number your exec team could live with.

It’s a way to reassure decision makers that you’ve considered variables and know what influences your costs, but also builds confidence that even if there are some challenges on the way or with the end result that you could still get value from the project.

What do you think, have you used this before? Let me know if I’m late to the party!