I’ve been racking my brain on this topic for some time now. I believe that I have come to a few legitimate root causes. I am hoping to get some insight on if my root causes are legitimate. If yes, then any thoughts on why it happens and if there is a way to fix it would be greatly appreciated as it is causing a lot of re-doing of timesheets, which is not a favorite of most to being with! Please bear with me in my trying to describe this as I am not an IT person by trade .
I have come to 2 problems that are intertwined. Here is my assessment:
Root Causes of PWA Save function disabled:
At a high level, I have come to the following causes (one has to happen before the other can happen):
1. First, it has to do with a task that spans two time periods. That task gets marked complete on a date that falls into the next time period that hasn’t been opened yet. Resource opens new time period and sees incremental decimal values (pre-populated values) because the system tries to help by adding the remaining hours that are assigned to that now completed task (decimals because it takes hours/days), thinking that the task was worked (very not helpful for us).
o I have instructed resources to delete these values so that it doesn’t skew their actual hours.
2. This than leads to the second and primary problem, which happens when deleting the pre-populated values. My end assessment of why the PWA timesheet save function gets disabled is that the system will not allow you to delete hours that would decrease the value of the work hours assigned (estimated in the schedule) on an already completed task. PWA will error out.
I don’t know how to fix this, but some things we have done:
o Once this happens, one can willy nilly go in add time in hopes that enough hours will be added back in to re-activate the save functionality.
o I can go and find the tasks that cause this to happen and add time back into to those tasks
o Or the resource has to leave the page unsaved and start over.
Primary questions are:
1. Can we stop the pre-population of values in PWA?
2. If not, then how can I fix problem #2?
Thank you so much in advance for any insights. Kerry S.
If helpful, here is some background information on how we use MS Project and Project Online and how we use the information from the systems.
Use Project and PWA in our environment:
– MS Project is used for client project progress updates (using 0% or 100% in the % Complete Field).
– Pre-defined hour estimates are associated with the tasks in MS Project.
– Resources enter actual time into PWA .
– Time Reporting Period in PWA is one-month.
– Using MS Project 2016 and Project Online 2013.
– Use single entry mode.
Primary use of this information:
– Assess the variance between our pre-defined hour estimates and the actuals for the tasks.
o We need to first learn how long things actually take – something that has just never been looked at .
– Capacity reporting and resource availability to take on new work.
o Right now we use pre-defined hour estimates for capacity.
Kerry, as you can see you have a lot going on here. All of that is difficult to fully explain in a forum response, but I’ll try to provide some ideas that hopefully can provide some direction.
1. Using timesheets with integration to project schedules is a complex process. Make sure that you are getting the value for the effort (team members, PMs, Admins). I’m not saying don’t use it, but there are alternatives depending on your goals.
2. You mentioned that PMs update % Complete, which doesn’t match when using timesheets. You have two functions that update actual work, resulting in inaccurate actual work. One function is overwriting the other.
3. When using timesheets with the goal of accurate actual hours in the schedule, you need to set the “Only allow task updates via Tasks and Timesheets” setting in “Task Settings and Display”. This prevents PMs from modifying actual work in the schedule. PMs marking tasks with % Complete is what’s causing the future actual hours issue.
4. Use baselines to pre-define hour estimates. Then use team member updatess and Project to adjust progress.
5. Best practice is to have PMs update time to the schedule, make any adjustments, then “Reschedule uncompleted work to start after:” setting (Project tab, Update Project). This sets up the timesheet for the next week.
6. Task type and effort driven settings are important when using timesheets. Suggest keeping the default Fixed Units and not Effort Driven (you will get others that disagree, but trust me this works).
That’s a high level of what I’m seeing and some changes that will help provide a standard process and prevent the errors you are getting. Good luck, and feel free to ping me if you want additional support (LinkedIn works).
Larry, Thank you so much for your insights. A bit to digest. I’ve been facing challenges with the time tracking implementation process and the subsequent challenges/impacts on project schedules for about 6 months now (almost continuously). It’s just me and I’ve had very little help (just a boat load of research and to some extent trial and error). That’s where these forums come in handy. So thank you again. I sent a connection request to you via LinkedIn and hope to follow-up with you on a few questions. Thanks again.
You are welcome. You are tackling a lot to be doing this without support…but you know that I’m sure. Good luck, and I will help if I can.