Everything you wanted to know about customers but were too busy coding to ask.

In the last column, we discussed the initial contact and the issues that are important in that first meeting. In this column, we discuss negotiating the terms of the contract.

Some issues that are distracting in the first meeting are the meat of negotiations: cost, schedule, and approach. Of course, there's also the matter of a signed contract. How you negotiate the contract and define the process will determine, to a large degree, the future of the project. We've found that when we make exceptions in the beginning, exceptions inevitably become rules, and exceptions are rarely in our favor.

What is being negotiated?

Some people were born to dicker. Some people have learned it over the course of many hard years, and have earned their battle scars. Then, there are the rest of us. Quite simply, negotiations chart the course of the project. Viewed that way, customer and contractor alike will want to have a successful, mutually beneficial negotiation. There are good resources out there for the business side of software development, such as: Whil Hentzen's The 1999 Software Developer's Guide (ISBN 0-96550-932-X), Janet Ruhl's The Computer Consultant's Guide (ISBN 0-471-17649-4), and The Computer Consultant's Workbook (ISBN 0-9647116-0-5). Negotiating is just one aspect of the contract, so we will not attempt to cover the same ground as these authors.

The goal of this column is to approach the contract negotiation as a mutually beneficial process. Just in case you are in doubt: contracts are good. Repeat this to yourself until you believe it: “Contracts are good, and I won't work without one.” We've worked without contracts, and have even done so successfully. By successfully, we mean completing a project and getting paid. But that's been by sheer luck, frankly. At best, the lack of a contract can be awkward when the inevitable mismatched assumptions arise, and can leave you feeling uncertain. It's a little bit like crossing a street without checking for traffic. You might be fine, you might have a close call with a cyclist, or you might have a blind date with a semi.

If you are a corporate programmer, translate “contract” into “scope of work” or “task description”. If you spend 6 months coding away in a back office, only to come out for your semi-annual review with a manager who has no clue what you're doing (she might not be the person you're doing the work for), you want to have an official document that shows you have, indeed, been doing what was required and that you really do deserve that great raise.

During negotiations, be prepared to walk out the door. That is, be prepared for specific situations. Each of us has different minimum requirements. Know yours before you start negotiating. You need to be willing to walk away from a situation that doesn't meet your needs. If you're not willing to do that, or if you're not clear about why you would do that, a good negotiator will obtain concessions from you. This may make it hard to fulfill the project (too little money) or may set up the development process less efficiently than you prefer.

At a minimum, you'll want to make sure that your contract deals with these issues:

  • The services provided and deliverables
  • Billing rates
  • Other charges (travel expenses, phone expenses, etc.)
  • Billing, payment periods, finance fees and stop work conditions (if an invoice is 30 days late, for example)
  • Liability
  • Non-disclosure of customer's information
  • Non-compete agreements
  • Copyright
  • Termination and Arbitration
  • Warranties
  • Whether any work will be done by subcontractors and whether your subcontractors are subject to your NDA (if any).

These subjects are covered in detail in Hentzen's and Ruhl's books. However, a brief discussion of copyright is warranted because it's such an important subject. Copyright laws vary from country to country. We are familiar with copyright laws in the U.S. so you should definitely check with an attorney in your area. Many programmers don't realize that as an independent, the programmer owns the copyright to any work he creates, unless there is a specific document granting that copyright to someone else. This is true even if someone else has paid you to do that work. If you do sign over copyright to a customer, because, for example, you are developing a product for them that they intend to resell, make sure that you are very careful about what the copyright covers. You don't want to turn over the copyright for the components and tools that help you develop your applications. It's best if you can grant them the copyright for the work as a whole, plus any components that are proprietary to their system, but keep the copyright for all other components.

With an employee, just the opposite is true. An employer owns the copyright to any work created by its employees. Work done by an employee on her own time and equipment is usually not covered under this rule. However, some companies have clauses in their contracts that grant them copyright to anything the employee creates at any time. Read your employment agreement before you sign it. Employers have wildly varying degrees of sophistication in this area.

Keep in mind that there are gray areas. It's possible for the IRS to reclassify you as an employee if they determine that your customer has too much control over where, when and how you work. Your status as an independent contractor can be undermined quite easily for any of the following reasons: 1) you have only one client; 2) you work out of your client's office other than intermittently for specific on-site needs; 3) you've signed an agreement that names you as an employee; 4) you receive any materials or support from your client such as office space, equipment, or staff support; or 5) you have some authority in hiring, firing or supervising employees working for your client. If the relationship is at all ambiguous, check with a lawyer. This affects not only copyright, but also your tax filing status in the U.S.

Tip: American Express has an HMO-type legal service that gives you access to a lawyer at lower than normal rates. While we aren't endorsing any particular company, you might want to check into similar services. Also, Intuit has a software package called Business Lawyer with hundreds of sample contracts and agreements, with a wizard to guides you. Again, this is a suggestion to help the small contractor develop an appropriate contract or agreement.

