Sample Scheduling Standards

Alex S. Brown, PMP IPMA-C

To help create consistent, high-quality schedules, organizations may create standards for schedules. These standards help all project managers follow similar principles when creating a new schedule, making them easier to integrate into a portfolio and easier to manage overall. Standards can also help ensure that newer project managers do not repeat common mistakes made by the organization in the past.

Each organization performs different types of project work, reports on it differently, and uses the schedule for different purposes. This document is just a sample of scheduling standards, and needs to be adapted to a particular organization’s needs. The standards should also be owned by someone in the organization, so they can change over time based on experience and feedback. Ideally these standards are part of a larger effort of continuous improvement in project management processes.

These standards make the following assumptions about the organization:

  • Project status is reported weekly
  • Project end dates are generally revised monthly or after any high-impact event
  • No project-oriented time sheet system is used
  • Project deliverables are well-defined from the start (projects are not research-oriented)
  • Currency is measured in dollars ($)

The standards are designed to be used across a variety of scheduling software packages. If a single vendor’s package is used, the standards can be enhanced by describing specific features that must or must not be used. Ideally, these standards will be audited by an automated analysis and reporting tool, as well as by human auditors.

Project Scheduling Standards

  1. Every project deliverable will appear by name in the Work Breakdown Structure (WBS)
  2. The WBS will be hierarchical, with each level of the hierarchy generally containing between three and seven child items
  3. The primary goal of the WBS will be to organize the work so it is clear to stakeholders and completely defined, not to sequence the work; phases and deliverables may be overlapping in time
  4. If there is a standard life cycle, standard phase names, or a standard schedule template for all or part of the project work, the organization’s standard names or template will be used for the WBS
  5. Level of effort (LOE) work will be represented as tasks in its own WBS element, and not mixed together with deliverable-oriented tasks
  6. LOE work will include project-management-related work that does not produce project deliverables, including status reporting and schedule maintenance
  7. If meetings contribute to one or more deliverables, include them as work in the WBS under the deliverables, either as a special task or included in the work of other tasks
  8. Except for LOE work, tasks will be less than two weeks in duration, and less than one work-week in effort
  9. All tasks will be at least 4 hours of work; work of smaller amounts will be combined with other tasks
  10. Except for LOE work, every task will have a definite beginning and definite end; if the beginning and end of the task are unclear from the title, they will be described in the WBS dictionary
  11. Milestones will have an owner responsible for declaring when they are complete, but will have no duration and no work; work will be represented by tasks with assignments and duration
  12. At least one milestone will appear on the schedule every two weeks, so that definite accomplishments can be reported with every other status report; preferably there will be one or more milestones for every reporting period
  13. Resources will all have an estimated or actual rate assigned, to estimate costs; if no rates are known then all resources will carry a rate of $1/hour, so costs can be measured in work-hours
  14. Every project will have a start milestone and an end milestone
  15. There will be no loose ends in the scheduling logic (every task and milestone will have a predecessor except the project start milestone; every task and milestone will have a successor except the project end milestone)
  16. All major deliverables and phases will have start and end milestones
  17. Resources, work, and scheduling logic will never be associated with summary elements in the WBS; they will be tied to tasks and milestones only
  18. If the scheduling logic calls for a task to have more than four predecessors or four successors, one or more milestones will be created and the logic moved to the milestones instead, for clarity
  19. Any use of start-to-start, start-to-finish, and finish-to-finish scheduling logic will be accompanied by an explanation; generally this logic is discouraged
  20. Schedule constraints (must start on, must finish on, etc.) will only be applied to milestones (never tasks) and will be accompanied by an explanation; generally constraints are discouraged
  21. If some work cannot be estimated or defined accurately at this time, it will be included as a deliverable in the WBS and as high-level work tasks with the word “TBD” (representing “to be determined”) in parenthesis in the title
  22. “TBD” tasks and deliverables will be generally be estimated and defined at least two months before they are due to start (in other words, no “TBD” between today and two months in the future)
  23. Assignments for work more than six months in the future will be represented by an unnamed resource (describing the skills needed), not the name of a specific person
  24. Resources will be scheduled so that the organization’s holidays and any planned vacations are considered non-working time
  25. For unnamed resources, their typical availability per day will either be reduced by a proportion equal to the typical vacation and working days for that type of resource, or a typical seasonal vacation schedule will be considered
  26. Resources will be scheduled for no more than 35 hours per week of work, to allow time for non-project work and other employee responsibilities
  27. At least monthly, record which tasks and milestones have actually been completed and worked on, then reschedule the remaining work to estimate a new project end date
  28. Apply all changes that affect the schedule (scope, budget, etc.) to the schedule the week that they occur and reschedule the remaining work based on the changed schedule

