*** Update *** See http://blogs.msdn.com/brismith/archive/2009/06/18/project-server-2007-tracking-method-updates-since-sp2.aspx for details of settings changes to see previous behaviour, and http://blogs.msdn.com/brismith/archive/2009/07/16/project-server-2007-office-system-june-2009-cumulative-update-is-now-available.aspx for the CU details that reverted to the previous behavior for Activity Plans and Proposals.
Sometimes we fix bugs and then find that customers had been relying on the “broken” behavior. I have covered this topic in some comment postings to the Service Pack 2 article but thought it worth a full posting to help customers understand why they are seeing different behavior.
In the Infrastructure Update we introduced a timephased grid for task time tracking. Most customers thought this was a great thing – but it did introduce issues in that Project Managers who had specified a project tracking method of % Complete and remaining work could no longer enforce this method – the timephased grid was a back door to “hours per period” statusing. So we fixed this in SP2 so that Project Managers could once again control how task time was entered.
How does this affect Activity Plans and Proposals? These server-side, or Light Weight Projects, as they are sometimes called, have certain limitations; only 100 tasks, only one assignment per task and also only one method of task statusing – which is % Complete and remaining work! This cannot be changed or over-ridden. In fixing this issue for “real” projects the fix also applied to all projects with this tracking method – and included Activity Plans and Proposals.
Now we are finding that between the IU and SP2 many customers were enjoying the ability to enter timephased data against these server-side projects. As always, I’d love to hear your comments.
Thanks to Laksh for his suggestion to make a full posting, and Ville for raising my awareness via comments to my blog.
This is a major disappointment. One of our enterprise customer's entire lifecycle is dependent upon recording actual hours. I don't know any org that is doing resource allocation that would use % complete, so the logic behind this escapes me. This has caused enormous grief, and we have to now reinstall servers because of it. I cannot believe that the team would be so cavalier in doing this and not realize the issues it causes.
Also, I do not understand why after converting it to a full-blown project, you still can only log % complete. That violates the entire 'force project managers to use tracking method' logic. Sorry to be so curt, but between the moving actuals problem (which we experienced over a year ago) and now this, I'm really lost as to the rationale of the team on some of these things.
There have been quite some confusion about lightweight projects and the trackingmethods, so it is totaly understandable that organizations that want time entered/reported on dayly basis, but still want to enjoy the freedom to create plans/tasks adhoc; would have enjoyed the possibility to have timephased tracking.
This is even more interesting if the default tracking method in pwa states that it should be hours done per day, this is totaly ignored by lightweight projects as you state. The question is where this have been documented?
In a consultancy organisation that do many short activities, this behaviour of having % complete as the "only" Tracking method have limit them to not use proposals, even though it would have been the easiest way of setting up the plans.
And ofcource, then we have the bug with the converted proposals, that still have % complete as tracking method even though pwa states something else.
To sum. The issue here is not that you changed the behaviour, the issue is that you don't allow the customer to decide what behaviour is the best for them.
Hi Michelle and Robert. Thank you very much for this feedback. We have been reviewing this behavior and are currently considering a reversion to the behavior our customers having been enjoying between the IU and SP2.
I will review Michelle's point about converted projects.
Thanks again and best regards,
Wow. I'm SO happy i did not recommend that our infrastructure team deploy SP2 to our Project Server 2007 environment... We're using Activities to track time spent on ongoing operational tasks for long term projects (3-7 yrs in duration) in our data center - % complete in that scenario makes no sense whatsoever, and being able to do time-phased time entry for Activities is crucial for that kind of tracking.
Please, please, please, please PLEASE turn that into a feature! feel free to contact me if you need any further elaboration on our use case.
I may need some clarification? We are not using activity plans at all, though we have been using the time phased grid regularly. We track actual hours and remaining effort as our status methodology, and ask resources to enter their hours onto the time phased grid throughout the week and then build their timesheet at the end of the week - rather than "Import timesheet" data. Can one no longer enter ANY hours into the time phased grid for ANY sort of project?
The ability to track by hours is a long-standing desire among users. It makes activity plans much more useful as they can pertain to hours-by-day environments. Otherwise one has to use regular projects for this purpose.
No problem using the timephased grid Michael for projects where the project manager has set the tracking method to hours per period - just if the PM says % Complete then this shouldn't allow daily time entry. Just change the setting and re-publish the projects if you want timephased and can't currently. This only applies to full projects - not activity plkans and proposals.
And Gary - I hear you. Hopefully we will revert this fix as it relates to Activity Plans soon...
I posted a short while ago about this topic , but wanted to make clear how you can continue working with
The ability to enter timephased data against activities indeed seemed a little awkward because even after doing so (through the "back door") there was no convenient way to pull this timephased data. As oppose to regular project, which in "Resource Usage" view could show the timephased data captured from PWA, in activity plan there was no way to see this information. If I wanted to know how many hours were submitted in April by the project team, I couldn't do it, unless I went to "Resource center", checked all project team members, clicked "Resource Assignments" and chose April date range (It was possible to create a view grouped by project instead of by resource for this purpose). So, if the development team consider to bring it back as a feature, please add a comfortable way of retrieving the timephased data. And speaking of activity, How can the project manager change a task in activity to be 100% complete? This columne is grayed out and it seems like only the resource can change the %complete... (or remaining work, if using the back door...)
I have installed SP2 and now none of my users can edit tasks in TimePhased grid.
Users cannot enter time for task by day. However user can modify the Remaining work. I have checked Task Settings and the option "Actual work done and work remaining. Resources report the actual work done and the work remaining to be done on each task." selected.
Not sure how to face my users now.
This is so irritating....
To allow entry of hours into My Tasks in time phased view you must do the following:
a. set "Tracking Method" under the "Task Settings and Display" page to "Hours of work done per period. Resources report their hours worked on each task per period."
b. republish you project
We just installed SP2, so I am just now becoming familiar with this issue--one of my resources brought it to my attention.
I would like to register another vote for allowing timephased work entry against Activities. It really makes sense in our IT environment--all of our time is tracked and timephased entry was a great fit.
This would have been a great feature to enter timephase information against activity plan (Specially operational tasks)