Software Estimation
-
Rama Krishna Vavilala wrote:
I assume you know that just reading a book does not make one a good estimator.
You assume correctly, but I have to start somewhere. Do you think there's some weight in learning Agile methods even if the company I work for doesn't use them (assuming I'm staying where I am for a while)?
C h r i s C h a m b e r s wrote:
Do you think there's some weight in learning Agile methods
Absolutely yes! Try to understand them properly. Many companies boast that they follow "agile" methods but actually end up following nothing but unorganized development (I have also been guilty of that :-O). You can also learn them and employ them as much as possible in your company. You will definitely find them useful.:). Probably might have already learned from your training material, that accuracy of an estimation improves as the project progresses and things become more an more concrete. If a project sits for a long time in design it is almost impossible to estimate it accurately. Part of the reason is that there is a risk that whatever is developed might not be what the customer wants and then the project has to be re-estimated.
Proud to be a CPHog user
-
Hi guys, My boss has suggested that I might be in line for promotion but first I need to get to grips with software estimation. Having spent a few weeks digging around for training courses and material I haven't found a great deal, however one book that consistently pops up is the Software Estimation by Steve McConnell. I have his Code Complete book and it's superb, and I'm thinking about investing in this estimation book too but I wondered if anyone else had read it, or perhaps had any other recommendations for approaching the subject. Chris.
If you want to learn estimation, this is a fine book. You must read The Mythical Man Month as well, to get an understanding of why adding more resources to a project brings diminishing returns to reducing the development time.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
-
Hi guys, My boss has suggested that I might be in line for promotion but first I need to get to grips with software estimation. Having spent a few weeks digging around for training courses and material I haven't found a great deal, however one book that consistently pops up is the Software Estimation by Steve McConnell. I have his Code Complete book and it's superb, and I'm thinking about investing in this estimation book too but I wondered if anyone else had read it, or perhaps had any other recommendations for approaching the subject. Chris.
One other point - there's a thing called the project management triangle which you need to be aware of. Basically, you can view it like this:
Time /\\ / \\Cost +----+ Scope
What this states, is that if something changes at any point in the triangle, then the other points will be affected. For instance, you have estimated that your project will cost $10,000 and take 20 days based on scope X. However, the client comes back and changes the scope to add 4 new features - this will result in you needing to rebalance the triangle, either by increasing the time or the cost (where cost normally equates to personnel required). This is one of the reasons why it is vital to lock down scope - don't let somebody add feature x, because while it may only take half an hour to implement, the scope has changed and the time to document and test it will increase.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
-
One other point - there's a thing called the project management triangle which you need to be aware of. Basically, you can view it like this:
Time /\\ / \\Cost +----+ Scope
What this states, is that if something changes at any point in the triangle, then the other points will be affected. For instance, you have estimated that your project will cost $10,000 and take 20 days based on scope X. However, the client comes back and changes the scope to add 4 new features - this will result in you needing to rebalance the triangle, either by increasing the time or the cost (where cost normally equates to personnel required). This is one of the reasons why it is vital to lock down scope - don't let somebody add feature x, because while it may only take half an hour to implement, the scope has changed and the time to document and test it will increase.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
That's a very interesting point, and it's something that I think is often lost on project managers under pressure to 'please' the client, despite the fact that it inevitably hurts the client when timescales slip.
-
One other point - there's a thing called the project management triangle which you need to be aware of. Basically, you can view it like this:
Time /\\ / \\Cost +----+ Scope
What this states, is that if something changes at any point in the triangle, then the other points will be affected. For instance, you have estimated that your project will cost $10,000 and take 20 days based on scope X. However, the client comes back and changes the scope to add 4 new features - this will result in you needing to rebalance the triangle, either by increasing the time or the cost (where cost normally equates to personnel required). This is one of the reasons why it is vital to lock down scope - don't let somebody add feature x, because while it may only take half an hour to implement, the scope has changed and the time to document and test it will increase.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
Pete O'Hanlon wrote:
What this states, is that if something changes at any point in the triangle, then the other points will be affected. For instance, you have estimated that your project will cost $10,000 and take 20 days based on scope X. However, the client comes back and changes the scope to add 4 new features - this will result in you needing to rebalance the triangle, either by increasing the time or the cost (where cost normally equates to personnel required).
If you're increasing the time without the cost, doesn't that amount to doing extra work for free? Unpaid work is unpaid work regardless of if you're doing an extra three hours a day, working the weekends, or working several days for free after the planned end of the project.
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
-
Pete O'Hanlon wrote:
What this states, is that if something changes at any point in the triangle, then the other points will be affected. For instance, you have estimated that your project will cost $10,000 and take 20 days based on scope X. However, the client comes back and changes the scope to add 4 new features - this will result in you needing to rebalance the triangle, either by increasing the time or the cost (where cost normally equates to personnel required).
If you're increasing the time without the cost, doesn't that amount to doing extra work for free? Unpaid work is unpaid work regardless of if you're doing an extra three hours a day, working the weekends, or working several days for free after the planned end of the project.
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
I guess I didn't make the point forcefully enough. You're right that the time would increase the cost. I was trying to differentiate between personnel increase and time increase, but I should have stated this. The key thing, is that you have to rebalance the triangle everytime - regardless.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
-
If you want to learn estimation, this is a fine book. You must read The Mythical Man Month as well, to get an understanding of why adding more resources to a project brings diminishing returns to reducing the development time.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
Uhmm. Looks like someone did not like the Mythical Man Month book and down voted your post.:~
Proud to be a CPHog user
-
Uhmm. Looks like someone did not like the Mythical Man Month book and down voted your post.:~
Proud to be a CPHog user
I saw that. Perhaps it's a project manager who thinks that if it takes 1 person 10 days to do a task, 10 people can complete it in a day. I suspect they didn't want their bubble bursting.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
-
If you want to learn estimation, this is a fine book. You must read The Mythical Man Month as well, to get an understanding of why adding more resources to a project brings diminishing returns to reducing the development time.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
Bitter experience will also give the same lesson, again and again ... :sigh:
Bar fomos edo pariyart gedeem, agreo eo dranem abal edyero eyrem kalm kareore
-
I saw that. Perhaps it's a project manager who thinks that if it takes 1 person 10 days to do a task, 10 people can complete it in a day. I suspect they didn't want their bubble bursting.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
Pete O'Hanlon wrote:
t takes 1 person 10 days to do a task, 10 people can complete it in a day.
Is it not true? If it take one person to make a mess in 10 days. 10 persons can make the same amount of mess in one day.
Proud to be a CPHog user
-
Hi guys, My boss has suggested that I might be in line for promotion but first I need to get to grips with software estimation. Having spent a few weeks digging around for training courses and material I haven't found a great deal, however one book that consistently pops up is the Software Estimation by Steve McConnell. I have his Code Complete book and it's superb, and I'm thinking about investing in this estimation book too but I wondered if anyone else had read it, or perhaps had any other recommendations for approaching the subject. Chris.
One thing I'd add is that the cost of changes increases exponentially to the complexity of the code base. i.e. it's cheap to change things early, extremely costly to change them later on. Which leads me to my other observation (ok, I know that's two things). Projects fail early because of bad analysis. Bad analysis leads to late changes. Late changes kill the budget, timeline or both. Ok, third thing. This is becoming a Monty Python sketch. One bad developer is the negative of many stellar developers. If you don't have control over who's in the team, you'll need to factor in damage control. It's best to leave them idle, especially early on when they can do most damage.
Bar fomos edo pariyart gedeem, agreo eo dranem abal edyero eyrem kalm kareore
-
C h r i s C h a m b e r s wrote:
Do you think there's some weight in learning Agile methods
Absolutely yes! Try to understand them properly. Many companies boast that they follow "agile" methods but actually end up following nothing but unorganized development (I have also been guilty of that :-O). You can also learn them and employ them as much as possible in your company. You will definitely find them useful.:). Probably might have already learned from your training material, that accuracy of an estimation improves as the project progresses and things become more an more concrete. If a project sits for a long time in design it is almost impossible to estimate it accurately. Part of the reason is that there is a risk that whatever is developed might not be what the customer wants and then the project has to be re-estimated.
Proud to be a CPHog user
Yeah, the last company I was at claimed to use agile. In reality the only 'methodology' used was methodically beating the stuffing out of the development group saying 'Do it! And do it NOW!'. Talk about unorganized, it was a complete cluster...
BFinney
-
Hi guys, My boss has suggested that I might be in line for promotion but first I need to get to grips with software estimation. Having spent a few weeks digging around for training courses and material I haven't found a great deal, however one book that consistently pops up is the Software Estimation by Steve McConnell. I have his Code Complete book and it's superb, and I'm thinking about investing in this estimation book too but I wondered if anyone else had read it, or perhaps had any other recommendations for approaching the subject. Chris.
While I agree with everything the other repliers have said, there's one aspect of Software estimation that everyone has missed, and only painful experience can really teach the importance of. When you have figured out the most accurate estimate you can, allowing for as many factors as possible, take the final number and multiply it by 4. This is because when you give it to your PM, he is going to half it before giving it to the salesman. The salesman will half it again before giving it to the client. If you don't multiply it by 4, you'll end up being told to complete a project in 6 weeks that you estimated would take 6 months. Actually, this is the corollary of another rule I've followed for years. Multiply everything the datasheet says by 2 in the worst direction, and everything the salesman tells you by 4. If the datasheet says something needs 2Gb, it actually needs 4Gb. If a salesman says you can process 400 invoices a day, you can only do 100
-
I saw that. Perhaps it's a project manager who thinks that if it takes 1 person 10 days to do a task, 10 people can complete it in a day. I suspect they didn't want their bubble bursting.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
I am in a completely different situation, there must be around 10 project managers (most of whom appear to be barely involved in the project) and 1 person, me, who is the code monkey - my boss agrees that this is crazy.
Continuous effort - not strength or intelligence - is the key to unlocking our potential.(Winston Churchill)
-
Pete O'Hanlon wrote:
What this states, is that if something changes at any point in the triangle, then the other points will be affected. For instance, you have estimated that your project will cost $10,000 and take 20 days based on scope X. However, the client comes back and changes the scope to add 4 new features - this will result in you needing to rebalance the triangle, either by increasing the time or the cost (where cost normally equates to personnel required).
If you're increasing the time without the cost, doesn't that amount to doing extra work for free? Unpaid work is unpaid work regardless of if you're doing an extra three hours a day, working the weekends, or working several days for free after the planned end of the project.
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
dan neely wrote:
If you're increasing the time without the cost, doesn't that amount to doing extra work for free? Unpaid work is unpaid work regardless of if you're doing an extra three hours a day, working the weekends, or working several days for free after the planned end of the project.
No. If you increase the time and keep the cost constant, it means you are paying less per hour/day/whatever. Therefore it's most likely that the scope and/or quality will suffer. Same thing for the others. If you keep the scope and the time constant, you better be prepared for high paid experts and overtime, hence the cost increases, etc. I usually see this in terms of "cheap, fast, good quality - pick two."
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
-
One other point - there's a thing called the project management triangle which you need to be aware of. Basically, you can view it like this:
Time /\\ / \\Cost +----+ Scope
What this states, is that if something changes at any point in the triangle, then the other points will be affected. For instance, you have estimated that your project will cost $10,000 and take 20 days based on scope X. However, the client comes back and changes the scope to add 4 new features - this will result in you needing to rebalance the triangle, either by increasing the time or the cost (where cost normally equates to personnel required). This is one of the reasons why it is vital to lock down scope - don't let somebody add feature x, because while it may only take half an hour to implement, the scope has changed and the time to document and test it will increase.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
-
Forgive me but isn't that patently obvious?
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
Nothing to forgive. It should be obvious, but it's amazing how often it's forgotten.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith