If you bothered to read "Part 1" of this, then I can go ahead and say that this article is "Part 2". Amazing, isn't it? No. But here goes.
NOTE: Although this article, and the other parts to it, are focused on web development projects, most of this applies to all aspects of technical services. Take from it what you like, ignore the rest.
So you've spent many a late night building this dream of yours: a web site. You've got your notes, sketches, templates, facts and figures, budget plans, timelines, and maybe even drawn up a business plan (or business case, etc.). Maybe you've built a prototype or two in WordPress, Ning, SquareSpace or KickApps, and some of them do things the way you like, some do not. Maybe one of them is 95 percent of what you want, but you can't figure out the last 5 percent. No problem.
Now you're ready to meet with a web developer (or five or six). If you feel that your idea and your plans are sensitive enough to protect from someone else stealing them, you probably should consider getting some basic protection in place. By that, I mean legal matters. This doesn't have to cost you anything except a little time. If you have a friend who is an attorney, by all means ask them for advice. If you're not fortunate (or unfortunate) enough to know an attorney, fear not, there are free options available.
Non-Disclosure Agreements
A Non-Disclosure Agreement, or "NDA", is a document that states that all parties (legal term for all persons who agree to the document by signing it) must abide by the terms it provides. Those terms are usually focused around limiting what the involved parties can say about the project, or certain aspects related to it, to other people. There may be penalties stated for breaking the terms. There may be time limits and other special conditions. They can be vague and general, or particular and specialized. The terms can be tailored to suit your needs, and the concerns of all others involved.
Regardless, the purpose of the NDA is to prevent people from blabbering, stealing, sharing your sensitive ideas and planning. They often go both ways as well. In many cases, the NDA will also protect the other party against you telling other potential bidders about how they estimate projects, or what resources they can leverage, and so on. It protects ideas, capabilities, goals, and material works as well. There are plenty of free NDA templates available on the Internet for you to download and modify to suit your needs. You can also consult an attorney, which is usually a better option if you can afford it.
Before you sit down to discuss your ideas with developers, even for preliminary estimates, don't forget to decide whether an NDA is worth including. Have them sign it before you discuss your project. They may want some time to review it before signing it, which is always a good idea. The goal is to protect your idea. But make sure you really need it before you spend a lot of time on it.
TIP: Search the web for "non disclosure agreement template" for links to sites with free and low-cost templates to get started with.
Statement of Work
A Statement of Work, or "SOW" is a shopping list of what the developer will provide to you as part of your agreement. It should include an itemized list of each and every task, key dates or time frames, milestone terms, materials to be delivered (source and/or final), and so on. They should be detailed.
Don't just say "develop customer registration page". The item should either describe what that page will look like, what it will do (functionally), and even refer to figures (sketches) or screen shots. Describe workflows as well. Write down the workflow process for things like registrations, subscriptions to mailing lists, unsubscribing, opting out, privacy agreements, and so on. A good web developer can help you work this out, but you should understand it fully so you don't feel confused and frustrated later on.
Most arguments and disagreements I've seen were born out of vaguely worded SOW's. It's amazing that some customers actually get frustrated when I ask questions to help nail down the details. They assume that by discussing and agreeing "now" will be understood the same context six months later. "I thought you said…" or "I thought that meant…" are common phrases that indicate someone is confused and upset. They feel let down. They feel cheated. That's not good for business.
Nail down everything early on. Shapes. Colors. Fonts. Pages. Graphics. Workflows. Titles and sub-titles. Table borders. Margins. Footers. Get the specifics and put them into the SOW.
| Here's how I look at a SOW: Think of it as though you were asking someone for instructions on how to build the site, and then you were going to hand it to a complete stranger with no knowledge about the project beforehand. Will the SOW have enough detail to guide them to build it properly? |
TIP: If the developer doesn't insist on specifics, or gets irritated by your insistence, walk way and find another developer.
Service Agreement
A Service Agreement is simply another name for a contract. It's a written agreement that states who is doing what for whom. It also states conditions, limitations, liabilities, responsibilities, exclusions, warranties, assumptions and expectations, important dates, deliverable items, ownership issues, copyright and trademark issues, legal jurisdiction, arbitration terms, invoicing and payments and so on. Lot's of legal mumbo-jumbo, but it's good. Yes, it is GOOD. It protects YOU. It protects THEM also.
While there are plenty of free contract templates available on the Internet and at retail stores (yes, they too have them for sale), this is one piece of the puzzle that I always recommend getting from a qualified attorney. They shouldn't charge a lot for this if they're reasonable. If you know an attorney, ask them what their fees are for either drawing up an agreement or reviewing an agreement you draft on your own. Make sure they are familiar with service agreements involving consulting or technical services. An attorney that only works with building contractors or retail contracts is not a good choice unless you can't find anyone else.
This is part one of the Agreement preparation. Next…
Next, you will give it to the developer/consultant for them to review. This is still considered a draft at this point. They will likely want to take to their attorney to have it reviewed and they may request some modifications as well. That's normal. It's why we have attorneys. They look things over and catch the loopholes we don't see, and plug them to protect us. It's a good thing.
A reputable web developer will often have a prepared agreement from previous projects which has been reviewed many times and should be fairly good. Always ask how many times that same agreement has been used in the past. The more the better. But even so, have it reviewed by your attorney to make sure it fits YOUR needs as well.
TIP: Consult an Attorney when developing a Service Agreement. If the developer provides the Agreement, have it reviewed before signing it.
Invoicing
Your Service Agreement should include instructions on how and when invoices will be submitted, how they will be paid and how long it should take to process them. It should also describe how to resolve discrepancies between delivered services/materials and invoiced claims. There are two kinds of invoices in my book: Intermediate and Final.
An Intermediate Invoice is one that is submitted for partial delivery of items requested on the SOW. There may be multiple such invoices before the project is completed.
A Final Invoice is just that: Final. Some projects will only require a final invoice. Some will involve intermediate invoices. Some will involve both. It typically varies by how large, and complex the project is. It can also vary by how the customer handles invoicing (that would be you, in this case).
A Final Invoice can just state something simple like "services and deliverables as requested by SOW ___" and an associated amount requested for payment.
An Intermediate Invoice should always be more detailed. It should describe EXACTLY what tasks were performed. It can break them apart with sub-totalled amounts, or just itemize the tasks and provide a total amount. That is something you should discuss with the developer AHEAD of beginning work on the project.
TIP: Ask for a sample invoice so you don't get caught by surprise.
Summary
I hope this helps. It may seem scarry, but it's really not. These are important aspects of getting involved in any project that requires hiring someone else to do work for you. If the work involves something sensitive or precious to you, it's worth protecting. It's worth protecting at the beginning, in the middle and at the end as well. Don't rush through it, and don't let anyone rush you either.
In keeping with my promise to streamline my expulsion of thoughts via "social" outlets, I am going to start focusing more on the blog and less on the other stuff. That means I'm also not going to post any more blog announcements on Twitter or Google+. Blog posts will be on the blog and shared via my Google Reader stream only. Time to get serious about quality rather than quantity. This will also be the last blog post I link on Twitter or Google+.
