What are the main pitfalls you've faced when negotiating contracts for commissioned software?

Question

I'm making my venture into the small business world and I've got my first gig lined up. I was wondering if you guys had any advice or lessons learned from negotiating contracts for commissioned software? Are there any common pitfalls? How you come to agreement on the scope of work even when the client isn't sure of what they want? etc..

Answer 1

When you write the specification for what you are going to deliver to the customer, make sure you also include some points describing what they are NOT getting. Often the customer assumes that when you deliver feature A, it will automatically mean that feature B and feature C is also included since they are related in some way.

Take an example. A company developed a small feature for one of our common customers to add some filtering rules to a CRM system. The filter included some standard rules which always applies, but it will also check a SQL table to include additional rules. However, they did not deliver an actual application to manipulate the table. So any additional rules will need to be entered by a SQL statement, and hence not by an end user.

This is a perfect example of a scenario where it would be wise to include in the specification that no admin interface to the extra filterrules is included.

Answer 2

A few words of advice:

• Don't back down. After your first 1-2 contracts with a client they may start trying to get 'more for less'. Stand your ground.

• Building and delivering software- make sure you have in writing any extended support contract. This is guaranteed to happen- that they will want you to build something and then support it indefinitely. Make it clear before you start anything.

• Make sure you get the exact specs, something that you can discuss with them in good detail each aspect of the software, before you sign or start. Make sure this spec is part of your contract and there are clear terms for completion.

• Don't take initial payment until you have a completed agreement. When this happens you will never again agree on specs and then never get that contract- and then you may end up in a position where you were paid and started but never had a contract and can never finish.

• Don't assume that they will 'just know' what you are talking about.

• Be up front with all costs. They will want everything 'right away' but make sure you explain what it will cost.

• Don't take on work that you won't enjoy.

• Be friendly- portraying a good clear mind and good mood is very important if you are a consultant. They need to have 100% confidence that you are in complete control and there are no doubts.

• Be confident. This is your company- you are the boss. They come to you to get their project completed.

• Start small- learn your ground.

• ... there are so many things, but the best things you learn are through experience. Don't be afraid to jump in and fail. Failure is a good way to learn.

Answer 3

If you have a customer who is truly unsure of what they want it would be foolish to enter into a fixed price contract with unfixed or unclear deliverables. I have personally found that getting customers involved in SCRUM is the best way to go in situations like this. Simply have the customer create a backlog and then prioritize the items within that backlog. You can then draw a standard contract based on estimations for those deliverables, then alter the contract with the following clauses to make it compatible with the agile way of doing things:

1. You will be demoed working software every N weeks at no extra charge.
2. You can add any new items to the backlog and make appropriate alterations to the contract at no extra charge but must either remove an item of equal size (size estimations will be made by the contractor) or accept a cost extension to the contract based on the following rates........
3. If the software has met the requirements of the client before all items in the contract have been completed, the client may terminate the contract at that point, the charge for termination will xx% of the total contract value.

Obviously this will need to be dressed up a little, but you get the idea. I have found that customers who are at least partially aware that they don't know exactly what they want from the outset are extremely receptive to this approach, as they know they are less likely to be charged 'uncertainty tax' by the contractor.

For customers who 'think' they know what they want but have not yet realized their ideas are ill conceived will be more resistant, but at least will be able to assist in drafting a contract with fixed deliverables, but remember to make sure you have outlined the mechanisms for contact revisions within the contract, this will save problems when they finally have their moment of enlightenment.

Answer 4

I've found that the best contractual arrangement to set up with a client is a time-and-materials contract with an additional fixed-fee payment (usually pitched as a licensing fee to cover the incorporation of in-house components into the final product) payable on delivery of the completed software.

The fact that the client is paying for every hour that you work is a strong incentive for them to help you complete the work as quickly as possible. You can actually have discussions with them where you say "you don't really need feature X, let's not implement it" and they will usually happily agree.

The fact that the client owes a fixed fee upon delivery is a strong incentive for you (the developer) to complete the work as quickly as possible, too. You could drag your heels in order to stretch out the billable hours (and believe me, this happens like crazy in the commissioned software world), but then you would get fewer fixed-fee payments and thus make less money.

This arrangement does not eliminate the need to do good requirements gathering up front, which is really not difficult once you've done it a couple of times. We all hear about customers who "don't know what they want", but that's actually nonsense. Business owners who are willing to plunk down a couple hundred thousand for software usually know exactly what they want (or rather, they know generally what they want the software to do), but can't articulate it in programming terms. And that's your real job, of course. A crappy programmer who is good at understanding what a client really needs will be much more successful than a great programmer who isn't.

Answer 5

It happens a lot that the client cannot tell you for sure what he wants. But he will know you have to be within the budged and time frame. Tell him, that uncertainty for you means less hard deadlines from him. A previous client tried to negotiate a clause, where I as a developer had to repay him a fee, for every day late. I told him that was not possible, without a detailed spec and design, so he backed down.

Another tactic is to talk about a very feature-loaded product, with a way to big price tag. They will tell you which stuff they like, but give a maximum allowed price to cut things back to. The maximum price is what you want to know!

Answer 6

One thing I haven't seen mentioned is to figure out whether this is a "Work for Hire" arrangement. You may not realize it but you will still own all copyright to the completed work even if someone else pays you for it. You are legally entitled to turn around and sell the same package to someone else and, if they were to sue to stop you, they'd be thrown out with barely a hearing. That is, unless they have a "Work for Hire" clause. In that case, the client will own copyright.