The Money Files

These days, project teams are expected to do so many different things, from deep dive root cause analysis to making sure that projects align to strategy. As a team, you’re both in the weeds of the project and also trying to communicate the big picture to stakeholders.

Let’s face it, it can be difficult to have all those skills – I mean, have you seen the latest PMBOK® Guide?! Between that and the Standard for Project Management there are hardly any management and leadership skills that a project manager is not supposed to have.

However, we aren’t able to say, “I’m not very good with PowerPoint so we won’t create slide decks for status reporting.” We have to be all-rounders, even if we aren’t very good in some areas, or don’t enjoy those tasks.

Here are 3 skills for project managers that I know from my mentoring work that people in project roles have difficulty with. I’ve also included some tips for how to improve, if you choose to do so. If you lead a team and find your colleagues struggle in these areas, perhaps the ideas will help them.

1. Risk management

Large programmes may have a dedicated risk manager on the team, but if that isn’t you then you’ll have to get stuck in with risk identification, analysis and management yourself. In my experience, there are several areas that people struggle with:

• Risk identification: making sure it is not a one off exercise
• Risk analysis: using metrics to quantify the risk instead of just guessing what the impact might be
• Risk management: defaulting to mitigation strategies or ‘do nothing’ because the alternatives are poorly understood or too hard.

Address this by:

• Making sure the team has regular points where risks are discussed. You can put these on the plan.
• Giving everyone the tools to analyse risk. Use software. Provide details of what it means to be a ‘low risk’ in terms that are financial, reputational, operational and more so they are not guessing
• Talk about all the different options available to you and manage actively so risks are reduced, not just put on a list.

2. Task Management

This skill is all about managing your To Do list and making sure tasks have owners. It’s also time management overall on the project, so it encompasses resource levelling and capacity planning so you don’t overload people with too many tasks.

People seem to struggle managing their workload and time, and that leads to them feeling overwhelmed and overloaded.

Address this by:

• Making sure everyone knows what is a priority task and what can wait. That will help people understand how they should be spending their time.
• Consider using timesheets to track where time is being spent, if you don’t already use them.
• Use milestone schedules to draw attention to the next big milestone coming up.

3. Managing multiple projects

These days, most people are managing more than one project. There are still people who lead one large, complex project, but many people are finding themselves running several initiatives at the same time, sometimes with the same resources.

This can lead to each project inching forward at a snail’s pace, lack of understanding about which project should be worked on, feeling overwhelmed as your To Do list encompasses several projects, dealing with conflict between stakeholders, all of whom feel their project is the top priority.

I wrote a book about this exact problem, which came out last month, so check out Managing Multiple Projects from wherever you buy your books if you are struggling with the juggling.

Meanwhile, here are some tips to help.

Address this by:

• Prioritising projects. Make sure you know and are telling people what priority their projects have so they can apportion their time appropriately.
• Using software to track actions. I’m a big fan of pen and paper but even I have moved to digital task management to keep track of multiple projects.
• Time-boxing instead of multi-tasking. Block out time for a project, or for similar tasks across projects (like status reporting) as this is more efficient.

What other skills do you think are key to project management but are actually pretty hard to do? Let me know in the comments!

Let’s say you have been through your programme and are ready to close it out. There is obviously quite a lot to do, and the finance elements will be part of that. Here’s what to consider when closing out the financial management of a programme, inspired by the Standard for Programme Management.

Benefits stewardship

The programme will have created benefits, some of which have probably been realised as the work progressed. Towards the end of the programme, you may need to estimate the ongoing costs for making sure those benefits continue to be realised. For example, maybe recruiting an additional person to manage some deliverables once the programme team is stood down. This should last for as long as the benefits are going to be tracked for, or as long as you think is appropriate.

Any ongoing costs that will be passed to the operational teams should be made clear and budgeted in their ongoing profit and loss accounts for the department.

Leftover funding

Will you have any money left at the end of your programme? Probably not – in my experience project and programme teams tend to spend everything allocated to them!

On the off-chance that you do have funds left – let’s say, in the case of closing the programme a little earlier than expected – you should be in a position to hand some funding back. Any contingency funds that have not been used can be returned to the corporate ‘pot’.

Reporting

You’ve been creating financial reports for the duration of the programme, and those will now stop as the programme is wound up. However, stakeholders may be relying on that information. If there is the expectation that some of the financial reporting is still required, perhaps in a slightly different or amended format, you should put in place options to make that happen.

For example, perhaps another department can pick up running the reports, or they can be automated.

Tip: Even if you are automating the reports, please make sure each report has an owner! When we migrated a load of reports from a legacy system into a new one we weren’t sure which reports were used and which were no longer required because there was no data ownership. We didn’t migrate a bunch of them, figuring that if they were missed someone would say! Nobody said anything, so it’s probably those were simply no longer required, even though the system produced them regularly.

Sustainment

