The Money Files

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!

In my early days as a project manager, my business cases and PIDs were full of non-quantifiable benefits. The kind of improvements that I thought we could get but weren’t set up to track.

In my more recent years, I’ve been heavily focused on quantifiable benefits, most specifically the money-related ones. Anything that presents a trackable, cash improvement is something to focus on. If it improves the bottom line, managers want to know about it.

There are also quantifiable benefits that are harder to track like reducing cycle time for invoicing and reducing energy consumption. These would lead to financial savings, but they are more difficult to pin down and measure realistically with no other influencing factors. Cycle time, for example, may lead to bills being paid faster which would lead to better cash flow and increased bank interest, but how do you separate that out as a benefit of just this project and not something to be attributed to one of the many other projects that are doing their bit for continuous process improvement?

Energy consumption can be tracked, but it’s several steps and calculations – it’s doable but harder. That’s not to say we shouldn’t do it, but it is something that you have to put effort into tracking.

Non-quantifiable benefits seem to have dropped out of favour. For example, staff satisfaction survey results is a good one that I used to mention a lot in project documentation. However, there are lots of things that influence staff satisfaction, and I’m sure my projects only played a very small part in influencing the results one way or another.

Also, new initiatives that once seemed completely life changing and a huge improvement quickly become ‘the way things work around here’ and the benefit tails off to nothing. No one would want to go back to the old process, but equally no one is celebrating the new process 6 months later when it’s just normal BAU.

I learned this on a Six Sigma course I took many years ago where the instructor talked about giving customers a biscuit with their coffee in a coffee shop. At first customers were excited they were getting a biscuit for free, but over time they came to expect that service and were disappointed when they didn’t get it, but not more happy because they did.

Therefore there is a balance to be struck with benefits: you want a mix of both quantifiable (financial and other) and non-quantifiable. But not so many that they all become meaningless. And not so few because you can’t be bothered to put the tracking mechanisms in place for more.

Be realistic about what you can achieve with benefits and how much time people really are going to spend on tracking the more difficult ones. If they believe that it’s worth tracking, they’ll do it, but if they feel energy consumption, for example, is tracked adequately through other types of environmental reporting or projects, they probably won’t be falling over themselves to create project-specific benefits reporting.

Talk to the key stakeholders about what sort of benefits you are putting forward for a project and make sure they are reasonable, measurable (where possible) and realistic.

Last time I looked at some tips for making lessons learned sessions run a bit more smoothly, and it made me think about some of the pitfalls we see when facilitating those sessions. My own experience is with using the model associated with predictive projects, but I imagine you could get stuck with these pitfalls if you were doing retrospectives with an agile team as well.

Image credit: ChatGPT

Here are some things to look out for once your lessons learned conversation is in the diary.

Focusing on only the negative things. Don’t let the session focus only on the negative. Yes, people like to have the opportunity to share the things that didn’t go well. If it helps the atmosphere to have a moan about the elephant in the room, then do so. But make sure there’s some time on the agenda left to discuss the working practices that were successful, otherwise you’ll all leave the meeting feeling like nothing went well, and I’m sure that wasn’t the case.

Making the sessions too long or too short. Who wants to give up an afternoon for a workshop? No one. And yet if your session is too short, you won’t have time to properly address any issues, come up with action plans or go through the agenda. The exact length of time is going to depend on what you’re wanting to cover and how much prep the team have done beforehand. Question why you need longer than an hour.

The same topics coming up regularly because they haven’t been handled. Regular lessons learned are part of the process, but too frequent and you won’t have had a chance to fix anything – and the same problems will come up again.

Listening to people say they suffered the same challenges because nothing has changed is annoying and frustrating and leaves people wondering what the point is of raising anything if nothing will be done.

People not feeling safe to speak up. Psychological safety is important if you want to get to the truth, but if no one is prepared to share what they thought didn’t go well, you won’t be able to improve. This is a hard one to address if the organisational culture is conspiring against you, but have a think about how you may be able to overcome it if it’s a risk for you. Having smaller sessions with targeted conversations, or anonymous surveys might be options.

Not doing anything with the output. Yep, this is all about leaving your lessons documented in a folder gathering electronic dust somewhere. Not good. Make sure they are turned into actions and have people responsible for doing something with them. At the very least, share them with the other project managers in your group.

Not being able to determine actions properly as you don’t have the detail to hand. So you’ve recognised you need to do something to change a process? If you don’t have the As Is process to hand, it might be hard to work out the action required to make the improvement. And that basically means the improvement won’t get done as what are the chances of someone doing the mapping and analysis afterwards? Unless the leadership team puts a lot of emphasis on follow up, you might miss that out.

These are some of the pitfalls of holding reflection sessions, but by all means I’m sure this list is not definitive. What are the other challenges you’ve found in your own meetings? Let me know in the comments!

