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