The Money Files

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.

So many of my projects involve technical development, and if that rings true for you as well, it’s helpful to know what different types of software testing you might encounter on a project. Then you can add them to the discussions about the plan.

Just to confirm – never pop them on your schedule without talking to the right teams about how long they are going to take and when they are going to happen. But at least if you know the different types of testing, why you would use them and when they typically happen in a project, you can ask the right questions.

Here we go!

1. Unit testing

What it is: Testing individual components (e.g. functions, methods, modules) in isolation.

Who does it: Developers.

When: Early in development. As each individual piece of the solution is delivered, it’s tested, or you might do all the software development and then test.

Why it matters: Catches logic errors early and makes debugging easier.

2. Integration testing

What it is: Testing how components work together (e.g. how modules exchange data).

Who does it: Developers or test engineers.

When: After unit testing, before full system testing.

Why it matters: Ensures that interfaces and data flow between parts of the system work properly.

If you have an integration engine, the team responsible for that would be involved, as this is all about how different tools link together. If you have interfaces or data moving from one system to another, you’ll definitely want to factor this in.

3. Smoke testing

What it is: A quick, shallow test to confirm that the most critical features work.

Who does it: Developers or QA, often automated.

When: After a build or deployment.

Why it matters: Gives fast feedback before deeper testing begins.

Smoke testing can happen at different points in the project. As the project manager, the question you need to ask is, ‘are we planning any smoke testing?’ and then you can decide together when to add it to the schedule.

4. System testing

What it is: Testing the complete, integrated application as a whole.

Who does it: QA/test team.

When: After integration testing, before UAT.

Why it matters: Verifies that the system meets technical specifications and behaves correctly.

This is the important testing, and you’ll want to leave enough time for it.

5. Acceptance testing (including UAT)

What it is: Validates whether the system meets business requirements and is ready for release.

Who does it: End users, product owners, or business analysts.

When: After system testing.

Why it matters: Confirms the solution works in the real world for the people who’ll use it.

While system-y people might be involved with the acceptance testing, the main focus for me is on the user testing. You’ll need to identify the right users, make sure they have access to the test system and most importantly, that they know what to do. They’ll record any bugs they find and the developers will put them right.

You’ll probably want at least 2 rounds of UAT, to allow people to find bugs, fixes to be deployed and then for testing to evidence that the fixes work.

Schedule in enough time for UAT testers to be trained on the system, test their access, attend a session on how to record bugs and for them to re-test the fixes. This always takes longer than you expect!

Next time I’ll share four other types of testing that you might need to include in your plans.

Is the amount of unread emails in your inbox kind of a badge of honour? Time to rethink what you value! And I’m here to tell you that it’s not a selling point as a project manager to have lots of unread emails. Your inbox is not your to do list. It’s the first port of call for incoming messages (as well as all the other channels you have). But if you want to reclaim some bandwidth, then here are 7 tips to stay sane when email is out of control.

1. Batch process, don’t check constantly

Set 2 to 3 times a day for email review only. Block the time out on your calendar. Let people know that is your approach because you mention it in your status message or auto responder.

2. Use folders or tags that work for you

Come up with some folders or tags that work for you. I use a folder per project, and then break down that folder into subfolders, each related to a specific aspect of the project. So I’ll have a fold for budget and benefits, another one for steering group prep and correspondence, one per deliverable, topic or theme of the project, and so on.

