Have you ever had a client who said or thought something that seemed so asinine, so completely out of left field that you were left questioning how the hell they ever managed to start a business of their own?

I have. And let me tell you about one in particular…

I had a client who loved to come up with stuff. And after each meeting, we’d invariably end up adding a bunch of earth shattering ideas du jour to his project backlog. But he wasn’t willing to reach deeper into his pockets and broaden his budget with each increase in scope.

…So we started putting less important features into the “icebox”, or what I like to call: “that place where features go to die in obscurity.”

But my client didn’t think so. To him, the icebox was a place where time & material billing ceased to exist. It was a place where you could put stuff that’d be done later, but would be… not billed for?

Sounds completely absurd right? Of course it does, especially if you do this stuff for a living. But ultimately, no matter how hard I had to resist this realization, this was all my fault.

I assumed.

This is the second installment of a mini-series I’m doing on project management (read the previous post). In this post, I’m talking about the importance of setting expectations so you don’t end up with problems that are easily avoidable.

Most problems related to client projects have nothing to do with screwing something up technically — communication and expectation setting, or a lack thereof, is at the heart of most issues.

And what I’ve seen a lot of freelancers do is to assume that their clients know how they work, how to review, how to approve, how to provide feedback, and so on. When assumptions start being made, you’re exposing yourself to a disconnect  — you’re thinking one thing, and your client’s likely thinking something totally different.

Next in the series, I’ll be covering ongoing communication, but today I want to outline a few things that you should be discussing before kicking off a project with a new client:

• When and how you’ll meet. If you don’t set up a meeting protocol, some clients might think they can and should give you a call whenever they feel like it (this is how employees are treated.) My preference leans toward scheduling once-a-week meetings at a certain time for the life of a project.
• How you bill. Do you charge for being on the phone with a client? Or writing an email? Or doodling workflows? Or stuff in the icebox (!!!)? Make this clear. If your client thinks they’re only being billed for the time you’re in a code editor or Photoshop, they’re not going to be very happy to see “Meeting” as a line item in your next invoice.
• How you invoice, and what your payment procedures are like. How often do you bill? How soon do you need to get paid after dispatching an invoice? What are the consequences if an invoice is not paid on time?
• How to provide clarification. OK, so you’re paying money each month for a fancy project management app, but your clients keep emailing you. It’s probably because you didn’t tell them to actually use that thing you invited them into! I tell my clients that Client Portal is the central source of authority for their projects. And since I’m billing them for any time spent on their project, wading through dozens of email threads for information is not in their best interest.
• How to test. This is a big one for developers… Don’t assume your clients know how to test your deliverables. Teach them the difference between a bug (a problem with the software) and a feature (“maybe this button would look better over here…”.) I spend time a lot of time teaching each new client about how to test and what kind of feedback I’m expecting (e.g., “This isn’t what I wanted” doesn’t help me.)

These are just a few prerequisites that you should discuss with each of your clients, but I’m sure you can come up with plenty more based on the problems you’ve run into in the past. It goes without saying that much of this could (and should) be available for your clients as an easily shareable PDF or video.