The Money Files

I’ve been managing a programme for a while now, and it’s quite different from managing projects, or the very large projects that we call programmes that are really not programmes!

Programmes need their own budget as well as the budget of the projects, and here are the things I think should be included in that.

1. Costs of running the programme

It seems silly to point it out explicitly, but there are costs incurred from running a programme with a programme management structure.

For example, my time as programme manager needs to be costed and included along with any support resource from the programme office. Even though we are not full-time, the programme wouldn’t run without us so our costs have to go somewhere.

Ideally, there would also be a programme-level risk budget for handling unforeseen issues.

You may also find that on your programme there are other costs associated with running the programme, such as office space, software licences for third parties to access your programme management software (which is likely to be the same project management software everyone else uses, so hopefully not too large of an overhead there).

2. Assurance costs

Are you planning on having internal (or external) audits and reviews as part of the programme? If so, those costs should be picked up by the programme budget.

Internal reviews, in my experience, don’t cost anything except time, but if you are bringing in consultants or external auditors, there is definitely a cost associated with that (as well as time). Certification or compliance programmes may have extra costs here too, for example, if you have to comply to certain standards, going through the accreditation process is both time-consuming and normally costs something. There’s also often an annual cost to main the accreditation so factor that in too if your programme is multi-year.

Plan all those costs into the programme budget at the frequency and estimate required.

3. Benefits realisation costs

Benefits might be realised at project level, but you’ll likely have some programme benefits to track as well. And the cost of delivering and tracking those should be included somewhere – in your programme budget.

For example, you may need to programme software to create new reports. You may need a new role, and someone hired to go into that role. Some benefits might include making staff redundant due to organisational restructure, and there are costs associated with that activity too.

Plan all of those in at programme level. You may find that it’s useful to take the project-level benefits realisation costs into the programme budget as well so you can track benefits all in one place, but that’s up to you.

Project costs

Of course, there are costs to running the projects too, and in your overall programme budget, you’ll want visibility of those for forecasting and tracking. But these are the ‘obvious’ costs so it’s likely you already have them.

The project costs would normally include the large infrastructure type items that are necessary for the programme to move forward. The first project would normally take the hit for any large infrastructure-type investment, but that makes the business case for that project rather wobbly. You might decide that large capital costs are picked up by the programme as an overhead instead, and then each project goes forward on its own merit without having to fund the infrastructure required to make it and future projects work.

Talk to your financial analyst or project accountant for how best to apportion the costs across the programme and projects so it’s transparent and reasonable.

The PMBOK® Guide – Seventh Edition talks about four different ways to define business value.

‘Value’ is quite a vague term when it’s used in everyday speech, so I think it’s useful to have something to hang a definition on when we’re using the term in project management.

The Guide does specify that there are lots of aspects to value, including non-financial considerations, and that the four ways that are listed are only some of the ways that you could measure value. However, they are a good starting point if you’re trying to have conversations with execs about what projects you should work on – you do need some kind of idea of what value means.

Here are the four metrics that you can use to measure value, as outlined in the PMBOK® Guide.

1. Cost benefit ratio

This ration works out the present value of the investment compared to the initial cost, basically, do the costs outweigh the benefits (if they do, you probably shouldn’t start the project unless there is a strong justification for doing so in the knowledge that it will cost you more to deliver than the benefit expected).

2. Planned benefits compared to actual benefits

This is a bit of a weird one if you ask me – until you start delivering, you don’t have any actual benefits to compare to. It’s fine if you want to review value after the project is complete or while it is in progress, but it’s not a metric you could use for project selection.

You’d have to use the planned benefits, and that really is the planned value of the work to the organisation – so it’s just a different way of talking about the other metrics until you have some actuals.

3. Return on investment

This is my favourite of the four (is it odd to have a favourite value metric?). Probably because I use it the most and it’s very clear on what it is. It’s easy to explain to stakeholders and finance teams seem to like it.

Plus it’s easy to work out.

ROI is the financial return compared to the cost, so it’s helpful in project selection. However, you can use it throughout the project to refer back to whether or not you are on target to hit that particular ROI – useful to do when your costs are going up.

4. Net present value

NPV used to confuse me because it’s time-phased, but once you get your head around it, it’s straightforward. It’s a very common metric in use for project selection so it’s definitely worth taking the time to understand how it is put together and what it means.

You can measure NPV throughout the project and check that the investment still holds up.

With all of these, as long as you keep measuring if you are getting enough value out of the project, you can make an ongoing commitment to keep the work going. If the numbers point to a trend of decreasing value, there is likely to be a point where you’ll want to stop the work, because the amount of effort expended isn’t worth the value you’ll get at the end of it.

