The Money Files

Last time I wrote about the business benefits that you might want to consider for your business cases. But identification of the benefits is only the first step. The training I was putting together was an hour-long overview, so nothing really deep dive, but I wanted to cover the process for managing benefits beyond simply brainstorming the things we could list to justify the business case.

This is the process I included in my presentation.

1. Identify

This is the step covered in my last article. Define what benefits the project is expected to deliver. Consider financial, customer, operational, strategic, employee, and ESG benefits.

As well as the list I shared last time, go back to some past business cases and see what kind of things they included, as well as the level of detail expected. For example, some business cases I’ve seen are really high-level with hardly any detail and they still got approved! I think it depends on how much you have already socialised the idea and how much the exec team want to do the project… But don’t waste too much time doing the work if you don’t need to in order to get it approved. Maybe stick to two or three good quality benefits instead of listing out 15 non-quantifiable benefits instead.

2. Define and quantify

Make each benefit SMART (Specific, Measurable, Achievable, Relevant, Time-bound). Where possible, quantify in financial terms or KPIs.

This is the step where you’ll spend the most time. It’s normally quite easy to work out the kinds of benefits you’ll get from the project activity. It’s really hard to agree what the baseline is and how you are going to work out the measures going forward.

3. Map and align

Link each benefit to project outputs and strategic objectives. Ensure they support organisational goals.

Do this on a slide to include in the business case or just in a paragraph. This bit doesn’t have to be too much work but you will want to evidence to the decision makers that you have thought about strategic alignment.

4. Plan for realisation

Clarify how and when each benefit will be achieved, who owns it, and what dependencies exist. Go back to step 2 – normally it’s the person who owns the baseline data who will own the ‘new’ data for the benefit. Think about when the benefit kicks in. If it’s about more sales, do they happen in the same month as you made them on the call? If customers have 60 days to pay their invoice, maybe you need to recognise the revenue 60 days later?

This step is another time-consuming one as you work out and negotiate all these pieces.

5. Track and measure

Include plans to track benefits through delivery and beyond. Does the project need to deliver a new dashboard to track sales or some other target? Add those tasks to the project plan otherwise you’ll get to the end and have no way of measuring your achievements.

6. Review and update

I wish I could have made this into 5 steps for the training because 6 doesn’t fit so nicely on a slide! But there is this final step which is to keep benefits under review. Update the business case as the project evolves or as assumptions change. This might mean going back around the approval process if the benefits are hugely different.

Hope that helps with your next business case and benefits discussions! Let me know what else you do in the comments below.

Recently a colleague asked me to do some training on business case benefits – how to identify them, manage them and track them. We spent a lot of the time thinking about different types of benefits, and I thought the list we brainstormed might be useful to you too.

Why not copy/paste this list or bookmark it so that next time you are creating a business case you can review whether you’re going to get any of these types of benefits?

1. Financial Benefits

Let’s start with the obvious ones, and the ones most execs, in my experience, tend to care about the most – the money benefits. You might have:

• Increased revenue (e.g. from new products or markets)
• Improved EBITDA (earnings before interest, tax, depreciation, and amortisation)
• Cost savings (e.g. from process efficiencies or automation)
• Avoided costs (e.g. preventing fines, reducing waste, or legacy system support)
• Improved cash flow or working capital efficiency

Working capital efficiency benefits were only something I came across on a project last year. While they might not make such great headlines as increasing revenue, they are definitely something you should be looking at if you have the opportunity.

2. Customer Benefits

Next up, benefits to your customers.

• Improved Net Promoter Score (NPS) or whatever measure you use to track customer satisfaction
• Reduced customer complaints or complaints about not-so-serious things
• Faster response/resolution times
• Enhanced customer experience (e.g. self-service tools, more intuitive systems)
• Increased customer retention or loyalty

3. Operational/Process Benefits

Next, we looked at internal benefits.

• Faster cycle times or reduced lead times
• Better data quality
• Improved productivity or throughput
• Standardisation or simplification of processes
• Increased system uptime or availability
• Improved compliance with regulations or standards

Some of these will translate into a financial benefit, for example, if you reduce the time it takes to answer a customer service call, you’d expect an agent to be able to do more calls in a day. Each call might turn into a sale, so there is the potential for increased revenue as a result of more calls answered. That kind of thing. You then start getting into the realms of assumptions – we assume 50% of calls convert to a sale, or something like that. I’d lean on your finance team or business planning and forecasting team here rather than try to guess at what the right assumptions might be.

There’s no reason not to include process benefits – they are easy to track for the most part – but if you can convert them to money benefits you might find your business case stacks up better.

4. Strategic Benefits

Personally, I think the strategic benefits are a bit vague. These are the kind of benefits you’d list in the exec summary to convince people of strategic alignment and the overall  ‘goodness’ of the business case, but you wouldn’t necessarily put them in a financial model.

