Unexpected behavior in Baseline Variance values

tcalvey

Hello All,

I'm pretty excited to see support for baseline dates, however, during testing, I'm confused by these variations:

Since the actual and baseline dates are the same, the expected value is "0."

Can anyone explain the formula that is used to calculate this Variance?

Find more posts tagged with

Accepted answers

tcalvey

I'll do that. It's not a huge deal, as I just added another column to calculate a variance, but something is definitely off.

Thanks Paul

All comments

Paul Newcome

I would suggest reaching out to Support. In your screenshot, 2 rows below the second highlighted row is the same thing where the actual and baseline match and you are getting the expected variance of zero.

Paul Newcome

But based on the other rows, it appears to be pulling the number of working days from Baseline Finish as compared to Actual Finish.

tcalvey

I'll do that. It's not a huge deal, as I just added another column to calculate a variance, but something is definitely off.

Thanks Paul

Paul Newcome

What did you use to calculate your variance? The highlighted row in the second screenshot shows the same logic being use for the baselining feature as those couple of rows in your first screenshot where the end date is the same but the variance is showing as 1 day.

tcalvey

NETWORKDAYS([Baseline Start]@row, [Baseline Finish]@row) - NETWORKDAYS(Start@row, Finish@row).

Instead of calculating the total elapsed time of the variance in days, I'm going to see if the PM's would prefer workdays instead.

Paul Newcome

But since the highlighted task was finished on time, there was no variance. Yes. It took a different amount of time from start to finish, but overall it was finished on time which means the task did not cause any variance in the project's schedule.

NETWORKDAYS though does make sense for those tasks where the dates are the same but it is displaying a 1.

If you do 16 June 2021 - 16 June 2021, you will get zero, but if you use NETWORKDAYS you will get 1 because it is counting it as 1 working day.

tcalvey

That makes more sense. Thanks for the clarification.

When I subtract the two dates ([Baseline Finish]@row - Finish@row) I get a fraction. The system must round up (or down) any amount to the nearest whole number

Paul Newcome

How long do you have your working day set for in your settings? 9 hours?

tcalvey

8 hour workday

Paul Newcome

Well there goes that theory. Ugh.

0.375 is 9 hours out of a day. I was thinking maybe it was pulling the "end of the day" vs the "beginning of the day". Although depending on timezone and whatnot, that could still be possible.

I take it no word back from Support yet?

tcalvey

The .375 result was not based on a NETWORKDAYS() formula. To test if there were fractions (since there is no formatting control over the Variance column) I revised the column formula to try subtracting the raw dates (in the column description in the image above). A decimal result is strange because all of the values in the sheet (durations, dependencies) are based on days. There are no other units of time used.

Here's the screen with both calculations (NetWorkDays, and simple date calc)

Support provided a thorough response, but they tested it and cannot reproduce the same result. They basically recommended I reset the baseline and see if it happens again.

Paul Newcome

Right. I understand the fraction came from the raw dates. When working with dependencies, there is a sort of timestamp that is stored on the back-end but not displayed. I have seen this cause issues before. The NETWORKDAYS would appear to "round" this but really if it is (for example) a 9 hour day, then the NETWORKDAYS function will register this as a full day.

It is definitely some odd behavior, but at least Support was able to provide some feedback.

Did their recommendation work for you?

tcalvey

Not exactly. I don't want to reset the baseline. If I could modify those dates manually, no problem, but we can't, so I'll need to keep them. Secondly, it doesn't change the fact that the logic that causes this behavior is still there.

I'll get to the bottom of it. I just need to spend some more time trying to figure it out.

Thanks again for your help.

Paul Newcome

You aren't able to manually modify the baseline dates? I haven't had a chance to play with the new baselining feature yet, so I didn't realize that was a restriction.

Sign in to join the conversation!

Quick Links

Component react.discussion.discussions had an error.

ref must be one of: categoryID, siteSectionID, category, category/categoryID, category/name, category/description, category/url, category/allowedDiscussionTypes, locale, siteSection, siteSection/basePath, siteSection/contentLocale, siteSection/sectionGroup, siteSection/sectionID, siteSection/name, siteSection/description, siteSection/apps, siteSection/attributes, layoutViewType, discussionID, commentID, page, sort, discussion, discussion/name, tags, breadcrumbs, discussionApiParams, serverDraftID, serverDraft.