A few weeks ago I wrote about the distinction between bioinformatics and computational biology. My point in that post was not to be absolutely correct about the definitions. Rather, I hoped to encourage conversation around the differences. I hoped to light up the importance of considering this distinction when planning and executing on projects.
There is a similarly valuable distinction to be made between contractors and consultants.
The core of it (for me) is that contractors are paid to do the project itself, where consultants are paid for their opinion, advice, and support – usually framed in highly actionable recommendations.
Opinions will, of course, vary. Please leave comments, particularly if you disagree!
With that framing, you can see why it’s important to know which kind of engagement you’re signing up for, either as customer or provider. I’ve had projects go rather radically off the rails because of mixed signals on the role that I was expected to play.
Note that many of us walk in both worlds. Most people spend the early part of their career doing projects, and transition to opining and advising once they have the benefit of that experience. There are, of course, exceptions, particularly when the services are closer to coaching than engineering.
This also ties into the question of how to set rates.
Finding the appropriate value for a contracting engagement tends to be relatively straightforward. The customer usually has an idea of the value of having the project complete, and has an idea of what it would cost them in staff effort and wall clock time to do it in-house. If that value (to the customer) is greater the amount that the contractor needs in order to make it worth their while, then there is space for negotiation.
Consulting roles are harder to quantify, though it is possible. One fruitful approach is to look at the expected costs / returns of various project outcomes. One need only look at the costs of a ransomware attack, data loss, or HIPAA violation to see that there is plenty of space in the information security field, both for good advice and also for robust operational practices.
As usual, I’m excited to hear your thoughts on this – doubly so if you think I’ve missed something important!