• Entry into new markets or segments
• Support for strategic goals or transformation
• Improved agility or responsiveness to change
• Future-proofing the organisation (e.g. through technology upgrades)

5. Employee and Organisational Benefits

Benefits to staff often use similar measures to the customer service metrics, so if you can reuse any calculations, assumptions of measurement methods, then that will save you time.

• Improved staff engagement or morale from staff satisfaction surveys. Best to make these the ‘official’ surveys but you could also do ad hoc surveys before and after your project goes live to assess the difference
• Increased staff retention
• Better tools or systems for employees
• Upskilling or capability building
• Reduced manual work or rework

Get your HR team involved in measuring and tracking people-related benefits as they probably have access to a lot more data than you will about turnover, retention and so on.

6. Environmental, Social, Governance (ESG) Benefits

Even if you think your project might not have any benefits that fall into the corporate/social responsibility or ESG category, spend a few minutes thinking about them as you might find something.

• Carbon footprint reduction
• Waste reduction
• Improved sustainability reporting
• Better ethical or diversity practices
• Community or social impact

These are pretty hard to track in my experience. Waste reduction and recycling not so much as you can measure what you throw away, but carbon reporting can get quite complicated, especially if you don’t have someone in your organisation who is responsible for this.

7. Risk Reduction/Avoidance

Finally, we talked about the benefits of reducing (or avoiding) risks, including:

• Reduced operational risk (e.g. from old systems, manual processes)
• Improved data security or resilience
• Better business continuity or disaster recovery

Which of these could you use in your business cases?

Over the past few articles I’ve talked about different aspects of data privacy and how that links to project management deliverables and the ways of working for the team. One of the big things that we use as project managers is our software, and often we’re involved with selecting new tools or upgrading existing tools.

In this article, I wanted to point out a few things you should be looking for in your PM tools to make sure that you’re having the right conversations about whether they are secure enough for your data. I’m sure your info sec teams will also have a lot to say, so use the content below as a starting point for a discussion, not a replacement for guidance from your internal teams!

Access control and permissions

Ensure that the tool allows for granular control over who can access sensitive data. Role-based access control (RBAC) is essential for minimising the risk of unauthorised access.

What this looks like in practice is that you might have one person on the team with admin or ‘override’ permissions, and everyone else just enters the data. In one company I know, the workflow pushes a project between stages. While it’s going through the approval process, no one can edit the data. That’s good because it means all approvers are seeing the same thing, but also a bit annoying if you’ve accidentally left something out or there is another very valid reason for needing to add another attachment, for example. Admin users could have the power to make changes while a record is blocked for editing by ‘normal’ users, but it’s a power to use very carefully!

Data encryption

Verify whether the tool provides end-to-end encryption for both data at rest and data in transit. This ensures that data remains secure even if intercepted, which is important for software that is hosted in the cloud, or for financial information. I don’t know why you’d need information like bank card records in a project management tool, but even your business case information should be company-confidential and you wouldn’t want it accessible in case of a data breach.

Data storage and backup

Assess where the data is stored and whether that meets your requirements. For example, in the UK there are rules around where patient data is stored in the healthcare industry – we couldn’t have certain data stored in off-shore data centres, for example. Check out your regional data privacy laws.

Again, project management software isn’t going to have the kind of sensitive, personal information that’s on the same scale as medical records, but you still want to be sure it meets your company’s policies for storage.

The same goes for backup. However good your internal systems and however reliable your supplier, can you get the data back when there’s a problem?

Audit logs

This feature is so helpful in the project management software that I use. It’s great to easily be able to see what changed, when and who changed it.

Check if the tool has built-in auditing and tracking features that allow for monitoring access to data and changes to project information. And if it does, who has access to see the audit logs (I’m a believer in transparency here – why not make them available to everyone?).

Certifications

If you’re using software that you’ve bought in, check to see if it (or the company that makes it) has any data or compliance-related credentials like ISO 27001, SOC 2, or EU-U.S. Privacy Shield, which indicate that the tool has passed rigorous security and privacy assessments.

That’s not an exclusive list, but you can use the ideas above as a starting point for thinking about the requirements for data security and privacy for your project management software. What did I leave out? Let me know in the comments!

One of the major risks facing our projects today is data – and all the problems that can arise when the wrong data falls into the wrong hands. Even if nothing malicious happens with the data, the fact there was a breach can lead to reputational damage and fines. And no project manager wants their project to be the one where data leaked out. So we work on making sure data privacy best practices are built into the way projects are delivered.

Mostly, data privacy regulations are baked into internal processes and policies, but it never hurts to have a reminder. Here are some things you can do to foster a culture of data privacy awareness in the team, so they automatically (hopefully) consider data privacy when they are working out work packages and activities.