You could have ‘for action’, ‘waiting’ (for where you are waiting on someone else’ or folders for different stakeholders. You can also flag messages, so if you don’t want to move them to a folder, colour-code the flags and create a system that works.

3. Craft better subject lines

“Action needed by Friday” is better than “Update”. Typically, we start emails with: For information, For review, For action and then state what the task is. Then people can decide when they want to read it, and for senior stakeholders, their exec assistant or PA can filter out the mails where their boss has to do something.

4. Default to clear, short responses

Try the 4-sentence rule: context, ask, next step, close.

For example: Thanks for coming to the steering meeting on Thursday. The ask of the group is to ratify the change proposed (see attached change request slide). We agreed to feed back consolidated responses to Elizabeth by Friday. Thanks in advance for your help!

5. Unsubscribe or filter relentlessly

I know we all have newsletters that we subscribe to, and they are a good way of keeping up with topics you want to learn more about, or from creators who inspire you. I’ve got folders for the newsletters I want to keep – when you find people who send stuff you want to refer to time and time again, you know you are on to a winner!

Move newsletters to a reading folder. Move reports to an archive and use search tags so that you can find them again.

6. Use flags/snooze/delayed send features

Too busy to deal with it now but worried you might forget later? Snooze the message or use flags to remind you to come back to it. Is it too early to deal with it but you’d rather get it done? Use the delayed send feature so your message gets sent when the time is right but you can draft it now – and cross it off your to do list!

Deal with inbox items on your terms.

7. Establish norms with your team

This is the thing that people on my training courses seem to find the hardest. Talk to your project team and your immediate colleagues about what norms you want to use. For example, if there are more than 3 replies in the chain, pick up the phone and talk to someone.

What are your boundaries about sending emails out of hours? When do you move a discussion to a chat channel so more people can see it instead of copying everyone in?

Email doesn’t need to run your life, even though it might feel like it right now! I’ll confess that I am not at inbox zero – I don’t think I ever have been in my 20+ years of working as a project manager. But I also don’t have hundreds and hundreds of messages in my inbox as that stresses me out. My goal is less than 50, so I can easily scroll through and see what’s top of mind at any given moment.

What about you, have you ever got to inbox zero? What tips do you have for keeping your inbox uncluttered? Let us know in the chat!

Let’s say that you’ve decided you want to integrate your project management tools with some other platform or software within your organisation – there are lots of reasons why you would want to do this that I have covered in other articles.

So how do you get started? Here’s a quick guide to planning out what you need to do.

Understand your needs

Start by assessing the needs of your project team. Identify which functions are lacking or could be enhanced (e.g., reporting, communication, time tracking, etc.). This will help prioritise which integrations to set up if you’ve got several options.

My suggestion would be to start with something small and easy. That will help you prove the concept of integration, get some useful data and get a ‘win’ that might make it easier to get funding for any larger piece of technical work to do other things.

Choose the right applications

There are probably lots of options for integration. Finance tools for pulling in actuals? Capacity management software for resource planning? Timesheets? Focus on finding applications that complement your project management tool and enhance its capabilities – things where you would actually get use out of the data, the workflow or the interface.

Before you actually make the decision, check that it’s a reliable, supported tool that aligns to the business processes and that it’s going to be worth the effort! Another consideration is your project management tool itself. It seems to me that organisations change tools every few years so you don’t want to invest in enhancing something that is not going to be around much longer. Make sure you’ve got confidence in the longevity of the products you are using.

Review the integration options and approaches

Most project management platforms offer integration options through open APIs or pre-built connectors. You might have an integration hub as part of the tech stack that you would need to  use to pass data from one product to another.

Think about how best to integrate the tools, and lean on enterprise architects and data analysts to work out the best route, and what needs to be done. My recommendation would be to go for solutions that are the simplest, with the fewest data points to reduce the technical complexity.

Test the integration

Before you hit the button, make sure it’s all as tested as it can be. You really need the data integrity to be 100% or people will lose confidence in the data. Then they’ll go back to the original sources and you won’t have saved any time or improved processes at all.

Test with a small group, controlled data and look for issues related to data syncing, user permissions, and overall functionality.

Monitor and refine

As with any software project or process change, you’ll want to keep an eye on it and make sure that it is working as expected. Monitor feedback from users and tweak as necessary to make any improvements.

You might find bugs that were missed during testing or there might be new requirements that help make it more user-friendly or workable.

Once you’ve got one integration set up and working, think about what was the next priority on your list. How can you get that one kicked off? With citizen development and low code development, plus the power of AI, it might be easier than you expect to get something off the ground! Good luck, and let us know in the comments which your most successful integrations have been!