4 ms·

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 understandin

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".
- acrooks 5y ago
  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.
throwaway81523 5y ago
Thanks, this is helpful. I will think about whether any of the stuff I've done could have been spec'd out that way.

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

acrooks 5y ago
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.

throwaway81523 5y ago

Thanks, this is helpful. I will think about whether any of the stuff I've done could have been spec'd out that way.