Start with culture

Build a culture of data privacy. Lead from the top and make it expected that privacy is just ‘how things work around here.’

Make data privacy a part of the team’s daily routine by integrating best practices into everyday project management tasks, such as reviewing documents, storing information, and sharing data. For example, think through who has access to what data, and who gets permission to delete it.

I had an interesting discussion with some German colleagues recently who shared that the data privacy laws there are so strict that you can’t ask employees for some information, which must make some aspects of performance reviews, feedback, celebrating birthdays and employee satisfaction surveys really difficult! (If you’re based in Germany, let us know your thoughts in the comments below, or if your country has similar restrictions, tell us about them!)

Offer formal training

If your company offers mandatory data privacy and security training programs for all team members (and they probably do) make sure everyone does the modules. It’s usually e-learning and not onerous, but that also means that people have a tendency to skip to the test or assessment part without actually paying that much attention to the training. However, it’s the minimum people need to do.

This training will most likely cover topics like identifying sensitive data, safe data handling practices, and understanding legal requirements – all things you need to have top of mind for projects.

Work through examples

Use your team meetings to work through practical scenarios. Use real-world examples or case studies, for example, internal projects or projects in the media in your industry, to illustrate the importance of data privacy and the consequences of non-compliance.

Ask the risk management team if they could write some scenarios for you to discuss and add them to your team meetings a way of upskilling.

Set clear data handling guidelines

Your company might already have overarching data handling guidelines, so you can lean into those, or set specific ones for your project if it’s data heavy. Guidelines should cover data collection, storage, sharing, and disposal. When you kick off a new project, ensure that every team member understands the policies and any other applicable laws.

Stay on top of changes

One thing I’ve noticed in the 20+ years I’ve been managing projects is how often things change. Privacy law and data laws are changing all the time as technical advancements introduce different types of data and ways that it needs to be managed (AI and deep fakes being cases in point at the moment).

Don’t assume nothing has changed since you last did a project with a big data element. Talk to your legal team and get the latest.

Talk about the implications of non-compliance

Make sure people are aware that it’s not a small problem if there is a data breach or non-compliant situation. Your company could risk:

• Legal risks: Fines, sanctions, or legal action for breaching data protection regulations.
• Reputational damage: Loss of client trust, which can affect relationships and future business opportunities.
• Operational risks: Inefficient processes or security breaches that may compromise the success of a project.

And sometimes the individual might be liable as well as the organisation… so know what you are getting yourself into!

Last month I looked at some of the basics for data privacy on projects. Let’s go into that in a bit more depth this month, by looking at some of the project tasks you can schedule to help manage data on your project within the regulations of your country, whatever they are.

1. Data mapping

The first activity you can schedule is data mapping. You might already have a customer journey or user flows or process maps. Can you add a swimlane for data on that? Or if necessary, create a new data map.

The data mapping exercise should help you understand where, how, and why data is being collected throughout the project lifecycle and beyond.

2. Data Processing Agreements (DPAs)

Another task is creating DPAs with the relevant parties for your project. This is normally something you’d do as you contract with a third party, so lean into the legal or procurement team for support.

A DPA is a document that outlines how data will be handled, stored, and protected. There is probably a template within your organisation already.

Alternatively, the task is to check that DPAs are already in place, if the vendor is one that you use regularly. I like the kind of tasks that can easily be checked off! They help the team feel they are making progress and ensure that you are putting compliance at the forefront of your processes.

3. Due diligence

Schedule time to conduct due diligence on third-party tools and vendors to ensure their privacy and security measures meet your organisation’s data protection requirements. You probably won’t be doing the actual due diligence, so talk to your procurement or legal teams, or the data protection officer to find out how this will happen.

Again, if your company already has a relationship with the third-party, the task here is to check that it was done at some point and does not need to be done again.

4. Data security and risk mitigation

Make sure there are activities on the schedule that involve implementing strong security measures to protect project data. That could include setting up multi-factor authentication, data encryption, and secure access protocols.

Generally, the IT team would have to take responsibility for doing these things or checking that they are already in place from a third party. Talk to them about the kinds of tasks that need to go on the schedule so they have enough time to put security measures live before the project launches.

5. Testing

Make time for data testing. For example, schedule penetration testing. Look through your risk register for risks related to data breaches or leaks and have mitigation strategies in place that you can test out. That might be checking you can restore from back up or testing security protocols for data access.

Again, talk to your technical teams about what this might look like for your projects and put the time in for this work so it doesn’t get squeezed in at the last minute or forgotten about.

All of these scheduleable (is that a word?) tasks will help you address any risks or issues relating to non-compliance and show that you are actively prioritising data privacy. Next time I’m going to look at training teams on data privacy best practices. Meanwhile, why not share your experiences of data on your projects in the comments below? Thanks!