Agreements = Expectations

Every client/vendor relationship is based on a set of expectations, whether they’re stated or not. When you hire a painter, the act of applying paint is only part of the gig. All the steps that lead to the finished job are where the details lie.

I expect the painter to:

• Get to my house on time.
• Move any furniture that’s in the way.
• Put down drop cloths.
• Refrain from smoking in my house.
• Refrain from rinsing brushes in my kitchen sink.
• Be respectful and professional.
• Finish the job on time.
• Leave the house in the shape it was in before the job started.

I don’t expect the painter to:

• Feed my dog while I’m at work.
• Set my alarm system.
• Paint areas I didn’t specify.
• Apply three coats of paint.

A lot can go unsaid or unspecified for any project, large and small. Not being specific can lead to disagreements, quarrels, and high blood pressure.

For my day job, I’m on the other side of the fence. At Happy Cog, we work with dozens of clients each year. Over the years, you learn a thing or two about a thing or two, usually as a result of the mistakes you’ve made along the way. A business relationship is governed by what you mutually agree to. A Statement of Work (SOW) or Statement of Services (SOS) is one tool used to align expectations. We used to use SOW and SOS synonymously with the words “contract” or “proposal,” but they’re actually a little different. Whatever you call them, they will save your bacon.

SOWs and MSAs#section2

A Statement of Work (SOW) is usually a document that accompanies yet another document, often referred to as a Master Services Agreement (MSA). They’re the Lenny and Squiggy of legal agreements. The MSA is usually the governing document for the entire relationship, while the SOW usually deals with the specifics of a single project or scope of work. Our larger scale clients usually prefer to lead with an MSA, even though we’d rather lead with our own agreement, which we call a Project Service Agreement (PSA). The acronyms are already making me loopy.

An MSA will typically address relationship-governing topics such as:

• General Services—In general terms, what you’ll provide the client (web design services, content strategy, etc.).
• Project Management—What the roles for project managers on both sides will be.
• Deliverables—How deliverables will be provided to and accepted by the client.
• Support/Deployment—What assistance you’ll provide the client with implementation, and what additional support you’ll provide moving forward.
• Payment/Expenses—How you’ll get paid, which expenses are covered and which aren’t.
• Audits—How the client can ask you to prove you’re doing your job.
• Confidentiality—What you can’t say about the work, and what your client can do if you blab.
• License Grants—What client-owned information you’re allowed to use, and for how long.
• Proprietary Rights—Who owns the work (even the individual elements of it) when the job’s done.
• Term and Termination—How long the agreement lasts, who can end the agreement, and for what reason.
• Representations and Warranties—Ensures you can do the work, you’re not in conflict with other agreements, and that you’ll fix what’s broken if it’s your fault.
• Indemnification—To guarantee against any loss which another might suffer.
• Insurance—The types and amounts of insurance coverage you’re required to carry to perform the work.

A SOW, on the other hand, typically addresses such things as:

• Requested Services—Describing what the project actually is.
• Project Phase Descriptions—Detailing how many phases, and what goes into them.
• Project Duration and Milestones—Estimating how long the project will take and what milestones occur along the way.
• Resource Hours—How many hours are allocated to each phase.
• Billing Rates—What you’re charging for each practitioner in your company.
• Proposed Tasks & Deliverables—What you’ll do and deliver, and when.
• Commencement and Completion Dates—When you’ll start, and if all goes well, when you’ll finish.
• Service Fees—How much you’re charging for the entire engagement.
• Payment Schedule and Terms—How much you’ll get paid, and when.
• Listing of Representatives—Who the primary players are on each side, or at least what their roles are.

As you can see, it’s all quite invigorating.

If the MSA and the SOW have similar or conflicting language, the MSA is usually the agreement that takes precedence. Some lawyers will tell you it should be the other way around, and will fight for that stipulation. After all, the details the SOW captures are more project focused and granular, and therefore may provide more context. An SOW is created for each specific project, and is highly specific to the current work at hand.

Be careful: don’t lock in to a long-term MSA#section3

We usually don’t sign MSAs that carry a term longer than a year. Why? Well, say you sign an MSA with a two-year term that states that the client can terminate the relationship whenever they want, but you can’t. You sign the MSA anyway, because you were too lazy to consult a lawyer to slap some sense into you. Then, you execute a SOW for a big project that takes a year to finish, and everything goes smoothly. Based upon that positive experience, you agree to sign another SOW for an even bigger project. Remember, you’re still governed by the MSA you originally signed a year ago. Say that during the second project, the person you loved working with on the client side leaves, and is replaced with someone who is impossible to work with. After trying everything you can to make the project work, you decide you want to get out. Well, too bad. The MSA says you can’t. Have fun with that!

The bottom line is this: you’re always learning, and your needs change. Don’t lock yourself into things. It’s the same reason you don’t want to sign a three-year contract when you sign up with a mobile carrier.

I’m not the first to say this, as it applies to both MSAs and SOWs: everything is negotiable. Don’t simply take an MSA from a company, and because you might need the dough, sign it without scrutinizing it. Get yourself a lawyer and go through it. Track changes. Your client will expect that, and you won’t be a jerk for putting it under a microscope. We once had a prospective client try to slip a non-compete clause in the MSA that stated we couldn’t consider any opportunities in their industry for a period of five years. Um, no. Be sure to look closely.

PSAs#section4

