Project time calculation

How do you calculate time needed to complete a project from scratch?

This question is very broad.
The main guideline to follow is: split the project in as many parts as possible. (and add 50% time)

Example:
You want to create a text editor. Split in parts:
-Designing lay-out (Load/Save buttons, textarea) -> 10 minutes
-Save code -> 5 minutes
-Load code -> 5 minutes
-Code a messagebox that asks for saving on quit -> 5 minutes

Total time: 25 minutes. +50% = 37.50 minutes.

Programming a text editor will take 37.50 minutes to complete.

Ofcourse: This example is extremely simplified and a little stupid. But on a bigger project, it makes more sense.
Also, there is good software to manage these work parts and time: http://blog.capterra.com/free-open-source-project-management-software/

You base it on you knowledge of the subject matter, you expericence with the language, your experience with the design principles required…

And seriously… a text editor in 37.5 minutes… that example causes more issues than it solves

but the bottom line… EXPERIENCE

I find that testing can take about 25% as long as writing the initial code. Unless you plan on letting your end users find the bugs. :wink:

I just had a customer that was really pushing me for a major upgrade. I released the app with out doing all the testing. There were 5 bugs with two of them being somewhat crippling. It saved me a bunch of time (fixing bugs is easier than finding them), but made for a very poor user experience, although the issues were all resolved the same day.

When I was System Development supervisor at Morton-Thiokol we always added the FUD factor: Fear, Uncertainty and Doubt.

Estimating time is almost always harder than doing the project. Dave is absolutely correct. It is experience, and an educated guess.

Experience from previous projects is about the only gauge. Although I can now do in two hours what used to take 20 hours. :slight_smile:

Then also you can’t really tell how long a project will take until you have decided exactly what you want to achieve and how.

For example 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…

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

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 …

Speculate might be a better word for it.

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.

I fully agree with @Edwin van den 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.

[quote=350199:@Joost Rongen]I fully agree with @Edwin van den 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.[/quote]

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.

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.

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.

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).

Mr. Vilfredo Pareto was a genius.

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

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.

The “Scott School of Engineering” at StarFleet Academy? :wink:

  • Karen