The Money Files

I’m continuing my deep dive into continuous improvement this month as it’s such an important topic for project managers. There’s this expectation that we will use the retro and lessons learned processes to make improvements, and yet there is rarely the time to fully implement lessons. That’s one of the major challenges, and I want to talk more about challenges in making changes to ways of working today.

Resistance to change

The first challenge is resistance to change. Resistance can come about for lots of reasons, not least because people are worried about the extra workload of having to deliver project management process changes on top of their project execution activity.

Also, humans seem programmed to not like change. Having to learn a new way of working is a pain.

We can address this in the same way as you address change resistance to any of your projects: understanding the concern, clear communication, training and support and demonstrating the benefits. Plus a bit of management ‘this is the new way of working and you will follow the process’ can be useful!

Sustaining momentum

Improvement programmes might start out well, but it’s challenging to keep them going. After all, there are only so many improvements that are simple to make and easy to implement, so you might feel your goal of improving continuously is struggling because people have already suggested the easy wins.

Team members might not engage with it any longer. Keep celebrating success, keep recognising good contributors (without making those who cannot suggest improvements for whatever reason feel bad).

Pace out your changes so there is a small strand of work happening throughout the year instead of a big push and then nothing.

Resource constraints

I’ve mentioned this a lot throughout the series because I really do think it is the hardest thing to overcome. We have to balance improvement activities with project deliverables.  In resource-constrained environments (isn’t that everyone’s project environment?), you may find it challenging to allocate time and resources for improvement initiatives. Management might not see the value.

People doing the work might prefer to focus on their project work, which probably already has to be balanced against their business as usual activity. Now you’re asking them to do even more, and even if they are willing, they have to make prioritisation calls, and frankly, changing processes is probably way down the list.

They might be incentivised on other things. Their personal performance metrics or team objectives and KPIs probably don’t include the new improvement that has only just been thought up. So unless you’re going to work with line managers to write in a percentage of their availability to work on improvements, expect to see some up and down commitment throughout the year. People will do what they can, but creating the space for them to do that is important.

I’d love to hear your suggestions for helping teams find the time to overcome resource constraints for project improvements? Do you build it into their personal objectives or make it part of the expected ways of working for the squad? Let me know in the comments below!

That concludes my deep dive into continuous improvement. It’s an important aspect of project management practice, and it helps us create an environment where we can contribute to the business in more ways than simply project delivery. We can be the driver for change as project managers, and help our teams, and our organisations, deliver more in difficult times.

While so many of us still use the humble spreadsheet for project management and tracking, there are lots of cool technologies out there that will (eventually) be game-changing for project managers. And I’m not talking about AI, although of course that is huge in our industry at the moment.

Project management tools are often seen as task-based, schedule-based, scenario-based products, but will that change when we bring more elements of gaming into the way that teams and results are managed?

Gamification

Gamified project management systems could incentivise teams to make progress. We could introduce a bit of healthy competition. I know not all teams are going to love the idea of gamified work, but in some teams it could provide a bit of engagement and interest. If your project management software has the option to award stars (for example) for contribution, then take a look at what features you could switch on.

I’m part of a community where likes on posts are rewarded – not for the person doing the liking but for the person being liked. The aim is to encourage thoughtful, helpful comments that the community finds valuable. I think it’s a balance between spending all your time crafting the perfect, likeable comment and doing your work, but I do think we’ll see more gamification coming into project management, and I’ve talked about that at conferences before.

Role-playing

I know, I cringe too when role-playing gets mentioned. However, when I’ve been on training courses and we’ve done some role-playing (for example, having a difficult conversation with a colleague) it has been very helpful in addressing the situation in real life.

If you think about it, you’ve probably used role-playing already in your projects. If you have ever demonstrated a solution to a group of customers, you’ve probably had someone playing the role of a customer placing an order or interacting with your product. Just do more of that! It really helps bring the product to life.

You could also look to incorporate role-playing scenarios in training and change management activities. Work with stakeholders and users to give them first-hand experience of the change in a safe environment, helping them see it from different roles in the journey, for example, what it will be like to interact with the product as a customer.

