The Money Files

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!

Last time I looked at 5 different types of software testing, and today I’m looking at other types of testing you might need to add to your plan.

Of course, you might not need all of these, but if your project includes technical elements or software build, then it’s worth asking the question. “Are we going to do XXX testing?” And if the answer is yes, then go on to ask how long that will take, who needs to do it, how you will know that it is completed (in other words, what the exit criteria are for testing) and when it should happen. Then you can add it to the project schedule.

1. Regression testing

What it is: Re-running tests to ensure existing functionality hasn’t broken after changes.

Who does it: QA team or automation scripts.

When: Any time there’s a code or config update.

Why it matters: Prevents new features from breaking old ones.

Make sure the team has this on the radar to test any old functionality still works after other bits have been updated. You don’t want to accidentally turn off some functionality that was previously working just fine!

2. Performance testing

What it is: Tests how the system performs under load (speed, responsiveness, stability).

Who does it: Performance testers or DevOps engineers.

When: Before go-live or after major updates.

Why it matters: Ensures the system won’t crash under real-world use.

There are different types of performance testing. I’ve used these (well, not personally, but my projects have included these):

• Load testing (how it handles expected volume)
• Stress testing (how it copes under extreme conditions)
• Spike testing (reaction to sudden traffic surges)

The type of performance testing you want to do depends on the product you are building and also the tools you want to test. I remember one day being told we all had to log in and test something at the same time… these days you can simulate multiple users hitting a system with tools designed for that purpose. Your project budget might need to invest in testing tools if you don’t have the products you need already.

3. Security testing

What it is: Tests for vulnerabilities like data breaches, access control issues, or malicious input.

Who does it: Security testers, pen testers.

When: Before go-live or in regulated environments. Actually, in all environments these days! You can’t be too careful!

Why it matters: Prevents security flaws and meets compliance needs.

Sometimes security testing can feel like you’re just ticking a box or lining the pockets of a penetration testing company, but you really can't be too careful. With the amount of cybersecurity incidents out there, it is essential that you follow all the guidelines and do the right type of security testing to build confidence in the system and ensure that your company remains safe and secure.

4. Compatibility testing

What it is: Verifies the system works across different environments (browsers, devices, operating systems).

Who does it: QA/test team.

When: Before launch or when targeting diverse user bases.

Why it matters: Ensures consistent user experience.

Ever launched a website feature and then find it doesn’t work on Firefox? Yes, been there. It’s really important to test on a variety of systems if the product is going to be used by users using those systems. In other words, if members of the public could be accessing the software from mobile devices, does it work with all of them? Or as many as you can reasonably test? Don’t build for your own phone and assume it looks good on others – that’s what this testing is all about.

So, overall, that’s 9 different types of testing – how big is your testing phase? Some of those tests can be run in parallel, some you might not need, others will take longer than you have planned, which is why we add contingency to test phases. Work with your team to schedule in the best possible approach to making your software as functional as possible and then you’ll be well on your way to delivering something useful and bug-free.