The Money Files

What does it mean to manage a portfolio? And what does portfolio management look like? For most of my career I have been involved with IT portfolios that were a blend of business-led projects and operational work. However, portfolios can be department-based, geography-based, customer-based or whole-company, or even another split. Basically, a portfolio is just a way to group work to make it easier to manage, monitor and control.

I think there are 6 main responsibilities for a portfolio management team. I’m sure there are more, but these are the main things that I feel form the priority To Do list for people in that role. The 6 features that make up portfolio management are below.

1. Assessing ideas for projects

Ideas for projects can come from anywhere, but often they come from people already working within the organisation, who are involved in projects somehow. For example, project or product teams could be working on one initiative, receive a change request, and realise that would make a great addition to scope, even if it cannot be incorporated into the project right now.

The portfolio team should be on the look out for relevant project suggestions, making it easy for people to put forward new ideas. Then they should review and assess suggestions. That list then feeds into the next key feature of portfolio management: deciding which projects to do.

2. Prioritising projects

Next, we have prioritisation. Part of the role of the portfolio team should be prioritising the order of projects and deciding when projects should start. Some lower priority projects might need to be started work if, in fact, they provide the infrastructure or enabling architecture for more important projects. The team should consider the whole portfolio and make choices based on that, as well as the relative priority of individual projects.

3. Strategic integration

Projects don’t exist in isolation, so although the portfolio team may have quite a lot of say over what gets done and when, based on the results of their assessment, there’s also a job required to align what project work is proposed with the rest of the business strategy. This draws on the ‘run the business/change the business’ approach, where some teams focus on delivering new stuff and others focus on keeping the business going. Either way, both ‘sides’ of the organisation should talk to each other.

The purpose of the alignment is to make sure the overall strategy can be delivered, but also to make sure risk management is carried out in a ‘whole company’ way. It’s no good having a risk-heavy portfolio if the operational side of the business is also falling on the side of taking chances. Overall, the organisation’s work should balance a risk profile that is acceptable to the leadership team. Perhaps they are OK with taking risky measures – I wouldn’t be though.

4. Governance

The whole point of using portfolio management techniques is to improve oversight and decision making – in other words, to put decent governance in place. That includes project steering groups or project boards (and the programme equivalent) as well as monitoring the delivery of the work inside the portfolio.

Monitoring and oversight might be a light touch or involve multiple layers of approvals, depending on the investment and method, and the consequences of decisions taken. It will help to have some documentation here to spell out exactly what is required.

5. Tracking results

Yes, benefits tracking! Someone has to be responsible for tracking benefits, and the portfolio management team is in a good place to be able to do that at a portfolio level. You may have individual programme managers or department heads tracking benefits for their areas, but if you want to see the results at an organisational level, this data needs to be consolidated at the top. And de-duplicated, because you don’t want benefits to be counted twice (I’ve been there – it doesn’t look good).

6. Portfolio management processes

Finally, the portfolio management team is responsible for the management of the portfolio. I know, it sounds obvious to write that but someone has to be the gatekeeper and guardian of the processes, life cycles, review process, approvals, funding requests, paperwork and people. The day-to-day operation of the portfolio is also a key responsibility.

In your experience, what else do portfolio teams take responsibility for? What are the other key features of working in portfolio management? Let us know in the comments below!

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?

Q1 tends to be a time when new budgets are approved and that means we’re starting to see requests for contracts with suppliers trickle through the PMO. It always takes a few weeks for budgets to get released, even if the intention is to start the work in January. By February, project teams are ready to get started, knowing that any further delay in the admin is going to put pressure on their ability to deliver by the dates from the business case. And that’s why all the supplier agreements seem to be floating around at the moment.

The infographic below talks about the major groups/people involved in putting together and approving supplier contracts for new third parties, but it’s the same people involved in renewing deals and reviewing an existing supplier to see if we want to give them more work.

 As with any internal process, this is probably a bit specific to certain environments and types of contract, and you might not see all of these roles in your business.

Equally, there might be some other key positions that have a part to play – I know that in one set of contract negotiations for a multi-million software project, my project sponsor attended every conversation, along with the technical architect. And just as well they did too: it created a great sense of common purpose and everyone was on the same page from the beginning.

