I was having a conversation the other day with a software engineer who told me that they tried to explain to their clients that things would be better on the project, as a whole, if they could also write (along with the code) some automated test routines.
The client asked if it would cost extra, to which the developer said, “Yes, up to 20% more.”
You can imagine how the conversation went from there.
The client rejected the extra fee and went with the least costly approach to the project.
The developer then looked at me and said, “The problem is that no client wants to pay for testing.”
My response, as you can imagine, was that the issue wasn't their desire to pay for anything.
The issue was in the narrative.
You know, by now, that for me, the story is everything. I don't mean story as in a fiction we tell others. I mean story as in the way we present information to help people think about the decisions they're making in the appropriate context.
I followed up my conversation with that engineer by asking a different question.
“Do your clients ever come back later in the project and ask for changes?”
You can imagine what their response was – because it's likely that we've all been in that world together, right?
Clients always want something else down the line.
And to be clear, there's nothing wrong with that.
But when someone wants something added to a project, there's another task we all have to do, that people rarely explain or charge for.
Before I explain it, can I ask you a question?
Do you now charge people for project management?
A couple years ago I would ask the question and most people would tell me that they don't have it as a line item. Thankfully, over the last few years, I've seen that issue slowly disappear.
People are charging for project management. That's a good thing.
But here's the new line item I bet you're not putting on those change orders.
Impact Analysis.
Just two little words, like “project management.” But they mean a lot. And most people don't have them on their change orders.
Here's my simple definition:
“Figuring out what's going to break or need to be changed, now that you're changing things after the initial design.”
That takes time. It has cost. And it should be a line item on every change that shows up in a change order.
At least it's what you would expect in any other realm. So why not expect it in the world of software?
And that's why our narrative should be different when we talk about testing.
If we add test routines for our key features, even if it takes an extra 10-50% of effort for the features we code, then the cost of impact analysis moves low enough to almost be considered zero.
We distribute the cost of tests (and automated testing) across an entire development plan so that we can reduce the cost of those last minute changes that people want.
And that's good news when those last minute changes could mean a significant amount of impact analysis.
But if we're not explaining impact analysis, then our clients just think about testing the wrong way.
Instead of thinking of it as a way to mitigate their own costs, they think of them as a way to mitigate our costs (our own mistakes). And that's a narrative that's hard to sell.
In the end, if you tell the story the right way, my sense is that clients will want to pay for testing.
Especially if they want the freedom to change their minds later and make changes.
Which is a good thing.