The purpose of this article is to explain the difference in the behavior of actual dates between the two releases and rationale behind the change.
Prior to London (Kingston or Jakarta):
Actual Start Date: When user moves a task to work in progress state (from pending or open state) or updates % complete from 0 to another value to indicate progress on task, it takes the current timestamp (date as well as time).
Actual End Date: When user moves a task to closed state or marks as 100% complete, it takes the current timestamp (date as well as time).
Actual Start Date: When a user moves a task to work in progress state (from pending or open state) or updates % complete from 0 to another value to indicate progress on task, it copies actual start date from the planned start date
Actual End Date: When a user moves a task to closed state or marks as 100% complete, it copies actual end date from the planned end date.
Driver/Motivation for the change:
As a typical use case, the Project Manager does not update the task progress on the same day when someone starts working on a task. We will simulate an update to the percent complete of a task in the below example project and see how it impacts the schedule of the project in the Kingston release.
Planned Start Date: 2018-11-01
Planned End Date: 2018-12-10
Planned Duration: 28 days
Now the PM process updated the percent complete of Task 1 to be able to progress, but it shifted the original planned dates.
- Planned End Date of my Project changed to 2019-02-19(Only % complete is updated). It made the task to WIP.
- Planned End date of Task1 too from 2018-11-14 to 2019-01-24.
- The intention of the PM was to update the progress of the project but behavior changed the whole project plan and pushed it further.
This was causing the confusion to PMs as a simple change in Percent Complete updates the overall schedule of the project.
London and further:
- The project’s Planned Start Date is 2018-11-12: 08:00:00 and the Planned End Date is 2019-01-02 17:00:00 with a Planned Duration of 38 days.
- The project has 4 tasks with Finish to Start (fs) dependency on each other in the same WBS Order.
- The user now goes and updates the % complete of the Task 1 (let’s say today is 2018-11-08 at 15:00:00).
- If you notice now even after starting a project before the schedule nothing has changed. My overall plan is the same. No dates have been affected.
- The system ensures that the dates on the tasks are not altered unless the user explicitly updates the actual dates of the task.
- The project schedule will only be updated when the user explicitly updates the actual dates of the task.
Frequently Asks Questions:
Q: Is there a way to roll back the feature?
A: No, this is a fairly thought decision made in order to make product align with all the other market products in the same domain. It will be very hard for SNOW to maintain two paths of codes and it will not be scalable.
Q: Can I customize it to make it work?
A: We highly suggest not to customize the OOB Scripts because it might work now in current release but will surely break upon further upgrades.
Q: This is a very big change for our users and we don’t want this?
A: We would suggest to setup a training plan for all the users and explain the details and thought process that was put in.