• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Estimating a Project

 
Ranch Hand
Posts: 1491
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What documents form the base for estimating(cost, man-hours, schedule) a project? For eg Requirement Spec, Design Doc, .....
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Documents like requirements specifications give you a rough idea of what you need to build. Past experience building similar systems tells you how long or how much effort it will approximately take. Estimating is the act of pulling these two resources together into an informed guess also known as "the estimate."
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Understanding what needs to be build and breaking it down into estimable chunks - that is what forms the base for estimating a project.

Note that the understanding doesn't have to come from documents; actually it could be argued that a discussion between those who know what they need and those who know how to build it, like in the XP Planning Game, often works better.
 
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You might find Comparing Approaches to Budgeting and Estimating Software Development Projects and Agile Project Planning Tips useful.

- Scott
 
Scott Ambler
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I just posted the initial draft of The "Broken Iron Triangle" Software Development Anti-pattern and would appreciate feedback.

Thanks in advance.

- Scott
 
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
From the requirements and the design, along with much discussion, you can come up with a task list. Once you have a fairly detailed task list, think about who will do the work and task dependencies if you want to derive a detailed schedule.

Some points on consider:

* the smaller and more detailed the tasks in your list, *usually* the more accurate the overall estimate, but then more work is required to do the estimate.
* plan to reassess the schedule periodically, it will change as the project progresses
* knowing what needs to be done is, at best, only half of the information you need. Who is performing the work will have a huge impact on the schedule.
* include holidays for your developers. Also, as a general point, calendar time and estimated work time to complete a task are different; business people usually think about the former and developers usually think about the latter.
* include a good sized contingency (doubling the estimates is surprisingly common)
* include adequate time during iterations for bug fixes
* include time for new staff to come up to speed, especially if you are modifying an existing system
 
Ranch Hand
Posts: 904
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

as Ilja mentioned understanding what needs to be done should be the base
of your estimate. A good place to start is making an architecture of the
system - from the derived structures you shold get a good idea of what
has to be done.

@ Scott: I havn't had time to read your article yet, so I can not comment
on that, but I just wanted to mention an article by Atkinson called
"Project management: cost, time and quality, two best guesses and a phenomenon" which (also) deals
with the short commings of the Iron triangle. It might be of interest to you.

/Svend Rost
[ March 01, 2006: Message edited by: Svend Rost ]
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Don Morgan:
Some points on consider:

* the smaller and more detailed the tasks in your list, *usually* the more accurate the overall estimate, but then more work is required to do the estimate.


And the smaller and more detailed the tasks in your list, the more likely they are to become obsolete/wrong before you get to actually implementing them.
 
Scott Ambler
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Then you should do the estimating at the point when you're about to do the actual work.

An interesting question:
What's more important to you: trying to get an estimate up front which you know will more than likely be wrong, or spending your money wisely by managing the project properly?

- Scott
 
Don Morgan
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


And the smaller and more detailed the tasks in your list, the more likely they are to become obsolete/wrong before you get to actually implementing them.


Change is fine. Keep in mind we are talking about a task list for estimates, not implementation level requirements. Estimates for smaller pieces of work are generally more accurate than estimates for larger pieces of work and usually lead to more accurate overall project schedules.

Without adding some detail to our discussion, I am not sure how much we agree (or disagree). This will vary a lot from project to project, but here are my thoughts:

* if the overall project is person-months of effort, try go down to the level of detail of days per task

* if the overall project is person-years of effort, try go down to the level of detail of weeks per task

Do you think this is too detailed?
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Don, I don't think we're disagreeing that much about the granularity of the "tasks" to estimate. I think we might have different preferences regarding how big a portion of the whole system we would break down to the "task" level for estimating in the first place. What I'm trying to say that I don't feel comfortable breaking something into tasks of even several days a piece if I'm not even sure that those tasks will be needed.

As usual, there's a balance to strike somewhere between saying the first number that comes to mind and implementing the system first before saying how long it will take. Without a context, there won't be any "right" answers to the question of "how to estimate". In fact, even with a context, there won't be any right answers.
 
What's that smell? Hey, sniff this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic