As an agile consultant, I’ve learned a multitude of lessons over the years, but one stands out above the rest: the statement of work (SoW) often bears little resemblance to the actual problems my clients face. This insight transcends the realm of agile consulting; it applies to any consulting role.
The Disconnect Between SoW and Client Needs
In my experience, the primary focus for many consultants is to deliver on the SoW. It’s a straightforward approach: “Here’s the contract, and this is what we need to do.” However, I’ve found that this can lead to a losing proposition. Delivering exactly what’s outlined in the SoW can result in unhappy clients because, more often than not, it doesn’t address their real needs.
- Unmet Needs: Clients may receive what they asked for, but if it doesn’t bring about systemic, lasting change, they’re left feeling dissatisfied.
- Temporary Solutions: Without addressing the core issues, organisations often revert to their old ways as soon as the consultant leaves.
A Personal Anecdote
Let me share a personal experience that illustrates this point. I was on a train in England, and the Wi-Fi was utterly horrendous. Frustrated, I tweeted the train company to express my dissatisfaction. Their response? “We’re not contractually obligated to provide Wi-Fi.”
This response epitomises the pitfalls of rigidly adhering to a contract. It’s a classic case of missing the forest for the trees. The company was so focused on the letter of the contract that they neglected the spirit of customer service.
Rethinking Contracts
This experience has shaped my approach to contracts. I often prefer to work without formal contracts, opting instead for a more flexible arrangement. Here’s how I typically operate:
- Variable Contracts: I use what I call an “email contract.” It’s simple: “Can you help us out?” “Yes, I can.” “What dates?” “These dates.” That’s enough for me to book my flights and get to work.
- Trust Over Formality: This approach has served me well, especially with larger clients who often come with their own contracts. I assume an NDA for every engagement, but I prefer to maintain a level of flexibility that allows me to adapt to the client’s needs on the ground.
Delivering Value Beyond the SoW
The key takeaway here is that delivering value should be the primary goal, not merely fulfilling the terms of a contract. I strive to provide enough value that my clients feel confident in saying, “Yes, Martin delivered.”
- Focus on Relationships: Building a relationship with clients allows for a more dynamic and adaptive approach. When you understand their needs, you can deliver solutions that truly matter.
- Value-Driven Engagement: By prioritising value over contractual obligations, I ensure that my clients receive the support they need, even if it diverges from the original SoW.
Conclusion
In conclusion, the most valuable lesson I’ve learned as a consultant is to focus on the real needs of my clients rather than the constraints of a contract. By fostering relationships and delivering genuine value, I can help organisations achieve lasting change.
If you found this insight helpful, I encourage you to engage with me. Whether you want to discuss agile, scrum, or DevOps, feel free to book a coffee chat through Naked Agility. I always welcome the opportunity to connect and share ideas.
Well, I think so. The question is, what is the most valuable lesson you’ve learned as an agile consultant? And I think you could take the word agile out, and it’s just the most valuable lesson I’ve learned as a consultant in whatever flavour, right? I’ve ended up working in, and that’s that quite often the statement of work—in fact, almost always the statement of work—bears no relevance to the problems that the customer actually has.
And that’s where you have to try and tread carefully because it is your business, it’s my business as a consultant, in delivering a statement of work, or is it maximising the value that I bring to the customer, right? And quite often, consultants will deliver to the statement of work. “Right, here’s the contract, this is what we’ve been told we have to do, and we need to deliver to that contract.”
I find that that’s a losing proposition because you can quite often—and this happens a lot—have unhappy customers because you’ve delivered what they asked for, but it’s not what they need, right? It doesn’t actually bring any systemic, lasting change to their organisation, and things go back to the way they were as soon as you leave because there’s not that change because the statement of work didn’t include it or scope for it.
A great example of that was I was on a train in England somewhere, and it had Wi-Fi on the train, and the Wi-Fi was absolutely horrendous—absolutely horrendous. And I think I tweeted at the train company, and that’s using my mobile signal when I could, and basically said, “Your Wi-Fi is completely unusable on the train—completely unusable.” And the answer I got back, obviously from their marketing team, right? Because that’s where Twitter goes, was, “Well, we’re not contractually obligated to provide Wi-Fi.”
So, “Of yours,” right? That was pretty much the answer that came back from them. It’s like, “It’s not in the contract, so if it doesn’t work, we don’t care,” right? And that, to me, is that idea taken to a little bit too extreme, right? Of just following what’s in the contract. I quite often don’t like having contracts at all with customers because of that. I want to be able to dynamically and adaptively figure out what it is they need when we get on the ground and get engaging.
For most customers I work with, I just have a variable contract—an email contract, right? “Can you come and help us out?” “Yes, I can come and help you out.” “What dates can you come?” “These dates.” “Okay, I’m there,” right? And that’s enough for me to go book flights, right? Pre-COVID, book flights, turn up on site, and help them out, and then invoice them afterwards. And I never had a problem—never been burned. I’m sure now I’ve said that it will probably happen, right?
But never had a problem for the big, large customers, right? They come with their own contracts that they like you to sign and then do EAS and all of those things. I just assume NDA, right, for every customer I work with. But those bigger organisations with bigger contracts lock you in to delivering something that the procurement we need in the organisation is going to hold you to, regardless of whether you’re delivering value to the customer.
So you have to deliver enough value that the people that you’re working with will happily just tick that box and say, “Yes, Martin delivered.” Right? What’s in this statement of work when actually there’s no relationship between what’s in the statement of work and what was delivered? But we delivered what they needed at the level they needed that provided them with the value they needed to not worry about what was written in the contract.
Thanks for watching the video. If you enjoyed it, please like, follow, and subscribe. I always reply to comments, and if you want to have a chat about this or anything else—agile, scrum, or DevOps—then please book a coffee with me through Naked Agility.
