On 11 Apr 2009, at 1:40 pm, Maurí cio wrote:
But I have an additional concern: to fit in burocracy. I need to write a contract that someone else, who understands just office applications, not software writing, will need to feel safe enough with to sign it. It's not that important to have a good contract, but actually to be able to say "someone else did it like this, and had no problems". Then I can save that contract and forget about it. I need something that won't hurt, more than something that will help development.
So "contract" here means "legal document", not "specification". The really important thing here is the level of trust between the two parties. If you have a high level of trust, something along the lines of "You will do something nice for me and I will pay you a fair price and we'll keep in touch while this happens" on the back of a paper napkin will do fine. If you have a low level of trust, you'll need a great level of detail, and it still won't help. I suspect you're somewhere in the middle. In that case, what you really need to do is to agree on a process that will _build_ trust, step by step. Maybe you can't explain to each other what the final product should be like. Can you agree on a _first_ step, to be done in a couple of weeks, where neither of you has much to lose? Sign a contract for that. Because it is by intent a small step, where nobody has much to lose if you just abandon the whole thing, you shouldn't need a heavyweight legal document. Showing that you understand the other side's need to manage risk will help to build trust. I don't want to go into details, but heavyweight up-front agreements can come unpleasantly close to killing a company.