The Money Files

One of the issues with managing multiple projects is that everyone thinks their project is top priority and they all have to show some progress by the end of the month. I wrote a book about that (inspiringly called Managing Multiple Projects) and there are lots of things I could teach you about keeping all the balls in the air.

However, today I want to focus on one thing: helping you understand what makes a project a priority.

You might think this is an odd subject, because your PMO creates prioritisation lists and everyone knows where they sit in the order. But there are many companies that don’t have that level of structure. Or they do… but everything on the list is a Priority 1.

Here are 5 signs that your project really should be a high priority project.

1. It contributes to a strategic objective

Does your project directly align to strategy? Does it deliver something, or a part of something, that is on the strategic roadmap? Can you link it to a corporate objective? If you can, then it’s probably high priority.

I believe that there is a place for non-strategic projects, as there are peaks and troughs in project work and time enough to get other things done. But if your project gets a mention on the strategy deck that was shown at the last corporate Town Hall, then it’s a high priority for the organisation.

2. It is documented as a priority

There’s an obvious way of checking: if your PMO has a priority list, where does your project fall on it? As I’ve said above, having a list isn’t always a sure-fire sign that prioritisation is actively happening. If you read through the list and see that everything is a High Priority, move on to the next criteria below to assess what your ‘real’ priority is!

3. It is an enabler

Wi-Fi upgrades, telephony, laptop replacement schedules, infrastructure projects… they might not sound top priority, but if they enable something else then they are critical.

You can’t launch a new sales portal on a creaking infrastructure. You can’t build a new office if the foundations aren’t in place. This kind of project might plod along in the background but it’s an important one.

4. It gets a lot of attention

Do you have execs dropping by your desk asking for updates? Does your project sponsor return your calls quickly?

Projects that get a lot of attention are high on management’s radar. If the senior leadership team thinks it is a priority, it probably is.

However, they might also think it’s important as it is their pet project. Check to see how many people are giving the project attention. If it’s just the one, it might be a vanity project, and not something that is important to the organisation overall.

5. It is adequately resourced

OK… this one isn’t a perfect sign. I know a few high priority, strategic projects right now that are struggling for resource.

But generally, priority projects have the budget and support to secure the resources they need. I’ve worked on projects where resources have been pulled off to go and do something else – that’s a sure sign that my project was not as important as someone else’s.

If you have the people, time, budget and other resources that you need, you can bet that someone is enabling that to happen and there are routing for the project to be a success.

Would you agree with this list? What other signs have you seen that point to your project being an important one? Let me know in the comments below!

You probably measure a range of things on your project. I’ve seen PMOs track number of open risks, projects closed this month and other numbers that are pretty much meaningless out of context. Here are 5 ways to make your metrics work better and give you more useful information, inspired by the Measuring What Matters report from PMI.

1. Measure more often

A study by PMI and PwC found that only 41% of PMOs were consistently measuring and reviewing performance. If you don’t measure regularly, how can you monitor trends?

They also found that around half of PMOs spent time communicating to the C-suite about milestones and project impacts. I know that in some organisations the PMO doesn’t have a direct line to the execs (although I think they should). Improving the perception of the PMO relies on the right people having the right information.

Action: Make sure you have a regular schedule for measurement so you can capture and track trends.

2. Collaborate up the organisation

Another thing highlighted by the PMO study was that metrics are often set by people who are not the PMO and who are not C-suite execs. Whether you are a project sponsor, senior leader or project manager, make sure you involve the right people in the conversation about what should be measured.

More collaboration between the PMO and delivery teams and the executives responsible for setting strategy should mean that you are measuring stuff that demonstrates whether the organisation is getting closer to the strategic goals.

Action: Check your measures are in line with the strategic vision for the company and that the right people were involved in coming up with them.

3. Focus on outcome-based measures

Outcome-based measures are those that reflect what was achieved on the project in terms of deliverables and change. They are different from the project management measures of time, cost and scope. (Note: those are still useful, but they aren’t the only thing you should be tracking.)

Projects exist to deliver change. That’s what is important: the impact that the work has on the organisation.

Action: Review the measures you are using to track your project and see which of them are outcome-based. Is that enough?

4. Review measures regularly – and with the right people

Once your measures are set up, keep them under review. Make sure to get input from a wide range of stakeholders: those who are collecting data for the measure, those who are using the measure for decision-making, the PMO and the project team, along with anyone else who has a stake in the outcome.

Reflect on whether the numbers or results are telling you what you thought they would. Do they provide accurate, reliable data that can be applied to different projects in a meaningful way? If not, why? Perhaps the measures need tweaking to make sure they properly serve their purpose.