Who sets the rules?

The work you're about to do is for the customer, and conceivably will make his life better. He is paying the bills, so the natural inclination is to think that he should make the rules in negotiations. In fact, it's the opposite. We know about developing software: the components, the process, and the pitfalls. We know how it is to work on a project and not be paid. Too many projects like that, and we're out of business and no help to anyone. It's we who should make the rules, and we should do it in a way that makes sense for the project and facilitates success. That said, a customer may have corporate rules and procedures, and it's important to accommodate them if it makes sense for the project.

However, a corporate rule might be at odds with what you know is good development strategy. In that case, you may need to walk away.

What does a contract do?

A contract alone doesn't do much. However, the contract negotiation will tell you how business-like your customer is and how well she responds to technical information. You'll be soliciting all kinds of serious information from her, and how she deals with this phase will tell you how she'll deal with the analysis phase.

There are two general areas covered by contracts. The first covers items that would apply to any project, like your company policies on what's billable and what isn't, conflict resolution, and possibly non-disclosure and copyright agreements. The second area covers items specific to the project, such as estimates for costs and schedule, deliverables, and specifications about the work to be done. It is generally preferable to have two separate documents: one general contract that is effective for the length of the relationship with the customer; and the second, a technical specification for each project. Keep in mind, though, that it's much easier to charge for analysis and specifications after you have a signed contract. Any work to determine cost and schedule before you have anything signed will probably be done at no charge.

A thorough contract helps eliminate surprises. A contract should protect both you and your customer by making all expectations known ahead of time. The negotiating process should identify and address assumptions and expectations. You will have difficulties if, at the end of a project, you find that your customer expects 50 copies of a bound manual, when you have just a paragraph explaining how to run Setup from the CD. If the customer owes you money, you may be hard-pressed to get it without delivering the goods. In our opinion, customers rarely know all the pieces of a software product. Therefore, it's our job to clearly point them out. You might even need to say that you do not supply any hardware. For a simple example, discuss with your client the format of the delivered product: CD, diskette, or DVD. The format could have a significant impact on cost. The point is that it's often the assumptions that seem to be common sense that can cause the most confusion.

Negotiating 101

How do you start negotiating? Supposedly, you've broken ground with your customer on this topic by mentioning in the initial contact that you will be putting together a first draft of a contract for him. A good technique is to have a standard contract already prepared. The books we've recommended have some excellent samples. Present one to your customer as a starting point. Many customers will accept your contract as is. Others will ask for minor revisions. Still others will insist that you sign their standard contract. If you find yourself in this last situation, make sure you know which elements from your contract must be required in any contract you sign. If your customer is reasonable, she should be willing to add the clauses you require. If not, be prepared to walk away. Whatever you do, don't sign a contract that you are not completely comfortable with, and don't start work without a contract!

How to negotiate the unknown

There can be two types of unknown sections or phases of a project. The first is where the general idea of a module or function is known, but the specifics have not been determined. The second is where an unstated need turns into a requirement later in the project.

In the first case, you can write something into the contract about the need for the module, and specify who is to provide the missing information and when the unknown details are to be provided. The difficulty here is in anticipating the actual scale of the module before the specifications are known. Sometimes, customers are willing to place unspecified modules on hold until the rest of the project is complete or near completion, so that the remaining budget can be reallocated if necessary. Sometimes it's necessary to give it a budget and schedule. In either case, include language that states explicitly that this portion of the project includes unknowns that will require you and your customer to reevaluate priorities. Then, don't forget it! It will help your client if you keep the module in the foreground by asking if other pieces you are developing might apply to it, and by anticipating other changes that might encroach either on its necessity or priority (sometimes these unspecified modules evaporate).

The second situation cannot be specifically handled in your contract, but you can include a general statement to cover such situations. Language like this should give you and your customer a starting place for renegotiations: “Although we try to create specifications that are as thorough as possible, sometimes unforeseen needs arise during development. The customer understands that any modifications made to the original specification will require a written change order, and may affect the project cost and time estimates.”

Whew! Can We Work Now?

Negotiating is not an easy topic. There's often no clear-cut right or wrong way to approach a situation. Negotiating techniques can be subjective, since so much depends on the specifics of the situation and the attitude and mood of both you and your customer. Negotiating and agreeing on the content of your contract will give you a good understanding of how your customer will approach the project, and gives you a hook for discussing any business issues that arise. You don't want to tell your client 3 months into the project (without a paycheck), that you really need some money to feed your starving cats. It's much better to be able to point to your contract's payment schedule.

We hope we've given you some good ideas and some helpful resources. In the next column, we'll discuss the analysis phase. As much possible, you should interview and observe the people who will actually be using the system. Watch how they work so you can understand the company's workflow. We'll give some strategies for handling some of the personalities you're likely to encounter.