I've never seen a project where the customer knew what they wanted clearly enough to have a SOW with a fixed scope.
Not sure if you do this but that's why you really should charge for helping with the requirements gathering and solution design, it's really valuable to pin down what the problem is and know that what you're going to build will fix it properly. It also means you're not in a rush to throw out an estimate with limited information. Better for both sides.
Right, I'll usually do an initial phone consultation for free, but anything more expensive would be billed. The issue is that there is not usually a well-defined problem. There is a general goal that takes some iterations to accomplish, with the customer concocting new features and requirements as development progresses. Of course everyone says to build some padding into the schedule for that, but they think of expansion factors like 10% when it really has to be 10x.
If it really is a well defined, contained problem, they will probably go on Fiver since they don't really need any design help, which is the most useful thing I can usually supply as a consultant. Banging out code is by itself nothing special these days.
The standard advice is that you're the one coming up with the list of tasks required to achieve an agreed upon goal, and concocted features to be added are a new, additional contract.
Stick to your list, practice establishing boundaries. If you're just working on whatever their whims bring to the table on any given day and can't control the tasks and outcomes to which you've already agreed, you aren't a contractor, you're an employee without benefits.
"Banging out code" is nothing special, yet here they are knocking at your door?
In my experience, requirements gathering and obtaining project design consensus is a huge part of the value add from a consultant.
(1) You're usually better at it than they are, because they're hiring a consultant in the first place. (2) You're outside of their political network, and can thus be a more neutral, objective arbiter. Invaluable! (3) You're looking at the problem with fresh eyes, whereas they're looking at it with a history of counterparty relationships, failed or successful previous projects, etc.
Furthermore, requirements gathering and obtaining project design consensus is going to happen at some point. Better you verify that it happens as fully as possible, as early as possible, versus trusting the client that they've done it accurately and sufficiently.
Exactly. The Handyman's Invoice/$1000 Plumber joke is a positive anecdote from the standpoint of the service provider, but it's usually stated as something like "Step 1: Know your value," which is deceptively simple.
The "when to throw out an estimate" is something I've evolved on a lot in my career. Initially, naive happy path. After that, happy path + some overly-large fuzzy padding number.
Now, I push back on PMs who ask for an estimate at an unknowable point in the project.
The problem is not estimating work. The problem is estimating work volume risk (the range of work the project might take). And the only thing that can decrease that is prototyping and similar.
I work in somewhat of a sub-niche (automation), so have a larger than average number of black-box, outside-of-my-control, unchangeable components. But I've come around to believing modified spiral [0] is a better approach when risk dominates.
Sometimes, the right answer to "How long will this take?" is "It will take this long to get an answer to that question."
Sometimes, the right answer to "How long will this take?" is "It will take this long to get an answer to that question."
Yep, or sometimes "no idea, let me work on it for a day and get back to you". You can't expect an estimate for something with many unknowns to be very accurate so best to reduce the unknowns first.
Real world projects have too many factors out of your control as well (e.g. decision making and schedules of stakeholders, combinations of software/people/requirements you've never worked with before, evolving requirements) so this idea that you can guess the total number of hours with high accuracy as you get more experienced doesn't make a lot of sense to me.
Fixed price projects are also a way of saying "we genuinely don't know how long it's going to take, but we'll take on that risk instead of you".
Comments
Not sure if you do this but that's why you really should charge for helping with the requirements gathering and solution design, it's really valuable to pin down what the problem is and know that what you're going to build will fix it properly. It also means you're not in a rush to throw out an estimate with limited information. Better for both sides.
Right, I'll usually do an initial phone consultation for free, but anything more expensive would be billed. The issue is that there is not usually a well-defined problem. There is a general goal that takes some iterations to accomplish, with the customer concocting new features and requirements as development progresses. Of course everyone says to build some padding into the schedule for that, but they think of expansion factors like 10% when it really has to be 10x.
If it really is a well defined, contained problem, they will probably go on Fiver since they don't really need any design help, which is the most useful thing I can usually supply as a consultant. Banging out code is by itself nothing special these days.
The standard advice is that you're the one coming up with the list of tasks required to achieve an agreed upon goal, and concocted features to be added are a new, additional contract.
Stick to your list, practice establishing boundaries. If you're just working on whatever their whims bring to the table on any given day and can't control the tasks and outcomes to which you've already agreed, you aren't a contractor, you're an employee without benefits.
"Banging out code" is nothing special, yet here they are knocking at your door?
In my experience, requirements gathering and obtaining project design consensus is a huge part of the value add from a consultant.
(1) You're usually better at it than they are, because they're hiring a consultant in the first place. (2) You're outside of their political network, and can thus be a more neutral, objective arbiter. Invaluable! (3) You're looking at the problem with fresh eyes, whereas they're looking at it with a history of counterparty relationships, failed or successful previous projects, etc.
Furthermore, requirements gathering and obtaining project design consensus is going to happen at some point. Better you verify that it happens as fully as possible, as early as possible, versus trusting the client that they've done it accurately and sufficiently.
Exactly. The Handyman's Invoice/$1000 Plumber joke is a positive anecdote from the standpoint of the service provider, but it's usually stated as something like "Step 1: Know your value," which is deceptively simple.
They tend to want to pay pretty poorly in this situation.
Perhaps, but my point is that calling what one does in this situation "banging out code" is underselling and unfair to oneself.
The "when to throw out an estimate" is something I've evolved on a lot in my career. Initially, naive happy path. After that, happy path + some overly-large fuzzy padding number.
Now, I push back on PMs who ask for an estimate at an unknowable point in the project.
The problem is not estimating work. The problem is estimating work volume risk (the range of work the project might take). And the only thing that can decrease that is prototyping and similar.
I work in somewhat of a sub-niche (automation), so have a larger than average number of black-box, outside-of-my-control, unchangeable components. But I've come around to believing modified spiral [0] is a better approach when risk dominates.
Sometimes, the right answer to "How long will this take?" is "It will take this long to get an answer to that question."
[0] https://en.m.wikipedia.org/wiki/Spiral_model
Yep, or sometimes "no idea, let me work on it for a day and get back to you". You can't expect an estimate for something with many unknowns to be very accurate so best to reduce the unknowns first.
Real world projects have too many factors out of your control as well (e.g. decision making and schedules of stakeholders, combinations of software/people/requirements you've never worked with before, evolving requirements) so this idea that you can guess the total number of hours with high accuracy as you get more experienced doesn't make a lot of sense to me.
Fixed price projects are also a way of saying "we genuinely don't know how long it's going to take, but we'll take on that risk instead of you".