Improved Time sheet

    1. Improved Time sheet
      1. Initial Design Notes
      2. Scope:
      3. User Stories
      4. Requirements and Defintions
      5. Model
    2. Comments and current status by SACHIN
      1. Current (now old) Handling:
      2. Initial TODOs:
      3. Current handling of Timesheet object
      4. Proposed De-coupling of Task and Assignent
      5. Thoughts on the UI design for timesheet entry
      6. Functionality changes impact on task module
Scheduled for Release: v8.3 and v8.4

BFD#:

Status: In Design

Staff: Sachin

Work: 6w?

As of v8.2, the project.net timesheet feature only allows the user to report work complete against tasks assigned to that user. Additionally, the timecard is tightly-coupled with the task on the project schedule. This coupling can cause unexpected results when a task's work complete is changed.

The timesheet should model a resource's (person's) report of time they spend working on various activities during a time period. Over the next couple Project.net releases, we will improve the functionality for users to view their assignments and create timesheets to report their work. The concept of creating a timesheet rather than continuously entering work complete against tasks simplifies the users interface and better models reality. For example, the user no longer needs to enter negative work to correct a timesheet entry, they simply correct that entry on the timesheet.

The new timesheet concept will also allow us to add invoicing features in the future.

Initial Design Notes

Team members would need a way to centrally update their work complete on tasks was they do work during the week.

Otherwise project schedules/Gantt chartss are only updated when a timesheet is submitted. Perhaps we leave the existing functionality (with minor UI changes) for viewing assignments and entering work complete against those assignments. Then add the concept of creating a timesheet to formally report a user's work. When the user creates a timesheet, that timesheet might automatically be filled in with tasks/work they updated since the last timecard was created (or for updated during the time period the timesheet covers). The user could then add additional tasks or non-task categories to the timesheet and fill in all the hours.

We would also like each project.net user to have a personal blog where they can enter text status on a daily basis. This feature might be located on the Personal-->Assignments page. This blog is different that the user's text status that might be included on a timesheet.

Scope:

Phase 1 (v8.3) Scope:

  • Change timesheet "capture work" behavior to only advise a task's work complete. A tasks's work complete can later be changed without affecting or changing the timesheet entry.
  • Add the ability to capture work against simple non-task "categories" defined at Project-level.
  • Keep interface similar to the current interface.
  • Add the concept of "creating a timesheet" for a date range (week only).
  • Add the concept of "submitting" a timesheet for approval.
  • Add simple timesheet approval by only allowing Space Administrator to change timesheet Status to "approved".
  • Limited to weekly timecards starting on Sunday.
  • Allow timesheet entries for activity categories defined at the project workspace level (i.e. meetings, customer support, training)

Phase 2 (v8.4) Scope:

  • Improve Personal-->Assignments page to allow the user to display non-task assignments (i.e. certain types of forms).
  • Allow timesheet entries unassigned tasks (tasks for assigned to the person. i.e. the helped out).
  • Allow timesheet entries for Forms that support assignment (i.e. BFDs, Issues, Action Items).
  • Allow configurable timesheet period (weekly, bi-monthly, monthly) and starting day (Sunday, Monday, etc.).

User Stories

A user of the project.net application may optionally report work they have done on various activities for various projects. The user "creates" a timesheet for a time period (usually a week). After creating the timesheet, the user selects one or more Tasks from their Assignments page and adds those tasks to the timesheet. Then they enter the hours they worked for each task and each day (similar to the existing timesheet page). The user may also add a non-task entry to his timesheet by selecting a non-task category created by the project space administrator. Users can view only their own timesheets. Users can view all their previous timesheets, but can not make changes to their timesheets once they have been "submitted" for approval.

Once the user has completed adding items to their timecard and entering the day and hours worked for each activity, the user changes the status of the timecard to "submitted" to submit the timecard for approval. The project Space Administrators can view all timesheets from all members of the project. The Space administrators can view timesheets by date, and status. A person can only submit a timesheet for himself.

The project Space Administrator can add non-task categories to a project workspace. These categories might include things like "meetings", "customer support", "travel" that the user spent time doing, but were not planned as tasks. These categories can be used on timesheets by all users of that workspace. Only a person in the Space Administrator Role can change the timesheet status to approved.

  • User enters time worked against a task assigned to them
  • user enters time worked against a task not assigned to them
  • user enters time against an non-task (unscheduled activity) such as meetings, customer support, etc.
  • User enters time against a project.net form record (i.e. BFD)
  • The user can enter negative work for a task-day up to the amount of positive work for that task-day. Time for a task-day can never be less than 0.
  • The entry of time worked against a task should only advise that task's work complete.
  • The time entered by the user shall not be changed when the task's work complete or percent complete is changed.
  • The work entered by the user on their timesheet can only be changed by the user or the workspace administrator from the time card interface.
  • Reports -- For time tracking, a summary of logged times per resource/week.