I taught a webinar on lessons learned recently and while I was researching it I found loads of good tips. I drew from my own experience, that of other people and published research, and I thought it might be worth sharing a few of the tips here.

Be considerate of hierarchical power in the room and split the sessions by delegates if necessary. In my experience, more junior colleagues don’t share the things that didn’t work so well, or point out successes that they were a part of if there are senior managers in the room.

This is going to depend on your organisational culture – maybe everyone is happy sharing. But I remember a workshop (not a lessons learned) where someone who did the job we were talking about shared a point about the detail and the project sponsor (who hadn’t done the job for many years, if he ever had done it at all) said, “No, it doesn’t work like that.” And consequently shut the conversation down. It’s hard to challenge leadership so split the sessions if you need to, if you think it will help you get more honest feedback.

Write up the output and share it promptly. Lessons are already ‘old’ by the time you are talking about them because they’ve happened and you’re reflecting on them. Write up what you need to write up and circulate the actions as soon as you can.

If there are too many actions, prioritize them and focus on the ones that will add most value. Lessons learned meetings can come up with loads of actions, and if you are doing the exercise mid-project, it’s likely you’ll have actual project work to focus on instead of setting up a whole new project just to fix the things you’ve identified.

Delegate actions to other people, or if you can’t do that, just pick a couple of the major points to work on during the next few months. Come back to the rest of the list later.

Avoid scheduling near holiday times. If you need key people to be in the room, make sure they are around. That might mean scheduling the lessons learned conversations now, even if you are mid-way through the project, or a few months in advance so they hold the time in their calendars.

Ask each individual/team to come with their top 3 lessons. Save time in the session itself by getting people to put in some up-front work. Invite them to come along with their top 3 lessons already prepared, either by sending out a survey or question prompts or letting them have free rein.

Be assured that some people won’t have done this pre-work by the time they arrive in your meeting, so you might want to allocate the first 5 minutes of the meeting to silent individual brainstorming. Then everyone can use the meeting time to come up with the things they feel are the most important.

Collate outcomes in groups/categories to better manage them. The suggestions and lessons are going to fall into various categories, especially if you have given the attendees prompts to think about.

If you’re meeting in person, have separate flip charts or when you are picking up sticky notes from attendees, group them together in common themes as you stick them up. It’s so much easier with an electronic whiteboard, where you can ask participants to drag and drop the stickies, or you can do it as they appear on the screen.

Hope these tips help! When’s your next lessons learned session? Let me know that you’ve got one booked in the comments!

Last month, I wrote about 3 things to include in your schedule creation activity before you could say your schedule is ready for use, after you’ve created the work breakdown structure and added in dates, dependencies and task owners. Here are another 3 things you can build into your project planning tasks to polish your schedule.

1. Add in the costs

One thing we’re doing at work more and more is cost loading schedules. You don’t have to do this in your project scheduling software unless it makes sense to do it there. You could also create a phased version of your budget that shows when costs are going to hit.

Adding costs into the schedule to each individual task is a more accurate and detailed view, and then if work is rescheduled or delayed, the costs move too. However, you can get started with a simple spreadsheet where you phase the forecasted budget across the months of delivery and then record the actuals.

You can do this as a practice exercise if you want to give it a go, even if you don’t have external costs. Resource costs are normally a huge chunk of budget, so if you are tracking time, you can match up how many hours/days were worked against the forecasted effort in the week/month and use that to phase the costs by activity.

2. Look for float

Float is where a task has the ‘luxury’ of being able to start or finish later than the dates on the plan and not affect the critical path.

Look out for the tasks with wiggle room – where you could let them slip a day or so or start them early and overall it has no impact on your ability to deliver to the agreed end date. Personally, I like to get ahead with those tasks because you never know when the resources or work might change later and you need that time for something else, for example a team member going off sick.

However, some tasks are better done in a just-in-time way, so don’t bring forward those. You risk rework if you do something too early that might need to be changed later, even if there isn’t a formal task that would drive the change. For example, project communications can be drafted early but might need to change if the context changes, and if you are going through a transformation or strategic reset, the direction of travel might change mid-project causing you some more effort later.

3. Check in with stakeholders

It should go without saying, but given that I’ve reviewed project plans created by the project manager with no input from the team when I’m mentoring project managers, I feel it does warrant a note – check your schedule with the stakeholders.

I do create a high level overview with as much detail as I can before I share it with the rest of the team, because it saves time, and the alternative is having a giant workshop for planning. And frankly, we don’t have time for that (I know, I know…. The irony of not having the time to plan!). If we’ve had phone calls and conversations, there is probably enough I can glean from those to put together an outline and fit it to our project methodology.

But the plan is not workable and achievable unless the key members of staff doing the work have signed off on it.

A project schedule is a working document, so even when it has been around the team for discussion and refinement, it will need to be revised later on.