Sustainment of a programme is the work required to make sure the outcomes are maintained going forward, once the programme structure itself is no longer there to support them. Beyond benefits, there might be some additional funding required to sustain the programme’s vision, achievements or outcomes. For example, perhaps you implemented new tools and now the business needs to have someone in post to maintain that software.

In my experience, people who enjoy the environment of delivery are not always the same people who enjoy the day job. You may find that programme resources are not interested in staying on in ‘day job’ roles to support the ongoing running of whatever needs to be sustained, so you could end up having to budget for hiring new roles.

Close out checklist

At the end of your programme, check to make sure you have the following aspects covered from a budget perspective:

• Financial inputs to the programme closure report and any final financial reports or closure statements
• Updates to the financial management plan if necessary
• Updates to the lessons learned database or organisational knowledge repository
• Any related documents that might be useful in the future
• All invoices and supplier contracts wrapped up and closed
• Programme budget and cost centre/cost codes shut down so no further work can be allocated to them.

What else would you consider when closing out a programme budget? Let me know in the comments!

Strategic thinking is one of those skills that gets tossed around as something project managers should have. But how can you be more strategic in a practical way? I’ve been thinking a lot about this recently, and here are 3 things I think you can do as a project manager or leader of a project delivery function to try to bring more of the ‘strategic’ into the way you work.

1. Get involved with business cases and proposals

First, lobby to get involved with business cases and proposals. The more delivery expertise we have involved in the initial stages of a project, the more likely it is that the project will be able to actually hit its goals.

Have you ever been involved with a project where you’ve been handed something to do and the sales people have made promises that you can’t deliver on? Then you’ll know what I mean!

When project people are involved in business cases, in my experience you’re more likely to end up with a timescale that’s achievable and a resource plan that reflects the real amount of resources likely to be consumed by the work.

It’s even better if you can lobby for a seat at the table when the 3-year plans are being drawn up, so your top level project people, like the Head of PMO, get involved in creating the strategy in the first place. That provides a real insight into what initiatives are coming and how the delivery teams can help.

2. Use the project assurance function as a check mechanism

Project assurance is a way of checking that what you think you can do is actually achievable. It’s their job to pick apart your plans and proposals and apply a sense of real-world pragmatism. They can also help identify whether there are any resource gaps, strategic holes or other issues that you haven’t seen.

After all, as a project manager I’m sometimes so close to the information that I can’t see the bigger picture enough to realise that this project will clash with something that someone else is working on – but project assurance has the bigger picture and can point that out.

If you don’t have a project assurance function, ask a colleague for their opinion and talk them through the plans, asking them to basically pull them apart. Ideally, to be able to add some strategic oversight to your plans, this should happen around the time of the business case or PID. By the time you’ve got to creating a schedule you’ll be looking for a different kind of peer review.

3. Share what you know – but only what you know

My third tip is something I learned from Tony Meggs, Chief Executive of the Infrastructure and Projects Authority in quite an old article now that he wrote for Project magazine, but it has stuck with me. He said: Only announce what you know.

We know this in theory, so it’s not news to you, I’m sure. However, many project managers are ‘encouraged’ to share dates before we are ready, or pushed into committing to dates publicly before we have all the information to support the fact we can deliver to them.

So, if you want to be a strategic operator, only share what you know to be achievable. That goes for delivery methodologies as well. Meggs talked in the article about not committing to anything unless you know it to be true, including how the work would be delivered. If you are going to partner with someone and there’s a robust contract in place, by all means announce it. But don’t announce your intentions before they are fixed in stone because if it doesn’t happen you’re then having to walk back on the messaging and that can be damaging.

We can do this as project managers on a small scale, by giving our teams the space to come up with the best methods and timescales before we announce them to sponsors, but also on a strategic level, by ensuring there is a communications plan in place that supports the bigger picture messaging for the project, programme or even the portfolio.

Do you do any of these already? How are they working out for you? Let us know in the comments!

At the EVA conference in London in March, I had the pleasure of listening to Gary Hill, Co-chair of PsACE, the Public Sector Advisory Community for Estimating. He was talking about the importance of estimating and how the community helps shape the professional estimating done on public sector projects in the UK.

The purpose of the group is to simplify, standardise, systemise and professional project estimating process and capability across the public sector. He shared their vision, which is to bring together experts across government and client organisations to promote leading practice in estimating, underpinned by an ethos of trust and collaboration. I like how he talked about leading practice instead of ‘best practice’ because as we all know, there isn’t one definitive best practice for pretty much anything in project management.

He talked about how the community started in April 2019 when someone reached out to him and asked for help with something. “It started over coffee and turned into a beer,” he joked. The community sets out to address the problem that many project managers have in all aspects of our work: where do you go for advice, how do you know if that advice is any good and who says it’s good anyway?

To find out where good practice was in the public sector the community carried out a benchmark of 7 government departments where they measured good practice. Surprise, surprise, no department was good at everything.

Today, the community is sponsored by IPA, the Infrastructure and Projects Authority, which Gary said gives the community’s work more weight and more chance of making things stick. They really started to gain traction when they were mentioned in a government select community discussion, and membership started to grow.