Of course, there are some projects where the value is simply being able to continue to trade or operate within a legal framework, or benefit related to social/corporate responsibility or sustainability, so you might find it irrelevant to track metrics like the ones above. The takeaway from all this is to work out what ‘value’ looks like to your team and your project, and measure that.

How do you do it? Let me know in the comments!

Mostly on projects we think of ‘resource’ costs and ‘resources’ as people. Because mostly, with the majority of office-based, corporate-led projects, what we need to get the work done is people’s time. And people are expensive.

Meetings in particular are often left out of the time-budget. We’ve factored in the cost of the hours required for them to deliver their tasks, but not for them to show up to project team meetings, lessons learned calls, extra meetings because something in someone else’s area has gone wrong, and so on.

So factor in enough buffer time for the overhead of meetings for resources that are booked out to do work on the project.

But what about the other things we need to cost out in project budgets that aren’t people’s time? There is a whole host of smaller (and bigger) costs that it is worth building into your financial planning if they are relevant to you – because even the small costs start to add up when you are asking for ‘real’ money (versus people’s time which is wooden dollars if they are internal resources).

Here are 12 non-labour costs that you might incur on your project.

1. Room hire and hospitality

In my last job, we had open plan office space and very few meeting rooms. They were reserved for the exec, and it was difficult to book them. Even if we did book them, I remember being bumped out of a room because someone more important than me needed it (they did give me notice, to be fair).

Room hire costs might be something you need to factor in, and with that comes catering for people attending.

In fact, it’s not just meetings. On one project, the team had a portacabin on site as their project war room. That was a space we had to pay to hire.

2. Event hosting

Event hosting also falls into the bracket of room hire and hospitality – but it’s not necessarily project stakeholders attending.

Perhaps you have clients who need to see the new release of a software product. Perhaps you’re running an industry conference as part of the product launch. Perhaps you have training events for internal staff who need to travel and be fed when they arrive.

Training events might also incur the cost of producing materials for the delegates or paying an external trainer, as well as hire for the AV kit in the room.

3. Admin support

Sometimes projects require admin support.

You could buy in a VA (virtual assistant), or even buy access to an AI-powered assistant for meeting note taking or meeting booking, and all the many other things AI can do for you these days.

You may also need transcription or translation services, depending on what you are working on and who is involved.

4. Travel and accommodation

On my first project in my last job, there was a lot of travel for the implementation teams. They were out on the road 4 days a week during most of the go live periods, supporting locations to implement new processes and tools. As a result, we had huge expense bills for petrol, rail travel, accommodation and food.

Fortunately for me, most of it went through the corporate expense booking system so all I had to do was add the numbers to the budget at the end of every month. It was part of the cost of doing business and keeping the project going.

These days, we travel less for work and do a lot more remotely, but you may still have to factor in days out of the office and on the road for some team members.

In addition, your in-house guidelines might allow for per diems or expense allowances for colleagues out and about. Be clear on whether you have your own internal rates or are using industry published guidance for these so you don’t have any queries when people submit their expenses.

5. Tech

Technology costs crop up even in projects that are not tech-led.

For example, you might need to access webinar tech to deliver training, or buy an online learning package. Even loading training videos to your existing online learning platform might incur a fee.

Most of the tech costs I have been involved with on projects come from having to buy hardware items or software licences. Those items rack up the cost, but they are often clearly known and factored into the budget from the start.

In addition to those items above, you might also have these on your projects:

• Other materials
• Utilities if these are costed to your project or required specially.
• Printing and binding (less used now with the focus on sustainable project management and green delivery, but there might be some things you have to create as hard copies)
• Web page and creative supportive
• Subscriptions
• Photography or photocopying
• Subcontracts – again, normally clear and well-known at the outset.

Link these costs to the person who is incurring them in the work package so they can be accounted for appropriately in the budget.

Have you ever been caught out with a project cost (and was it on the list above)? Share your non-labour common expense items in the comments below!

We talk about the cost of change often on projects. If you’ve been in a delivery role for a while, you’ll no doubt be familiar with the idea that if you find something you want to change later on in the project, it costs more to make that change than if you identified it at the beginning.

That’s typically because there are fewer things to unpick and less rework required because you haven’t got as far yet. You can change the buttons on the widget if you haven’t manufactured any buttons yet. Just change the drawings or spec and you’re done. But if you have a factory stacked with boxes of buttons, then there’s a bigger cost involved – all the pre-made buttons need to be scrapped and you have to manufacturer a bunch of new ones.