Virtual reality

Personally, I can’t say I’ve used VR for project delivery (yet) but it is a feature of science-based learning at my children’s school. They use VR headsets for educational purposes to explore science topics. Which is cool.

We could see the same for project deliverables, perhaps a virtual simulation of a building that users could walk around to see what it’s like before the construction is complete, or something like that. Perhaps it will get used for virtual project kick off meetings or simulation-based training. This community has probably seen examples of that in use. If you have, can you drop me a comment below and let us all know how that worked out for you?

How do you feel project management is going to adopt new tech (that may or may not be aligned to AI)? If you’ve seen any of it in practice I’d love to hear how you are using it! Thanks!

As much as we’d love to have everything working to plan, sometimes we can take some aspects of project management for granted. I wonder how many of these project challenges you have but you haven’t openly recognised within the team?

I don’t want you to have your head in the sand, so below I share 10 things that you might be missing on your project.

(I didn’t want to bury my actual head in the sand, so you got a photo of my feet buried instead! Not quite the same, I know.)

1. Stakeholders are reading your communications

We might believe that stakeholders are reading our project comms, but are they really?

It’s hard to tell, but if you aren’t seeing any action, or people are asking questions you have already answered in your comms, then they probably aren’t.

2. The training you’ve scheduled is enough

I expect it isn’t, even if it feels like it should be. People won’t turn up or won’t use the online training to teach themselves. Plan to have post-launch training support because your users will need it.

3. Your change management plans are adequate

Hopefully they are, but as above, there will always be someone who says they didn’t get the memo, or couldn’t access the materials. Make sure you’ve got post-launch training in the diary as well, and do more change management activity and engagement than you think you should have to.

4. The UAT plans are long enough

UAT is the one thing that gets squeezed in my experience. Add in an extra cycle if you can. It’s easy to take it out – not so easy to squash it back in if you do need more testing time.

This obviously depends on your project – if you are doing something you’ve done a lot before you should have a high degree of confidence in your deliverables, but you might need more if you are working on something new.

5. Risk identification has spotted everything

It hasn’t!

Make sure risks are constantly mentioned in all meetings, and that you are always listening out for what might be a new risk.

6. Team morale is OK

Team morale is something to keep an eye on. The team can get demoralised for the smallest of reasons, from a change not being approved to a reschedule for whatever reason. That negativity can spiral.

Even if things are going well on your project, events outside the project can influence morale, such as a change in leadership, redundancies, an increase in BAU work or pretty much anything else.

7. Benefits are understood

We’d like to think the financial and tangible benefits are understood, but how well have those assumptions been documented? I’ve worked on a couple of projects where we think we understand what we are tracking, only to find that we can’t replicate the exact formula the finance person (who has now left) used, or some other difficulty.

You should be able to answer straightforward benefits-related questions like ‘is this incremental revenue or total revenue’? So make sure you can.

8. There is no conflict in the team

There probably is, but people are too polite to mention it. You should dig for it! Some conflict is healthy so don’t worry about bringing it up.

9. Quality is being managed OK

Are you finding bugs in your deliverables? And more importantly, are you squashing bugs? What are your criteria for exiting testing and how does quality play into that? Ideally, you should have great quality measures, and be performing in line with those, but sometimes project teams get swept up in the desire to deliver and that means some lower-risk bugs are left in for now.

10. There is no technical debt

Are your project deliverables introducing technical debt? Are you breaking things elsewhere or for other teams, or introducing workarounds or degrading the solution for someone else? Sometimes your part of the world might be fine, but a process you’ve implemented ends up in many additional steps or a new report being needed for someone else.

Check that you aren’t creating technical debt by accident – if you know about it, document it and have created it ‘on purpose’ as part of a stepping stone to a different solution, then that’s probably fine.

Which of these might your project be at risk from? Let me know in the comments!

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.

Change adoption

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.

Start small

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.

Be consistent

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.
I recommend starting with customer satisfaction as it’s easy to do with no specific tools required, and it has a huge impact on stakeholder engagement: it’s very much worth it!

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.