The Clearly Podcast

Andy:
Last week's session was therapeutic. Just talking about ourselves felt relaxing. Maybe we should do that every week and publish it. Even if no one downloads it, we'd feel better.

Tom:
Yeah, yeah.

Shailan:
I agree, even though last week was only a few days ago.

Andy:
Today, we’re discussing the link between implementation methodology and client culture. Do you match your implementation methodology to the client's type? In a world where agile is often the default answer, how often do we assess if that’s the best fit for the client?

We deal with various clients: government organizations with structured cultures, high-growth organizations that are chaotic, and stable traditional commercial organizations. How do we tailor our approach based on the client type, and do we change direction based on our experience with them?

Shailan, why don’t you kick this off?

Shailan:
Sure. The answer is yes.

Andy:
Tom, is the answer yes?

Tom:
Yes.

Shailan:
SharePoint, I mean agile.

Andy:
Agile and SharePoint are the answers. Let’s start with agile. Many organizations think they do agile because it's culturally trendy, especially larger ones like those in the public sector.

Andy:
Why do they think that?

Shailan:
They are trying to transition from traditional methodologies like waterfall. They might have internal advocates for agile, but it takes time. Some business areas aren’t fully agile, so clashes occur when they revert to traditional methods during sprints.

Andy:
Do you course-correct when this happens? Do you admit it’s not agile and adjust?

Shailan:
You try to course-correct, but in large programs, it’s challenging. You’re often just one part of a bigger picture.

Andy:
Tom, have you suggested different implementation approaches based on the client's culture?

Tom:
Yes, but agile is often seen as best practice, making it hard to suggest alternatives. However, agile itself is flexible. For example, we started a project with strict sprints but later adopted a Kanban style for more regular releases.

Andy:
Does this change happen organically?

Tom:
It often does, but it should be explicit. If you pivot your methodology, make it clear why and what the new rules are.

Andy:
What if agile isn’t working?

Tom:
You need a conversation with the client. If they can’t provide the necessary resources, agile may not be suitable, and a waterfall approach might be better.

Andy:
Agile can make managing a project feel vague, which is hard for organizations that want clear timelines and budgets.

Tom:
True, but if you want defined deliverables in a fixed time and budget, that’s not agile. Agile projects need flexible objectives and budgets, reconsidered regularly.

Andy:
I like the idea of "wagile" - combining agile and waterfall. It uses the best of both, though it can also risk the worst of both.

Tom:
Yes, if you mix methodologies, ensure you pick the right elements from each.

Shailan:
If you work on a wagile project, you’re a "wage."

Andy:
Or a "wack" project. Let's wrap up. How do you handle situations where you start with one methodology but need to change? What are the top tips for managing this?

Tom:
Speak up early to the client and be honest. If agile isn’t working, suggest alternatives like waterfall.

Andy:
Shailan, any last thoughts?

Shailan:
An in-depth kickoff meeting is essential to align objectives and methodology. Review the implementation methodology regularly in project meetings to ensure it’s still suitable.

Andy:
Good points. Let’s make sure we address these early and explicitly to avoid issues later on.

Shailan:
Absolutely.

Andy:
Thanks, everyone. Next week, we’ll discuss client motivations and how they affect project delivery. Until then, thanks for listening!