Defining the Rules of Engagement

Usually when we talk about engaging with clients, we start listing tangible deliverables they should expect from a project, from the initial draft schedule to the final product design.

When you start a project, conversations should be only about what clients require from us. It's also about what we expect from them. The best way to do this is to define the rules of engagement for your clients.

The following expectations are completely fair to request from any new client:

• Timeliness
• Consistency
• Direct dialogue
• Respect for process
• Transparency
• Accommodation for human error

Now, you can't just send this list to a client and say, "Hey, now you're going to respect my process!" If you don't tell your client up front about your expectations for their behavior, you're scolding them for things they never knew they needed to do.

So provide to your client in writing your rules of engagement. It only needs to be one page, which includes at least the following:

• The type of feedback they need to provide, and when
• Who is assigned to collate their feedback (that isn't your job!)
• The frequency and consistency of client contact: whom will respond, when, and how
• What will happen if errors should occur
• Whom the key decision makers are, and when their input is required from deliverable to deliverable

Not meeting expectations, stated or unstated, is one of the major reasons that client relationships fail. So don't let that happen—state up front what you require, and the project will always run a little more smoothly as a result.

Thanks to Erica Goldsmith for collaborating with me on this post.

Comments

[Katie]

David,

I appreciate this post. At Newfangled, we've made great strides in improving the structure of our client engagements (defining key decision makers, outlining preferred feedback) but we haven't defined a risk assessment plan in the event of error. I'm intrigued by the idea, but have a few questions:

1. What reaction do you get from clients when outlining what will happen when they're at fault?

2. When error does occur, how often do you end up referring back to these agreements? Or does simply outlining the process tend to prevent error?

Thanks again for the great post!

Katie

[David Sherwin]

Hi Katie,

To answer your questions:

1. If you're describing all of the possible things that can go wrong—from your own team's internal POV, in what could happen with third-party vendors, and from the client's side if they are late with feedback on key deliverables—then the client understands that you are acting in the best interest of the work being done to a professional standard. If you just outline what might happen if they cause a problem, then they will feel like you are being punitive.

2. Outlining the process helps prevent error—and if one does occur, you state in your written response as to how the error will be mitigated that you are following the protocol that you'd described in the risk mitigation plan... the same one that they agreed to at the start of it all. I've found that when you make one of these, you keep pulling it forward and improving it from project to project, based on key learnings from any errors that do slip through.

[Kate]

wow, your timing on this post couldn't be more relevant to me right now! Just last week I had to "break up" with a client for completely ignoring every item on your list of expectations -- even when they themselves had outlined some of them in their initial correspondence. The straw broke the camel's (or designer's) back when I couldn't even get a phone number from them after asking via email 3 times...

thanks for the post, I feel a little more validated for thinking I was being jerked around, and less like a bratty Artist.

[Jake]

This post inspired me to create an 'initial contact' outline for new clients that lays out all the expectations I have of my clients and what they can expect from me. I hope it works!