Project time calculation

  1. ‹ Older
  2. 4 months ago

    Bill

    Sep 13 Pre-Release Testers, Xojo Pro Longview Texas

    you might have a plan but get partway through and find out you need to take a different approach. It's hard to plan for that.

    How true that is. Estimating would actually be fairly easy and straight forward if you REALLY knew everything you had to do before you started the project.

    At MTI, unfortunately, too many project specs were moving targets....

  3. Edited 4 months ago

    Thank you all for the feedback. What do you think about Function Point Analysis to calculate project duration and cost?

  4. Dave S

    Sep 13 San Diego, California USA

    If you think you can "calculate" how long it will take to design, code, implement, test and deploy a project, than I suggest you are delusional ...

  5. Neil B

    Sep 13 Pre-Release Testers

    @Dave S If you think you can "calculate" how long it will take

    Speculate might be a better word for it.

  6. Edwin v

    Sep 14 Pre-Release Testers, Xojo Pro The Netherlands

    Also, when you create code that can be reused, should you take that in account?
    I mean, I have several external modules with convenience methods. Some help with constructing databases, others handle image scaling, string manipulation etc. It took years to create this toolbox, which is still growing. And adding it to my projects only takes seconds. The question is if you use the seconds or some guestimate in minutes.

  7. Joost R

    Sep 14 Pre-Release Testers, Xojo Pro The Netherlands

    I fully agree with @Edwin vden ;Akker..

    For any estimation you'll need:

    1. knowledge of the domain you're working for;
    2. scope;
    3. proven technologies to work with;
    4. experience with programming and the tools you're using;
    5. a set of code and libraries you successfully used before;
    6. acceptance criteria;
    7. some slack.

    And I would count with max 6 productive coding hours a day.

  8. scott b

    Sep 14 Pre-Release Testers, Xojo Pro local coffee shop

    @Joost R I fully agree with @Edwin vden ;Akker..

    For any estimation you'll need:

    1. knowledge of the domain you're working for;
    2. scope;
    3. proven technologies to work with;
    4. experience with programming and the tools you're using;
    5. a set of code and libraries you successfully used before;
    6. acceptance criteria;
    7. some slack.

    And I would count with max 6 productive coding hours a day.

    number 7 is rarely taken into account when doing scoping. This is important if you are doing programming, SystemAdmin work, hardware installs, etc.. and way too many people add almost zero to zero slack in there in case something doesn’t go perfect.

  9. Mark C

    Sep 14 Pre-Release Testers, Xojo Pro Spain 35510
    Edited 4 months ago

    And the ALWAYS double it, at least in your own head.

    The changes made by the customer, regardless of how tight a specification you have, will be guaranteed to dramatically increase the timeframe, and the customer NEVER expects additional time to be included in the changes, but it is of the highest priority to say to the customer, before any other words, that a change will make the project time slip.

    Many times the customer will then reflect on the change and not undertake it, as they are likely to never consider a change will take time, after all, you are simply doing a bit of typing on the keyboard, what could be difficult in that?

    And to re-iterate previous posts, this can only be done with experience, if you simply accept that things will not work out as you hoped and DO NOT get stressed about it then you will live to fight another project into submission, good luck.

  10. Douglas H

    Sep 14 Pre-Release Testers

    Like many things, there is an 80/20 rule:

    • The first 80% of the project takes the first 80% of the time
    • The last 20% of the project takes the other 80% of the time

    Which is another way of explaining why you need to add 50% to your estimates.

  11. Emile S

    Sep 14 Europe (France, Strasbourg)

    You do not took into accounts the bugs:

    a. your own bugs,
    b. your development tool bugs and the time to either found and write a work-around or wait until a new version appears that sqash your bug OR use a different tool and prey you will not found another fatal bug.

    And, what about your third parties ? The gal for the graphics who tooks a week instead a day to send these graphics (for whatever reasons like lack of time or sick or…).

    What about Murphy’s law ?

    BUT: thank you all for the question and the answers, all answers (thanks too for the writing specs that are on moving sands).

  12. Joost R

    Sep 15 Pre-Release Testers, Xojo Pro The Netherlands

    @Douglas H Like many things, there is an 80/20 rule

    Mr. Vilfredo Pareto was a genius.

  13. Greg O

    Sep 15 Xojo Inc Somewhere near Raleigh, NC

    And always multiply your final estimate by a factor of 7 so you can maintain your image as a miracle worker! :P

  14. Dale A

    Sep 17 San Diego, California, USA

    It is said that, in war, no battle plan survives first contact with the enemy. Well, the same can be said for project planning. It is important to keep in mind that the plan's time-frame is an estimate that will need to be revisited on a regular basis during the project's development lifespan. That said, the more history you (the team) has with the product, the development tools, and the customers' requirements the more accurate the projections can be.

    As others have pointed out, a sudden, unexpected change in the requirements or an unforeseen bug in the tools can throw a schedule way off. Plus, there are often the frequently under-estimated elements. Testing, especially on a large, complex project, is often a longer task than allowed for as the code bounces back and forth between testing and developers.

    There are a few things that can help, many of which have been mentioned here already. Here's another one: do not allow any feature or requirement change until and unless the time impact has been acknowledged. If a change will extend the time for the project beyond the acceptable range, don't let the team waste their time on it. More projects and time estimates have been destroyed by "creeping featurism" than any other reason.

  15. Karen A

    Sep 17 Pre-Release Testers

    @Greg OLone And always multiply your final estimate by a factor of 7 so you can maintain your image as a miracle worker! :P

    The "Scott School of Engineering" at StarFleet Academy? ;)

    - Karen

  16. Douglas H

    Sep 17 Pre-Release Testers

    @Dale A That said, the more history you (the team) has with the product, the development tools, and the customers' requirements the more accurate the projections can be.

    The converse -- not knowing as much about the customer's requirements -- can also lead to the response:

    "It's just what I asked for, but it's not what I want!"

    Truth is, sometimes customers don't know what they want until they see.

  17. Julian S

    Sep 20 Pre-Release Testers, Xojo Pro UK

    Also, dont forget feature creep. The longer you spend on the initial spec the less chance you have of coming across creep. You (or the client) will always forget/overlook something, those text fields could use some validation or there needs to be confirmation dialogues here and there. All small things, but they all add up and add time. As others have said, experience and practice is the only way to work things out. If you have neither, then spec something up in your own time and build it as if you were the client. See where your pitfalls were/are and learn from the experience.

  18. Bob K

    Sep 20 Pre-Release Testers, Xojo Pro Kansas City

    Since we usually have a good idea on the number of windows in a project I list them out and then think of how long it will take (in hours) assuming I know everything. So a window with under 10 controls might be .5 hours. A window with 100 controls might be 4 hours.

    In my second column I have a multiplier that is based on complexity of the window. The simple window would get a 1.0 while the more complex window might get a 3.

    The third column multiply these together.

    Add all those up. Add 20% on top of that for unknowns. Add some time for testing and bug fixing and a little scope creep.

    Estimating projects is part science but mostly art form that you get better at as you gain experience.

    But that's what we do. Since we use ActiveRecord (our product) and Shorts (our product) and have 17 years of creating our own kit so we have a lot of built-in shortcuts.

    Above all, I would suggest being very liberal with your estimates. We, as humans, are generally very bad at estimating how long it will take to complete projects. The larger the project the harder it is.

  19. scott b

    Sep 20 Pre-Release Testers, Xojo Pro local coffee shop

    @Bob K We, as humans, are generally very bad at estimating how long it will take to complete projects. The larger the project the harder it is.

    AMEN!

  20. Greg O

    Sep 21 Xojo Inc Somewhere near Raleigh, NC

    @Bob K But that's what we do. Since we use ActiveRecord (our product) and Shorts (our product) and have 17 years of creating our own kit so we have a lot of built-in shortcuts.

    On that note, make sure your contract is very clear on what the user is buying and if it’s sourcecode and there are licenses of other products needed to maintain their sourcecode, that they’re itemized and included in the price as well... and if they’re not perpetual licenses, mention that there may be an ongoing renewal fee.

    When I had a programming business, our lawyer explained it like this:

    “There’s a difference between the customer buying a bundle of sticks dipped in amber which provide a particular function as a whole and a bundle wrapped in string where the customer can untie the string and access each individual part. “

    The point is that most customers think they’re getting the latter (full sourcecode to do with as they please) whereas most people quoting jobs are thinking of the former. There can be a huge price difference between the two and it should be spelled out up front especially so if there’s trouble later you can point to it and say “this is the contract you signed, if you want more it’ll cost more. “

    Oh and make sure you include a note that says that anything not explicitly specified in the signed spec is subject to your hourly rate and that a change order may be required... even if it has no money attached to it, it’s a record that the customer asked for a change and signed off on how you were going to fix it.

  21. Bob K

    Sep 21 Pre-Release Testers, Xojo Pro Kansas City

    Of course. I was simplifying the process. Our contract goes into detail on what the client gets and what parts they get non-exclusive rights to and what they can claim as their. This most often comes up with someone that wants to sell their software at some later point. After 17 years we've been through the legal ringer a few times on this stuff.

or Sign Up to reply!