The Money Files

I’ve just finished reading Business Resilience by David Roberts etc al. It’s a book that sets out a whole framework for delivering progress at a sustained pace and not being left behind in VUCA times. It’s aimed at senior leadership at the top levels as that is where the culture change is likely to need to start from, if you are rethinking strategy delivery.

It did get me thinking about what it means for projects and project managers. Thinking about what resilience meant in an IT world, back in the days when I worked in the IT team, I could draw a few parallels with resilience from a tech perspective and what it translates to for project professionals. (These are my thoughts, they aren’t from the book, which is far more strategic and articulate!)

Process

Process resilience to me means having steps in place to get things done, even when things change. For example, when I moved from a fixed term to a permanent contract, my records were updated. Unfortunately, that meant that I could no longer see any purchase orders that were approved by the ‘old’ me.

That wasn’t a huge problem but as process steps go, it would have been nice to have the continuity without having to ask for it.

Another example of building in process resilience is making sure workflows can be delegated when you are out of the business. For example, handing over order approvals, estimates or change management approvals to a colleague during your holidays, instead of them all being stuck in your queue to approve when you get back.

Redundancy

In IT, we used to build solutions that had adequate redundancy. For example, the servers would fail over to another server if the first server had problems. We had back up generators to keep critical systems operational if (when) the power went down.

In project terms, that would look like having two people trained to carry out a project role so that if one resource is off sick, someone else can step in and do the work.

That’s quite an overhead for a project team, as normally we wouldn’t want to carry additional cost, but on business critical projects, or where your resource is truly specialised, it might be worth it.

Data availability

How long do you spend looking for project documentation? Probably quite a long time, especially if its on a collaboration tool that shall remain nameless! Thank goodness for being able to search.

In a technical environment, we’d create backups so the data was available even if the main system went down (although of course with the redundancy, the goal is that the main system stays up…).

Project documentation and data availability in a resilient team would mean you could find what you are looking for easily, in the right place, and access the data.

I think as the world gets more complex, projects get busier and teams have more to handle, being resilient is more and more important if we want to get things done and avoid burnout. These are just 3 ideas of things you can do with your project team this week to be a little bit more resilient and prepared for what next week might throw at you:

1. Review your processes and look for where you can build resilience in to keep things moving and avoid the process stalling
2. Look at your resource plans and consider how you can build in resource redundancy – maybe get a few more people on a training course
3. Consider where you store your project data and how easy it is for people to access when they need it.

What do you think of these ideas? Share any other resilience-building tips you have in the comments below!

Metrics are an important way to learn about how the project is going and to reflect on what has happened in the past so you can do things different in the future. Or repeat the things that work well.

I learned a few lessons about project metrics when I worked on an ERP implementation a while ago now. We measured internal customer satisfaction from the angle of the stakeholders’ experience of being on the project. We used standard questions and asked them to rank our performance on a scale of 1 to 10. (I write about all of this in Customer-Centric Project Management, which I co-wrote with a colleague.)

In my experience, workstream leads scored reasonably based on the context: no one ‘played politics’ to get what they wanted. But there was always room for improvement based on our scores. We had plenty of armchair debates in the lobbies of hotels while working on the road, talking over the scores and why they were ranking project performance the way they did. They weren’t my favourite conversations, but they were extremely useful in building great stakeholder relationships and goodwill over time.

The big lesson for me came when I was asking my own colleagues in the IT department to rank the project and they scored it badly. I took it personally as the project lead as you can imagine! But it was a huge wake up call for not taking my colleagues and friends for granted: I was pouring all my stakeholder engagement effort into people outside of my own team.

Luckily it was easy to fix. I set up conference calls for team Q&A and made time for regular communications. If you listen to what people want and give it to them, you can make a quick difference to perceptions and how easy it is for them to do their jobs.

The takeaways for me, specifically around metrics were these.

Identify stakeholders in the process

Put some time into identifying stakeholders and don’t miss the obvious ones like I did!

Ensure the measures are representative of all stakeholders

If your measures are not objective and are not representative of all stakeholder, consider having different versions of the measures for different things. That’s OK as long as there is some longevity baked in for comparison purposes.

Decide on how to record results

In my case, it was better to keep individual stakeholder results separate instead of creating an aggregate of stakeholder satisfaction scores. That gave us greater insights into how each workstream was feeling. An average would be unrepresentative of the community overall.

Sense check

Are the metrics telling you what your instincts are telling you? If not, why?

As project leaders, it’s important that we set up metrics to measure what matters (I’m sure you’ve heard that before). We need to know who matters and their experience influences the overall metrics on something like satisfaction or the interpretation of project value.

Metrics are only useful if they include or are representative of all stakeholders, and all interested parties, even if you then split those groups out further.

Have you ever worked on a project where when things went wrong, the sponsor was calm and measured, helping you create a map towards a resolution but backing off as required and letting you get on with the work?

That’s great.

The alternative is a much more destructive environment, where pressure from the levels above create a sense that everything has to be done now, even the tasks that don’t actually have to be done now. When things go wrong, that pressure intensifies. The team are pressed to deliver a fix to the exclusion of everything else, or to hit a milestone that has been made up by a senior leader and would never have been committed to if the full plan was understood at the time.

Where does false urgency come from?

False urgency comes from the pressure that is put on a team, group or individual to make a decision. It’s normally – in my experience – the result of some kind of failure.

Something goes wrong, and suddenly the big boss says he wants it fixed by 5pm. There’s no denying it’s a mistake that needs to be fixed, and fast, but the 5pm deadline is false urgency. Wouldn’t it be better to be fixed by 6pm and be right, rather than slap together an issue response plan and do a not-so-good job by 5pm?

The other situation I’ve found myself in is where a senior leader has committed in public – to a client, customer or during a Town Hall meeting – that something will be done by a certain date. And then we, as the project delivery team, have to find a way to meet that date. This false urgency is created by someone who doesn’t have the full information about what work is required and how much effort is likely to go into the project. But once a date is out there in public, it’s kind of hard for it to be extended without someone losing face.

How does false urgency affect people?

False urgency makes people think the situation is out of control, especially as the first deadline whooshes by. I’ve been on teams where we’ve been asked to do something asap, but it’s become clear that the solution – the correct solution – is going to take a bit longer. Suddenly, the fake deadline is swept out of the way. The fake urgency is gone. It feels like that was just a tool to get us to focus, which of course we did. And would have done anyway. We all know the problem needs resolving and that it’s top priority.

That sense of not being respected or allowed to find the solution, the pressure of having to do something just because someone says so, it all goes towards creating feelings of anxiety and anger. I know I get grumpy if I think something is important and someone then comes along and tells me it should be my most important task. It is already – but as a project manager, there’s often not much I can do beyond facilitating the process of issue resolution.

It's also tiring to be micromanaged and to be under the pressure of scrutiny.

The pressure of being in an urgent situation can make people do strange things. For example, looking busy. Busy is not the same as proactive or productive. When the bosses are circling because a client is being affected by a project issue, it’s important to look like you are gainfully employed, even if you can’t actually help the team to code the solution or run the fix or whatever.

There are lots of meetings, often to go over things that you’ve already gone over with other people. There are lots of reports. You end up defending behaviour and progress and explaining why things are taking as long as they are or involving the resources that they are.

How do we avoid this?

Given that false urgency can have such a negative impact on the team, I think it’s important to consider how it can be avoided. Sometimes – such as when your sponsor blurts out a delivery date in a client meeting and you haven’t even finished the estimating yet – you can’t in the moment. You can, however, mitigate the impact with open and honest communication and a bit of negotiation.

Be data-led, keep the communication channels open, be transparent with your sponsor and customer and avoid promising things before you have finished the planning stages. Have you ever been in a situation like this before? If you’re prepared to share, please tell us in the comments!

Last time I looked at 7 types of expense that are worth mentioning in your business case, to show that you’ve got a rounded handle on all the costs.

The Better Business Cases^TM model that I mentioned last time goes on to describe even more different cost types that you should be aware of. I did know about some of these, but this list has some in that I wouldn’t routinely think of.

We might not need to mention or use them all in business case preparation, but it is worth having a general awareness of them, not least so you can ask your Finance colleagues smart questions!

1. Sunk costs

If your business case represents a Phase 2 or subsequent investment, then it’s worth mentioning the sunk costs: the money already spent on other parts of the work that you cannot get back. These might be in contracts already issued, purchase orders already raised that must be fulfilled or previous steps of the project.

They get a mention in the business case but they aren’t part of the appraisal. In other words, talk about them so that decision-makers have the whole picture, but don’t include them in the cost assessment or budget figures for this part of the project.

2. Full economic costs

This is another term I wasn’t aware of but it only means including direct, indirect and attributable costs for each option mentioned in the business case. In other words, flesh out your finances so they show the whole, true picture. Use a bottom up approach to get the real figures.

3. Attributable costs

Wondering what attributable costs are from the section above? These are generally the costs related to staff time. If your team members are caught up delivering the project in this business case, they aren’t doing work on other business cases, that might be equally or even more important. So attributable costs are things that don’t fall into the direct or indirect category but are relevant as they round out the business case.

I think too many managers forget that if you are working on Project A you can’t be working on Project B at the same time (because they expect that everything gets done, most likely!). It’s worth calling out that if you tie up a team full-time on this initiative, their costs go towards the project and their staff time is allocated.

4. Organisational development

Organisational development costs are the figures related to change management. These are definitely worth including. I can’t even remember the number of times I’ve had a project budget handed to me and there has been no allocation for training, printing, change management, travel and room hire for workshops or town halls, or anything else. Make sure your business case includes the costs of what it will take to go from the current way of working to the new way of working, including any process updates, change activity and staff development required to make proper use of the thing you are delivering. 

5. Contingent liabilities

Now, I confess to including these in business cases in the past but not knowing the correct term for them. You are probably aware of them too: they are the expenses related to future events. For example, the costs you may incur to buy yourself out of a contract early. Make a mention of those in your financials as well.

So, we have all those, as well as capital, revenue, fixed, variable, step, opportunity costs and inflation that I covered last time.

It feels like this business case is going to be weighty! Remember to draw on your sponsor, finance analyst and the finance team more broadly for support with the numbers and to make sure your maths stacks up. Ideally, they should be providing the underlying assumptions and algorithms that make up the financial parts of the business case template. As the business case is a major input to how much money you get to do the work, it’s important.

Are you putting together a business case? This is the time of year when many project teams are kicking off new work with the lovely new budgets that are available at the start of a financial year.

The UK government (HM Treasury and the Welsh government)’s guidance called the Better Business Cases^TM model, has a section on different costs that are helpful to include in your outline business case.

Project managers don’t always get involved with business case creation but I think it helps when we are. If you are working on a new proposal, here are 7 types of cost that you can consider including as part of the economic appraisal for why the work should take place, and to show that you have fully considered all the elements.

1. Capital costs

For my projects, I’d say that capital costs make up most of the budget. These relate to buying equipment, whether that is IT kit, or in my case, machinery. They relate to costs that can be capitalised and (depending on your local regulations it might be different for you) the costs of bringing an asset into service.

2. Revenue costs

Also known as opex, these are pretty much the opposite of capital costs: things you can’t capitalise but are required for running the project. Maintenance, operational costs like some software licences, things that hit the P&L like the electricity bill and disposable coffee cups, if your project is required to pay for those.

Even if they are not necessarily part of your project budget, it is worth knowing abou tthesee and including them in the business case to show you have considered the whole life, complete costs of the work required.

3. Fixed costs

These are costs that are constant over time, regardless of how long the project goes on for. Typically for me, these are resource costs that are spread over the life of the project. They could also relate to other overheads like having to hire a portacabin as a project office on site.

4. Variable costs

The monthly impact on your project budget from these costs are variable. They tend to relate to how much of something you use per month, so it could be printing, it could be downloads of something, it could be training costs or meeting room hire.

5. Step costs

These are prices that increase as you reach a certain threshold. For example, if you use project management software you’ll be familiar with the licence model for SaaS tools where if you go into the next ‘bucket’ of users you’ll be charged an uplift. Let’s say the cost for 1-10 users is a certain price per user. When you hit user 11, you’ll be charged a different price.

This could also relate to items like post: as you ramp up receiving in items of post, your parcel handler changes the pricing structure and you end up paying more for hitting the threshold.

6. Opportunity costs

In a business case, you want to say what you’ve looked at in terms of other solutions. The model says that these should be explored in full and be representative of salary with all the on-cost (pension, employer’s tax contributions etc). These represent what you won’t be doing if you go with the recommendation: the loss of other alternatives.

7. Inflation

Yes, given the rising prices we’re experiencing at the moment, it’s worth building some inflation into your financial modelling. Your Finance team can tell you what the right amount to include is for general ‘normal’ inflation and also whether there are other rates applicable to certain elements of the business case, or the cash flow projections.

Next time I’ll look at another 5 types of cost you should also be including in your business case presentations, so watch this space!