Project Online: Changes to Granularity of Time phased OData


This was announced a while back as you needed to be aware of the impact on reporting – and you should have seen the posting in the Office 365 Admin message center.  This is rolling out now, and the message center post has just been updated to say that we should be completed by around the end of the year.  (If you are not seeing the message center posts – then talk to your admin and share my blog post https://lwal.me/3n).  The official article on the time phased data roll-up feature can be found at https://support.office.com/en-us/article/Configure-rollup-of-timephased-reporting-data-in-Project-Online-da8487fe-899e-4510-a264-e2ebc948928c.  I’ve also been beaten to the blogs by Paul Mather (and probably others) so I’ll try not to just repeat the great content that is already out there – but highlight a few of the nuances.

The change has a few different aims – and one is certainly to give you faster reporting against your Project Online data.  This can be achieved if the new granularities of weekly or monthly work for you better than daily – with the added bonus that the publish will be a lot faster too!  We don’t have to break the project data down to a daily level for publishing, then have you pull the daily data only to have you aggregate it back to weekly/monthly again.  It will save space too – both in your tenant but also in any local data warehouse you are using.

The first thing to say is we aren’t changing anything automatically.  We are changing the OData schema so you may need to change your reports to ensure the schema changes do not break anything – even if you stick with ‘Daily’ – see this article for more information on best practices.

image  image

If you create a new PWA however, we do now set the default granularity as ‘Never’ so that you will need to make a conscious choice on the granularity you want – or leave it as ‘Never’ if you do not need time phased data (your publish times will be faster!)

I’ll walk through some scenarios, and I’ve also changed my regional site settings to make it more interesting – with my week starting on a Saturday and the first week of the year being defined as the First full week.

image

I’ll use a dummy project that I’ve created with work, costs, baselines etc. – just so we can see what happens to the data in various scenarios.  This is my plan – with 3 work resources, a material resources, a cost resource and a budget cost resource.

image

With my new default (as I only created this PWA site this morning) of ‘Never’ for my timephasded data I find that I have no records in any of my timephased data sets.  This is expected!  I’m showing this in Excel – but you’d see the same just browsing to the OData endpoints under …/PWA/_api/ProjectData.  I see 2 projects as it records the Timesheet administrative dummy plan too too – which also accounts for the 7th Task – and the 6 baselines are for the 6 tasks in this project.  The TimeSet just records the days from 1984 to 2149, and will always be 60,631.

image

I’ll switch to Daily in my reporting granularity settings and republish and see what I see…  and now I have some time phased data – and 828 rows in each of the feeds.  This is a record for each day that has values – and in this snippet I see some costs, actual work and budget cost for one of my tasks.

image

Next I’ll take a look and see what weekly looks like…. and this gives me 120 records for each time phased data set.  One record for each task for each week there is something to report.  The records aren’t in exactly the same order – but you can seer the weeks that are totaling 120 and 80 are those with 16 and 24 hours per day.  The dates the time shows against – such as 9/30/2017 – are Saturdays as that was the day I had set in my regional site settings as the First day of the week.  I’ll come back to ‘week of the year’ later.

*** Update 11/30 - there is a slight change that will likely arrive before you see the feature - any roll-up such as weekly/monthly/fiscal periods - will record data against the FINAL date of the period rather than the FIRST.  Currently as of 11/30 you will still be seeing 'FIRST' as per my screenshots ***

*** Update 12/5/2017 - back to Plan A - all aggregations will list against the FIRST date in the period - as per my screenshots ***

image

Next I’ll go to the Monthly option – and that is Monthly set in the reporting time phased granularity page and not using a Fiscal Period of Monthly.  Here I just have 32 records in my time phased data sets (and they are only matching as I just have 1 assignments per task and the same durations for task/assignment) – with each data item being recorded against the 1st of the month – and we get to see all the rows in one view – with the project summary task being at the top.

image

Now stepping on to Fiscal Periods.  Hey – where did my data go!

image

As it mentions in the Reporting configuration page – “Important: Reporting data will only be generated for defined fiscal periods. Also, if you change an existing fiscal period, you will need to republish all projects.” and as I have no defined periods (see above – my FiscalPeriods feed is empty) so I will need to go and create some.  I’ll define 2017 first on its own to stress the point – and I’ll use the 4,5,4 method.

 

image

Now at this point I discovered a bug of sorts – fiscal periods need to be complete years, and the default for the 4,5,4 pattern leave 12/31 out on a limb…  My Reporting (Project Publish) jobs went down a hole trying to work out what their calendar was and after an hour or so they failed.  We are looking in to it and the fix is easy (once you know what caused the problem – I had a few variables in my plan and hadn’t noticed my year finished too soon).  Not sure if we will address this, but now we are making more use of fiscal periods it might make sense to not allow an incomplete year to be defined.  So once you define the 4,5,4 make sure the final period goes to 12/31- unless you are creating 2018 now too in which case you could start that on 12/31 – whatever works for you.  This same issue can be seen if you don’t have Fiscal Periods defined for the complete duration of your plan – so for example in my case as my plan starts in October 2017 and finishes in March 2018 and my Fiscal Periods start in January – I need to create both the 2017 and 2018 Fiscal Period.  I’m getting some confirmations of this, as the reporting page appears to indicate that you will only get data if you have defined the Fiscal Period – which to me meant that I could ‘choose’ not to create my Fiscal Period for 2018 if I was only interested in 2017 at the moment – so my publish would be quicker and I would use less space and reporting would be quicker (though only for 2017).  However, currently projects will fail (after about an hour in my tests) at the Reporting (Project Publish) unless all the Fiscal Periods you need are created.  I hope to hear that this is a bug.

*** Update 11/30 Confirmed as a bug and we have a fix coming - we will not fail if any missing dates or periods exist.  For example if you only defined Fiscal Periods for 2017 and 2019 then a plan from 2017 to 2020 would only publish the details for 2017 and 2019.  Not sure why you ever would - but that is a good way to describe the behavior you will see) ***