At Happy Cog, our preferred starting point when defining a business relationship isn’t the MSA/SOW combo many of our potential clients enjoy so much. As I mentioned above, we lead with our own Project Service Agreement (PSA). It’s specific to the project at hand like a SOW, but it also contains all of the relationship-governing legal stuff like an MSA. It’s an MSA, SOW, proposal, and agency résumé in a neat, elegantly designed package (MSAs and SOWs are usually ugly legal documents, so we like to construct/design our own that better communicates our brand).

Our PSA starts with the information our prospective clients want to see the most: the cost. We save them from the page flipping/PDF scrolling. There it is, our price tag, right on page two in big, bold numbers. On the same page, we detail our proposed payment schedule, and how we prefer to be paid. On the surface, it sounds like the wrong thing to do, but after considerable testing, our prospects appreciate it.

Next, the PSA provides an overview of the history of our company, talks about our differentiators, and includes bios of our people. Next, there are several paragraphs that introduce the problems we’re trying to solve. At a very high level, we describe how we propose to solve them. We then detail the phases involved with our effort, including the number of hours we expect to expend on each phase.

After all of the prose comes the legalese. It is a bit jargony, but it has to be. Every time we tried to convey legal language in an easy-to-understand way, we were doing ourselves more harm than good. Know your audience. Lawyers expect to read things a certain way.

Be vague (you heard me)#section5

This is subtle, but important: don’t try to solve what you don’t understand yet.

Reflecting on many years, even before my role at Happy Cog, I think we tended to consider projects a bit too “one-size-fits-all-ish.” Up front, we would establish which tasks we were going to perform, which artifacts we were going to produce, how many comps we were going to design, and how many revisions we would offer. It usually consisted of a site map with three rounds of revisions, 10-12 wireframes with three rounds of revisions, three different design comps created by three different designers revised three times, and HTML/CSS templates for 10-12 pages. For just about every project. This created a bunch of issues.

First, we were prescribing solutions before really understanding the problems. And the only way you can be 100% confident about what you should be delivering is to do your research and to have in-depth conversations. But how do you articulate how you’ll solve problems you don’t fully understand yet? You’re still trying to be asked to the dance. There are no signatures on contracts yet. And we didn’t want to do a bunch of unpaid fact-finding to achieve clarity for the sake of a contract.

We needed to solve that issue. Two ideas came to mind. We could choose to:

• Change our approach to simply pitch a project research/definition phase for a fraction of the total project cost, and allow the findings from that effort to provide the ammo we needed to put together a detailed contract for the rest of the work.
• Be a bit more vague with what we say we’ll do.

That second bullet point looks ridiculous when you read it. Shouldn’t you be getting more specific, not less? I’d argue no. Instead of prematurely committing to a course of action that may or may not be appropriate for the project, we identify all of the possible artifacts we could produce in each phase. Then we commit to zero of them.

Then, we list them. For example, the types of deliverables we could provide for information architecture work includes:

• Taxonomy creation
• Persona development
• Content outline
• Content genre classifications
• Site outline
• Site map
• Wireframes
• Page description diagrams
• User/process flow diagrams
• Comprehensive experience document

Your client’s role in selecting a vendor includes performing the necessary due diligence to feel confident with your work, your people, and your process. This includes checking references. If your client has faith in your abilities, you’ll have no problems being less prescriptive with your PSA or SOW. In fact, you’re actually being responsible. You don’t know what you don’t know, right? Don’t suggest the wrong stuff just to tie your agreement up with a pretty bow. Be honest, and say that you’ll do what is the most appropriate. Most of our prospective clients, when reading our PSA, don’t bat an eye over our purposeful lack of specificity.

Bucket those hours#section6

Back when we’d prescribe exactly what we would deliver ahead of time, we’d run into another conundrum. Clients wanting more.

We once had a client that wasn’t happy with the designs we created for them. We promised them three variations, with the winning idea revised twice more until we had the perfect design. We felt strongly about the work, but it wasn’t resonating with the client. Shortly thereafter, we exhausted our specified number of comps and revisions. We let the client know that. And to that, they responded, “That’s too bad. But we still don’t have our design, and that’s not our fault.”

That’s a fun spot to be in.

You could issue a change request/order, sure. But that will make your client breathe fire. So in addition to abandoning prescribing specific tasks and deliverables up front, we switched our model to use “buckets of hours.” We price our jobs at a fixed fee, but we also know how many hours we’ve allocated for each phase of the project. Upon exhausting 75% of a phase’s hours, we’ll fire a shot across the bow to let the client know that. Then, if they hit 100% and use all the hours, we stop work and they need to buy more. We won’t steal hours from another phase to fund the shortfall. This way, if a client wants five designs iterated five times, that’s cool with us. The hours are used how the hours are best used. Freedom.

Documenting requirements#section7

Whether you’re hiring a painter, a builder, or a creative company, you need to think about requirements, which also set expectations. In our world, there are business requirements, content requirements, and technical requirements, to name a few. And you might think that a contract is the right place to document those requirements. I know I’ve tried to identify as many of those details as early on as possible to minimize risk and ambiguity. It’s tough to do. I’d argue that the contract is not the appropriate vehicle for articulating requirements. However, the contract should specify a process by which requirements will be gathered, evaluated, and prioritized. What you can ultimately execute upon will be dictated by your project budget and timeline.