I’ve shifted to bidding fixed rate on projects around a defined scope. It’s a lot more work upfront to define a clear statement of work, but it has allowed me to stay above USD$200/hr without customers batting an eye - whereas my rate was consistently a sticking point in negotiations.
My consulting mostly focuses around IT/digital strategy and the work product usually involves connecting together incumbent systems, and sometimes implementing new systems while ensuring they’re deeply interconnected with the rest of an organisation, aligning them closely with biz process, etc. My customer is always a business unit lead so the budget tends to be more aligned with top-line outcomes.
I've never seen a project where the customer knew what they wanted clearly enough to have a SOW with a fixed scope. The work always expands. Maybe I've been doing something wrong. How are you doing during the pandemic, which makes in-person meetings and on-site work difficult?
- Because of my focus in particular industries, I tend to start projects already having a baseline of understanding of what my customers need.
- You can write a fixed price contract that leaves room for a customer to change their mind / not know what they want. If you articulate very clearly in the SOW what you will deliver for the fixed price, then you leave yourself open to issue change orders as the scope evolves. Of course, you need to be careful how militant you are here, because issuing a change order for every minor thing won't help you get repeat business. To hedge against this, I tend to include a bucket of hours for arbitrary changes. This gives the customer some room to change their mind still without allowing them to derive and negotiate against an hourly rate.
- In my experience, fixed price allows me to 2x or more the hourly rate I would otherwise be able to charge, so if I do a bad job at writing an SOW then I have a lot of breathing room between what I'm getting paid and what I likely would have gotten paid had I billed hourly.
RE: Pandemic: I don't develop the work product on customer sites, so I'm only really there for meetings (so a lot during discovery and a lot during delivery). I've found that it's been pretty easy to migrate this to Zoom/Meet albeit with a bit more friction. It's a lot more difficult doing discovery remotely, but I find running workshops in Miro has been invaluable to ensure I'm capturing everybody's voice.
Of course, you need to be careful how militant you are here, because issuing a change order for every minor thing won't help you get repeat business.
Yep, I also find people don't notice the changes usually go both ways as well, where it's common that some requirements change a little or get dropped in a way that makes your life easier. It's great when both sides can be reasonable and non-adversarial about it all. A deadline with a well-defined goal helps a lot too, over a rigid list of requirements.
To hedge against this, I tend to include a bucket of hours for arbitrary changes.
Can you explain this part more? How do you explain what gets charged against the bucket of hours and how many hours for each change? At what stage do you issue change orders?
Small thing I don't hear people mention but with the SOW I always add a list of "not in scope" items too (e.g. "web app works in latest version of Chrome only" + "Internet Explorer and mobile support is out of scope"). I find this help uncover ambiguities like the client saying later "I assumed it would have worked on mobile Chrome and desktop Edge too", and makes it much easier to say "we agreed that's out of scope".
For the arbitrary changes, I mean that I will sometimes add a clause along the lines of: "Includes a maximum of _ additional hours for work not already defined as part of the Deliverables." Where the number of hours is a very small percentage of the overall project estimate.
I find it's an easy way to give the customer more budget certainty upfront and offer some level of flexibility. So as the customer asks for something out-of-scope that's small, I can just draw down the hours pool instead of debating between issuing change orders and eating the cost. And then you have some form of contractual protection saying "oh hey, your 10 tweaks took up the entire pre-agreed contingency, it's time for a change order" which is a much easier conversation to have.
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".
It’s a lot more work upfront to define a clear statement of work, but it has allowed me to stay above USD$200/hr without customers batting an eye - whereas my rate was consistently a sticking point in negotiations.
I don't know why I'm reading this thread 15 minutes before I study the back of my eyelids for 8 hours, but the truth in this statement oddly stoped my academic pursuits dead in my tracks.
Comments
I’ve shifted to bidding fixed rate on projects around a defined scope. It’s a lot more work upfront to define a clear statement of work, but it has allowed me to stay above USD$200/hr without customers batting an eye - whereas my rate was consistently a sticking point in negotiations.
My consulting mostly focuses around IT/digital strategy and the work product usually involves connecting together incumbent systems, and sometimes implementing new systems while ensuring they’re deeply interconnected with the rest of an organisation, aligning them closely with biz process, etc. My customer is always a business unit lead so the budget tends to be more aligned with top-line outcomes.
I've never seen a project where the customer knew what they wanted clearly enough to have a SOW with a fixed scope. The work always expands. Maybe I've been doing something wrong. How are you doing during the pandemic, which makes in-person meetings and on-site work difficult?
Well, there are a couple components to that:
- Because of my focus in particular industries, I tend to start projects already having a baseline of understanding of what my customers need.
- You can write a fixed price contract that leaves room for a customer to change their mind / not know what they want. If you articulate very clearly in the SOW what you will deliver for the fixed price, then you leave yourself open to issue change orders as the scope evolves. Of course, you need to be careful how militant you are here, because issuing a change order for every minor thing won't help you get repeat business. To hedge against this, I tend to include a bucket of hours for arbitrary changes. This gives the customer some room to change their mind still without allowing them to derive and negotiate against an hourly rate.
- In my experience, fixed price allows me to 2x or more the hourly rate I would otherwise be able to charge, so if I do a bad job at writing an SOW then I have a lot of breathing room between what I'm getting paid and what I likely would have gotten paid had I billed hourly.
RE: Pandemic: I don't develop the work product on customer sites, so I'm only really there for meetings (so a lot during discovery and a lot during delivery). I've found that it's been pretty easy to migrate this to Zoom/Meet albeit with a bit more friction. It's a lot more difficult doing discovery remotely, but I find running workshops in Miro has been invaluable to ensure I'm capturing everybody's voice.
Yep, I also find people don't notice the changes usually go both ways as well, where it's common that some requirements change a little or get dropped in a way that makes your life easier. It's great when both sides can be reasonable and non-adversarial about it all. A deadline with a well-defined goal helps a lot too, over a rigid list of requirements.
Can you explain this part more? How do you explain what gets charged against the bucket of hours and how many hours for each change? At what stage do you issue change orders?
Small thing I don't hear people mention but with the SOW I always add a list of "not in scope" items too (e.g. "web app works in latest version of Chrome only" + "Internet Explorer and mobile support is out of scope"). I find this help uncover ambiguities like the client saying later "I assumed it would have worked on mobile Chrome and desktop Edge too", and makes it much easier to say "we agreed that's out of scope".
For the arbitrary changes, I mean that I will sometimes add a clause along the lines of: "Includes a maximum of _ additional hours for work not already defined as part of the Deliverables." Where the number of hours is a very small percentage of the overall project estimate.
I find it's an easy way to give the customer more budget certainty upfront and offer some level of flexibility. So as the customer asks for something out-of-scope that's small, I can just draw down the hours pool instead of debating between issuing change orders and eating the cost. And then you have some form of contractual protection saying "oh hey, your 10 tweaks took up the entire pre-agreed contingency, it's time for a change order" which is a much easier conversation to have.
Thanks, this is helpful. I will think about whether any of the stuff I've done could have been spec'd out that way.
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".
I don't know why I'm reading this thread 15 minutes before I study the back of my eyelids for 8 hours, but the truth in this statement oddly stoped my academic pursuits dead in my tracks.