none
Keep Original Measurement Unit For Custom Duration Field RRS feed

  • Question

  • In order to be able to see the total duration of tasks (in terms of aggregated effort as opposed to total duration) one has to add an additional custom field, and make that sum the values for roll-up summary tasks. There's a nice video on how this is done here.

    However, the problem is that the unit of time defaults to days for all the tasks (picture below), instead of keeping the corresponding one (day/hour/minute). Is there a way to automatically have this new field keep the unit of source duration field ?

    Monday, January 11, 2016 1:20 PM

Answers

  • Albert,

    Yes, I'd say there was a disconnect from the start.

    With regard to your last paragraph, you are not wrong, but I would correct the statement to say that the "correct" (versus "normal") way of doing this is to enter estimated work for each task into the Work field - that what it is there for. Then as the project progresses the actual work can be entered into the Actual Work field and if necessary (i.e. things have changes), the Remaining Work field can be updated (i.e. task will take less or more effort [work] then initially estimated).

    I don't know why you would need a custom field to reformat the Work field. Work is normally expressed as hours, rarely is there a need to use other units for work unless perhaps the task only takes a few minutes to complete, then minutes of work may be appropriate but then only if the whole project consists of tasks of minute effort.

    John

    • Marked as answer by Albert Mihai Wednesday, January 13, 2016 10:38 AM
    Tuesday, January 12, 2016 2:38 AM
  • I consider that the "normal" way of doing this is to do it in a way which is consistent with the critical path method.

    It is primarily a task scheduling problem first and foremost, and a resource management and work/cost management problem secondarily.

    These are the inputs.

    1. Identify a task. Identify every task. Don't leave any out, especially those which have predecessors and/or successors, or require any resources, or cost any money.
    2. Estimate its duration. The estimate is just the estimate. Do not get obsessed with "accurate estimates, or be afraid to be "wrong" because it is almost certainly "wrong" anyway.
    3. Link it to its predecessors and successors.
    4. Assign the resources, usually at the default 100%.

    These are the outputs

    1. The work and cost are then whatever they come out to be.
    2. The overall duration is whatever it comes out to be.

    You may have some resource over-allocation, which is indicating that your plan is not yet feasible.
    Get rid of the over-allocation. Various ways such as re-assignments, assignment substitutions and levelling are available.

    You now have a feasible plan. If you don't like the output, change the input until you do.

    When tracking progress, start with the facts as they occur, in the order in which they occur.
    Facts progressively replace estimates.

    Take care of actual start, actual duration, and actual finish first.
    Attend to actual work and actual cost next.

    Why? Because this way you can be sure that any actual work or actual cost happen on days of actual duration. If a task is actually finished, some of the days between the actual start and actual finish must have been days of actual duration (although not necessarily all of them), and actual work and actual cost must have occurred on those days.

    Any help?

    • Marked as answer by Albert Mihai Wednesday, January 13, 2016 10:38 AM
    Tuesday, January 12, 2016 4:04 AM

All replies

  • Albert,

    I'm afraid I'll have to take exception to your first statement. Duration is NOT a measure of effort, work is. That's why the existing Duration field at summary level is calculated the way it is.

    However, to answer your question, no, there is no built-in option to separately select the units for extra duration fields. To do that, you need a custom text field with a formula similar to this, where the divisor is however many minutes are in the unit you want to display (e.g. 60 for hours, normally 480 for days, etc.)

    ProjDateDiff([Scheduled Start],[Scheduled Finish])/60 & " hours"

    John

    Monday, January 11, 2016 2:41 PM
  • I will back up John here. Duration is not work, and work is not duration. People often like to use the term "effort" as meaning the same thing as work, but in MSP there is no such thing as "effort" so it is probably best to avoid that word and stick to calling it work.

    That video refers several times to work (or effort) and duration as though they are the same thing, and this is incorrect. All the video really does is show how to make a custom field with a formula, and roll up to the summary.

    However, since a task can have duration even when there is no resource assigned and no work, clearly duration is not work.

    Your custom field is simply a counter which counts the duration in working days of the tasks under that summary. This can become a meaningless or indecipherable number if the tasks have various different calendars and/or the summary has some other calendar.

    Since your durations are input in two flavours, you could capture them with two custom duration fields, with one of them having the formaula as John shows.

    Your example has problems, mainly numerous date constraints, and two tasks with no predecessor, one or the other is going to be redundat or they will conflict.

    Monday, January 11, 2016 4:16 PM
  • Alternatively, or as well as, if you use a custom number field with [Duration] in the formula, you get an answer in minutes, and you could wrap an IIF function around this which tests for the text in the duration field to see if it is in hrs or days, and divides the minutes by 480 or 60 accordingly. I haven't tested this but I think it would work.
    Monday, January 11, 2016 4:24 PM
  • Gentlemen, thank you for your replies. I've renamed the field to "Aggregated Work", in order to eliminate ambiguity.

    Trevor, I first tried searching through the [Duration] field for "days", "hrs" etc, but it turns out this field only holds a value equal to the  number of equivalent minutes. From this I arrived at the formula below, while also changing the type of the custom field to Text. Unfortunately I realized that text fields cannot be rolled up (duh !). So I've used an intermediary numeric custom field that would store the number of minutes and also included Sum for rollup, and simply referenced this in the final formula.

    John, I've actually used the reference to the [Duration] field instead of the difference between start and end date, since I thought that if a task is delayed (dotted line on the Gantt chart - not really sure what the name of this feature is - for example when the Duration is 1 hour but the End - Start actually amounts to 3 days) the amount of work for that task should still remain equal to the value in the Duration field.

    As for having all Duration, Start and Finish - I actually only enter/modify Duration and leave Project to calculate the dates (as well as automatically updating everything via "Update Project"). Task Mode is set to "Auto Schedule". What would be a better way to tackle this ? Actually it's one of the reasons I've put the whole snippet - in order to get some welcomed constructive criticism. As for the predecessors for 2 of the tasks, indeed they are loose ends that need to be corrected.

    The example now looks like this:

    Monday, January 11, 2016 6:05 PM
  • Albert,

    You can call an apple an orange but that doesn't make it an apple. Likewise, you can call your custom field "Aggregated Work" but if it's based on duration (passage of time), it does not represent work. If the task is "waiting for paint to day", "waiting for concrete to set", or "waiting for a wound to heal", then duration is relevant, but for anything else, effort (i.e. work) by one or more resource is the measure. For example, the schedule may allow a week for a task to be completed but it will only require a resource to work on it half time so the work content is 20 hours.

    If a single resource is assigned to each task full time then yes, duration will equal work, but the Work field already exists and is summed up appropriately so the equivalent summing of aggregate duration is redundant.

    If you want to know the aggregate elapsed time of all the tasks under a summary, and I'd love to know how that is of any value, then your formulas do represent that metric, but it is not "work".

    So to answer your last question, (i.e. what is a better way to tackle this), I say "if you believe the metric of summed up elapsed duration is meaningful then name the metric appropriately, but don't call it work".

    My two cents.

    John

    Monday, January 11, 2016 6:47 PM
  • I think the problem is the way I looked at this from the beginning - hence the whole mixup with duration and work. First thing - most of the tasks in my example are actually assigned to only one resource. Next, my using of the Duration field is skewed - I'm actually using this to specify the actual work against the task eg. task "Paint Walls" actually takes 4 hours of work. In my case, since this task is amongst the many that are assigned to just one resource, the duration of this task will be 4 hours (if there were 2 resources assigned to it, the duration would have been 2 hours, assuming both resources work at the same rate - and using the duration field, which is placed so conveniently near the task name by default, becomes wrong).

    Now, due to various delays, I'm using the Update Project to update the tasks. MS Project will happily move the tasks according to the status day selected, however now there's a problem: if a summary task has been delayed by some other task (belonging to a different "chapter" of the project) for say - 1 year, now when I look at the field where I've inputted my actual work, I see a huge amount of time versus what I would have expected to find (I'm looking at the Duration field, expecting to actually see Work, given that I've entered Work in those fields). The outcome is quite normal - I'm feeding apples to the coffee grinder and expect nice apple juice in return.

    So the normal way of doing this - please correct me if I'm wrong - is to enter the actual amount of work for the respective task in the Work field (after this has been added to the project). Then I could use my custom field in the previous post with the formula, which would only be a slightly nicely formatted Work field, that takes into account days / hours / minutes.

    Monday, January 11, 2016 8:23 PM
  • Albert,

    Yes, I'd say there was a disconnect from the start.

    With regard to your last paragraph, you are not wrong, but I would correct the statement to say that the "correct" (versus "normal") way of doing this is to enter estimated work for each task into the Work field - that what it is there for. Then as the project progresses the actual work can be entered into the Actual Work field and if necessary (i.e. things have changes), the Remaining Work field can be updated (i.e. task will take less or more effort [work] then initially estimated).

    I don't know why you would need a custom field to reformat the Work field. Work is normally expressed as hours, rarely is there a need to use other units for work unless perhaps the task only takes a few minutes to complete, then minutes of work may be appropriate but then only if the whole project consists of tasks of minute effort.

    John

    • Marked as answer by Albert Mihai Wednesday, January 13, 2016 10:38 AM
    Tuesday, January 12, 2016 2:38 AM
  • I consider that the "normal" way of doing this is to do it in a way which is consistent with the critical path method.

    It is primarily a task scheduling problem first and foremost, and a resource management and work/cost management problem secondarily.

    These are the inputs.

    1. Identify a task. Identify every task. Don't leave any out, especially those which have predecessors and/or successors, or require any resources, or cost any money.
    2. Estimate its duration. The estimate is just the estimate. Do not get obsessed with "accurate estimates, or be afraid to be "wrong" because it is almost certainly "wrong" anyway.
    3. Link it to its predecessors and successors.
    4. Assign the resources, usually at the default 100%.

    These are the outputs

    1. The work and cost are then whatever they come out to be.
    2. The overall duration is whatever it comes out to be.

    You may have some resource over-allocation, which is indicating that your plan is not yet feasible.
    Get rid of the over-allocation. Various ways such as re-assignments, assignment substitutions and levelling are available.

    You now have a feasible plan. If you don't like the output, change the input until you do.

    When tracking progress, start with the facts as they occur, in the order in which they occur.
    Facts progressively replace estimates.

    Take care of actual start, actual duration, and actual finish first.
    Attend to actual work and actual cost next.

    Why? Because this way you can be sure that any actual work or actual cost happen on days of actual duration. If a task is actually finished, some of the days between the actual start and actual finish must have been days of actual duration (although not necessarily all of them), and actual work and actual cost must have occurred on those days.

    Any help?

    • Marked as answer by Albert Mihai Wednesday, January 13, 2016 10:38 AM
    Tuesday, January 12, 2016 4:04 AM
  • John, the default format in hours for the Work/Actual Work/Remaining Work will do just fine. I think I got hung up on the whole days/minutes/hours format trying to customize the custom Duration field I added, which wasn't what was needed to begin with.

    Trevor, given that most of the tasks in this project are "action-oriented", for which I can do an estimate of actual work required to finish it, I'd rather use Work as input, and keep the Duration as the output. By contrast, if there would have been more "Wait for cardboard glued pieces to set", "Wait for paint to dry" then Duration should be entered, and by leaving the Resource field empty, there would be 0 hours of Work for that task. Am I on the right track ?

    Tuesday, January 12, 2016 1:25 PM
  • Albert,

    Okay, it sounds like you've got a handle on it. I would caution you on using the term "estimate of actual work". An "actual" is never an estimate, it is reality. The correct term is estimated work - that's what you start with. After the task starts they you will have "actuals".

    As far as waiting for something to happen (e.g. glue to dry, paint to day, etc.), those should not generally be tasks anyway. If they must be included in the plan, one good approach is a delay (lag) in a successor task. For example, for a painting task there is the painting effort itself (resource work), followed by a drying period (no resource - elapsed time), then perhaps followed by moving the furniture back into the room (resource work). In this example the moving furniture could have the painting task as a predecessor with a delay equal to the paint dry time.

    I hope we have answered your questions.

    John

    Tuesday, January 12, 2016 3:43 PM
  • Thank you for your help and guidance. Much appreciated !
    Wednesday, January 13, 2016 10:38 AM
  • Albert,

    You're welcome and thanks for the feedback.

    John

    Wednesday, January 13, 2016 4:09 PM
  • Albert,

    I am afraid not. I can see your argument and why it is appealing to you, and you have constructed a persuasive logic to support it.

    Notwithstanding that, I am not persuaded and I still think you should reconsider, mainly because it can cause problems and difficulties later, and even more mainly it is not consistent with the critical path method. Work is not an input to the critical path method, duration is. Since MSP is built around the CPM, I would suggest that the software has been designed to be used in a certain way, and you should do it that way.

    I remember realising a long time ago, that if you want MSP to work for you, then you must work with it rather than against it. Life got a lot easier after that.

    When I make a list of tasks, I include everything I can think of that is part of the scope of the project and  resembles an "event" or an "occurrence", especially anything that has duration, but also events etc which have zero duration, and also anything which is a predecessor or a successor of anything already in the list.

    Some events may also have cost even if they have zero duration, so I include those too. This saves me from having to discriminate between tasks as "action-oriented" or something else. MSP doesn't discriminate so neither do I. This makes the way I do it easier than the way you do it.  Your way, you have to invent a new characteristic "action-oriented" and keep in mind whether tasks are or are not.

    By the way, call me pedantic if you wish, but vocabulary is important. You can't do an "estimate of actual work". An estimate is about something which is in the future and has not yet happened (and it may not happen at all). An actual whatever is something which has actually happened and, of course it can only be something which actually already happened in the past. Look up wikipedia for a definition of "actual".

    Thursday, January 14, 2016 5:13 AM
  • ...Like John said.
    Thursday, January 14, 2016 5:14 AM
  • Trevor,

    I'm curious, give us an example of a zero duration (milestone) that has a "cost". I can see where a milestone might trigger a payment but I cannot see how a cost is applicable to a milestone.

    John

    Thursday, January 14, 2016 5:15 PM
  • When a building company starts a building project they need a building permit and must pay a fee to the local government when they submit the application for the permit. This takes 0 duration but it costs $100. It is not necessary to assign a resource to the zero duration milestone, only necessary to assign a fixed cost to it.

    The application is the predecessor to "wait for the permit to be granted" and this does have duration, 20 days, say, and then the event of granting the permit has zero duration. You may say that the two zero duration events and the one non-zero event (call it a task) could be collapsed into one task with a duration of 20 days and it could be called "apply for, wait and receive the building permit" and accrue the permit fee as a fixed cost at the start, but I prefer a bit more detail.

    Zero is just as valid a duration as any non-zero positive number. An event or occurrence which has zero duration is not really any different from one which has a non zero positive number for its duration. It's just that by convention they are called milestones.

    I also like the entire cost of the project to be in the plan. So if I know the project will cost $1M, but all of my tasks have a cost which sums to only $0.95M, it is no trouble to make an event with zero duration called "sundry costs" or similar, and a fixed cost of $0.5M. This amounts to an allowance for office rent, phone calls, printing and stationery.

    Friday, January 15, 2016 6:52 AM