Aug 02 2022 09:39 AM - edited Aug 17 2022 01:45 PM
I created a custom text field called Elapsed Duration as I want to use this field instead of the built-in "Actual Duration" field which calculates based on % complete. I want to monitor and know the true duration that a task has been in progress even when work is not performed. Elapsed duration would be the amount of time that has passed between the Actual Start and Project Status Date for tasks that have not finished or for completed tasks amount of time that has passed between Actual Start and Actual Finish of the task. Then I want the Elapsed Duration rounded to whole days. I'm not sure what function in project to use for that. I'm not sure how to build complex formula like this for Elapsed Duration. Below is what I've come up with so far for individual functions.
Calculate Elapsed Duration for Tasks That have started but not finished:
IIf([Actual Duration]=0,"NA",ProjDateDiff([Actual Start],[Status Date])/480 & " " & "days")
Calculate Elapsed Duration for Tasks that have finished:
IIf([% Complete]=100,ProjDateDiff([Actual Start],[Actual Finish])/480 & " " & "days")
Round Duration To Whole Days:
?????
Aug 02 2022 10:04 AM
Aug 02 2022 04:35 PM
Aug 02 2022 05:28 PM
@ignacio_martin_mvp Yes, I believe this formula works. I got a syntax error at first because you used semi colons in the formula so I had to replace those with commas. I can now see that a tasks baseline duration was supposed to be 20 days and is 25% complete, however the actual elapsed duration or time its been in an In Progress status shows 36 days. Thank you for your help.
Aug 15 2022 08:16 AM
@ignacio_martin_mvp I don't know if its the way I'm using the formula you provided is calculating Elapsed Duration using the difference between the status date and actual start date, but somehow, For one of my projects, For the project summary task circled in RED, I show an Actual Duration aka "Work Duration" that is greater than the Elapsed Duration as shown below. How is that possible? I wouldn't think that Actual Duration of project work could exceed the total elapsed duration or time that has passed since the project has been in progress. Any ideas?
Aug 15 2022 07:29 PM - edited Aug 16 2022 07:11 AM
I think the formula provided isn't quite what you requested. I believe this simplified formula meets your original requirements:
IIf([% Complete]=100,round(ProjDateDiff([Actual Start],[Actual Finish])/480)*480,round(ProjDateDiff([Actual Start],[Status Date])/480)*480)
As to your current question, why couldn't the calculated Elapsed Duration be greater than the Actual Duration? Actual Duration is driven by % Complete whereas Elapsed Duration is derived from the Status Date and the Status Date and % Compete are independent metrics. Take the following example of two 10 day tasks starting on Monday. The Status Date is set as the first Friday in the two week span. Note the difference in Actual Duration compared to the Elapsed Duration for each of the tasks.
Make sense?
John
Aug 16 2022 07:50 AM - edited Aug 16 2022 08:15 AM
@John-project Thanks for the revised formula. It appears however, it doesn't account for tasks that have not yet started, so the Elapsed Duration Field is displaying a #ERROR. I'll have to include a criteria that if Actual Start=NA then Elapsed Duration = 0, or something like that.
What I'm trying to do here is develop a "Work Process Efficiency" project performance KPI. For that I was taking Actual Duration/Elapsed Duration. Basically, the duration of actual work being performed compared to the time the task has been in an "In Progress" status. This is similar measuring a business or manufacturing process. Process Time is the actual touch time or time working on a task, whereas the lead time aka Elapsed Duration is cycle time+lead time. So maybe I need to use a custom field and formula or a different built-in field that represents "Work Duration" as it doesn't seem like the built in Actual Duration field is what I want to use, because the Work Duration should never exceed total elapsed duration. Any ideas?
Aug 16 2022 08:11 AM
Aug 16 2022 09:29 AM
@John-project Thanks for the formula update. Sure, if anything comes to mind, please let me know on how I can use MS Project data to calculate Work Process Efficiency as using the built-in Actual Duration field probably isn't the right field to use. I'll keep brainstorming in the mean time as well.
Aug 16 2022 03:37 PM
Aug 16 2022 04:18 PM - edited Aug 16 2022 04:32 PM
@John-project There are certainly many conditions/variables to consider when trying to come up with a work process efficiency KPI in MS Project. I got the whole idea from the PMBOK 7th edition that mentioned measuring process efficiency in terms of value-added (Working on a Task) versus non-value added (Task started but idle) time. I'm still thinking the easiest method to calculate a Work Efficiency KPI is taking Actual Duration / Elapsed Duration (total time from the tasks start to the status date). It may not be the most accurate but at least it doesn't make my head spin.
The obvious downside however, is that you demonstrated how its possible for Actual Duration to be greater than elapsed duration, which in reality can't happen. So if there was some way to solve for that. That would help.
Aug 16 2022 06:46 PM
Aug 16 2022 07:30 PM
@John-project I’m not quite sure I’m following. You might have to provide a scenario where what you are suggesting would work to give me work duration using what you suggested. Also I hated programming in college so when you mentioned VBA I got nauseous. I think my Elapsed Duration formula is good, but calculating the amount of work duration that occurred during the elapsed time until the task finishes is still unknown since it appears Actual duration is so close, but not the answer obviously if its possible for that value to exceed the elapsed duration.
Aug 17 2022 08:55 AM - edited Aug 17 2022 09:34 AM
As I think more about how you are tying to apply a theoretical concept (i.e. lead time and process time) to Project, there just isn't a good fit. When creating a plan in Project the normal process is to create a logical sequence of tasks to accomplish an end goal. Tasks are linked using finish-to-start relationships with other variants (e.g. lead, lag, etc.) only used in very limited circumstances. As such, the plan doesn't provide any leading or lagging "dead" time, unless specifically pre-programmed into the plan (e.g. lead/lag in task relationships). When one task finishes, the next task starts so the conceptual lead time and real process time are the same.
With the above reality, the KPI for work efficiency will be 1 for all but perhaps a very few tasks. For covering those isolated tasks, (and I'm not sure why there is any benefit in doing so), the "work duration" (e.g. process time) is actual start to actual finish for completed tasks or actual start to status date for in-progress tasks. Lead time, including process time) would be the sum of predecessor lag (if any) plus process time plus successor lag (if any). I'll attach an example once my computer is finished booting up after a power glitch.
Update (after power glitch recovery):
While creating an example, it came to my attention that for in-process tasks, work duration is not actual start to the status date but rather, it is actual start to actual start plus actual duration.
John
Aug 17 2022 09:51 AM
@John-project Oh my this is getting complicated. Still to me based on how I read the definition of Actual Duration and how it's calculated, that to me represents "process time"/touch time/work duration.
Actual Duration: The Actual Duration field shows the span of actual working time for a task so far, based on the scheduled duration and current remaining work or percent complete.
My custom field for Elapsed Duration which I would define as the span of total time passed so far based on the difference between the Actual Start of the task and the project status date. This is where the ProjDateDiff formula comes in to calculate that difference (excluding non-working time as defined in the project calendar).
Again, the downside however of using the built-in actual duration field and how it computes, its possible in the MS Project world anyways that the Actual Duration could exceed Elapsed duration, which in the real world we know isn't possible. If I can solve for that, then I think I can calculate work process efficiency a little more realistically and accurately. So I get my 3 project performance KPIs: Cost, Schedule, and Work.
Aug 17 2022 10:33 AM
@John-project Maybe to compensate for the potential of Work Duration exceeding elapsed duration, I could include an IIf condition in the custom work duration field where if Actual duration is greater than elapsed duration, then Work Duration equals Elapsed Duration.
Aug 17 2022 01:12 PM
Aug 17 2022 01:43 PM
@John-project So I ended up using the workaround where if the actual duration is greater than elapsed duration it sets the work duration value equal to the elapsed duration. I don't think using baseline fields would be good because that's according to the "Plan", not what actually happens. in measuring process performance, I need "Actuals". As far as lags, I've never had the need to use lags in an agile project. Most of my project tasks don't have predecessors/dependencies. So, I don't see how lags would be applicable here.
I'm just going to stick with my Work Duration formula that uses actual duration with the condition that work duration can't exceed elapsed duration. It may not be precise, but I think it will be good enough to measure work efficiency.
Aug 17 2022 04:28 PM
Aug 17 2022 06:57 PM
@John-project In agile projects tasks/aka requirements/aka user stories are supposed to be Independent, meaning it shouldn’t have any predecessors or successors. However in practice it’s not always possible to meet the I-Independent for the story INVEST criteria. Some requirements have to be implemented before others but not all. When these instances occur then I establish the predecessor in project and JIRA has an option to select must be done before or must be done after and then you link it to the related requirement/story