This is a great reflection, Blanca. In my experience, stand-ups remain valuable when the emphasis is on flow and shared understanding.

A helpful rule for me has been keeping discussions limited to what the team needs to move forward today.

For me, it’s the importance of slowing down long enough to set real expectations at the start. Early on, I thought momentum came from jumping straight into delivery, but I learned pretty quickly that clarity is what actually keeps a project moving.

A few honest conversations at the beginning – about roles, risks, decision points, and what “done” really means – save months of confusion later. Looking back, I wish I’d appreciated sooner how much alignment shapes the entire project, not just the kickoff.

It’s not flashy, but it’s the thing that’s made the biggest difference in how I work today.

Blanca, you’re spot on with this. Any time I’ve seen a project slow down, it usually comes back to unclear ownership somewhere. A RASCI looks simple, but when people aren’t aligned on who’s actually responsible or who gets the final say, the team ends up spinning its wheels.

What’s worked well for me is treating the RASCI like part of the workflow. At the end of a sprint or when new people join, we give it a quick refresh. It only takes a few minutes, but it keeps everyone honest about who’s doing what and stops those “I thought you had it” moments.

And you’re right – the value isn’t the grid, it’s the conversations. You catch role overlaps, gaps, and mixed expectations early, before they slow the whole delivery down.

I usually revisit mine every couple of weeks, or sooner if the scope shifts. It keeps things clear and stops small issues turning into proper blockers.

Interested to hear how others handle theirs too.

Really well put, Blanca — you’ve nailed what so many of us have been feeling in delivery roles.

From my side, the “Amazon Effect” has completely reshaped how we plan and execute. It’s no longer about just launching an eCommerce platform — it’s about delivering something that can scale, adapt, and perform under constant pressure. Teams expect speed and precision, and that tension keeps delivery leads on their toes.

What’s changed most for me is how operational thinking now sits right alongside delivery strategy. You can’t separate fulfilment logic, data flows, or real-time visibility from the delivery plan anymore — they’re all part of the same ecosystem.

Have you noticed that this “always-on” model makes it harder to define when a project is truly done? It feels like the line between delivery and operations has almost disappeared.

Great insight, Luigi. You’ve captured something many PMOs struggle with – the shift from process focus to real value creation. Thanks for sharing this piece.

Hey Aidi,

That project in Tunis sounds brilliant – and a huge opportunity for impact. I’ve not worked directly in social projects, but I’ve followed a few where the real breakthroughs came less from the tool itself and more from how people stayed aligned — clear communication, simple workflows, and cutting out clunky steps.

That feels familiar from my own delivery work: a Gantt is fine for funders, but day to day it’s usually the lightweight tools — shared boards, simple roadmaps, even WhatsApp — that keep things moving. And when people help shape the plan together, it tends to stick far better than something handed down.

In your past projects, did partners lean more towards structured PM tools, or did they prefer the lighter, everyday ones?

For me, the most effective strategy has been creating space for open conversations early on. When people feel heard and know their concerns matter, resistance tends to soften. It shifts the focus from “change is happening to us” to “we’re shaping this together,” which makes a big difference in how the team adapts.

I often see project closure treated as an afterthought once delivery is complete. Yet handovers, lessons learned, and stakeholder wrap-up can shape how the project is remembered.

In your experience, what makes closure genuinely effective rather than just a tick-box exercise?

From what I’ve seen, Jira works best when the setup reflects how the team actually operates rather than how the tool is “supposed” to be used. A few things that have helped in my projects:

Keep it simple at the start – resist the temptation to over-customise workflows. If the board is intuitive, adoption is much easier.

• Align fields with reporting needs – we only add custom fields if they directly support decision-making (e.g. risk indicators, dependencies). Too many extras slow things down.
• Use dashboards for visibility – stakeholders don’t need to live in Jira, but clear dashboards give them confidence without pulling the team into constant updates.
• Regularly review and adapt – as the project evolves, so should the board. Sprint retrospectives are a good time to ask if the Jira setup is still helping or hindering.

The challenge is avoiding tool fatigue – people disengage if Jira feels like extra admin. Anchoring it to actual delivery outcomes keeps it valuable.

