SOLVED

Duration vs work

Copper Contributor

Hi,

I'm having trouble understanding how Project auto-calculates things.

Specifically, let's say I have a task that I know will take 3 weeks of real time to happen, because it includes waiting for a delivery. So I want to put it into my program as:

"Order widget" 3 weeks ("Fixed Duration").

 

There might be a person doing some admin work on this same task (let's say placing the order, writing a PO, following up with the supplier, tracking the delivery, receiving it, checking it etc.) I don't want to create 15 tasks to cover all the little chores involved in ordering something.

Nor do I want to allocate 3 weeks of the person's time to this task, since over the three weeks, they will probably spend 4 hours on the task.

 

So I put in, with 3w Fixed Duration:

 

OlafGladAndBig_0-1679194248507.png

If I now change the Work column, (let's say I reduce the work to zero hours and make the Resource a non-human entity called Wait), it SOMETIMES insists on changing the Duration to zero. But other times it will happily accept zero work against a given duration, without changing the duration.

 

1/

Here's an example of when it forces a change:

 

"Duration" is 3 days before editing the Work column (which presently says 24 hrs). The Resource is simply called "Wait". (The number 39 is a Precendent column).

 

OlafGladAndBig_3-1679194681445.png

 

And the Task Form looks like this:

OlafGladAndBig_2-1679194643126.png

 

After changing the Work column to zero, the Duration is forced to zero as well. It happens in both directions... i.e., if I edit the Duration, it recalculates the Work. If I edit the Work, it recalculates the Duration:

OlafGladAndBig_4-1679194711458.png

 

2/

Here's the example when it doesn't force a change:

This shows the effect of me changing the Work column to zero. As far as I can tell nothing else is different except there is no precedent this time (guessing that's the issue, but not sure why). I'm using the same Resource, but it now happily accepts 0 hrs work against a fixed duration.  

 

OlafGladAndBig_5-1679195202968.png

Task Form looks like this:

OlafGladAndBig_6-1679195532235.png

 

I'd be interested in any thoughts. Thank you!

5 Replies
OlafGladAndBig,
There are three types of resources, work, material and cost. There is no human/non-human option. So what exactly does your Resource Sheet look like?

In your first screen shot you show a task with a duration of 3 weeks although it is entered as working time, not what I would call "real time". If you want 3 weeks of calendar time you should enter the duration as 3ew ( 3 elapsed weeks). But then in your example screen shots, that duration is suddenly 3 days. So which is it?

I cannot replicate your first scenario wherein the duration is forced to zero when the work goes to zero and vice versa, and that includes a predecessor on the task. So, something else is going on. A screen shot of the Gantt Chart before and after might help. Please outline the exact steps for your first scenario starting with a fresh new task.

John
Thank you for your response John. Apologies if my question wasn't clear.

There are six screenshots above.
1. "Order widget" with Resource Some Guy, duration 3w (Not referred to again - simply an example).
2. "Manufacture prototype with ac base". Duration 3d. Work 24h.
3. Task form for screenshot (2)
4. Screenshot (2) taken again after changing work to zero, where "fixed" duration has also been forced to zero.
5. A new task also called "Order widget" after setting work to zero where duration was not forced to zero. (the resource here is called "Wait").
6. Task form for screentshot (5).

Since these were all made-up examples, I threw in arbitrary times rather than using elapsed etc.

I can't replicate the behaviour now either, so it was either a glitch or I was doing something wrong that I'm no longer doing.

Regarding your point about resources, if you have a moment, I'd be interested to understand how you deal with a wait period. Say I order a part and have to wait 3 weeks for it; then the next task can't start until it arrives. If I put a zero-cost resource name "Wait" against that 3 week "task" then it's clear looking at the Gantt that a three week wait is happening, because it says "Wait" right there against the bar.
If you have a moment, or can point me to an explanation online, I'd be interested to know how to present a wait time.
Thanks again.
best response confirmed by OlafGladAndBig (Copper Contributor)
Solution
OlafGladAndBig,
I've found that sometimes when you're doing various scenarios and use the "undo" to back out of a step, Project goes a little "sideways". The undo command apparently is a "clean wipe" of the undone step. I don't know if you used undo in your original scenarios but that might be the "glitch".

Anyway, wait periods can be handled in various ways. One way is to create a "wait" task line with no resources assigned. Activities leading up to the wait (i.e. creating the PO, writing the order, coordination with the vendor) can be a separate task line perhaps as a predecessor to the wait task with a start-to-start + 50% (e.g. 39SS+50%). Or another common way to handle a wait time is with a lag in the predecessor where the lag itself is the wait (e.g. 39FS+2w)

John
Thank you - much appreciated.
OlafGladAndBig,
You're welcome and thanks for the feedback.
John
1 best response

Accepted Solutions
best response confirmed by OlafGladAndBig (Copper Contributor)
Solution
OlafGladAndBig,
I've found that sometimes when you're doing various scenarios and use the "undo" to back out of a step, Project goes a little "sideways". The undo command apparently is a "clean wipe" of the undone step. I don't know if you used undo in your original scenarios but that might be the "glitch".

Anyway, wait periods can be handled in various ways. One way is to create a "wait" task line with no resources assigned. Activities leading up to the wait (i.e. creating the PO, writing the order, coordination with the vendor) can be a separate task line perhaps as a predecessor to the wait task with a start-to-start + 50% (e.g. 39SS+50%). Or another common way to handle a wait time is with a lag in the predecessor where the lag itself is the wait (e.g. 39FS+2w)

John

View solution in original post