How to run a retrospective that isn’t awful
Categories:
project delivery
Categories: project delivery
| Tired of retrospectives that feel like box-ticking exercises? Let’s fix that. Sometimes it’s nice to fall back into tried-and tested tools, with comfortable conversations, but sometimes you need a bit more. Refresh the formatIf you have go to formats that you use, try to mix it up a bit. We use Start / Stop / Continue quite a lot, but if you don’t use that, try it out. The Sailboat is another good one: what helped us, what held us back, what propelled us forward and what hidden risks did we find or might we find in the future as we sail along.  Team awards could be another route in to a different kind of discussion. For example, most improved, unsung hero, or ask people to write award categories for each other (as long as you can guarantee they will be written with kindness. If you normally do them in-person, try remote. If you normally go remote, try meeting up. If you find people talk a lot, go for speed rounds or sticky note voting to bring a different pace. Avoid blame and awkwardnessI’m sure your retros don’t have any blame or awkwardness anyway, but just to be on the safe side, use anonymous inputs where you can. We always have the question about whether online forms or silent sticky note gathering really are anonymous when you can trace technical submissions or match handwriting, so if you want to be truly anonymous, you might have to have submissions made before the meeting so no one sees you do it.Ask reflective rather than evaluative questions, so you get responses based on experiences rather than ‘what we did’. Shifting the facilitator round or taking it in turns to lead a section can also help, it’s just a way to get different voices. And your colleagues will chair in a different way to you, so that’s a very simple way to help them build confidence in running meetings and get a fresh take on what is a regular slot on the calendar for the team. Normalise saying, “I don’t know,” or, “We need to explore this more,” so people feel comfortable bringing things to the table – psychological safety plays a huge role here so if you don’t have that sorted in the team, you aren’t going to get a lot of properly useful stuff out of your conversations anyway. Make it human and engagingWhat about adding a warm-up, like a team question, quiz, meme of the sprint or something like that? What about ending with a “one word” check-out (like, how do you feel now?) or asking people to bring their own playlist?What about linking it to food, or doing the conversations while out on a walk, if you’re in a small team? Remove the chairs or put the chairs back in. Focus on actionAlways close with concrete takeaways – that’s not a new technique, it’s something you should be doing anyway. Assign owners and dates for changes, where you have tangible actions that you are going to take as a team.And also, don’t forget to review what got actioned from the last retro so you can show everyone that their feedback matters and you are taking steps to do the right thing. A great retro energises teams and improves delivery, so if you come out of yours feeling a bit flat it’s time to mix up the process! What do you do to keep your retros feeling fresh and useful? Let us know your top facilitation tips in the comments so we can all learn how to keep the momentum going! |
Posted on: September 22, 2026 12:00 AM
| Permalink |
Comments (0)
A practical guide to stakeholder influence mapping
Categories:
Stakeholder Management
Categories: Stakeholder Management
| Stakeholder influence mapping is always a touchy subject, because in my experience, no one really likes to call out the people who don’t have influence… However, we have to have an understanding of stakeholders across the project because it’s going to affect how you spend your time on engaging others. These days, especially in cross-functional and matrix teams, influence matters more than titles. Classic frameworksI wrote a book about stakeholder engagement (in fact, I’ve written two, one on the niche aspect of communicating change, and one called Engaging Stakeholders on Projects) and the top, classic framework for analysing influence is the power/interest grid. There are also cube-variants of the grid with extra variables.You can also use the salience model, which looks at power, legitimacy, urgency and I think is a bit better. Alternative optionsEmpathy mapping works well as an alternative, and it has the added bonus of being easy to understand. You can map out influence networks (e.g. informal leaders) or even commit to political mapping for large organisations, if you feel like that would help understand how informal knowledge is shared and how you can get things done. How to use themWhatever model or tool you decide to use for influence mapping, a good place to start is project initiation. That’s when (or even before) you’ll be identifying stakeholders.You can also use the frameworks, or revisit what you already done, during major changes or conflicts because it’s important to have an up-to-date version of the truth. People change roles and their influence changes if their team changes and so on, so it’s worth double-checking that your maps and structures still hold true. Finally, there is value in using tools like these as a comms planning input, when you are working out which groups to engage with and how. Overall, if you’ve run workshops with your core team, consulted widely, refresh your notes regularly and make sure that you document everything in the most professional and least personal way, you can identify blockers and champions for the project. Then that informs how you are going to go about shifting perception and behaviour so that the can support, or at least not actively detract, from the project. When you’ve got strong stakeholder insight, you can get a smoother delivery, and fewer surprises. What tools are your favourites when it comes to analysing stakeholder input? Let me know in the comments! |
Posted on: September 09, 2026 12:00 AM
| Permalink |
Comments (1)
Why Your Project Forecast Keeps Changing (and What to Do About It)
Categories:
forecasting
Categories: forecasting
| Forecasting realism and credibility, but when yours keeps changing, it can be hard to feel like you’re being taken seriously. Forecast instability is a common frustrations for sponsors and PMOs, and project managers are often at the sharp end. We know it’s happening without being able to explain why, or at least be able to explain why with a decent reason rather than ‘we estimated wrongly (again) so it’s all messed up). Whether or not you deliver to budget, you’re also being judged on how good your forecasts are along the way. If the numbers change every month, expect to erode stakeholder confidence quickly! Even if you reckon by the end of the project you’ll be on track with whatever it said in the business case. The thing is, while stakeholders don’t expect everything to be perfect, they do expect stability and a bit of predictability, so wild swings up and down just make it look like the project team doesn’t know what it is doing. A forecast shouldn’t be a guess (or look like it’s a guess). It should be a best estimate based on what is known today: actual spend to date, committed costs, and assumptions about the remaining work.  What makes a forecast changeHere are 3 things that make a forecast change.Over-optimistic remaining effortYes, of course we can do all that work in just a few weeks… Early in delivery, teams often underestimate how long tasks will take or how much rework will be required. We can be over-confident about how productive we can be in a day or what suppliers will get done.Late recognition of committed costsMaking sure forecasts include committed costs can be another mistake that causes a forecast to change. Purchase orders, contract variations, or resource commitments may exist in practice but not yet appear in the cost report, giving a false sense that there is more money available than there actually is.Schedule slippage masking cost impactSchedule slippage can also hide cost impact, especially when time and money are reported separately, and then knitted together in a finance report. Be explicit about what’s already committed versus what’s still an estimate.Regularly revisit assumptions about productivity, delivery pace, and remaining scope, and document what has changed and why. That at least gives you the data required to have smart conversations with stakeholders about the financial figures. Stabilising your forecastsA stable forecast doesn’t mean one that never moves. It means one that changes for understandable reasons and moves in smaller, more controlled increments.Start with separating known costs from assumptions, especially if some costs haven’t come in yet. Book yourself some regular forecast hygiene checks to force everyone to have a look at where you are with the numbers. Align your cost forecasting with the delivery plan, so that milestones and spend profiles tell the same story. That can also help with cashflow as well, so your finance colleagues will be happier! The goal here is to really understand the drivers of change – stakeholders tend to be happier when they understand why changes are happening. While it’s obviously better not to have too many wild forecast shifts, if you do end up with some changes happening, at least you’ll be in a position to evidence and explain why they happened. |
Posted on: September 02, 2026 12:00 AM
| Permalink |
Comments (1)
Invisible progress: how to show value when nothing big has launched yet
Categories:
records
Categories: records
| It’s August, and I don’t know about your projects, but I’m working on some where we have made a lot of progress but haven’t actually ‘done’ anything yet. Do you know what I mean? Project managers can spend a lot of time supporting the team before any deliverables get delivered. Things like business case preparation, or solution design. Choosing suppliers and building out proper detailed requirements following ideation. Systems thinking work and as-is process mapping. All those activities are essential for making sure that when the deliverables happen, they are the right ones and fit for purpose. But it might not look like much is happening to the outside viewer. And summer is traditionally a time when things slow down, so it might feel to stakeholders that progress has stalled. However, we have to show that invisible work has value.  Why progress becomes invisibleFirst, let me explain why I think progress becomes invisible. As you would expect, projects do require some upfront planning, even in agile environments. Someone has to decide what to do, and how it’s going to be done. Some projects need groundwork, prework, integration, whatever you want to call it. For example, I worked on a project where we needed to upgrade another system first so ours would integrate, that’s all important foundations.The other reason why progress becomes invisible is that you aren’t delivering any benefits yet. The outputs of these early, important phases are less tangible – it’s the agreements, the stakeholder alignment, the expectation setting. And the benefits come later. Don’t get seen as stuckYou don’t want your project to be considered slow or stuck, because that can reduce stakeholder confidence and pile on the pressure for premature delivery before the team is ready. It also can lead to increased scrutiny because everyone important will want to know what you are doing and why it’s taking so long! And that just adds even more time to the schedule as you navigate all the requests for information while protecting the team who are doing the work. The foundations are importantWe need stakeholders to see that this foundational work is important. The groundwork means the future outcomes are more assured. We are reducing risk and uncertainty. And I know it’s not easy to talk about this stuff and make it seem like it’s actual progress, but we can try. Reporting the slower bitsWhen you are talking about what you are doing, make sure to avoid hype. There’s no need to make the activities sound more important or bigger than they are. Be honest about when stakeholders will start to see deliverables or value. A roadmap can help them understand the sequencing as well, and you can include that regularly in conversations to reinforce expectations. Visibility is a leadership responsibilityProgress doesn’t have to be dramatic to be real, we know that instinctively, yet it often feels like we have to justify ourselves! Part of your role as a project manager is to translate ‘effort’ into ‘understanding’, and also to make sure that people involved in those early stages get the recognition they deserve for their part in the work. For example, system architects design a solution, but it’s often the deployment or implementation team that are involved in the project celebration at the end, as the architect’s work is long finished. Use these periods that might appear ‘slower’ to external viewers to talk about and celebrate the work that is being done. |
Posted on: August 25, 2026 12:00 AM
| Permalink |
Comments (6)
Back ups – are you ready for disaster?
Categories:
data security
Categories: data security
 While we all hope that nothing bad will happen to our project data, it is really important to have backups in place. Backups protect against data loss. I know that seems really obvious to say, but regular backup safeguard you and your project data against system failures, human errors, and accidents. Because who hasn't ever worried about reverting to a previous version of a spreadsheet or overwriting a change that you shouldn't? Well, those are small examples of the impact if data is lost. In a more substantive way, having a recent backup means the project can carry on with minimal disruption. It's often not the project manager's responsibility to set backups in place, because these will be managed by your IT team. But it is worth asking what data is backed up and how you would access it if you ever needed to because a long term project that loses all of its schedules and financial spreadsheets... That situation could be very difficult to recover. Another thing to consider is corruption. That is, data corruption or errors, because if there are problems with the data, a recent backup can restore the latest saved version and that will give you a fighting chance at recovering what you need to and keeping your records consistent and accurate. As I said, you probably don't get the opportunity to set the backup frequency, or even to identify whether or not a backup will happen for the particular system that you're using. But some cloud based project management software will give you the choice in the settings. If you have the choice, pick a regular interval that works for you. If it's a tool that you're using all day every day, you'll want a more frequent backup because then you can minimise the risk of data loss between the backup windows. If it's something that you only go into infrequently, you might be able to get away with having a backup once a week or once a month. Putting aside the issue of backing up an entire project management software system for a moment, let's think about the different versions of project documents and artefacts that you use on a regular basis. When you've got version controlled backups, for example in your online document storage, that can give you the chance to roll back to the previous version if you end up with discrepancies. For example, somebody accidentally going in and deleting slides from your steering deck, or wiping all the data from a tab in a spreadsheet. Your IT team may share that there are a few different types of backups that you can do, so let's just look at those for a second. Full backups give you complete copies of all project data, which gives you the confidence that everything is recoverable. These are quite expensive though. Incremental backups only back up the changes made since the last backup. That's faster, and means your storage utilisation is less. But it can be harder to recover if you have to recover everything. I think these days most of us rely on cloud storage, which is storing backups in the cloud linked to the software system or app that we're using. That gives you remote access which is a reassurance against hardware failure, because if you've ever had a laptop die after you spilled coffee on it, then you know that it's important to have off-site backups and remote backups and cloud backups because storing things on your hard drive can cause problems later (Don't ask me how I know). Take this article as a reminder that it is important to manage your project management tools and documents using automated backup solutions that reduce the risk of human error and takeaway the fact that you have to think about doing the backups at all. Mostly your tools will have this built in because it's not an unusual requirement, but if you can't see how a product is backing itself up then it's worth asking the vendor or your IT team. Just to be doubly sure that you have that confidence and security that all of your project-related data is safe. |
Posted on: August 11, 2026 12:00 AM
| Permalink |
Comments (2)
