The Money Files

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!

Over the last few weeks/articles we’ve looked at different aspects of resilience and how you can boost it in practical ways. Today, I wanted to look at some tools you could use – some you might already have access to, others you might have to request or lobby for. They are all things that will help your project team feel better equipped to handle the ups and downs of delivery.

Collaboration and communication tools

Hopefully you’ve already got access to collaboration tools like Slack, Microsoft Teams, Google Meet or Zoom to keep lines of communication open. These days I don’t know how we would work without those.

Project management tools that focus on scheduling and task management are also your friend because they help everyone see the same version of the truth. They help keep tasks organised, track progress, and help you spot trends so you can deal with emerging things before they become big problems.

Stress management and well-being tools

Many organisations offer access to emotional support or mental health resources. Tap into what is offered by your company but also check out the plethora of wellness apps and resources that are available on your phone.

I’ve found one I like but it’s a personal choice. Maybe one team meeting, open up about the apps you use or have tried and see whether other people can recommend apps they use themselves.

How about doing a yoga video, breathing exercises or a guided meditation at the end of a busy week? Whether you do this as a team or just highlight to the team that you take time out for self-care, either is good.

Decision-making frameworks

Decision-making frameworks take the stress out of decision-making because the process to get to the decision is clear. Make sure people know how to use a range of decision-support tools and practice using SWOT analysis or root cause analysis at non-stressful times so people can turn to those tools when they do have complicated issues to resolve.

Sort out a RACI matrix to clarify roles and responsibilities, as that can help avoid confusion and stress during decision-making. Use Terms of Reference and Delegation of Authority levels to work out who can approve what up to what level.

Resilience training programmes

If you’re in a position to fund workshops and training on emotional resilience, mindfulness, and coping strategies, add these to the rota of available in-house learning. Or check out what your company already offers in the way of e-learning modules on these topics. There are also courses available on platforms like LinkedIn learning if you have access to those.

Recognition platforms

Use your in-house or app-based recognition tools to shout out when people have done well. Celebrate success, and make it the done thing to comment on resilience, overcoming challenges – even if things go badly and the end result was a failure.

If you don’t have tools or apps you can use, you could either talk to your technical teams about building one in-house (at its most simple, it’s just a form that pushes out the results to a place where everyone can see them, or even into someone’s inbox to collate the submissions to share once a month).

Sometimes, calling out what there is available helps people connect resilience with the things they are already doing and it makes it less of a daunting or incomprehensible topic. Resilience in project management is not just about bouncing back from setbacks, it’s about creating teams that can thrive in the face of challenges, adapt to changes, and remain focused on achieving project goals despite adversity.

And there’s plenty of change in our dynamic business environments, where uncertainties and changes are just a daily occurrence. What do you use – do you have any favourite self-care apps? Let us know in the comments below!