Avoiding scope creep: how to help ensure you get paid for extra work

Hello!

This is an excerpt from the book I'm writing called: "The Freelance Coder's Handbook: What 39 years of developing solutions for clients by myself can teach you"

I'm writing this because I have enjoyed a long career as a solo freelance coder and I want to give back something. Freelancing/solopreneurship can be a wonderful way of living, with many benefits. But there are things that can really negatively affect you. I know some of these and I want to get them into print so that others can see how I approached their solution. I am quite sure most of you will have had these types of challenges and your own unique solutions. I am very interested in what you think.

So here is a sample section: a case study within the Proposal Writing chapter.
(I've used Markdown).

Many of you have dealt with this type of thing many times, and so I'd like to hear from you if my approach rings true for you. Perhaps, you have had vastly different experiences. Let's discuss. I think we can learn much together.

Thank you in advance!

Fraser

---

Proposal Case No. 1

Freelance coders: consider this scenario: "Quick" Add-on proposal for an existing project

Background

You've had a meeting with a client where you delivered some (or all) of the agreed work. The meeting went very well. The client liked much of what you delivered, but they want changes. And, they found errors and shortfalls in what they think you should have delivered.

You ended the meeting well, saying, as you should, that you will review your notes (you took LOTS of notes, right?) and then get back to them before you start on any changes. You want to be able to discuss any implications that the meeting's observations have on deliverables and delivery. This internal review of yours is your way to get technical details ready as well as get your head clear to deal with any friction you feel.

So now you have reviewed. You agree that some things should have been done differently. You also agree that some other things were not working and need to be fixed. However, you don't agree with everything the client said/expected. In particular, you think some items are new to the scope. Your position with these: if they want them added to the current work, they will have to pay extra.

So now you have to report back to the client and you are a little worried about how they will receive this extra 'ask'.

Here's what to do:

1. Separate the 'free' things from the ones you want to be paid for. Place the free items at the top of your message.

I would even go as far as to list the free error fixes in one section followed by the free changes in another.

2. Transition into the items you want to be paid for, but don't give a price!

Instead, list the work you want to be paid for by giving each a title, and then, in point form, list the advantages this work has for the client (as you currently understand them) as clearly as you can. Leave the price conspicuously absent.

3. Finally, in your message just below these payable items, say this:

"Would you like me to quote on these?"

Why? Here's my rationale:

1. You clearly define what you consider free and what is extra to your current scope.

If they disagree, they will contact you. You can discuss from there.

2. You isolated the free items and thus remove them from further discussion.

By leading with the free, you are delivering good news first and you transition to what you want to be paid for with the benefits in a natural way. In effect, you are opening the door to a conversation solely about the things you want to be paid for.

You'd be surprised how many times shortcomings and flaws in a milestone/final product get rehashed if you keep all of the work to be done in one big jumble. And that wastes everybody's time.

3. You clearly define what you think the client is asking for: the what and the why.

By stating it in your own words and listing the advantages as you see them, you give the client a chance to confirm whether these items are truly wanted. A lot of misunderstandings are averted by this simple approach.

4. You give the client the opportunity to value the items you want to be paid for.

After all, these work items are not valuable to the client unit they say so.

By 1) telling them you think these work items are valuable, and 2) asking (tacitly) for their thoughts, you are signaling to them that you think they are valuable, but without their "how much is this going to cost me" guards coming up.

If they disagree with you, they will tell you and no harm done. You wasted no effort pricing the work. Neither you nor the client suffers any chagrin if they decide not to proceed as a result.

You may be surprised how often this seemingly negative outcome spawns a new idea (either from the client or you) that ends up being quoted, accepted, and paid for. You are giving the right solution a chance to appear - together.

5. You are giving them time to think about the amount they want to pay and the timetable for delivery before they ask you to quote.

This takes the pressure off both of you.

If the client wants to pursue any of your extra items, you have given them time to consult bosses and internal stakeholders. They also have time to estimate the work involved (from their perspective) and possibly the amount they might want to pay.

You give them time to get a budget and timetable that works for them.

The actual price you assign to a quoted work effort is another subject that we shall explore a little later.

Remember: There is no such thing as a bad conversation with a client, as long as you manage expectations (both yours and theirs).

If you are interested in further excerpts from the book, I am continuing my book writing journey on Twitter. You can follow me there.