Back to the main story – I have my Fiscal Periods for 2017 and 2018 configured – complete with 12/31 for each year so I publish my project:

image

Now I see 31 rows – 1 fewer than my monthly based report as the pattern of the fiscal periods doesn’t quite match up to the monthly boundaries.  I can see too that I have records coming from my Fiscal Period feed – and also see the Fiscal Period UID in my TaskTimePhasedDataSet for each row (Previously I just saw the NULL GUID (0000000000…).

Time to take a look at some of the other fields new with these changes and lets dive into the ‘Projects’ feed.  We can see for the project which time phased granularity we have from the new field ProjectTimePhased – so this confirms that when this project was last published the granularity was set to ‘By Fiscal Period’.  We cannot tell what the fiscal period configuration is, but looking at the TimeSet feed we could deduce that from the dates and fiscal periods.

image

Towards the end of the field list in the Projects feed we have some more new fields – and these relate to workflow and you can read more about these in the support document at https://lwal.me/4f. In my feed these are unpopulated and I am planning another blog posting where I’ll take a deeper look at these, but you will see that we now expose the WorkflowCreatedDate, WorkflowError, WorkflowResponseCode, WorkflowInstanceId, WorkflowOwnerId and WorkflowOwnerName.

image

With this information we hopefully make it much easier to spot any issues with workflows, and you (The PMO or helpdesk) will be able to proactively see what is happening to workflow across all of your projects rather than waiting for a project manager to come across a suspended or failed workflow.  As I said – more on that in a future post.

So in summary the new options for reporting allow you to considerable reduce the amount of data you might need to access – by 25 times in my example, that is assuming that monthly totals is ok for you – or around 1/6 of the data if weekly is your thing.  And the added benefit not just when reporting on the data but each time you publish too!  You can change these at any time, but you would then need to re-publish all of your projects (or at least the ones you wanted to report on) – so you might also want to look at some kind of automated publish option such as using PowerShell or Javascript.  You can search online for various articles on this – one of my favourites would be Paul Mather’s javascript example.

I’d love to hear back on how you find this works for you and which granularity is best in your scenario.  Or do you think you might change?  Maybe run with Never or Monthly and maybe switch to Daily and republish when you need the deeper granularity?


Comments (7)

  1. Ian Bruckner says:

    This is neat, for sure – I just wish we could keep the old TimeByDay & choose a new roll-up setting. Many of our reports could benefit from choosing a single additional roll-up period, the majority of which are common for us: weekly. Still, though, there are others that go down to the daily level so the lowest common denominator wins.

    Great write up, by the way!

    1. Thanks Ian, and yes it would be nice to have the multiple timescales but that wouldn’t have met the design goals here in reducing publish times and improving reporting speeds. You could of course switch at certain times of the year for more granular reporting. In most cases weekly should be ok – even if comparing timesheets you could validate at the weekly level and then if you need to you could drill in to the plan and compare to the timesheet if there appear to be differences. What do you typically need the daily level for?
      Best regards,
      Brian.

      1. Ian Bruckner says:

        We mostly use the daily to allow roundups to month and year – year to a lesser extent.

        Weekly is used most regularly by our project managers and the matrixed resource/operational managers. This support things like reports based on timesheet submissions and regular conversations on when can we take on new work?

        Monthly is used most regularly by the portfolio manager and our governance group to look at a higher level. While ideally we plot out new projects once a year, this realistically turns into a monthly deal. Monthly… supported by running many scenarios run to prepare for it, intermixed with the need to keep the weekly reports refreshed.

        This is needed primarily because the Portfolio Analysis capabilities of Project Online don’t actually seem to use base capacity for determining capacity for new projects, just counts every resource on a team as 100% (open support case on that, but a summary is here: https://social.technet.microsoft.com/Forums/projectserver/en-US/f62ec380-7eda-435e-b187-fec852d32191/portfolio-analysis-doesnt-seem-to-respect-max-units?forum=projectonline). Should that resolve, we’d be able to use the native functionality of Project Online to display this monthly capacity & timeline view and just move to weekly for reports that use oData feeds.

        Thanks for the interest.

        1. Thanks for sharing Ian – and yes, I can see the daily does give you the flexibility to meet all the other requirements here. I’ll see if I can get a definitive answer on the portfolio analysis scenario too.
          Best regards,
          Brian.

          1. Ian Bruckner says:

            Indications are the reason this wouldn’t work for me (needing to replicate via oData reports the portfolio analysis capability of PWA because it wasn’t interpreting capacity correctly) is now fixed. I’m excited to try it out again and look forward to being able to switch to the weekly roll-up! https://support.microsoft.com/en-us/help/4018336/description-of-the-security-update-for-sps-2016

  2. Pascal Idez says:

    So if I understand right, the TimePhasedData will be aggregated on a weekly or monthly or fiscal period. Which I imagine will make me gain lots of time, nevertheless some of our reports are weekly based (those related to time & effort tracking), other reports are monthly based (those for finance). How will these two needs co-exist?

    1. Hi Pascal, if you really need weekly and calendar monthly then you have two choices.
      1. Continue to use daily – then aggregate as you do now
      2. Use weekly most of the time – then switch to Monthly and republish all your plans when you need to do a monthly report cycle. You could keep this monthly data into SQL Azure maybe and refresh each month so it remains available when you switch back to weekly (and republish). This means that most of the time you will benefit from faster publishing of plans. It really depends on the data volumes involved and if publishing all of your plans again would be a workable solution.
      Best regards,
      Brian.

Skip to main content