I’ve played around with some of the AI features in tools like ClickUp and Asana. They’re pretty good for the basics – things like pulling a quick summary of updates or tidying up task descriptions – but I haven’t seen them crack the bigger stuff yet, like spotting risks or giving real progress insights.

The main value I’ve found is in saving little bits of time. For example, I’ve used AI to turn stand-up notes into a quick daily summary for stakeholders. It’s not game-changing, but it does take a bit of admin off my plate.

Tanisha, the way you frame this as a ‘conductor’ role really resonates with me. It fits with what I’ve noticed in delivery roles. A lot of our time gets eaten up by reporting and status tracking, and that is exactly the kind of repetitive work AI can take off our plate. The value for PMs is then shifting to what humans do best: interpreting context, balancing competing priorities, and keeping people aligned.

The flip side is the risk of leaning too heavily on the AI. If teams accept outputs without question, you can miss important nuances or end up with decisions that look tidy in the system but do not hold up in practice. That is why I think your inclusion of bias alerts and decision approvals is spot on. It keeps accountability with the PM.

On competencies, two stand out for me: critical thinking, which means knowing when to push back on what the AI suggests, and facilitation, which means helping the team engage with AI-driven insights without feeling sidelined. If we get…

Read more

Thanks, Aisling, that makes a lot of sense. I’ve been trying to do something similar, but it’s tough when leadership sees every new feature as something we should act on straight away. I’m considering setting up a separate backlog just for new opportunities so we don’t lose sight of them, but they don’t derail the main delivery either.

How do you usually get stakeholders comfortable with the idea that some of those ideas will need to wait until later?

I am delivering an AI project and it is the fastest-moving work I have managed. New capabilities appear every few weeks, stakeholders see new opportunities, and parts of the plan need to change.

I am used to managing scope changes, but this feels like aiming for a finish line that keeps moving.

If you have managed AI or other emerging tech projects, how did you keep delivery on track without constant rework?

I’ve found it helps to be clear about what goes where. If each channel has a clear purpose, you don’t waste time checking everything for updates.

We also do short summaries – daily or weekly – so people can catch up without scrolling through pages of messages. Keeps the noise down but the context intact.

What’s worked for us is starting with a clear map of our current process so we know exactly what must stay the same. From there, we’ve slotted AI into small, low-risk tasks first — things like summarising updates or flagging potential issues — so the team can see the benefits without the pressure of high-stakes use. We also make sure every AI-assisted step has a human review built in. That’s not just about catching errors — it’s about keeping people engaged in the decision-making so they don’t switch off and trust the output blindly. If you’re just rolling AI out, I’d suggest:

• Identify your “no compromise” process steps.
• Start with a trial in low-risk areas.
• Build in review checkpoints and share the wins with the team.

That combination’s helped us keep quality high while building trust in the tools.

Pushing back on scope creep is hard – especially when the ask is reasonable, the person is well-meaning, and the relationship matters. I’ve had moments where I knew saying yes would compromise delivery… but saying no felt political. What’s helped me is finding ways to delay without dismissing – “Let’s park that for phase two,” or “We’ll need to revisit resourcing if we go ahead.” Still, it’s not always clean. There’s emotional weight in those conversations. How do you handle scope pressure from someone senior? What language or framing has helped you hold the line without burning bridges?

I’ve been testing AI tools across a few projects to help bring more clarity to delivery, especially when we’re working with a mix of Agile and traditional approaches. One thing that’s worked well is using AI to generate quick summaries across sprint boards and status reports. It helps highlight blockers or slipped milestones early, so we can act before it snowballs.

That said, the value really depends on the quality of the inputs – and how you shape the outputs to suit different stakeholders. We’ve had to tweak quite a bit to avoid overwhelming people with too much information. In a lot of cases, less really is more.

I’d love to hear how others are using AI to support delivery across Agile and more traditional models. Looking forward to picking up some ideas from the session.

In my experience, adoption often gets missed because it’s squeezed between planning and real-world workload.

One thing I try to do is look at who’s affected and when, so we can build in some space. If people are expected to change how they work, they need time to do that properly. Even pausing a recurring task for a short while can help.

