Defining and Achieving Client Value in Projects: Essential Insights

How can we deliver value to a client unless we share an understanding of what value means for the project?

We’ve all heard of “value for money” and that something can itself be valuable. But how does the language fit into our project delivery and client management approach?

Projects start in different ways, but they all need to have one thing in common. Whether the client brings you a simple vision for the work, or they hand over a detailed 200-page specification, you still want to understand how to return the most value you can in the time available.

Continue reading

On Medium: You know what Agency Clients love? Certainty.

The article—posted to my Medium account—reflects on the challenges that Agile-first agencies face when they acquire new clients who often have a preference for traditional, Waterfall project management.

When we’re accustomed to agility and flexibility, we must adapt to provide the certainty and structured approach desired by a new client, balancing the innate human need for both certainty and excitement.

This adaptation involves documenting a delivery approach and being less agile about Agile.

But does changing our approach mean we’re no longer Agile?

Read ‘You know what Agency Clients love? Certainty.’ on Medium.

Less-Aligned Stakeholders: How to Carve Out Success

black and white street sign

Once your client induction process is complete, you’ll need to make a decision on whether their next project has a key stakeholder that’s going to be high-impact. With those two key stages in the bank, it’s time to evalute the best way to move forward.

Also see: What is a stakeholder?

The options below are not intended to be a definitive list. Indeed I can imagine a rewrite of this article or addition of other options in the future. What you will be able to take from reading these thoughts however is the number of ways you could move forward (or not) with a client who isn’t ready to—or won’t—consider your purely Agile delivery approach.

Right, let’s dive into some less-Agile options!

Continue reading

Client expectations of the inspect and adapt process

Originally posted as a thread to Twitter (X) October 2023

Let’s compare a sports situation with software dev best practice. There was recently a huge failure in the refereeing of a football match. A decision was made that processes should have corrected. Gary Neville here is saying refereeing is difficult & sorry should be enough here.

[quote tweet from Gary Neville definding the referee]

In software development we do ‘inspect and adapt’. That is we look at our processes and find ways to improve. We’re transparent about failure and actively look for places we can evolve.

A ‘sorry but’ wouldn’t be acceptable. “Oh there is a demand for speed so we’ll fail occasionally” and “that’s just the way it is”

The least we’d offer is…
Sorry
…and here is why it failed
…and here is what we’ve done to improve the situation

When you don’t offer those things, people (clients or stakeholders) will go looking for the improvement / failure themselves

And that is exactly what has happened with the football VAR failure. Where no change is promised, a change is demanded. It’s a valid ask, and a basic expectation of the consumer of any service. Here that’s refereeing.

Offboarding as a priority

There is nothing quite like the heart sinking feeling other team members get when a developer announces they’ll be leaving a small team.

Mild panic sets in, and everybody looks to each other for reassurance. Yet that moment is the right time to switch mindsets to focused offboarding. Ensuring the remaining members are left in the best state possible to continue their great work.

Team size is critical here. One developer leaving a team of five often has a huge impact relative to a developer leaving a team of 20. Small teams need to run offboarding in a way that acknowledges this size frailty and mitigates the short and long term risks associated with developer churn.

Continue reading