Forum Discussion

Alison Howes's avatar
Alison Howes
Copper Contributor
Jul 06, 2023

Using Timesheets in PWA but how to prevent changes to forecast

Hello Guys, 

 

I have a customer that is using Project Online. They are using Timesheets for capturing actuals and they want those actuals to be reflected in the original project. However they do not want the forecast to be updated in the Project plans  - they want that to remain as it was irrespective of the actuals. What's the best way to achieve this ?   Its vital that their forecast remains "intact" after timesheet updates are processed. They may well update the forecast manually but that will be up to the PM. Grateful for suggestions.  Many Thanks.  

5 Replies

  • RatanPushp's avatar
    RatanPushp
    Brass Contributor

    Alison Howes 

     

    Better to set baseline in a project to keep forecast intact and rename baseline columns. After timesheet submission, the actuals and forecast can be referred.

     

     

    Hope this helps you!

     

     

  • Alison --

    I feel for you, my friend, because what your client is requesting is NOT the default behavior of Microsoft Project and Project Online (or Project Server). After approving task updates, the next time that the PM opens the project, he/she will see updated actuals AND an updated forecast for the future. This behavior is automatic and there is no way to stop or turn off this behavior.

    As kindly as you can, I would recommend you explain to your client that the behavior they are seeing is the behavior they NEED to see. Hope this helps.
    • Alison Howes's avatar
      Alison Howes
      Copper Contributor
      Hi Dale,
      Thanks for your reply but I don't understand why you would say the default behaviour is what they NEED to see. It isn't. What they NEED is what I already outlined, and I understand what they are asking for. The fact that Microsoft Project doesn't behave in this way by default might well be the problem. The client is quite happy for actuals to get updated in the Project, but automatically adjusting the forecast as a result is definitely not required behaviour. The fact is that irrespective of history, the forecast should remain intact, unless the PM manually changes it. Turning off auto-calculation seems to go someway towards a possible solution, but I am still testing. 🙂
      I get where you are coming from of course. But that's not what this particular client needs!
      Thanks again.
      🙂
  • RodFromm's avatar
    RodFromm
    Iron Contributor

    Alison Howes We do something very similar to this. It's not the most elegant solution, but it's robust and relatively simple. Each project is split into two WBSs, one for a minimal number of time reporting tasks and the other for forecasting/planning tasks. The time reporting section is straight forward, but we do keep the number of time reporting task to a "meaningful" level (very subjective). However, the forecasting tasks have a different process to following:

    • Resources are assigned to tasks that are setup on a monthly basis.  This allows you to assign resource to task for the months they work, and you can adjust the allocation % from month to month as needed
    • No time reporting on these tasks....ever
    • Never status or mark these tasks as finished.  We also setup them up as manually scheduled tasks to help prevent them from being accidently updated.
    • Baselines - We don't use them, but may in the future.  We've used them in the past, but baselining processes tend to get complicated and time consuming, especially when your org has many projects (we have several thousand projects active). 
    • Users can view the rolled up forecast numbers within the plan, but this data is pulled with Power BI and we a set of reports that compare the Actuals vs Forecast (remaining) by work (hours or FTEs), costs and the values can also be displayed as %.

    The process also allows for the forecasting to be done in a separate project, for example at a program level.  This is done when the user has a lot of smaller projects and it's just not practical to setup forecasting tasks in dozens of projects.  When done this way all analysis is down in Power BI.

    As mentioned earlier, this is a pretty simple solution and may seem arduous, but in the all the years I've been doing this, it's the only method that has been widely adopted, which I believe is contributed to it's simplicity.  However, I'm always looking for better solutions and look forward to seeing how others tackle this. 

    • Alison Howes's avatar
      Alison Howes
      Copper Contributor

      RodFromm Thank you for the response. I will experiment with your suggestions and see how it works out. 🙂 

       

Resources