Understanding how much wiggle room there is for change is important in understanding how easy it will be to make change later, and how agile (with a small A) you can be during the project when it comes to addressing defects or changing your mind.

Bridge building, button making, house construction: all these are hard to change later. But business process change, website design, or software writing probably have a different result. You can tweak a process later on, and while a group of different stakeholders will be affected, it is certainly possible (and cheaper) to do in a way that changing the foundations of a building once half the building is built is not – it’s a different kind of conversation, and a different kind of cost involved.

How easy it is to make the change, and the cost of change, play alongside each other throughout the project.

The PMBOK® Guide 7^th Edition talks about Boehm’s cost of change curve. It sounds like common sense, but it is also important to challenge our assumptions and what we think we know. There is also a difference between bugs and changes that arise through active decision making. Is the cost of change the same for each on your project?

It might be possible to add a financial amount to each change and each defect so as to work out the potential cost of defects or changes addressed later in the lifecycle, but that’s probably overkill for most small and medium-sized companies, and organisations that are not software houses with plenty of data to analyse for this. Unless you’ve been through many product recalls or can model what it would look like to address a component failure, you might not have the data or time to create any meaningful cost models.

Instead, bear in mind the general principle: what is it going to mean to make a change on your project, for your decision makers, in your environment, for the development and delivery methodologies that you are using? Are there cutoff points? Points of no return?

Really?

Generally, as project managers we can make anything happen with enough money, time and resources – whether it’s the right decision to do ‘anything’ though is a completely different conversation.

It is sensible to think about the cost of change before you need to make any changes, and to consider how you’re going to avoid too many potentially costly changes. For example:

• Decent requirements
• Good quality stakeholder engagement so everyone is on board with the deliverables and no stakeholders are left out (as ignored stakeholders tend to want to insert  their requirements on to the project later when they do find out about it.
• A good change control process
• Robust attitudes to quality deliverables, quality control and assurance.

How do you think about the cost of change in your projects? Is it a discussion you have with the team? I’d love to know how you work to minimise it – or if you embrace it and go with the changes! Let us know in the comments below.

I’ve chosen a bad headline for this article: I have an issue with assigning tasks – it doesn’t feel like the collaborative, co-created environment I would like to work in. Ideally, we’d meet as a team to do some planning, have a workshop or two and then tasks would be selected by the right people. If we had Kanban boards, team members would be able to select what they want to work on – because as long as they are working on something, the board would manage the priorities and it would be all good.

However, sometimes on projects you do need to reach out to people and assign them work, even if you ask nicely. Sometimes it happens because it’s obvious who is going to do the work because there is only one person in the organisation who can do it anyway.

Let’s take ‘assigning’ in the broadest possible sense, so it doesn’t mean ‘expecting people to do stuff on a project without engaging them’. Because regardless of whether the work is obviously destined for them, it’s always polite to ask.

Here are 5 considerations to take into account when distributing tasks to team members.

1. Capability

They have to have the right skills. If you are looking for colleagues to contribute to your project, consider the tasks they are going to be doing. The person who ends up with the task has to have the skills to carry it out.

Of course, there are exceptions to that, and we often use people working through an apprenticeship or less experienced staff to complete tasks as part of their on-the-job learning. They will be supported by an experienced colleague, but if you don’t learn, you’ll never get the confidence or skills to do it yourself in the future. Factor in additional time, support or training budget if necessary so you can make sure the people taking on tasks are equipped to do them.

2. Cost

People need to be budgeted for at different rates. Consider the cost impact to your budget if you assign tasks to people who are expensive!

3. Availability

People’s availability is a constraint on your project timeline. If the person allocated to the task is on holiday, they won’t do it, and the task will be late. That might be fine – perhaps you have the flexibility to schedule around the best person for the role and the work can wait until they get back.

Perhaps you have a fixed date to hit and need to find someone else.

4. Location

Does it matter these days? I think it depends on the role. If I want in-person, classroom based train-the-trainer training so I have a team equipped to go out and deliver on site training, then I do need them to be within travelling distance.

If it’s a graphic design job, they could be anywhere.

Think about where the team members are based and whether that matters to the task in hand.

5. Cultural add

I was talking to someone the other day about one of their colleagues who was considered a ‘toxic cultural fit’.

The challenge with cultural fit is that it can be interpreted as simply hiring people who look like you and think the same as you, so they slot neatly into the environment without disruption. That’s not what this is about. Consider ‘cultural add’ instead. We want diversity of opinions. We want new ideas and different interpretations. We want disruption and challenge.

The people on your team should lift you up and make the team, and the solution, better.

What do you consider when working with your team to divide up the responsibility for tasks? Is there anything else you take into account? Let us know in the comments!