Definitions

  • Level of Effort (LOE) Support-type activity (e.g. Vendor or customer liaison) that does not readily lend itself to measurement of discrete accomplishment. It is generally characterized by a uniform rate of activity over a period of time determined by the activities it supports.Logical Relationship A dependency between two project activities, or between a project activity and a milestone. The four possible types of logical relationships are:
    • Finish-to-start
    • Finish-to-finish
    • Start-to-start
    • Start-to-finish

    Milestone A significant event in the project, usually completion of a major deliverable

    Work Breakdown Structure (WBS) A deliverable-oriented grouping of project elements that organizes and defines the total work scope of the project. Each descending level represents an increasingly detailed definition of the project work.

    Work Breakdown Structure (WBS) Dictionary A document that describes each WBS element, including scope, deliverable(s), specification, schedule, resource requirements, and so on.

    Work Breakdown Structure (WBS) Element An entry in the WBS that can be at any level.

All definitions taken from PMI Combined Standards Glossary, compiled by the Project Management Institute James R. Snyder Center for Project Management Knowledge & Wisdom (PMI, Newton Square, PA: 2004).

Checklist for Customizing Scheduling Standards

When customizing this list to your organization, consider the following questions:

  • Do we need more frequent or less frequent status reports? If so, modify the standards for maximum and minimum task size, as well as the frequency of milestones in the schedule.
  • Does my scheduling software allow all the things described in this document? For instance, many packages do not allow assigning resources to summary elements, allowing the deletion of that standard.
  • Do all schedules need to be submitted in a specific form? Should they be kept in a certain spot on the computer network? Should certain reports always be checked? Add items that are specific to your organization.
  • Does your organization track project costs? If so, how? By work hours? Are employee or contractor rates considered confidential? All these issues may change the recommendations for handling costs, and may add a need to keep all or part of the schedule confidential.
  • Do you have any templates, phased development models, or other structure that must become part of the schedule? Is it different for different-sized projects? Include these guides in the standards as well.
  • Are your projects open-ended and research-oriented? If so, you may want to allow open ends in the project logic.
  • How long are your projects typically? Do you encourage developing the detailed estimate and plan in phases or all at once? Customize the standards for “TBD” tasks to your organization.
  • Does your organization provide full-time or part-time resources to work on projects? How much time can each resource realistically spend on project work? What is a typical work-week? Depending on these answers, customize the standards for work hours per week.
  • Does your organization work a non-standard work week or work in multiple time zones? Add standards if special settings are needed to handle these scheduling issues in your software.
  • Do unplanned time off, staff changes, weather delays, or other unpredictable issues often cause delays to projects? If so, consider adding standards for how to allow for these types of disruptions based on typical averages for the organization.
  • Does your organization use critical chain or theory of constraints when scheduling? If so, then include standards for how to create and administer buffers.
  • Does your organization have a time sheet system or another method to feed actual work-hours into the schedule for each reporting period? If so, including standards for how to rework the schedule after actual time has been applied.
  • Does your organization keep a separate document for the WBS dictionary, or are details for each task somehow kept in special fields in the scheduling software? Include standards for how and where to document task details.
  • How do your schedulers track the difference between hard logic and soft logic (dependencies that must be met vs. ones that should be met)? Include standards about when and how to document the reasons for scheduling logic and dependency relationships.

Copyright © 2006, Alex S. Brown, PMP. All rights reserved. The right to modify and adapt these standards is granted to any organization, so long as this copyright notice and a hyperlink to http://www.alexsbrown.com/ is kept in the document.