We also rely on internal champions, but I try to pick people who actually believe in the change. It makes a difference when others see a colleague they trust using the new tool and being honest about what’s working and what’s not.

Coaching is important too, but not just one big session at the start. We add follow-ups like drop-in calls, short tips in team meetings, and Slack check-ins. These small things really help.

And I always treat adoption as part of the project, not an extra task. If people aren’t using the tool, the project isn’t complete.

Would love to hear how you handle it in your space too. I imagine timing is especially tight in education.

Hi Ivy, really relate to what you’ve shared. Stakeholder management is often the trickiest part of a project, especially where things can shift quickly.

I focus on building trust early by being clear and consistent. I’ll ask straight up how they like to stay involved, what they care about most, and what “done right” looks like from their side. It helps avoid surprises later.

If someone’s unresponsive, I don’t wait too long — I follow up in a different way. If they’re resistant to change, I try to understand the concern behind it. Often it’s less about the idea and more about timing, risk, or lack of context.

To keep engagement going, I use regular, visual updates — short and focused. It keeps things moving without overwhelming them.

Hello Mercy, I really appreciate your insight – it’s such an important point. I’ve encountered similar challenges in my own work, particularly around assuming that verbal agreement equates to shared understanding.

These days, I make more of an effort to pause and check: ask follow-up questions, invite people to share their take, and create space for any uncertainty to come up. It might feel a bit clunky in the moment, but like you said, it builds stronger collaboration and helps avoid a lot of confusion down the track.

As you mentioned, it can feel uncomfortable at first, but it ultimately leads to stronger collaboration and better outcomes.

We’ve gone a bit beyond the basics with Smartsheet, but only where it genuinely adds value. Dashboards are a standout — they give execs real-time visibility without extra reporting. We also use intake forms tied to resource planning, which helps manage cross-team workflows more smoothly.

What didn’t work? Using it as a document store — got messy fast. We now link out to SharePoint and keep Smartsheet focused on tracking and decision-making.

If your setup’s working, no harm staying where you are. But if you’re managing more complexity, it’s worth exploring deeper features.

Absolutely love what you’ve shared here, Emma, especially that line about certainty = control. That really hit home.

I’ve been on a similar path. One thing I’ve had to unlearn is the idea that being the one with the answers is what makes you a strong leader. For a long time, I thought I had to come into every meeting ready to steer the ship solo. But lately, especially in more complex or cross-functional projects, I’ve learned that creating space for others to bring their thinking forward is far more valuable than having a fixed direction from the start.

Like you said, it’s uncomfortable – letting go of the “perfect plan” or the “right answer” can feel like you’re stepping into fog. But when teams are supported to respond rather than react, you start to see this collective intelligence emerge. It’s less about control, more about coordination and trust.

One shift I’ve made is re-focusing on the human side of project work -facilitation, coaching, and helping teams stay connected to purpose. I’ve seen how much that matters when everything else is in flux.

I’m also staying close to what’s happening in AI and automation, not just from a tools angle but how it changes team roles and expectations. To me, evolving as a PM now means being someone who can help people navigate both the technical and emotional sides of change.

We talk a lot about learning new tools or systems – but in my experience, unlearning is just as important. Old habits, rigid processes, even assumptions about what “good” looks like, they can quietly get in the way of progress.

• What’s something you’ve had to unlearn to keep up with change?
• How do you create space for that kind of shift in your teams?

Would love to hear the uncomfortable-but-valuable lessons others are facing.

That really resonates. I’ve come across similar situations, particularly in telecom environments where the systems are live around the clock and there’s very little margin for missteps.

We were rolling out a new monitoring platform for a network operations centre, and while the technical side was solid, some of the teams felt like the change landed on them rather than with them. It wasn’t resistance to the solution itself, it was more that people hadn’t been brought in early enough to feel part of it.

What helped was taking a step back and creating space for proper engagement. We ran a few focused sessions – nothing overly formal, but enough to walk through what was changing, gather feedback, and give people a chance to shape how it landed in practice. Once they felt involved, the shift in momentum was noticeable. I’ve learned that in environments like these, getting the delivery right isn’t just about the tech, it’s about how well you bring people with you.