Requirements and Defintions

  • Activity -- is something that consumes time or resources (something that people spend time doing). An activity may be planned (such as a task) or unplanned (such as investigating a newly found bug). A task is one type of activity. We will focus on tasks first.
  • Work Entry -- The user can record actual work they complete for various activities. The activity may be associated to certain Objects (tasks, forms) or simply entered as a text description. This will be similar to the existing project.net "Capture Work" interface.
  • Assignment -- A user (resource) can be formally Assigned to certain types of objects in the project.net ppplication. Currently Tasks support assignment. In the future, Forms and other objects may support formal assignment.
  • Some activities may be formal Assignments to the user such as Tasks (and Forms in the future).
  • The user shall be allowed to record work against an activity (i.e. task) whether or not they are assigned to that activity.
  • The user may enter any amount of work for any activity, even if that entry exceeds the total work for that activity. It is up to the underlying activity to decide how to deal with the advice.
  • Work Entry Constraints -- The user should never be allowed to enter work that would cause their total work entered to exceed 24h per day. There shall be no constraint on the amount of work entered per week (other than 24h*7d).
  • Scheduling Engine -- Except for decoupling activity reporting from the task, we don't want to disrupt the behavior of the scheduling engine. Task calculations should still all work the same.
  • A task's work complete should be updated when the task receives work entry advice from a user that is a resource worked on that task. Updating work complete should not distibute the delta work among its assigned resources.
  • A task's un associated work complete -- If a user is assigned, does some work, and is unassigned the work that the user completed always belongs to the user. If there is 8 hours of work, you do 2 hours and unassign yourself there is only 6 hours left to do.This field is a denormalized place where that work lives. Without this field the remaining assignees would have 8 hours divied up between them instead of 6 hours. In the current design we have to reduce that 2 hours of work from task work complete and put in the task un associated work. This handling was needed as in new design we don't upadate the task work and work complete if an unassigned resource does some work on that task. Only assigned resource work and work complete gets added to the task work. So when the user gets un assigned this work is subtracted so that it can be added again if that resource is reassigned to that task.
  • A task's un allocated work complete -- The amount of work that have not been allocated to someone working on this task. This amount comes into existence because the project admin manually upadte the work complete or work % complete for that task by modifying it.

Model

Activity
what the resource spent time doing. An activity might be an assigned task, unassigned task, meeting, customer support, etc.

Timesheet
models the amount of time worked by a resource in a specified time period broken down into hours per named activity per date. The timesheet is an auditable financial record of time worked by a resource. The history of all changes to a timesheet should be saved. The changes in timesheet status over time and who submitted, approved timesheet might be modeled as a "TimesheetChangeHistory" rather than included in the Timesheet.

The timesheet is a collection of "TimesheetEntries" for a resource and a date range. Properties of a Timesheet might include: 

Resource (that is reporting time worked)
Start date (of the timesheet period)
End date (of the timesheet period)
Status (incomplete, submitted, approved, etc.)
Date submitted (date the resource submitted timesheet for approval)
Approved by (person who approved the timesheet)
Collection of TimesheetEntries
Comment (a long text “status report”)

Timesheet Entry
contains the amount of work a resource performed on named Activity (task, unplanned issue, etc.) on a single date. This as of now would be inherited from the WorklogEntries of an Assignment. Properties of a TimesheetEntry might include: 

Activity (reference to task, form, etc.)
Date worked
Time worked
Billable (Boolean)
Labor rate (the cost/hour for the resource on this entry)
comment

Timesheet Configuration
(part of phase 2)
contains the properties that define the timesheet behavior for all users of a particular project workspace. Properties might include: 

Time period {weekly, bi-weekely, monthly}
Time period starting day {Sunday, Monday, etc.}
Allow changes after submit?
Allow changes after approval?

Form Assignment
(part of phase 2)
In the future, we should allow objects other than task to be formally assigned and tracked like Tasks. Any project.net object could be made assignable by using the Assignment interface. Forms may be trickier due to their dynamic nature. In order to make Forms assignable, we could add an "assignment field" which is a meta-field containing all the HTML fields required for an assignment (such as assigned-to, due-date, work, etc.). Or we could add a new option on a form designer page where user indicates whether the form is "assignable".

Perhaps we need well-desinged java interface classes for Activity, Assignment, Work Entry Advice, etc.

