I wanted a field for the labour cost. Another field for the machine cost. And another for mark-up.
They didn’t price like that. They looked at a job and intuitively knew the price.
I had tried to construct the data bottom up. A piece of data for each element, which collectively made up the price. In my head, a price “should” be built up from its parts.
They’re not doing it that way. They’re pricing intuitively, and pricing up and down based on competition and what it takes to win the work, which only they know. I shouldn’t have assumed my data way of doing it was the correct one.
Three fields is the easy build. It is the obvious shape for the data, and all the effort of filling them in lands on someone else.
I built the easy one.
What it does now
Their number is the input. Whatever they want to quote is taken as correct.
Then the system works backwards. You’ve used these machines, these resources, and these are the cost rates for each of them. If we did a pure cost plus, what would those resources be worth, and therefore what margin are you making above or below that?
It doesn’t tell them what to charge. It tells them what they just did.
And it leaves the decision where it always was. They want to price low or high, strategically, and only they know what it takes to win a particular job. What they don’t want is to undercut themselves, or to find they’ve worked something at zero margin. The comparison lets them keep making exactly the calls they were already making, while finally being able to see whether they’re pricing correctly, whether they’re being too aggressive, and whether there are markets they should move out of altogether.
Simple is harder than easy
To keep it simple for the user, the system has to work a lot harder. And that is the way it should be.
I don’t need the neat data. I need the truth, that I can then compare. Their way gets me that and is far simpler.
The clues were already there
They already had a process. Yes it was manual and clunky, but it worked, and there were a lot of clues baked in.
The main user likes things visual. All the interfaces he was using were drag and drop, or delete from here, add to there.
The other clue was in how they described the process, and how many anomalies there were. There are always a lot of anomalies in a process. Asking them to describe the last five jobs, rather than to describe their process, would have got me to a better answer a lot faster. Take the evidence, not what they think.
And really listen to their words. I was guilty of listening to what they said in order to build a model in my own head, rather than trying to see the model they already had. The language they use really helps with that.
Why I stopped where I did
Underneath it is a tendency I have had for a long time, and if I saw it in others I would probably call it arrogant. I want to skip to the end. In my lane I can see the whole journey, so let’s just get you to the top and save you the effort of walking there.
The problem is that skipping to the end makes people feel stupid, and it is a sure fire way of not letting people get there and accept the change.
In this build it showed up as skipping to the bit where we have good data, and forcing the people to act in a way that produces it. Against my own policy of data as a byproduct.
I wasn’t being lazy. I stopped iterating when I found a solution, rather than continuing until I exhausted the question, could this be simpler for the user?
Close enough is not good enough
The fix for that isn’t more stamina. It’s being more rigorous about what I’ll accept as finished.
Does this serve the system, or does it serve the person?
If it serves the system and not the person, and there isn’t a very strategic reason for it, then the system isn’t finished yet. Close enough is not good enough.
I am so grateful for this re-build and the lessons it has taught me.