Gall’s Law is a handy principle to know when it comes to looking for ways to optimise your advice process.
The guy who first observed it, John Gall, was actually a pretty prolific author for a pediatrician, and of the seven books he published between 1975 and 2008, three focused on systems.
It was in his 1986 effort - Systemantics: How Systems Really Work and How They Fail - he observed the Law to which he gave his name
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
The moment I first read it, one word sprang to mind.
As anyone who has ever found themselves tinkering with using Excel to create business tools will tell you, there's a tipping point where something that started out simple suddenly becomes unmanageably complex.
Excel might be the simplest programming language on the planet, but it's also one of the most fragile.
All it takes is one level of complexity too much and you can find yourself spending hours working out how the hell you managed to design it in the first place.
Now, start that process off by building a behemoth from scratch (as opposed to slowly evolving the sheet) and you can see why it rarely works.
Why is it so hard to build a complex system from scratch?
Well, as Gall observed the more variables you have and the more detailed the web of interdependencies, which all need to happen in the right order, the harder it is to control the outcomes or even know what's causing the issues in the first place.
It's like trying to build an entire car from scratch and only finding out if it works when you turn the key at the end.
The odds are against you.
The point that's worth banking on here is about where to start.
Having lived in Japan for two years, there is a lot about the Japanese approach to art, efficiency and a bunch of other things that stuck with me, and none more so than one Japanese idealogy about perfection.
To me it's a beguiling idea that to achieve the optimal outcome, be it visual or mechanical, the goal should be to remove as much as can be removed without impacting the output.
It also explains a lot about Zen gardens...
Like a lot of firms I'm working with now, you may be looking for ways to get more done.
Perhaps your goal is also to reduce turnaround times, or reduce the amount of time it takes to do certain tasks, such as producing advice documents.
Usually, when I dive under the bonnet to understand the current state of play, what often jumps out at me is friction.
Too many pairs of hands.
Unnecessary detail in the documentation.
File Notes that read like someone's life story.
Too many meetings.
Steps in the process that add no value.
And often the cause is what's been done started out as complex and only got more so.
It's the complexity that's the issue
Underneath your complexity is a simple system that's desperately wanting to get out and evolve the way it should, instead of the way we may think it should.
Whether your goal is to improve your advice process, the way you deliver Reviews, how you deliver your service proposition, how you work together as a team, Factfinding or any one of the many opportunities to improve the efficiency, profitability and ease of doing what you do, if you've built something that is more complex than it needs to be...
...solve that first.