PAI Scheduling Philosophy

Our mission is to promote the use of project schedulers in large and multi project environments.

Scheduling is both an art and a science.  The science integrates information to produce the schedule that facilitates project planning, tracking, and control.  The art is integrating the information that comes from the project manager, the team, and the environment into the schedule.  Thus scheduling is a collaboration process.  We can teach the science, but the art is a combination of aptitude and experience.

The project management process is as strong as it weakest link: 
1) The project executive
provides the objectives, funding, and resources, monitors progress, and intervenes when needed.
2) The scheduler builds the schedule under the direction of the project manager and team.  The schedule
– is a contract among participants and stakeholders
– is an initial forecast of work and cost
– is the project manager’s primary reference document
The schedule provides
– a tracking mechanism producing the current progress assessment and forecast of final work and cost
– a report of who needs to do what each week
– a means of integrating changes and recovering from slippage to stay on schedule
– status reports to the team and stakeholders
3) The project team performs the weekly or bi-weekly to do’s.
4) The scheduler, project executive, and project team update to do’s progress and changes weekly or bi-weekly, the scheduler distributes the resulting status reports to all stakeholders, and next to do’s to the team.

The flexibility and functionality of MS Project (MSP) provides many choices on how to use it but the myriad of options leave most project manager part time users in poor control of their schedules.  As a full time scheduler I have selected features that provide our clients with unprecedented visibility and control over their projects while minimizing the time and effort required by the PM and project team. For multi project and large project environments there are significant benefits from the use of a dedicated professional multi project scheduler.

Objectives and how we meet them
1) Our primary objective is schedule control.  We want to know when each task, and the project, will end.
2) Task progress is determined by the task owner reporting their actual or projected finish date, not % complete, not work or time remaining.  Task duration is adjusted to end on that date and the MSP Mark on Track command will calculate task % complete and update the Gantt view.
3) Baselining: We baseline the schedule before the first project status update meeting and save that version in both the MSP Baseline and Baseline1 fields.  Baselining enables us to capture, view, and report on duration and finish date changes from one status meeting to the next.  After each status report is produced the schedule is rebaselined in preparation for the next update.
4)Earned Value metrics compare the current project schedule with the initial Baseline1 schedule.  Activities added as the project evolves may push the project end date reducing earned value because the formulas assume the later end date is due to slippage.
5) Version control:  PAI uses a date prefix format of yymmdd as the first 6 characters of every mpp or pdf report to indicate creation date of record.  If a second date appears in the filename it references the status date of the file.  For example “181212 Fabrication and Stamping 1219 3-To Do’s.pdf” is the to do view produced during the 181212 status update for the following week’s update for 1219.
6) Cost Control: We do not capture actual work in MSP.  A separate labor claiming application is recommended to capture work at the project, not task, level.  Typically a number of activities performed by project participants do not appear on the project schedule; meetings, correspondence, conversations, travel, action items, issue resolution; and there is no benefit to adding them.  A separate labor claiming application can capture a daily breakdown of how much time, including the unscheduled time, each participant allocated to each project.  Total project time to date can be applied to their daily labor rate to calculate the Actual Cost of Work Performed on each project for earned value calculations.
7) Calendars: We do not use holiday or vacation calendars.  During planning we ask task owners to provide duration estimates that take into account their expected out time.  We do this because it is common for people to work on some or all of a holiday or vacation period, and adjusting calendars to accommodate individual schedules is very time consuming during a status meeting,  Task owners control their schedule, not the software.
8) Workload balancing: There are several reasons not to use this feature; a) It distorts the critical path because it creates hidden task dependencies to simulate resource constraints, and the critical path is key to schedule control, b) To use it one must estimate the work in every task and as we pointed out in (6) above, all the work is not represented, c) Teams typically adjust resources as tasks approach overriding the balanced plan, d) Even though MSP defaults to assigning resources full time on their tasks unless specified otherwise, one can still use the MSP Usage view for an indication of potential resource bottlenecks.
9) Visibility: There are 2 ways to highlight information in an MSP schedule, filters and custom fields.  Filters show a condition only when they are run.  If the condition changes the schedule will not reflect the change until the filter is rerun.  Custom fields reflect conditions as soon as you change your schedule.  Filters do not.
10) Status Updates: Only the scheduler updates schedule status.  We invite the PM and team to change the schedule if required between status updates but not update their status outside of the status update meeting.   Changes must be returned to the scheduler before the next status update with enough time to meet if needed for clarification and possible adjustment.