It’s time again for another posting from me, David Ducolon, on some best practice use of Project Server. This time I will go in depth about the Administrative Time feature in Project Server 2007.
Before I tell you about what 2007 has to offer and how best to implement and use it, I feel I must first tell you about the history of this feature area.
- In 2002, we introduced a server feature for tracking time on other commitments than just project assignments. This was implemented with “Project Calendar Exceptions” through a process where the team member sent a request to another individual, who had the permissions to edit resource details. This individual then applied the calendar exception to the checked out resource pool. The enterprise resource pool would then be opened and saved from Project Professional before it would be reflected back on the servers’ resource availability information. This addressed the need for customers but for some it was slightly cumbersome. An additional request from customers was to be able to report on this data. That was seen as a must do item for the next version of Project Server.
- In 2003, the next version after 2002 was released. In 2003 we altered this feature and called it “Non Project Time”. The change was significant in that resources needed to be assigned to a special type of project called an “Administrative” project. Calendar exceptions were not an object customers can report on. This allowed full reporting on the time commitments for resources assigned to other non project work. The process was more streamlined with the removal of the enterprise resource pool update. However a publish of the administrative project was still necessary before the time request would be available for viewing in Project Server.
So with the experiences of 2002 and 2003, we took a long hard look at this feature for 2007. I am happy and proud to announce that in 2007, the process was further streamlined, the architecture was extremely scalable, performance out does previous versions and the category type and behavior is fully customizable to meet your needs for planning, tracking and reporting on work other than project assignments.
The functionality is so dramatically different that we changed the name to “Administrative Time”. The setup work requires:
- Customers to create Administrative Categories
- Each category must be marked as “Work” or “Non Work”
- Optionally categories can be set to require a manager’s approval
- Optionally categories may be marked for “Always Display” which places a copy of that category on every timesheet that is used
i) Non Working Time – Time scheduled as project calendar exceptions directly from the user without the need to involve Project Professional. While it still blocks the Project scheduling engine from assigning work to the individual during that time.
ii) Working Time – Time scheduled as virtual task assignments. These are virtual, since they do not reside in any true project file, instead they are simple records in the SQL database. This has the effect of allowing resources to be scheduled in excess of 100%.
Customers may create as many “categories” as they want without any impact on performance or scalability.
Simple Example for Managing Administrative Time Categories
Categories may be renamed, but they cannot be deleted once they have been saved to the database. This preserves the integrity of timesheets. If the category is no longer applicable you must close the category’s status and it will no longer be available to users without disrupting the integrity of the historical timesheets.
HOW TO USE
Let’s now talk about how best to implement and use these options. To begin with I would like you to consider the term “Non Working” and “Working” as terms that mean “Block Scheduling” and “Allow Over Allocation” respectively. With that understood, the first rule to consider is:
Non Working work type should only be used on administrative categories that will be used to plan time off.
This is important since Project does not like to move actual work once established and calendar exceptions cannot allow work to exist during time periods which they are set to occupy. An example of what you should NOT do is as follows:
i) You create a category called “Sick time” and make that non working.
ii) A member of your team comes to work on Monday and works on a task that begins on Monday and goes for two days.
iii) The team member reports that the task is 50% complete. But then the employee goes home sick.
iv) At the end of the week the team member fills in his timesheet and reports 4 hours of sick time on Monday.
Result: Project took the 16 hour task and assigned 50% of the work as actual work reported by the team member on Monday. But the timesheet also wants to place a calendar exception for that day. The team member should only have been able to logically complete 25% of the work on the task. Below are screen shots of what happens:
16 hours of work on Wednesday and Thursday, auto imported from My Tasks, with 8 hours of “Dr. Appointment” (non working time) entered into the timesheet.
After the timesheet is saved, the calendar exception is created. As you can see the assignment to task “Plan 1” seems to have lost the 8 hours of work on Wednesday (2/4). But the total work is still at 2 days with only 8 hours of actual work. This presents a difficult situation for Project to understand.
If all of your calendars and time settings are set to 8 hours for the definition of a day, after a round trip through project all will be fine. However if either the project or resource calendar or PWA setting of a day is not 8 hours, the results will be to reduce the work and to apply 8 hours of non working time.
To avoid this situation I strongly encourage all customers to be very careful when creating an Administrative time category with a Working Type setting of “non working”. Personally I set my server to break “sick” time into two categories.
1. I re-label the standard “Sick” category to “Dr. Appointment” and
2. I create a new category called “Illness” and set the working type option to “working”.
I would expect employees to plan for Doctor related absences in the future or before submitting actual work; which is really the problem. And Illnesses would conversely be submitted after returning to work when it would be reasonable and somewhat common to report the hours away from work after entering actual work possibly on the same day.
This will allow the resource to be overscheduled for Illnesses which will not automatically slip the project schedule and allow planned absences to be entered while not allowing the resource to be overscheduled and if initially planned then the task will slip accordingly.
I hope this has been enlightening and useful. If you find any particular aspect of Project Server that you wish to have explained with best practices feel free to drop a comment on this blog and you may see your suggestion in a future best practice update.