Mean Start/Finish

Hi Daniel

As far as I know ‘mean start/finish’ is a term derived from carrying out some form of risk analysis and in particular Monte Carlo simulations where, for each activity there will be a spread of start and finish dates. I guess the ‘mean start/finish’ dates are those that are generally used on the static project programme?

Pertmaster has fields for mean start/finish so maybe someone who uses that software could throw some light on the subject?

There is a discussion, which includes this topic, by Tony Rizzo on the Project Development Institute site (http://www.pdinstitute.com/soapbox/2004_10_17_soapboxarchive.html , sorry, can’t get the hyperlink to work).

Regards

David

edit: hyperlink activated - moderator...

The term mean I use when I describe the variance between the early & late date. (Mid point)

If your early date is 1 Jan your late date the 10 jan your mean date the 5 jan.

Hi David,
Thanks for the reply. Will also try to log into the site that you gave.

Jaco,
I guessed that as well, the printed report has well over 600 activites and it has to be generated from a software(Pertmaster as David mentioned?).

Thanks again guys.
Regards,
Daniel

David, et. al., you may post "live" links using a bit of HTML as described here:

Adding HTML links to your posts

Bernard Ertl
eTaskMaker Project Planning Software

Does anybody ever use these "average" dates?

It should be easier if you try and stay in between the early and average date. The problem is that people in a lot of the cases aim for the late date. They generally miss the date.

Regards,

Erik

Rightly "mean start/finish" usually refers to average dates from a risk analysis (as in pertmaster), but Monte carlo calls them ’expected’ dates. In Artemis and most other software uou can rename columns as you like so from a printed report it is impossible to tell what is meant. I would advise avoiding the terms expect when in risk analysis (its now, common usage).

Hi
As stated by others ’mean dates’ usually derive from risk analysis.
But are we [schedulers/planners] missing a trick here. When early dates are set as a target or baseline then any movement away from this the acusation of being ’in delay’ or being late steps in... or from the other side of the coin we claim we are being delayed. when it reality and in all reasonableness slippage away from earliest dates are not really of great concequence on the whole.
As Eric said , if we make the latest dates our target or baseline then any slippage is by definiition critical and you will enevitably miss the date and delay the project. not a good idea. Also contracturallly it is a dangerous game.
So why not make the mid point between the early to late dates the "Target" or baseline. This is easily done in P3 or openplan by mathematical manipulation of user defined date fields which can then be plotted out or used for comparisons. Now a days i do a similar thin with baseline progress or resource envelopes where i output the early and late curves and calculat the mean curve points and monitor progress against this as the target. In managing the project we aim to keep within the envelope so why not record the progress position against the mid point.

It would be useful if software automatically stored the mean dates, [i.e. not just following risk analysis] what do you think ?
Regards
JK

Jonathan
I go along with your point of setting a target which may be the mean date, or mid-point early/late dates. It also depends on what the plan is based (best achievable, comfortable expectations, etc.). However, it may be dangerous to automatically take the mean of early/late. I would prefer to use the risk analysis to get a better undersatnding of the risk exposure and then set the deterministic target plan with an acceptable risk level. What that level is depends on the use to which the plan is put - presentation to investors (choose a high probability, say 80%) or stretch target for the project (choose a low probability, say 25%). Then set plan durations to suit this probability of achieving end date.

We use early dates, late dates and critical dates.
Critical dates are between early and late. They show the reasonable reserves that you have on your tasks. Violating critical dates means that the probability of meeting project target dates will be low (less than 30%).
We suggest people to use early dates for management of people and critical dates to estimate current reserves.
Regards,
Vladimir

Hi Guys,

There is of course another method to get to an average, ie target or planned date. Resource levelling can be used. By using the average between the early and late date resource requirements, as your available resources, with total float as a priority, you should then get to some in-between dates. This should give better results, and be less risky than just taking an average.

Regards

Philip

Philip,
of course project should be leveled. And still there will be early dates, late dates and critical dates in the LEVELED SCHEDULE! And besides total float is not always the best resource leveling criterium.
Regards,
Vladimir

Hi Vlad,

Agreed, however, in most instances total float is a good criteria. What I do not agree with in P3 for example, that the time scheduled early dates, be replaced by resource scheduled dates. The resource scheduled dates should be shown in a different field, lets call it levelled dates. Thus you should be able to draw an s-curve with early, levelled and late dates, which will give you a good idea of how effective your resource levelling is. You can still do this, but in a roundabout way.

Regards

Philip

Philip,
I agree that it is useful to be able to compare leveled and unleveled schedules to estimate leveling impact. We do it other way - a package shows all delays though you can see all dates too. Total Float is a good criteria if you have no other options but to choose activity fields that will be used as criteria. In most times project schedule created using these criteria may be improved. And you can easily create three activities project where total float leveling produce bad result.
Regards,
Vladimir

Hi Vlad,

Although I said use TF, it is generally accepted as a good criteria, I normally create a priority code, in which I set priorities. I then use this as my first criteria and TF as the second, for res levelling. This gives me better control, during levelling, and also allows me to reset priorities,as the situation changes. I try to use a maximum of 3 to 5 priorities.

Regards,
Philip