Are those my shoes burning?

The other day there was an interesting little discussion on Deborah Finn's Information Systems Forum list about software development contracts. (You should get to know Deborah's projects if you don't already - check out her blog). [hmm... seems she's temporarily unavailable.] It's a subject that I find very interesting because over the years I've watched the contract we use grow from a one-page letter of intent to an eight page novella - and this is without ever mentioning any of the specifics about a project, which are relegated to the attachments. What feeds this growth of contractual yada-yada? It seems each time we do a project, the new client mumbles something half-apologetically about "Our board wants me to pass your contract by our lawyer". Now, the lawyer usually does not feel she will look like she's on her toes if she doesn't find at least one little issue to be concerned about. So a new point is proposed. We let our legal advisor glance at their proposed langauge. He says, "Sounds fine to me as long as you also add "blah-blah-blah" to give you the same protection. And voila - a clause is born. We've gotten pretty sanguine about the contract negotiations. They're just part of the process of building trust. It's like when your girlfriend's father said, "I want my daughter home no later than midnight." Once you announce your engagement, none of these early negotiations matter. The only part of the contract that really matters is how you agree you will handle things in the case the relationship really goes south. For example, you might want to put in a clause saying disputes will be settled by arbitration to reduce the risk of lawsuit. Fortunately, we've never had a dispute with anyone reach this point. And disputes of lesser intensity are going to be resolved by discussion and compromise, no matter what the contract says. All that being said, there is one thing that came up in the discussion on the list that I responded quite vehemently to. Helen Seal from Compumentor suggested: Other things to consider include: Penalties for not meeting deadlines (make sure you're up to meeting your deadlines too!). You could also have bonuses for coming in ahead of schedule and within budget.... I've had such bad experience with incentives like this I just had to reply. I've quit signing contracts with penalties for late delivery or rewards for early installation, and I'm convinced it's a mistake to ask your developer to do so. Every time we've accepted such terms, it's had a harmful effect on the quality of the software. Not surprisingly - it flies in the face of all the latest wisdom on software project management. The last time we did it, the guy who asked for the clause said "I want some way to hold your feet to the fire." I should have realized right then it would be an error - ever try to concentrate while your shoes were burning? We caused the client a great deal of grief by skimping on the testing and installing an application that was not really ready for prime time. But we wanted the bonus. Software takes time. Don't encourage your developer to rush. You and your developer will need to learn to manage requirement and schedule changes - they are bound to happen -- and a contract clause won't prevent them. Tags: nptech, contracts, software_development