Time Management System

Time Management System child topics: Use Cases?

· Time Management System

o Introduction

o Terminology

o Use Cases

§ Actors

§ UC1: Configuring

§ UC2: Processing

§ UC3: Reporting

o User scenarios

o Architecture

§ Design Discussions

§ Design Assumptions

§ Context Diagram

§ Configuring Change Management Applications

§ Configuring

§ Approver Role

§ Approval Policies

§ Processing Timesheets

§ Timesheet work flow

§ Reporting

§ Timesheet summary report

§ Timesheet details report

§ Missing Timesheets report

§ Rejected Timesheets report

o Data Model

§ Note: The resource here are work in progress.

§ Service

§ ${Resource}List

§ Connection

§ Project

§ Team

§ ApproverRole

§ ApproverPolicy

§ Timesheet

§ TimesheetHistory

§ ProjectTimeSheet

§ TimeRecord

o Reviews

§ 20101020

§ 20101108

§ 20101116

§ 20101118

§ 20101119

Introduction

Time Management System (TMS) tracks and manages the time spent by resources on various projects activities categorized by time codes. Timesheet application collects the time records from time tracking change management systems and mange them as time sheets.

Time management broadly includes,

Time Sheet life cycle management (new, submitting, revoking, approval and rejection)
Generating appropriate reports on time spent details

Terminology

· Rational Project Conductor (RPC) - Project management solution from IBM Rational , in this context RPC 3.1

· Change Management Application (CM) - An application that manages software changes.

· Managed Application (MA) - Any change management application which supports time tracking capabilities. Eg. RTC

· Time Management System (TMS) - The application that manages time spent in project activity by getting the time entry records from various change management applications.

· Time Record (TR) - A record contains details on daily time spent per person, on a work item by time code. CM are the source of Time Records

· Timesheet (TS) - A combination of of all the 'time records' entered by a Team Member over period of time

· Project Timesheet - Project wise grouping of time records in a given Timesheet. Enables project wise approval of a Timesheet.

· Time code - Time record attribute for categorizing time records based on different activities, like coding, testing, training etc

Symbol / Description
Not scoped in for RPC 3.1 2010Q2 release
Review comments addressed
Warning
Request for comments
Note
Information or Help

Use Cases

Actors

· Administrator: Team Member with administrative privilege to TMS

· Approver: Team Member with Timesheet approval rights. Typically project manager, team lead, resource manager etc.

· Team Member: User with author and submit permission for Timesheets

· Viewer: A Team Member or a System with access to all time data across projects, business units or organization either for reporting or for accounting. (Eg. Reports, Billing)

UC1: Configuring

· Administrator configures change management systems as time-record sources (Eg. RTC, CCM, RQM, Bugzilla, JIRA)

· Administrator configures the approval roles and policies

· Administrator configures the Timesheet period (default one week)

· Approver delegates Timesheet approval rights

UC2: Processing

· Team Member shall create or update time-records on CM for new Timesheets

· Team Member shall submit a Timesheet

· Team Member shall recall a submitted Timesheet

· Approver shall (partially) approve submitted Timesheets with optional note (Project Timesheet).

· Approver shall reject submitted or (partially) approved Timesheets with optional note (reason for the rejection)

· Team Member shall create or update time-records of rejected Timesheets

· Team Member shall not update time-records of submitted or approved Timesheets

· Timesheets that are ready to be consumed for billing shall be given 'Final' state.

· Fine Timesheet content are frozen for good.

· Should there be any modification to Final Timesheets can be handled thru new additional 'Corrective Time records/sheets'

UC3: Reporting

The following time management reports shall be generated by the system

· Timesheet summary report

· Timesheet details report

· Missing Timesheets report

· Rejected Timesheets report

User scenarios

· For the week of Jan 3,2010 Team Member Ashok has worked on WI 101 of 'Online Action' project and WI 201, 202 of 'Smarter Planet' project.

o scenario 1: Ashok has entered time records for all the three Work Items ( 101, 201 & 202)

