The latest episode of Unpivot is out. This week, they discuss what project success actually means
Hosts :Wyn Hopkins, Mark Proctor, Sue Bayes, and Giles Male
You can watch it HERE
"You can build absolute garbage in Excel and the client can be exceptionally pleased."
These are the words of Mark Proctor on the latest episode of Unpivot and it's been bouncing around my head ever since, because I totally agree.
The Unpivot team had an insightful discussion around what success on a project or training course looks like, and I’ve been comparing how that measures up to my own experience as an accountant, fractional finance director, and modelling trainer over the years.
The obvious answer is "the client's happy."
Job done, invoice sent, everyone goes home.
But as Mark said, a happy client does not equal a good job!
You can hand over a poorly built model held together with hardcoded numbers and circular logic, and if it tells the client what they want to hear, that could be enough to keep them happy. But that doesn't make it good and it doesn't make it right.
So if "happy client" isn't the only measure, what else is?
Giles told a story from early in his career working on a bid model. He'd built it properly, worked with subject matter experts, and got to a number that reflected the best view of reality (never forget - forecast models are always wrong!).
Then it went to the board, and the number was too high.
Diligent process, great model, "wrong" result!
This mirrors an experience of mine early in my career. I did a big piece of work on Activity Based Costing, using specific ABC software. Spend months out with the teams gathering information, crafting source reports and coming up with an accurate answer and a process that could be run each month.
Guess what.
It wasn't the answer that fit the business narrative. So we added some adjustments!
Wyn’s take was that those sorts of models still do their job. It gives people a realistic sense of what’s achievable given the assumptions, and the stakeholders then know how much the scenario in their heads differs from reality. Without it, they'd have picked a number out of the air with no idea how big a stretch it was. With it, they knew precisely how optimistic they were being.
That's a different definition of success entirely. Not "did they use the number I gave them," but "did they understand the ground truth well enough to know what they were choosing not to use."
I think this will ring true to a lot of modellers. You build the honest version, someone senior wants the flattering version, and it's tempting to feel like you've failed because your number didn't survive contact with the boardroom.
Wyn’s framing is the one I'll be taking away: the model succeeded, it provided the stakeholder with the context they needed.
Sue suggested that a client continuing to choose you to support them with either modelling or training is a good indicator of success.
Focusing on the training side, Wyn was sceptical as to whether someone needing more training for something you’d already showed them was really a good thing.
But Sue made the great point that people can only learn so much at a time, and just because they are in your session doesn’t mean they are ready to hear or implement everything you show them. If they enjoy your teaching style and come back to you when they are ready to go the next layer deeper, that’s a win.
For me, this really resonated. It's precisely why Full Stack Modeller is based around learn-when-you-like online training enriched with practice cases, community, live events and bootcamps.
Is a course successful if the room nods along and fills in the feedback form with fives across the board?
I believe successful training only comes when the learning is fully embedded in the day-to-day and becomes muscle memory. This may take a few sessions of learning plus lots of practice.
As painful as that may be to you as a modeller, there is a reason that this quote is still regularly rolled out.
Ultimately we need to give the customer what they want.
But, there is a careful balance to be struck here. You are being engaged (presumably) because of your expertise and the customer is unlikely to know all of the options available to them.
After all, you don't know, what you don't know.
Most clients aren't aware of Excel Tables and PowerQuery for example, and can find them daunting.
This is where your skill as a modeller helps you guide your customers through the scope and specification phase so that the end solution really meets their needs whilst being technically sound.
For me, a successful modelling project is guiding the client to the solution they really need, delivering that model on time and on budget, the model meeting expectations and being used without issue for years to come.
This comes from quality scoping and specification, a simple well structured build, a high level of user testing and training the client how to use the model.
The litmus test is when a client asks you to come back in for a new project and just casually mentions a model that you built five years ago and how it is still working perfectly.
The full episode of Unpivot is well worth a listen (as always). They’ve just hit 1,000 subscribers and have a great back catalogue of content to work through.
🎥You can watch the episode HERE
🧢👕There is now Unpivot Merch : Unpivot Mech Shop
🎧It is also available on all Podcast apps if you prefer to listen.