August 28th, 2012, 06:22 PM
Best practices for estimating a sofware project?
what is your best practices for estimating a software project?
And did you show the customer your detail estimation sheet?
September 3rd, 2012, 04:41 AM
September 4th, 2012, 05:40 AM
In a small corporate environment where many people do many things (ie. not specialized positions), I a Developer need to do Dev Specifications and Requirements Specifications as well. Based on a very customized version of Extreme Programming (eg. info here http://xprogramming.com/book/whatisxp/) I tend to the following concepts (please note that I am only speaking roughly here - and maybe my numbers to agree with those of other developers).
1. Dev Costs involve more than just the manhours for development implementation. Dev Costs include planning and requirements analysis and testing.
a) Many cases have proven that the end user understands the problem and what "they" need, but not necessarily how their needs would affect other customers using the same system. As Developer / Analyst is remains you responsibility to judge the development risks and benefits, and work out the requirements for development (ie. existing process flows, existing data strucutures and then to present a suggested development implementation. This takes time and a lot of conversation / consulting. This undoubtedly has to form part of the process and price. This step results in a Requirements Specification which needs to be okayed by the client and which will contain mostly Functional Requirements.
b) Technical Development Specifications need to be development (based on requirements), This is an internal department task and will determine how the new implementation affects / fits into existing system structures. This will determine system processes / data structures. This will contain both Functional and Non Functional Requirements.
c) Actual development - ie the time it takes to do the programming (In my case usually based on a single developer). If you use more than 1 then the time it takes will be less, but the cost won't. This time should include you developer's testing of the modification.
d) Testing and Fixing: Internal testing needs to be performed by individuals other than the developer (either another developer - but this would result in using a more expensive resource - OR by another individual who could test from a user's perspective. This will result in additional development due to either bugs / irritations / interface or concept design problem).
e) Piloting / End User Acceptance Testing: This is where the user will receive his / her version of the software as a test-release for Acceptance Testing. You cant bill the client for this testing of course - BUT you need to include a cost for development required during this period. You have to determine a % of development costs to cover this. This step of the process can take a lot longer than anticipated.
f) Official Release
My (very roughly judged) percentages of cost:
a) 30% Major Part of Dev Process
b) 10% Technical Internal Planning
c) 30 % Dev Time
d) 20% Testing + Extra Dev
e) 10% In Addition To Dev Time
Showing the detailed estimation? I don't think it would be an issue showing a detailed estimation: some might query the testing at 20% (asking why), It is a general part of development and could just as well have fallen together weith 30% dev time (making it 30 + 20 = 50) but be seen as a simple iterative process. So yes I would show the weights on my estimation (even in detail on a Development Specification). Honestly make the best policy :-)
Hope this is an acceptable / understandable answer :-)
Comments on this post
September 6th, 2012, 09:49 AM
Pretty good answer. I would say to take everything he said and try to calculate total time.... then multiply by TWO.
Originally Posted by dve83
Project Estimation for anything but the most trivial projects is an inexact science.
September 7th, 2012, 04:55 AM
LOL @ X2 - it happens that you need to do that at times. :-)
Originally Posted by Ronster
September 10th, 2012, 06:38 PM
I agree to pad almost any estimate from a developer, because I think as developers tend to under-estimate because we all fear that:
1. people won't understand why something that looks so simple could take so long
2. another developer will come along and say "how could it possibly take you THAT long?"
So when I used to Project Manage developers (I'm a developer now), I would usually add a certain amount of padding to the estimates they gave me, sometimes up to a week, but usually a few days, depending on the confidence level they communicated.
And yes, this is completely an art, not a science, so don't expect to get close, only closer than you would with no estimates. And always rebaseline a schedule, when possible, based on new information.