When projects get serious: what changes after the “easy” phase
Categories:
Governance
Categories: Governance
| In my experience, many projects feel deceptively straightforward at the start! It’s all about the planning, the goal, the vision. Early progress is visible because you’ve got a business case approved and everyone is enthusiastic. Problems feel manageable, probably because you’ve got a big budget and lots of time, and lots of senior-level focus to help get things done. It’s easy to reverse decisions as you haven’t actually delivered anything yet, so you’re making quick progress. The risk exposure is low, if you need to make trade-offs they can feel a bit theoretical at this point as you haven’t actually ‘lost’ anything (yet). But then there is a transition point where delivery becomes more complex, political, and consequential… and that’s when things start to change. ![]() What changes as projects progressWhen projects progress, decisions become harder to reverse. The cost for rework goes up because more work is complete. There are dependencies That can't change, and the tolerance for making changes drops. When you're making trade-offs they start reflect the overall cost the schedule and stakeholder confidence. In my experience, the pressure to actually get almost delivery increases even if your plan hasn't changed. People are more invested in the outcome because some work has already been completed. Leadership expectations shift from wanting to know that everything is going OK to reassurance that the project will hit the deadlines and spend within budget. You start being asked questions around confidence levels and scrutiny, instead of, “How can I help?” and, “Are we ready to go?” There's also a difference in expectation from the behaviour of you as the project manager. We are expected to use our professional judgement. At the beginning of a project it’s often about following the process to get things approved and to move through those early stages of project setup which can feel quite regimented in the approach as this is probably dictated by your PMO. Once we're in full delivery, there's a lot more scope for professional judgement and active decision making on everyday basis. How to manage this later stageSo how do we cope with this change in expectations? I think a lot of project management practice stays the same and what you're doing is probably fine. But I think that it's worth moving from being more of a coordinator to more of a facilitator of decisions. In my experience, it's also useful to be really clear about uncertainty and the consequences of those choices especially around risks and risk management. Communication is another area that you can lean into. We have to be even clearer about what we're doing, what progress we're making, and adjust the tone of the communication as you get closer to the end to improve the levels of confidence (assuming that you do want people to be confident about where you're going and that broadly things are on track). Finally it's worth thinking about escalations. You need to know where to escalate, what to escalate and how much drama you're going to create by doing an escalation even if it's the right thing to do. So there's an extra level of bravery and confidence in your own ability that comes with managing a later stage project. I suppose what I'm trying to say here is that setting up a project can feel like the easy part. Once you've aligned the stakeholders, got approval to proceed and put together a plan – that's when you are really going to have to lean into strong project management skills. So many project managers I've spoken to tell me that professional credibility is built or lost on their very last project and often their past experiences and many years of successful delivery are overshadowed by the fact that something went wrong on some project. And let's face it, there are going to be projects where things go wrong and it won't necessarily be the fault of the project manager. So I think we need to be aware that there is this change in project management approach needed between kicking off a project and seeing it through to the end. What do you think? Let me know in the comments below! |
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! |
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! |
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. |
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. |