Comments and current status by SACHIN

Time card module is intended to replace/enhance the current capture work feature for tasks.

Current (now old) Handling:

  • Currently work complete is managed in PN_ASSIGNMENT and PN_ASSIGNMENT_WORK.
  • Db schema wise I feel that these two tables are sufficient to hold the details of the time card entries.
  • In the File AssignmentFinder? we actually link up the work with the task by actually doing a join with PN_TASK table.
  • Next the assignments are encapsulated in the Assignment class which are sub classed based on type of object one is capturing the work for. Like for Task with would be ScheduleEntryAssignment.
  • Class design is good in a way that if we want to capture work for a new type of object we simply need to sub class that Assignment.

Initial TODOs:

  • Add the ability to show the meeting time. It currently shows in personal activity metrics. (done)
  • Need to attach a time card feature seamlessly with the form designer. Current thought is that in the first page of the form designer a check box would come, checking that would include time card related fields and links to the assignment work table(s). (part of phase 2)

Current handling of Timesheet object

Creating a timesheet object.

  • On Clicking the Assignments link on the personal nav bar user would be taken to the assignments page.
  • He would then click on "Create Timesheet" icon on the tool bar.
  • In the create timesheet page there would be a header section which would contain the timesheet data like start date and end date (as per the timesheet model).
  • It would also contain the listing section which would be same as the capture work page where list of activities worked for that date range would would show up.
  • There would also be a (+) icon in the header section, where he can create adHoc activities, which would be appended to that list on the fly. These would be the new unplanned activities.
  • He may enter work times against these activities. Once this is done he can click on create button which would create the timesheet in the "draft" stage.

Note:

  • One would be allowed to create only one active timesheet for a given date range. To create another for the same range the previous one would need to be canceled
  • Once the timesheet is submitted or approved the activities associated with that timesheet would not be allowed to update work hours against them for those dates, from anywhere in the pnet application.
  • Further once a timesheet for that date range is submitted or approved no work can be captured for any other activity for for those dates, from anywhere in the pnet application.

Updating a timesheet object.

  • In the same assignment page there would be a link "List Timesheets".
  • Clicking that would take one to the timesheet listing page where list of timesheets along with their state would be shown.
  • Clicking any one would take one to the timesheet details page which would contain the header section and also the listing section which would show the activities that belong to the timesheet.

Note:

  • Header section would be always be in read only state, and for draft timesheets there would be a submit button to submit the time sheet and a back button to return.
  • Timesheet with draft status would have their listing section editable and would use the same page as in the listing section of the create timesheet. This is same as the capture work page.
  • Timesheet in submitted, approved, and rejected state would also have listing section but in read only.
  • Cancel action would be similar to the soft delete in the pnet application.
  • Timesheet in submitted state would have approve or reject button if the user viewing is the space admin (or has the power to approve or reject the timesheet).
  • Timesheet in approved state would have no buttons but just an optional approved message filled by the person approving the timesheet.
  • Timesheet with the rejected state would have no buttons but a message stating why it was rejected which would be filled by the person rejecting the timesheet.

Proposed De-coupling of Task and Assignent

  • First step of decoupling we would have to remove the query join of tasks and assignments. (done)
  • Next in ScheduleEntryAssignment one stores the data of task like totalWork, totalWorkComplete and taskPercentComplete. Since we are decoupling the time card from task object these fields would go away. (done)
  • In the AssignmentAdder, AssignmentRemover and AssignmentModifier for task we re distibute the work complete. As part of de-coupling this would go away. (done)
  • Changing the work complete, work % complete or % assigned or adding, removing resources for a task should not alter the work entries of assignments. (done)
  • Further we would need a mechanism to correctly store the un associate and un allocated work for tasks. (done)

Thoughts on the UI design for timesheet entry

  • UI feature wise "capture work" is OK. Timecard entry would also have same UI.
  • To make it as per the user story we would have to decouple it slightly with the workplan. This would make certain fields in the list view to go away.
  • The assignment types would contain a drop down of: Task, Meeting (Including calendar events) and Forms where when designing those forms user had checked the timecard feature.

Functionality changes impact on task module

  • Further we might have to study the change/impact in some of the reports like Work Completed Report, which picks up the data from the assignment work log and also the schedule entries.
  • Further it should be noted that task data encapasulated in ScheduleEntryAssignment object is used in our scheduling engine to perform scheduling while assigning, removing or altering the resource object or changing some of the task data. Since this data would be gone due to de-coupling as discussed above we need to study what would be the potential impact on the scheduling engine and how much of that we would have to re write keeping in these changes in view.
  • Scheduling Engine improvements are discussed here