o scenario 2: Ashok has entered time records for only WI 101 and WI 201 and did not enter time record for WI 202

o scenario 3: Ashok has not entered any time records for any of the three work items.

· Ashok creates a Time sheet in RPC for the week of Jan 3, 2010

· Ashok sees the already entered time records ( 3 for scenario 1, 2 for scenario 2, and none for scenario 3) as part of newly created Time sheet.

· Ashok also sees the suggestive list of Work items ( none for scenario 1, WI 202 for scenario 2, and WI 101,201 & 202 for scenario 3) that he would've worked during this period on but didn't not enter Time records.

· Ashok creates the missing Time records.

· Ashok now sees all the Time records (WI 101, 201, 202) displayed under the newly created Timesheet.

· Ashok finalizes the Time sheet and submits for approval.

· Mahesh, one of the approvers of Online Auction approves Project Timesheet, with that Time sheet is considered as partially approved

· Sudipto, one of the approvers of Smarter Planet approves other Project Timesheet and now Time sheet is considered 'Approved'

· Rejection from either one of Mahesh or Sudipto means the Timesheet as a whole is rejected, even the other one has approved it

· Viewer Bala consumes 'Final' Time sheet details for Billing or Accounting purposes

Architecture

Design Discussions

1. Time Tracking@CM is mandatory or not?

There are two ways in which TMS can be designed based on where the Time tracking operation is being done. Time tracking can be done either at TMS side only or at CM only or at both the places. Current design assumption is that Time tracking to be done at CM and also enable Time tracking to be done from TMS side as well. This topic discusses and weighs both the approaches.

Time tracking @ CM is mandatory to enable TMS / Time tracking @ CM is NOT mandatory to enable TMS
Developers entering time records get persisted into CM's repository.
Later TMS sync up wiht CM's repository / Very first time TMS extracts all the CM's Time records of configured projects and disable CM's time tracking capability (RM Model)
Herein after all the time tracking records are stored at TMS repository only
Team Members@CM enters time records using CM's native UI / Team Members@CM enter time records using TMS time entry UI thru CALM links (embedded UI)
Team Members@TMS enters time record using TMS native UI / Team Members@TMS enters time record using TMS native UI
Sync-up required between CM & TM repositories / One time effort later TMS will be the only repository for Time records
CM system have to have Time tracking / CM system having Time Tracking is optional
Conclusion: TMS shall be implemented in a phased approach.
Consuming Time tracking from RTC is mandatory for first cut. In long run the time tracking records can be in TMS
Phase 1: TMS shall not aware of any CM application
Phase 2: TMS shall be aware of WorkItem? of a CM application
Phase 3: TMS shall be aware of WorkItem? and Timetracking and jointly work with CM Application thru REST API
Phase 4: %ICONURL/{stop}% TMS shall be aware of Work Item and Time tracking and Time tracking @ CM is done thru delegatable User Interface

2. Linked vs Stored data?

Time records are @ CM repository. There are two ways in which TMS could function.

Time records are only at CM repository and TMS access Time records@CM thru links
TMS makes copy of time records@CM repository and sync up at appropriate times

Conclusion: Approach is to have both Linked and Stored data

Design Assumptions

This section lists all design assumptions we've made while designing TMS.

1. CM Systems have to have Time tracking capability

· Each change management systems have to have time tracking capability implemented.

· Each change management system should implement the REST APIs described by TMS for the integration.

2. One interface for all Time management operations

· Team Member should be able to perform all time management operations for change management systems that are with time-tracking capability.

· The operation are time records creation @ change management system, timesheet submission, approval and reporting.

· For time-records creation, the system shall provide suggestive list of work items on which Team Member would have spent time on, based on code checkin, assigned active workitems, workitem state transitions or workitem update by a Team Member.

3. Time record to Timesheet mapping

· A Time record is created to store time spent by a single Team Member for a given period of time on a work item for a type of activity(time code),

