Re: Hello

As much discussion has happened offline, the easy way to enter PERT data 
is to allow entry of "optimistic duration," "pessimistic duration," and 
"most likely duration."  From those data you can calculate the PERT 
probabilities.  IMHO, PERT charts are useless unless you want to 
inundate an executive with paper that he won't understand but will lead 
him to think you are working hard on the project.  PERT charts were 
invented before modern computers and were used to hand-calculate and 
enter the probabilities.  They are also somewhat useful to get an idea 
of where slack is available in a project for crashing a schedule (adding 
or moving resources to other branches of the tree).

Even GANTT charts have limited use IMHO.  The best charting available is 
to display Budgeted Cost of Work Scheduled vs. Budgeted Cost of Work 
Performed (Schedule Variance); and Budgeted Cost of Work Performed vs. 
Actual Cost of Work Performed (Cost Variance).

Those two graphs will give the project team and executives a very good 
view of how the project is actually proceeding.

Estimated Cost and Time of Completion are also useful.

Jim

Nicolas MICAS wrote:
> Hello!
>  
> We haven't see the question asked by Dag about our criteria for 
> selecting things to do.
> To answer this question it is easy! (or ISI as you wants :P)
> We have studied the TODO list of KPlato on SVN and after clear it from 
> all things which were done we have selected those which seems to be most 
> important and easily realisable during our project.
> We are studiing a another items to do, relative to the PERT method, it 
> will consist to find a simple way to key PERT data and so to calculate 
> particulary things of the PERT method without a graph.
>  
> Best regards.
> 
>  
> 2006/11/10, Gaël de Chalendar <[email protected] 
> <mailto:[email protected]>>:
> 
>     Hello,
> 
>     Le vendredi 10 novembre 2006 08:30, Dag Andersen a écrit:
>      > Torsdag 09 november 2006 18:34 skrev Kevin Ottens:
>      > > I'm wondering about this one. I'm not 100% about the semantic
>     of this
>      > > dependency. Could someone enlighten me?
>      >
>      > task1 <--- task2.
>      > means task2 has to start before task1 can finish, so I suppose
>     task2 should
>      > be calculated first.
>      > I don't think there are many use cases for it, I can't pull one
>     from the
>      > top of my head just now ;)
>     Maybe some specifications (like a file format) of task2 (that could be
>     splitted in more detailed subtasks) should be finished to allow the
>     final
>     implementation of task1 ?
>     This allows to have some tasks not too much detailed.
> 
>     Regards,
> 
>     Gaël
>     _______________________________________________
>     kplato mailing list
>     [email protected] <mailto:[email protected]>
>     https://mail.kde.org/mailman/listinfo/kplato
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> kplato mailing list
> [email protected]
> https://mail.kde.org/mailman/listinfo/kplato