6 ms·

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 t

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.

mojomark 5y ago
>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.
throwaway81523 5y ago
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?
- deleted 5y ago
  [deleted]
- seanwilson 5y ago
  > 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.
  - throwaway81523 5y ago
    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.
    - rhizome 5y ago
      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?
      - ethbr0 5y ago
        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.
- acrooks 5y ago
  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.
  - seanwilson 5y ago
    > 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".

mojomark 5y ago

>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.

throwaway81523 5y ago

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?

deleted 5y ago
[deleted]
seanwilson 5y ago
> 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.
- throwaway81523 5y ago
  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.
  - rhizome 5y ago
    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?
    - ethbr0 5y ago
      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.
acrooks 5y ago
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.
- seanwilson 5y ago
  > 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".