We’re all familiar with the standard ways of measuring progress and project success. You might use earned value, or burndown charts or even percent complete.
There are other metrics we can build into our project management practice, and over the last few weeks I’ve been exploring them. One of the questions I got asked in response to my first article on alternative metrics was what challenges might arise from implementation and how could we, as project managers, overcome those?
Let me share some ideas.
The hardest thing with implementing any new way of working is resistance to change. You want me to track something else, in a different way, making more work for me? No thanks.
So when you want to introduce a new metric, like customer satisfaction tracking for internal customers, the goal is to make it as easy as possible.
Try to reduce the barriers to implementing the change, using all the good change management practice you are familiar with, like training and communication and helping people understand the reason for tracking in new ways. Find champions. Remove the old ways of doing things. Give people the tools they need.
As with all changes, it helps if you have someone leading the charge, and that is likely to be you. Let’s say you want to implement customer satisfaction measures, following the outline of the process in my book, Customer-Centric Project Management. There’s no obligation to start with your biggest program, or even to do it on more than one project.
Use your own project and just do it. Start by asking the sponsor what they value the most from project delivery or what they find important in the process, and then track how satisfied they are with that measure once a month. For example, when I did this, communication was one of the things stakeholders said was important, so each month we tracked how good we were at project communication by asking them to rate us on a scale of 1-10.
Ultimately, we did get the whole department of project managers tracking internal customer satisfaction in this way, but we did start with one project.
Another challenge with changing any way of working is being consistent. One of the things we’ve found with tracking measures monthly is that often (too often, really), we’ve found a flaw in the original assumptions, or some business process changes, or some other thing happens and we realise that the way we are tracking needs to change. Getting more data, more understanding and more accuracy is not a bad thing, but it does rather invalidate your earlier measures if they are now not comparable to your ‘today’ measures.
The way around this is to be consistent, both with tracking in general (in other words, do it regularly and don’t give up on it) and in how the measures are calculated.
Perhaps learn from our situation and give yourself three to six months where you allow for the measurement assumptions and tracking approach to be tested. Make tweaks as you go so you know that after that period you can ‘fix’ the way you are tracking so going forward your numbers are comparable and stable.
Consistency also means following through and completing the tracking regularly, whatever frequency you set, and that might be different for different metrics.
For example, we track some things monthly, but other metrics are only looked at quarterly because that’s how it makes sense.
Build the obligation to report into people’s job descriptions and roles. Set up a mechanism to hold them accountable if they are not completing the tracking. For example, the PMO could ask for all metrics to be added to a central spreadsheet so all portfolio tracking is in one place. Then you could easily see which projects had completed their tracking and which had not.
There are always challenges with doing things differently, but if you really want to make the change, you can. The good news is that often you don’t need PMO or portfolio office support, or even the consent of your line manager. If your sponsor is happy that you track, and you’ve got the energy and enthusiasm to do it, you can.
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 7th 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?
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:
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.
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.
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!
In this video I look at 3 things you can do to help calm the overwhelm when the business seems to be changing around you more quickly than you can keep up!
I talk about making sure change management, risk management and day to day operations on projects go as smoothly as possible, freeing you up to cope with whatever project-related changes are being thrown your way.
Pin for later reading:
This video looks at two different ways that you can use your change management process, above and beyond the standard change board and approval cycle.