Terms of Software Contracts
-
I was wondering how do people out there settle software contracts. Do you make a requirement list and sign on that? in what format? use cases, natural language? How do you handle estimating cost and time (and giving a budget based on that kind of unknown factors) when it seems clear the client isn't sure of what they actually want which means you will likely end up with an evolving prototype?
-
I was wondering how do people out there settle software contracts. Do you make a requirement list and sign on that? in what format? use cases, natural language? How do you handle estimating cost and time (and giving a budget based on that kind of unknown factors) when it seems clear the client isn't sure of what they actually want which means you will likely end up with an evolving prototype?
Difficult question. Some of my experiences: - Try to make the requirement list as good as possible, but always add a part that is open-ended on hour basis (with a time estimation) - Describe what your software can not do. This gives you some help when the client develops different expectations as the project goes - Small projects have a simple list in natural language. - Because the time to make a real good req.list is not payed for, you want to keep it simple. On the other hand you want risks eliminated. Problem is that even if you write everything out (what is impossible and takes much too much time) this still is not a garantue the project will not have problems on prizes, simply because your client does not think in terms of requirements but in terms of expectations. So keep your customer well informed. Try to invoice in parts. - If your customer wants a fixed price, or at big projects, sell a consult on requirements first - Raise your prizes a little. You'll need it to give something back when things do not go as expected - Best tip: Get a good account manager. Commercial people are born for these things Egards Rozis
-
Difficult question. Some of my experiences: - Try to make the requirement list as good as possible, but always add a part that is open-ended on hour basis (with a time estimation) - Describe what your software can not do. This gives you some help when the client develops different expectations as the project goes - Small projects have a simple list in natural language. - Because the time to make a real good req.list is not payed for, you want to keep it simple. On the other hand you want risks eliminated. Problem is that even if you write everything out (what is impossible and takes much too much time) this still is not a garantue the project will not have problems on prizes, simply because your client does not think in terms of requirements but in terms of expectations. So keep your customer well informed. Try to invoice in parts. - If your customer wants a fixed price, or at big projects, sell a consult on requirements first - Raise your prizes a little. You'll need it to give something back when things do not go as expected - Best tip: Get a good account manager. Commercial people are born for these things Egards Rozis
some very nice advise, thanks!
Rozis wrote:
- Try to make the requirement list as good as possible, but always add a part that is open-ended on hour basis (with a time estimation)
Follow up question, how do you handle the open-ended part? list a cost of per hour on the contract and then on the road let them know how many hours it would take?
-
some very nice advise, thanks!
Rozis wrote:
- Try to make the requirement list as good as possible, but always add a part that is open-ended on hour basis (with a time estimation)
Follow up question, how do you handle the open-ended part? list a cost of per hour on the contract and then on the road let them know how many hours it would take?
Abrojus wrote:
Follow up question, how do you handle the open-ended part? list a cost of per hour on the contract and then on the road let them know how many hours it would take?
What i do: - Tell my client why it is not reasonable/impossible my company does it fixed price - Tell him also how many time I expect that it may cost (a best guess) - Agree on that expectation A typical conversation is something like: "I must make a price while I do not have the specs yet. On my experience I guess it will take about .. days if the specs are reasonable. Having a price per hour at ... this would make ... So i can't do this part fixed price, but i can agree that i'll notify you as soon as i expect it takes more time, so we can find a solution together..." Aside: this is not how it goes into the contract, there we formulate it as price per hour - without any restriction. Problem for your client is that his boss wants to know how much it costs: he needs a number. So help him with that.. Rozis
-
Abrojus wrote:
Follow up question, how do you handle the open-ended part? list a cost of per hour on the contract and then on the road let them know how many hours it would take?
What i do: - Tell my client why it is not reasonable/impossible my company does it fixed price - Tell him also how many time I expect that it may cost (a best guess) - Agree on that expectation A typical conversation is something like: "I must make a price while I do not have the specs yet. On my experience I guess it will take about .. days if the specs are reasonable. Having a price per hour at ... this would make ... So i can't do this part fixed price, but i can agree that i'll notify you as soon as i expect it takes more time, so we can find a solution together..." Aside: this is not how it goes into the contract, there we formulate it as price per hour - without any restriction. Problem for your client is that his boss wants to know how much it costs: he needs a number. So help him with that.. Rozis
these contracts problems are commonly occured with customers. But main problem is that proving services not based numeric criters. Customer want to know how much pay for it and what will be gain after that. typical business relation. Simply all issue should be based number and time limit, than everyone accept to contract.