Take the suggestions below as a starting point for opening up the conversation with your colleagues if you are creating new supplier agreements, so you can make sure the right people are involved from the start.

Read more about who gets involved in contracts.

Your sponsor has asked you to get the work done faster… who hasn’t been in that situation?! That’s one reason why you may want to crash your project schedule, but there are others. In the past, I’ve written about 7 reasons to crash the schedule, and in this video, I pick out my top 5 to discuss in more detail. I talk about schedule compression (obviously), when part of the project has the potential to put the overall project at risk, when you’ve got a fixed deadline, when the team is needed for other work and when there’s a general delay which affects your ability to hit your expected deadlines. Crashing can help in all of those situations, used sensibly. Engage professional judgement before you go for it!

What are your thoughts on crashing? Personally, I try not to do it too often because it’s a lot of effort and it doesn’t always give you the results you were expecting, but it is a useful skill in the toolbox for predictive project managers, so it’s worth knowing when you would consider to use the technique.

Project financial analysis is what happens before a project is approved, and is a way of making sure that the company is spending its investments wisely by making smart choices about what projects to take forward. Thorough analysis is important to ensure that you don’t end up doing projects that lose money.

According to The Harvard Business Review Project Management Handbook: How to Launch, Lead, and Sponsor Successful Projects by past PMI Chair Antonio Nieto-Rodriguez, there are 5 common financial metrics: opportunity costs, payback period, IRR, NPV and ROI. Let’s take a look at those.

Opportunity Costs

Opportunity costs are a way of looking at what you aren’t going to do because the business’ resources will be tied up on this project. If the other projects are worth more to the business (however that is decided), then this project should be put on hold and instead the other projects should be taken forward.

You’ll need a relatively mature portfolio management approach to do this because you’ll have to identify the other projects that will be put on hold, and have budget/resource assessments for them to calculate what it would cost to do those – and have information about their benefits. If you’re in the kind of business that only does full business cases when the idea is pretty much ready to go, then this could be hard.

Even so, you should be able to include a paragraph in the financial evaluation that talks about the fact other projects will not be going ahead if the company decides to invest in this work.

Payback Period

This measure relates to how long it takes before the project starts to generate a return. On a programme, that could be before the end (and I’d hope it would be) because individual projects should be generating benefits as they complete.

Nieto-Rodriguez talks about the duration of the payback period being set by the organisation. Then if the project earns back the investment before that time is up, it’s a worthwhile investment. If it’s going to take longer than that, it’s time to think again. Typically, shorter payback periods are better, as it means the project starts to earn back more than it cost to do in a shorter time.

Internal Rate of Return (IRR)

I used to find IRR a difficult concept to understand, because rate of return is quite clear, but what’s the ‘internal’ all about? IRR refers to the amount the project ‘earns’ for the business. IRR is expressed as a percentage, and relates to the efficiency of the investment.

Let’s say you put your project budget in the bank and didn’t do the project. Instead, you just claimed the interest that the bank paid on the money. Your investment is safe, and you make some money back. But bank interest rates are pretty rubbish for the most part.

What if you did the project instead? The IRR calculation tells you what the ‘interest’ rate would be – it’s a different way of looking at the way project’s generate return. If the IRR is better than what you’d get in a bank, then the project is worth doing. If the IRR is less than what the bank could offer, you may as well save your time and effort and put the cash in the bank – assuming that financial returns are what you want to get.

Net Present Value (NPV)

NPV is really useful, because it helps you work out project financials as they relate to what money is worth today. A positive NPV is what you are looking for: that translates as the project forecasts being worth an amount that generates future cash at an acceptable rate.

NPV targets, minimum rates and discount rates may be set as industry standards or by your finance team, so check how if there are any specific variables or values you are expected to consider in the calculations (or better still, get a finance person to give you a template where you just plug the project forecasts in and get the NPV out). NPV is expressed as a financial value.

Return on Investment (ROI)

This measure relates to the project’s financial return given the investment made to deliver the project. In the business case or financial documents, it is expressed as a percentage of the total anticipated project cost, often including the Year 1 to 5 opex or running costs too, but the exact calculation will depend on the criteria set by your finance team.

ROI is a way to clarify what the business gets back from its investment. Typically, the higher the ROI, the better, as it means that the company is going to receive more income from the investment and it will pay off in a better way.