It’s a volunteer-led community and Gary shared the common problem that many volunteer-led communities have: everyone wants to get involved because it’s a good idea, but everyone has a day job to do so it’s hard to get people to take on jobs.

Next up on the agenda for PsACE is to write to each permanent secretary in the UK government and ask them to support the community’s work, so that’s a large piece of stakeholder engagement to do.

In terms of what they actually do, Gary explained that PsACE was involved in providing input to the IPA estimating guide, and was represented on the committee preparing British Standard 202002 for Project Controls.

There are current workstreams covering:

• People capability: creating a course on estimating
• Data platform: collating data for benchmarking
• An advisory panel: to provide deep dive reviews of papers and initiatives
• Guidance for Senior Responsible Owners: to help SROs understand estimating
• Group conference: to bring together the community for a conference
• Leading practice: to identify leading practice and launch a maturity assessment.

I found it really interesting to see what a grass roots effort could do, and how powerful it is when experts come together with a common goal of simply wanting to share knowledge and do things better.

Gary shared his vision for the community, and I think it seems hugely realistic given the momentum behind PsACE at the moment. He talked about how the long-term goal is to align policy, data and expertise to encourage informed decision making to achieve more predictable outcomes. That’s something worth striving for, don’t you think?

Do you have a community like this where you work, in your industry? Let us know in the comments!

Last month we looked at what goes into a programme financial management plan. One of the components of that document is, of course, the initial budget. You can’t track what you haven’t baselined, so there is an effort involved in making sure that the programme budget is put together in a robust way.

Creating a programme budget that is appropriate, timely, relevant, accurate, detailed enough to get through the scrutiny of the CFO, defendable, transparent and more is a huge, time-consuming task.

So where do you start?

Creating the programme budget

The initial programme budget is put together in the same way that a project budget would be: you bring together all the financial information you have from the business case, estimates, quotes, contractual arrangements and more to plan out what money is available and when it will be spent.

With a programme, you might also need to work out where the funding is coming from and on what schedule. For example, if it’s a grant-based programme of work, perhaps funding is issued in tranches, or made available on the completion or publication of particular milestones. If it’s a multi-year programme, perhaps funding is only available for this financial cycle and the expectation is that more funding will be available from next year’s pot.

Agree financial metrics

Next, work out how you are going to track and monitor the budget and what metrics will be used for benefits tracking. Again, this is no different from project budgets, although the figures might be larger and you may also have opex costs to consider – many projects are able to capitalise their costs so as a project manager I rarely had to worry about opex tracking.

The financial indicators are important because these feed into the health of the programme and will be reported regularly. But on a programme that spans many years and perhaps has difficult-to-quantify benefits, how will you check that work is proceeding as it should? Earned value management is one way, but if your company isn’t set up for that you’ll need an alternative.

The metrics you choose for indicating the financial health of the programme and also the benefits realisation measures will very much depend on what the programme is delivering. Sellafield, which is a multi-year nuclear decommissioning initiative, has a 20-year corporate plan. However, they have set out very clear milestones for each project as part of the transformation timeline.

A digital transformation programme spread over 2 years would have very different financial constraints and would be tracked with different metrics.

You may find that validating the metrics as you go is a suitable approach, if all the stakeholders buy into that. It’s important, however, to get the metrics as ‘right’ as you can because future decisions will depend on them. As you report progress, produce updates or even make decisions to move into different stages, you’ll be presenting the financial numbers using the measures for performance tracking that were agreed when the programme began. So it’s worth spending some time making sure they are the right ones and that people understand them.

Financial risk

Part of the budget planning is also being aware of the financial risk. In Sellafield’s case, for example, the timescale spans 4 government spending reviews which may impact the funding available to the team.

There will surely be budget-related risks that should be added to your programme risk log. They are likely to include similar risks that you’d see at project level, but with a programme focus, such as:

• Changes to exchange rates
• Changes to the price of goods or services
• Strategic changes that alter the course of the programme

There will also be risks that are more programme-focused, specific to your particular programme.

The more risk analysis you do, the easier it will be to calculate an appropriate risk budget. Be careful not to count the risk budget twice, once at project level and then again at programme level, if it’s for an escalated risk.

All this goes into the mix for working out contingency appropriate for the programme, and at what level you wish it to be attributed to the work. At project level? At the overall programme level?  Some mix of several methods for assigning contingency?

Ultimately you end up with a programme budget that will no doubt change and flex as time goes on, but should give you a reasonable baseline from which to start.

How do you know when you’re ready?

The outputs of getting ready to track your programme budget will tell you if you’re ready to go ahead. You should have the following:

• The programme financial management plan including the metrics you will use to track performance
• The initial programme budget, made up of the elements above
• Programme funding schedules showing where the income is coming from
• Payment schedules for each project, component or workstream, at least as far as you know them right now
• Operational costs for the programme e.g. resourcing that cannot be capitalised
• Risks for the risk register.

When all those things are in place, I’d say you were in a pretty good position for the programme’s financial management. What would you say?