Action: Schedule time to reflect on the usefulness of the measures you have in place.

5. Define success

Finally, define what success looks like. What parameters for your metrics represent a ‘good’ score? Below what level would you need management intervention? What are the red flags that would push the project into an Amber or Red status?

Capturing data is one thing – but being able to use it is something else entirely. In addition, some of the more ‘fluid’ desirable outcomes like cultural change or customer satisfaction are harder to grasp with a single number. You might need to combine several metrics to get a full picture of the current performance levels.

Action: Review the parameters that trigger action for your measures.

PMI and PwC did a survey on metrics and measurement on projects. You can read it online: Measuring What Matters.

I had a conversation about measurements recently with a PMO leader who wanted to understand how best to talk about what her team did. So are there any insights in the report that will help you if you are in a similar situation?

I think there are. Here are four of the key things that are worth looking at.

1. Measure more things

The survey points out that the top 10% of PMOs measure more than the average PMO. Quite a lot more: they tend to have 10 measures on average compared to only 7 in lower performing environments. Of those 7, generally the researchers found that 4 were linked to the classic project management iron triangle of time, cost, quality, scope.

Those metrics don’t really tell you anything about how the project landed in the organisation or whether the right project was done at all. Success in the eyes of strategic integration and execution is not often to do with whether you hit a budget baseline – especially if that budget changed during the project and was rebaselined to your new forecast anyway.

2. Make measures more effective

The research points out that there are two considerations for effective measures:

• Making sure you are using the right measures
• Implementing them appropriately.

The right measures for one project might not work on another project. Again, we see the fact the project management needs to be tailored in order to get the best results, and the PMO reporting is no different.

Some measures are worth capturing regardless: were you on time, did you deliver what was expected? But outcome-related measures like customer satisfaction, risk management and operational impact probably need to be tweaked for each project.

If you can’t tweak the measure itself, at least let project managers choose from a list of metrics so they can select how to report on the project in the most appropriate way.

3. Involve the right stakeholders

The PMI research shows that only 63% of organisations with a PMO use the PMO team as part of the development for metrics. Which begs the question: who is setting project measurements if it isn’t the PMO?

It seems to be middle management, as only 39% involve the C-suite execs. I think we can conclude that project sponsors or senior leaders decide what success will look like and what should be managed without linking into strategy or what’s actually practical and possible to measure as good practice (via the PMO).

When you adopt metrics on your projects, question where they came from. Are they part of an organisational standard created by the PMO with appropriate stakeholder input or did your boss just tell you to do it?

4. Use more tech-enabled solutions

The final takeaway from the PMI study into PMO metrics is about increasing the use of tech to measure effectively. Many online tools help you measure the impact. Whether you have advanced strategy execution tools or a simple online survey, tech opens doors to be able to repeatably and reliably collect data to help us assess success.

Many PPM tools collate data by virtue of the fact that we use them everyday for project management and scheduling. You can extract data about timelines, resourcing and budgets that helps inform future projects. However, it seems like budget is a barrier to investing in the tech that will help us do our jobs better. If you’re still stuck on spreadsheets, keep lobbying the powers that be for a better solution!

The Standard for Program Management, Fourth Edition (2017) defines Program Financial Management like this:

Activities related to identifying the program’s financial sources and resources, integrating the budgets of the program components, developing the overall budget for the program, and controlling costs during the program.

As you can see, there’s a lot more to crunching the numbers for program finances than simply having a single budget spreadsheet!

Let’s look into that definition a bit more and I’ll give some examples from my work as a programme manager (as we would spell programme in the UK).

Identifying financial sources

This means finding out where the money is coming from. In a large program, you might have a single source of funding, or several. Research projects, for example, might have grant income, so within the program you might have several funding sources.

On the large healthcare program I led, the Finance team created a brand new cost centre for the work so everything could be tracked in one place. Funding was centrally agreed and moved into that cost centre.

Identifying resources

This sounds easy, but in practice a large part of my role as a program manager was finding the right people to do the work and then helping them find the time to actually do their tasks! Admittedly, it’s a lot easier if your program has dedicated resources.

For some of my work, we’ve been able to budget for backfilled resources so we could bring people out of their day job and second them to projects. Then the project could pay for someone to cover their job while they dedicated their expertise to the work.

Integrating budgets of program components

Programs are made up of several (sometimes many) different projects and often a BAU component too. As a result, the program manager has to juggle the budgets and create a master, summary budget.

