While migrating to the application with discrepancies in the existing task plan, you may get failure messages when trying to check in your project plan from MS Project (MSP). You may perceive it as some kind of error/defect. However, these validations are consciously added with a clear vision of avoiding any scenario that may lead to the integration of inconsistent data in the system. Users need to perform this one-time activity of correcting their old data for true results.

To ensure a smooth transition, the validations will ignore closed allocations i.e., the resource that has concluded on the task and marked it as ‘Completed’. These validations will apply only to the in-progress tasks.

Terms Used in the Document

  1. The ‘Actual Start’ referred corresponds to the first day when the effort is tracked for a task by the resource in the timesheet, which may or may not is approved.
  2. The ‘Actual Effort’ corresponds to the resource’s total approved timesheet effort logged for a task.

About New Validations

Whenever an MSP project is checked in, the enhancements will validate the following two conditions for each task/resource:

  1. Condition 1: The Start date indicated in the application’s timesheet is earlier than the Planned Start Date of the task as seen in the MPP.
  2. Condition 2: The application timesheet-approved efforts (or work) are greater than the work for the task in MSP.

If any of the above conditions are met, the Checkin operation for the project/task plan will result in a Checkin failure. You will be notified with the details of the task/resource and the corrective action using which you can rectify the data and check in the task plan, again.

Condition 1: The ‘Start Date’ indicated in  the application timesheet is earlier than the ‘Planned Start Date’ of the task in MPP

The Checkin failure mail is sent when discrepancies exist in the task plan that you are trying to checkin. The Checkin Failure mail contains the possible causes of failure and suggestions on how you can rectify the data for the task and resource. A sample Checkin Failure mail is shown below.

 Note: Both the Approved and Unapproved timesheets are considered during Checkin validation.

Following are the scenarios that result in data inconsistency and hence this validation is added to the Checkin process.

Scenario 1: Actual Start Date is changed in MPP after the Timesheet was approved for actual hours logged in the application.

  1. A task T1 has been assigned to Resource A with a planned start date of 01-Dec-13.
  2. Resource A starts working on task T1 from 01-Dec-13. The effort has been logged from 01-Dec-13 to 10-Dec-139 and timesheets are approved for that duration.
  3. Now the PM checks out the plan in MPP. The task T1 is seen in MPP with the Actual start date as 01-Dec-13.
  4. The PM decides to postpone the task and so changes the planned start date to 07-Dec-13 in the MPP. Due to this the actual start date also shifts to 07-Dec-13 in MPP. (According to the MSP behavior).
  5. On successful Checkin, the task in the application shows the actual start date as 07-Dec-13, even though the effort has been logged from 01-Dec-13 in the user’s Timesheet

Scenario 2: Actual Start Date is changed for rescheduling in MPP, for unapproved  Timesheet with actual hours logged in the application.

  1. A task T1 has been assigned to Resource A with a planned start date as 01-Dec-13.
  2. Resource A starts working on task T1 from 01-Dec-13. The effort has been logged from 01-Dec-13 to 10-Dec-13 and the timesheet is not approved and is currently in the Saved state.
  3. The PM checks out the plan in MPP. As expected, task T1 is seen in MPP without any actual start date as the timesheet is yet to be approved.
  4. For some reason, the PM postpones the task and changes the task’s planned start date to 07-Dec-13.
  5. On successful Checkin, the planned start date for that task is seen as 07-Dec-13. However, when the timesheet is approved, the actual start date for this task changes to 01-Dec-13 and as expected on Checkout the actual start date is automatically updated to 01-Dec-13. Thus in this scenario, the PM’s rescheduling is overwritten or disregarded.

Scenario 3: Actual Start Date is changed in MPP after the task was marked ‘Done’ in Timesheet.

  1. A task has been assigned to Resource A in Week 1.
  2. The resource marks the task as ‘Done’ and saves the timesheet without logging any effort.
  3. The timesheet is in Saved state and PM checks out the project plan in MPP. The task is not seen as 100% complete in MPP as the timesheet is not yet approved.
  4. The PM postpones the task to start in Week 2 and checks in the plan.
  5. On successful Checkin, as the task has already been marked as ‘Done’ in Week 1, the task is no longer available in Week 1 nor Week 2 timesheet for Resource A. Unless the task is rescheduled to start in Week 1, it does not appear in the timesheet for Week 1 for Resource A.

Condition 2: The application timesheet approved effort (work) for the task is greater than the work for the resource in MSP

The Checkin failure mail is sent when discrepancies exist in your plan and you are trying to checkin. The Checkin Failure mail contains the possible causes of failure and suggestions on how you can rectify the data for the task and resource. A sample Checkin Failure mail is shown below.

 Note: Only the approved timesheet efforts (work) timesheets are considered during Checkin validation.

Following is a scenario that results in data inconsistency and hence this validation is added to the Checkin process.

Scenario: Actual Effort logged in Timesheet is greater than the Planned Effort

  1. A task has been planned for 40 hours and 30 hours of effort has been logged, approved, and closed in the application Timesheet.
  2. PM checks out the project in MPP. The Actual effort is seen as 30 hours.
  3. To reduce the estimated effort, the PM changes the Planned effort (Work) from 40 hours to 20 hours. Due to this, the actual hours to change to 20 hours.
  4. On successful Checkin, the task shows Actual effort as 20 hours while the Timesheet Report shows 30 hours against the same task. This causes data inconsistency that is visible in various artifacts in reports/Analytics.
  • Was this helpful?
  • Yes   No