· All time records by a single Team Member for given period of time (generally a week) across all the projects, is grouped together as one Time sheet.

· A Timesheet may have time-records by a Team Member from two or more different projects. Eg, Team Member Ashok worked on both Online Auction and Smarter Planet projects for the week starting 7-Nov-2010.

· Project Timesheet is project wise grouping of time-records of a Timesheet's time records for approval convenience.

4. TMS working when CM offline

· TA shall have private repository and store time records pulled from various CM systems * TA shall have appropriate refresh mechanisms to update local data as the source data change.

· Having private repository enables reporting and querying the approved time sheets even the CM are disconnected.

· However for approval/submission operations the CM applications needs to be connected and running.

Context Diagram

The following context diagram illustrates the system environment in which TMS functions also show the high level system interactions in a TMS environment.

· TMS is a jazz fronting application and is a part of Rational Project Conductor(RPC) product solution

· TMS shall be configured to work with CM systems with Time tracking capabilities

· For RPC 2011, the scope is to support RTC 3.0 WorkItem? application as Time record store.

· TMS can work with other Change Management applications like Clear Quest, JIRA, Bugzilla as well, provided REST APIs described by TMS are implemented at CM side.

Configuring Change Management Applications

As a very first step, list of change management Applications ought to be configured with TMS. The following diagram show the high level sequences of operation to be done by administrator as part of Configuring Timesheet Application.

Configuring

At a high level, for each Time management application setup, a Connection List which contains list of the Change management applications configured to receive time records from. Each entry of Connection Directory, Connection expected to have the connection details about each of change management application including how and from where the time records can be received from.

Connection may have the following properties,

· Repository connection details (http://rtcserver/ccm)

· Connection methodology (OAuth keys)

· List of projects definitions (For RPC, Sub-projects {project area, release plan})

· Timesheet retrieval details (time sheet collection URL for each project)

Do we've have to pull all the time-records, or the time-records of RPC configured projects alone?
PRC's Sub-projects configuration can be leveraged to construct Connection Directory?

Approver Role

The section describes how the approval role is defined in Timesheet Application.

· Approver role is specific to TMS, not in CM's scope.

· Different CM applications may have different roles defined within ( Agile [scrum master], Traditional[project manager, team lead] project areas)

· Administrator configures selected (role and process specific) CM roles with time-record edit permission as ApproverList for project and sub-projects levels

· Alternatively RPC's user mapping can be leveraged for Approver role mapping.

· Every logged in Team Member assumed to be timesheet user, however operations like, updating time-records, submitting time-sheets are subjected to permissions back in CM applications

· *Approver*'s scope can be at Project/subproject/team levels or at a Resource group level

o Projects/subprojects/Teams level approvers can approve time-sheets filed against the project/sub-projects by any resource

o Resource level approvers can approve time-sheets filed by member of resource pool against any project.

Approval Policies

Approval policies are collocation of rules established for performing time sheet approval task. Approval rules defines the approval process for a given project.

Approval rules include

· Levels of approvals (one tire or multi-tire?)

· Number of approvals (how many approvers required at each level?)

· Order of approvals (who get to approve first?)

Approval policy may differ from project to project based of the process being followed.

Here's an example of an apporval policy: For approving Online Auction project time-sheets, there ought to be 'one' team level approver and 'one' project level approvar required in the same order.

Though this resource provide support to specify such elaborated policies, For RPC 3.1 release, the scope is to implement *One approver" policy.

Processing Timesheets

Time sheets are collection of all time records entered by one resource(person) over period of time (week) across all the projects. Time records of a Timesheet are grouped by project called Project Timesheet for project level approval. Following class diagram shows the relationships between Time sheets, Project Timesheet and Time Records.

Change management systems are the sources for time-records and the time records are expected to be exposed thru REST Api. Time code attribute of time-record denotes the type of the activities on which the time is entered, which helps in categorizing the time for accounting purposes.

The life cycle of time sheet can be more understanding if we see the life cycle of Project Timesheet and the Time sheet itself.