Feild with Indicatorts

[iken]

Hi,

I am using Project 2007, and note I can add Indicators to custom feilds.

Can anyone tell me the formulae I need to enter so I can show the following:
1. start date is greater than status date (not yet reached)
2. start date is equal to or less than status date (can/should commence)
3. work complete behind scheudle
4. work complete is on track
5. work has not started but should have started

Thanks,

 

[ierland]

What do you exactly want to achieve?
Start Date > or <= Status Date is in principle not too complicated.
However, do you want this only for tasks without Actual Start? Or...?
Work Complete [= Actual Finish Date filled-in] behind schedule. Do you mean Actual Finish > Baseline Finish or something else?
Work Complete is on track. What is that for you? Actual Finish Date <= Baseline Finish Date or something else?
What is your difference between 2 and 5? Or do you want some tricks with the Total Slack? [Early Start and Late Start]
I use even different indicators for tasks that should start e.g. within 2 weeks after the Status Date and those beyond. In addition I can exclude summary tasks, etc.
Perhaps have an example with clear indication of the different situations.

 

[ierland]

Where are your requirements? Or did you loose interest? In case you found a viable solution, why not share it with us? Else, if you have clear and precise requirements I would be willing to look into a solution as I have made many of these indicators.

Why an easy solution if you can make it complicated?
Greetings from the Netherlands

 

[iken]

Hi ierland,

No i did not loose interest. The job/contrat is well underway, and as I ran out of i=time, I just made do with our standard layout (no flasy indicators to prompt anyone's attention).

Thanks,

 

[ierland]

It is not that complicated once your requirements are unambiguous.

Why an easy solution if you can make it complicated?
Greetings from the Netherlands

 

[iken]

I have read my initial post, and still can't see why you would think my questions were ambiguous.

For further clarity for you.

Assume Status date is today (29th March 2012)

1. start date is greater than status date (not yet reached)
Task 10 Start Date = 20th April 2012
Have an indicator (of my choice) for 20th April > 29th March
Nothing to monitor yet

2. start date is equal to or less than status date (can/should commence)
Task 5 Start Date = 27th March 2012
Task 6 Start Date = 29th March 2012
Have an indicator (of my choice) for 27th March =< 29th March)
Tasks should be underway

3. work complete behind scheudle
After reviewing progress, and entering actual % complete for
each task
Task 2 Baseline should be 75% complete
Task 2 Actual is 50% complete
Have an indicator (of my choice) for Task 2 Actual % < Task 2
Baseline complete
Task 2 is behind schedule

4. work complete is on track
After reviewing progress, and entering actual % complete for
each task
Task 3 Baseline should be 75% complete
Task 3 Actual is 75% complete
Have an indicator (of my choice) for Task 3 Actual % => Task 3
Baseline complete
Task 3 is on schedule

5. work has not started but should have started
After reviewing progress, and entering actual % complete for
each task
Task 4 Baseline should be 2% complete
Task 4 Actual is 0% complete
Have an indicator (of my choice) for If Task 4 Baseline %
complete > 0%, and Actual % complete = 0
Task 4 should have started, but has not

 

[ierland]

OK.
1. Start Date > Status Date. This assumes you never would enter an Actual Start Date > Status Date? In real projects I have seen quite often that an Actual Start beyond the Status Date [that may be in the past, as data may come in late] was entered.

2. How do we relate that to 3, 4 and 5? That is my real problem.

Anyhow we have to assume that % Complete is measured in Working Days. [We are not thinking of % Work Complete?] Do you use any Task Calenders different than the Project Calendar? Do you via Tracking perform Update Project? Thus Rescheduling unfinished work beyond (normally) the Status Date? Are you (therefore) getting Splits? Do you ever update the Baseline, thus having the possibility of Splits there as well? Or would there never be Splits in the Baseline and are you not performing Update Project, thus having no splits in tasks that were behind schedule?

You could have an Actual Start while 0% Complete. When rescheduling the complete task would be moved while still 0% Complete. If Baseline Start < Status Date and 0 % Complete is that case 5 or 2? Or is it 2 if no Actual Start given and 5 else? Or is the Baseline here not important at all?

3. Here you probably mean that Progress is behind Baseline schedule? As there is no field % Complete Baseline, in the case there would be no Split I could calculate Baseline Duration [in Working Days according the Task or Project Calendar] / Working Days between Status Date and Baseline Start Date. However, if you would have an Actual Start (long) before the Baseline Start it would not always be the case that % Complete < calculated Baseline % Complete would imply that the Task is behind schedule.

Normally when looking at the Status [field] the Baseline would not be taken into account, only if sufficient progress has been made with the current Start Date and Finish Date compared with the Status Date and % Complete. You want (much) more?

There are many more uncertainties, in my view, in your rules. Once your rules are unambiguous it must be rather easy to make a formula for the indicators.

Why an easy solution if you can make it complicated?
Greetings from the Netherlands

 

[iken]

Hence why this post went cold.

More hassle than it seems to be worth.

 

[ierland]

No, it is quite simple as long your requirements are straight forward. Yours are not consistent and orthogonal. Perhaps study the different elements in MS Project first. I make constantly Indicators, often even on the fly when somebody wants them. It is therefore absolutely no hassle if you can unambiguous specify your requirements. Although I don't believe that much in Indicators myself, more relying on the real data, they are great for many managers.

Why an easy solution if you can make it complicated?
Greetings from the Netherlands