The Project Schedule offers a Gantt-style overview of your Project's Milestones and Tasks, allowing you to quickly and visually track your Project's progress.
Using this guide, you can:
Accelo's predictive scheduling tool uses six different dates to track and schedule your projects in real-time. Those dates are:
Planned: When the work was originally scheduled to begin and end.
This baseline date is set by the project manager via the Project Plan and acts as the basis for all other date calculations. The Planned Dates also determine when the Task will first appear on your team's schedule.
NOTE: Planned dates will match the predicted dates based on your acceleration settings until upstream dependencies begin to move forward or backward.
Predicted: The date when work is likely to actually start or end.
Predicted Dates are used to present you with an estimation of your Project's future timeline, and are calculated using the Task's Planned Start and Due Date, its Duration and its Dependencies. Predicted Dates will initially be the same as the Planned Dates when work first begins but will be updated as the Project progresses. If the Task is not started by the Planned Start Date, or if the Task's Dependencies have not been satisfied on time, the Predicted Start Date will automatically move backward by one day (one day later). The Predicted Due Date will move backward by one day at a time if the Task is not started by the Planned Start Date, or if Dependent Tasks are running late.
Target: The date when the assignee could reasonably start or complete work.
Project delivery is often a team sport, and it often doesn't make sense to look only at the whole project to understand who is responsible for it being ahead or behind schedule. Especially in the case of upstream delays, it isn't fair to a team member whose work is done later to be blamed for delays caused by upstream work which they're not responsible for. To better track these situations, Target Dates track the date when work could reasonably be started or completed based on the original Planned Date and built-in dependencies. If a dependency causes work to be delayed or start early, the Target Dates will reflect the date when dependencies would allow that work to first begin. For example, if a dependency pushed a Task back by two weeks, then the Target Dates would be two weeks later than the Planned Dates.
Commenced & Completed - Actual: The date when work was marked Started and Complete.
The Actual dates are used to identify when work was actually performed, i.e. when a Task was Started or a Milestone Completed. Actual Dates will not be set until work is marked Started or Complete. Completing a Task outside of its Planned Dates will update the Predicted Date for any dependent Tasks or Milestones.
Scheduled: The dates when work has been scheduled to begin and end on, based on what is actually present in users' calendars.
We’ve added Scheduled Dates to the Project Overview to provide more clarity about the dates on which the tasks or milestones will be scheduled. These dates can be viewed on pages like the Task List, Schedule Dashboard, My Schedule, Team Schedule, etc.
The Scheduled Dates are calculated based on User Estimated, Actual and Fixed Dates. If none of these date types exist for a task, then the Scheduled Dates are calculated based on the Predicted Start or Target Start Date, whichever is earlier.
One of the philosophical tenets of Accelo is that the people actually doing the work are in the best position to know the reality on the ground. User Estimated dates allows your team members to update their Tasks with the dates which they expect work to actually begin or end, not simply based on pre-set dependencies or Planned Dates. These dates will also update your team's schedule, re-allocating budgeted time based on the available dates. User Estimated dates can be controlled and disabled by the Project's Level of Editing
The Project Schedule offers a quick and visual tool for staying on top of these complex schedules by incorporating these dates for a comprehensive overview of your Project's schedule. To do that, each line of the schedule includes the time frame in which that work is expected to occur, offering insight into where potential scheduling issues may occur.
NOTE: The Schedule tab will only appear on the View Project screen once the Project is in the Active status.
Each date is shown using a special format:
Solid Black Line: Planned Dates
Dotted Line: Predicted Dates
Dotted Outline: Target Dates
Solid Outline: Actual Dates
Black or White Circle: User Estimated Dates
The Gantt also uses color-coding to identify whether these dates are behind or ahead of schedule:
Green: Ahead of Schedule
Orange: Expected to Complete Behind Schedule
Red: Actively Behind Schedule
For more information on how these dates are used to schedule your team, check out Dynamic Scheduling.
To help simplify your complex projects, and focus on specific details and work, the Schedule offers several filters:
Search: Search the title of your Milestones and Tasks for specific work
Planned/Predicted: Toggles the Planned and Predicted Dates appearing for each line of the Schedule
Target/Actual: Toggles the Target and Actual Dates appearing for each line of the Schedule
My Work Only: Shows only Milestones and Tasks which you are either assigned to, or manage
Hide Complete: Hides all Milestones and Tasks which have been completed
Showing Day/Week: Changes the schedule's time frame to view either individual days, or full weeks
Go To Today: Jumps the view to "today"
Fullscreen: Expands the schedule to take up the full page
When viewing or editing Tasks within a project, you may notice some tasks display Boundary Dates, meaning the Task Start Date and Task End Date must fall within these boundary dates.
Typically these are the Planned dates of the parent object (usually a milestone, but possibly the project itself) but if a Deadline date has been set then this will be used rather than the Planned Due date.
The consequence is that users wanting to move tasks around will be limited to these boundary dates. If the tasks really should be moved, then it's better to update this in the project plan so that the flow-on effects can be fully realized according to the project dependencies, etc.