(That's how it should be, i think, in contrast to people who have expertise in consulting, while the actual domain knowledge is a (replaceable) after thought.
I guess much of it goes hand in hand with general communication skills and the fact that it is fun to talk about ones passion, but i'm looking for some best practices and general rules.
Can someone recommend a book/article/guide on the craft of consulting?
You may find "Cracked It!: How to solve big problems and sell solutions like top strategy consultants" useful: https://link.springer.com/book/10.1007/978-3-319-89375-4
I haven't read it but only skimmed the contents and it looks close to the process we converged toward through systematic and continuous refining.
Related reading and concepts: "Design Thinking", "The Complete Problem Solver", Clayton Christensen et al. work, "job to be done", "non-consumption", etc.
What I call "inverse framing": a client asks you to predict something 48h before it happens. 48h sounds arbitrary and you ask "Why 48h? Why not 30h" and get a reply, then you ask "At what point a prediction is useless to you? What is too late?" and they say "Even if you predict it 2 minutes before, there are still things we can do to mitigate damages and we have processes for that", so now you helped your colleagues by going from a 48h prediction to a 2 minute prediction, but even more useful, you have a better understanding of the constraints and the people impacted by that. You also ask "What's the cost/impact of a false positive? What's the cost/impact of a false negative?". Possible answers: human loss, environmental catastrophe, $100MM in loss, a $9B piece of infrastructure blows up, or a combination of these. or you wake up an engineer or attract the attention of someone on duty.
But the one dominating thing is that as a consultant you are usually being paid to solve a problem, as opposed to perform an activity. In the mind of whoever is paying you, they had a problem and they brought you in to solve that problem and they want it to go away, preferably with the minimum of supervision or drain on their time.
As a consequence, expectation management is a huge thing - it is very common that the problem you are there to fix may not have been understood well and so expectations are unreasonable, if not unachievable.
This also means that it is also very common, as a way of managing expectations, that the first part of the consulting is to write your own scope.
This allows a crucial aspect to be defined, being "when have I finished or succeeded", because you and they may well have different ideas about this otherwise.
As a consultant, if you look for repeat work or good referrals, you need to be trying to show that you are delivering service and value every hour you are billing. If you can do that they will happily pay whatever rate you charge. Don't hang around and "milk it". For some reason most people value a dollar paid to a consultant far more highly than one paid to an employee, so demonstrate you are worth it.
I usually like to create a "Project Execution Plan" as part of the offer, or worst case at the kick-off meeting. This can be as simple as one page that details the scope, duration, deliverables, who and how you report to, expected location and times of performing the work, and so on, signed off on by the client. This creates a referable basis that creates common expectations, thus greatly reducing the possibility of conflict.
I've been consulting as an engineer for 30 years now and had to learn as I went.
But every situation is different, you just have to wing it sometimes.