-
August 28th, 2012, 06:26 PM
#1
Best practices for estimating a sofware project?
Hi!
what is your best practices for estimating a software project?
And did you show the customer your detail estimation sheet?
-
August 29th, 2012, 07:10 AM
#2
Re: Best practices for estimating a sofware project?
Experience.
We give them a statement of which includes details of what we'll do, but not the details of how we arrived at the price.
-
August 29th, 2012, 07:53 AM
#3
Re: Best practices for estimating a sofware project?
Then you give the customer only the final Price and a delivery date?
-
August 29th, 2012, 08:09 AM
#4
Re: Best practices for estimating a sofware project?
Originally Posted by gicio
Then you give the customer only the final Price and a delivery date?
And a very detailed spec of what we're going to do for them. If you don't lay out exactly what the deliverable is and have them sign off on it, they'll keep having you change it forever. There needs to be a very clearly defined point at which you can draw the line and tell them you've delivered what you and they agreed you would deliver.
-
August 29th, 2012, 08:13 AM
#5
Re: Best practices for estimating a sofware project?
OK. but the spec is which form?
-
August 29th, 2012, 08:28 AM
#6
Re: Best practices for estimating a sofware project?
Originally Posted by gicio
OK. but the spec is which form?
Not really sure what you mean. We're a small company and I'm not really up on what the government or Fortune 500 official spec form of the week is. We just write down in detail what we're going to do.
-
September 2nd, 2012, 02:21 PM
#7
Re: Best practices for estimating a sofware project?
The spec is just in the form of what you and your customer agree on.
As GCDEF said, the bottom line is that your customer knows exactly what you are going to do and how the program will look and act when you are finished with it.
You write that up in any form (or format) that clearly conveys what the customer is getting.
You might start a document by listing the requirements that the customer has given you (or you have derived from what the customer has told you).
Then write down the features of the software, how the software behaves (or what changes you are making for existing software). For UI type changes, include several screen shots that show the finished screens and workflow.
Include delivery milestones and a definition of what makes the software complete.
In generel customers seldom know what they want and always want to leave the initial spec somewhat fuzzy (so they can change things at will). As a consultant it is better to try to nail down as much of the details as possible, because if you don't, you won't have any definition of done and then the customer can keep making changes. This is okay if the job is timebased, but usually disasterous if it's a fixed bid job.
One way to deal with this problem on a fixed bid job is to get the customer to agree that you are going to set aside X hours to create the initial spec and get them to buy off on the features for the rest of the project. Agree with the customer if nailing down the spec takes longer than the allotted time, then the fix bid price might change.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|