There’s work to be done here in making sure the whole thing is put together holistically and with the least repetition possible. For example, if you are securing a legal expert to support on one project, it makes sense that they are also kept on to help with another project as they will have gained some awareness of the program overall and the company. If the timelines can be made to work, or you can pitch a larger engagement for the legal consultant, you may be able to secure their time to get consistent resource (and maybe even a cheaper price for a longer engagement).

Developing the overall budget

When all the program components are effectively budgeted and you can bring the whole thing together, the program manager can create an overall budget and a way of tracking against that.

Controlling costs

Controlling costs is part of project, program and portfolio management, so it’s definitely up there as an important activity for program managers!

Luckily for me, my program costs were so large that I had the support of the Finance team – I think the company wanted the extra governance and accountability for having accountants pour over the details. Project budgets and costs were centrally managed and controlled in our cost centre. Tracking became a job of getting the data and consolidating it. Controlling costs became an issue of making sure change requests were done in an appropriate way and ensuring there was enough oversight of where we were spending the money.

We did not use EVM to track and monitor costs, but this might be part of your program management environment. If that is the case, you’ll probably have software to help you track and monitor costs and also to support with the reporting.

Summary

Program financial management might seem a daunting task but it’s very similar to managing your project budget. The numbers can be a lot bigger, but the maths is the same principles. What’s your experience of program financial management? I imagine it looks very different for every program as there are plenty of ways of setting up programs, and many variations on what financial management is necessary and appropriate.

Do you have a formal Change Control Board (CCB)? If not, this is the perfect time of year to be thinking about levelling up your processes and putting new ways of working in place to formalise the way change management is done across projects, programmes and the portfolio.

A Change Control Board is simply a group of experts that represent different organisational departments and who oversee both the process of change management and the different changes being put forward.

At a project level, your CCB is a group of people who know the project well and who can assess project-related changes, but at some point if your project is making changes to the live environment, like most IT and business change projects do, the change will need to be submitted to the wider, department or organisational CCB.

The role of the CCB is to:

• Assess the change
• Approve the change – in my experience, if the project team and project sponsor has already approved the change, there are few reasons why the CCB would then block a change
• Schedule the change
• Keep records about changes.

How it works

In our CCB, the functional lead or the project manager had to present the change. We had to talk about what it was, why it was useful and what it solved, and then make the case for whether it was a priority fix or not. If the change was considered a priority, it could go in the same day (mostly). If it wasn’t, it could be packaged up with a bunch of other small changes and go in the next release.

That made it easier to communicate changes to the end users.

Discussing the change

First, the change should be analyzed and discussed to see whether it has impacts beyond what the project team can comment on. The Change Control Board is convened to do that. I think the CCB is a really useful group and we relied on it in my last job. Our CCB looked at operational and project changes so the team could see the impact of ‘normal’ changes as well as the project-related ones.

I think it’s important that the CCB is made up of a cross-organisation group. It’s too common for changes (especially IT changes) to go in and for there not be a full understanding of the business impact somewhere else down the line. Complex ERP systems like SAP make that more likely, so a group of functional consultants getting together to discuss changes before they happen is a good thing.

I’ve had some changes rejected by the CCB because they didn’t have enough information to make an informed decision, or because something else was going on and they needed to wait on that, or because there was a change freeze. There might be many reasons why your change doesn’t go through.

Scheduling changes

The CCB can also schedule changes. There are normally scheduled windows to put changes in, especially in the live IT environment. That helps the support teams and the users know what is going to be different and what to look out for when they next log in.

Scheduling as a team also ensures that conflicting changes don’t get put in on top of each other. For example, if my project is updating the list of available categories in one part of the system, and another team is also updating that part of the system but taking away the category feature (that’s a bit extreme, but you see what I mean) then those conflicting changes can be discussed and overseen in an appropriate way.

It might involve putting them live in a particular order, or prioritising the changes so that one piece goes in this time and the additional change is put in next time.

I remember being told a story of a change in a data centre where engineers were working on cabling and flooring on both sides of a server stack. Without the support of flooring on both sides, the server stack toppled over! That’s the importance of making sure that changes are managed in a scheduled and sensible way.

We also had an emergency change procedure for anything that could not wait until the next release. On the SAP projects, for example, mostly things could be scheduled in a batch and changes pushed through on a fortnightly basis. But sometimes it was important to fix an issue straightaway without waiting until the next release. For example:

• Bug fixes
• Issues that affected customers
• Changes that went in and then didn’t work as expected.

All of these are emergency fixes to live systems that wouldn’t be appropriate to delay, and they are all issue-related, not nice-to-have features.

How does your CCB work?