A schedule as a valid and dynamic model

Introduction

Many organizations use a spreadsheet to plan and schedule their projects. This results in a very static model of the project that requires a lot of maintenance during the execution of the project. We will demonstrate how to create valid, dynamic models of projects and will discuss items on a 40-point checklist to verify if you have a solid model. In this article, I will share with you how you can check your own schedule if it reflects the best practices of scheduling.

Checklist for Creating Good Project Schedules

This material is used with special permission from International Institute for Learning, Inc., the copyright owner. This checklist is copied from the book “Dynamic Scheduling with Microsoft Office Project 2003” (Uyttewaal, 2003)

The checklist is the result of research on over 1,000 real life schedules that were submitted for certification. If you apply the checklist to your project schedule, you will improve the quality of the schedule and, hence, your control of the project.

What is a Good Project Schedule?

What is a good schedule? A good schedule is a model of the project that provides valid forecasts and that is easy to maintain. Only dynamic models are easy to maintain. Let's break the term valid dynamic model into its components:

A schedule has to be a model of the project:

• A model is a simplification of the reality.
  A model should be a deliberate simplification of the complex reality. We often use the criterion that if you cannot explain the model to your stakeholders, the model is too complex.
• A model of the project provides forecasts.

A schedule has to produce forecasts that are valid. A schedule will only produce valid forecasts if:

• It contains all deliverables.
• The basis for estimates (pure work time versus gross work time) is consistent with the working times on the project calendar.
• The time estimates seem reasonable for the work to be done.
• The schedule produces accurate forecasts.
  Unfortunately, this can only be determined after the project is over.

A schedule has to be dynamic. The ideal of a totally dynamic model is that if one thing changes in reality, you should have to change only one field in your Microsoft Project model. Even though this ideal is hard to reach, you can get very close to it if you set up your schedule in the right way. A schedule is dynamic if:

• It has as few constraints as possible.
• It has a complete network of dependencies.
• It is easy to maintain so that it can be kept alive during project execution.
• It is up to date in real time.
• It provides continuous forecasts.
• It is in an electronic format and accessible online.

Our recommendations are compiled in the checklist that follows. The list can be used to evaluate the quality of your project schedule and to check on the use of best practices.

If your schedule meets these guidelines, you have created a valid, dynamic model of your project. You have positioned yourself to bring the project to a successful completion. From experience, we can say that managing a large schedule is a nearly impossible task if it does not meet the requirements of the checklist. Schedules that meet the requirements need the least maintenance during the execution of the project. You need the single schedules to meet all requirements on the checklist if:

• You need to create an integrated program schedule for a large endeavor from sub-schedules. You need to apply the checklist on each sub-schedule.
• You want to start developing scenarios with a portfolio of projects using the Portfolio Modeler in Microsoft Project Web Access.
• You want to monitor and level the workloads across multiple projects.
• You want to apply Monte Carlo simulation to your schedules.

Best Practices Checklist for Schedules

In the checklist, we have used the words “summary task” and “detail task” very carefully. It is important that the words are interpreted correctly for the guidelines to make sense. A summary task is any task with indented subtasks listed beneath it on a lower level in the WBS. A detail task is any task without indented subtasks in the WBS.

The checklist has a background section and the following categories:

• Work Breakdown Structure (WBS)
• Estimates
• Dependencies
• Scheduling Constraints
• Resources
• Assignments
• Optimizing
• Reporting
• Updating

Background Information You Need to Know About the Project

You need to know the answers to the following questions in order to make a thorough evaluation of the schedule:

• What is the objective or final product of the project
  (if not described in File, Properties, Comments)?
• What is the deadline date of the project
  (if not shown as a deadline date in the schedule)?
• Does the project have a cost budget? If yes, how much?
• Does the project have a person hour budget (effort)? If yes, how many person hours, person days, person weeks, person months or person years?
• Did the project manager gather pure work time estimates or gross work time estimates?
• Did the project manager apply the Rolling Wave approach in the schedule? If so, what is the duration of the detail planning window?
• Will the project manager do task updates (durations) or assignment updates (time sheets) or both?

Setup

• Does the File, Properties, tab Summary, Comments field contain a description of the objective or final product of the project?
  The description is visible as a Note on the project summary task. You need to have some background information on the project to better evaluate the schedule.
• Do the working hours on the Tools, Change Working Time, Standard (Project Calendar) correspond to the Tools, Options, Schedule, Hours per day setting? For example, working times of 8AM-12PM and 1PM-5PM are consistent with 8 hours per day and 40 hours per week. If the settings are inconsistent, your forecasts are either too optimistic or too pessimistic. Also, you will often see decimals in the task durations in that case. The quickest way to check consistency is by choosing Tools, Change Working Time. The button will take you directly to the Tools, Options, Calendar dialog.

WBS

•    Are there deliverables in the WBS? Is the WBS a deliverable-oriented breakdown structure? Deliverable-oriented breakdown structures provide the best control on the project. Deliverables should be captured using nouns (perhaps with adjectives, but without verbs). Verbs change a deliverable into an activity. If there are no nouns in the WBS, we have to conclude that there are no deliverables.
Alternatives for a deliverable-oriented breakdown are a phase-oriented breakdown or an organizational breakdown. From a project control perspective, these are less effective.

•    Is the list of deliverables complete but lean?

    Are all expected deliverables explicitly included in the WBS? This should also include significant reporting items, like monthly status reports, test plans and test reports.

    Are the project management deliverables and activities included in the WBS?

    Are out-of-scope deliverables that may be expected by the client explicitly excluded from the WBS? We recommend you capture exclusions in the File, Properties, tab General, Comments field.

    There are no unnecessary deliverables in the WBS that were not agreed upon with the client or project sponsor.

•    Does the WBS have a logical hierarchy?
If you don't have a logical hierarchy, you may report the wrong cost and duration by phase or deliverable. You can check if the WBS is a logical hierarchy by expanding the outline structure level by level using the tool on the Formatting toolbar.

    Is the WBS an indented list with multiple hierarchical levels instead of a long list without structure?

    Are the most important items on the highest levels in the WBS?

    Are the phases, if present, on a higher level than the deliverables?

    Are the tasks, if present, on a lower level than the deliverables?

    Does each summary task have at least two subtasks?

    Is there any duplication or logical overlap between deliverables?

    Does each group of subtasks capture all the work of their summary task (top-down check)?

    Does each item logically relate to its summary tasks on all higher levels (bottom-up check)?

    Is the feature Tools, Options, View, Project Summary Task used instead of a physical project summary task? Microsoft Project's project summary task has ID number 0 (zero) in the first column.

•    Are there enough milestones?
There are enough milestones when there is roughly one milestone for each deliverable. Milestones allow you to create high level, one page reports on the project. Milestone events typically capture when the deliverable is completed, approved, sent, signed-off, published or shipped, for example. You can check this by applying the standard filter Milestones and checking if most deliverables have a milestone.

•    Are the WBS elements properly formulated?
If you apply the following guidelines, you ensure that everybody will be able to understand your WBS:

    Phases are formulated using the imperfect tense (-ing).

    Deliverables are formulated using a noun (perhaps with an adjective, but without a verb).

    Detail tasks are formulated using a present tense verb.

    Milestones are formulated using the noun of the deliverable and a verb in perfect tense (or past tense in English). Instead of a verb, the words ready, complete or sign-off can be used.

    Are the names of the deliverables, tasks and milestones used consistently in the WBS?

•    Does the WBS have the right level of detail?
Too little detail does not provide enough control on the project. There may be too few detail levels in the WBS:

    If you cannot estimate the duration or work on the detail tasks.

    If you have difficulties finding the dependencies between the detail tasks.

    If you often assign more than one resource per task.

    If there are detail tasks that are longer than a reporting period.

    If there are detail tasks with durations longer than 10% of the project duration (1%-10% rule).
An exception to the 10% maximum is if you created long tasks to capture overhead effort, like project management or technical support.

Too much detail causes too much work in maintaining the schedule. There may be too many detail levels in the WBS:

    If you think there are too many levels or if you think the task list is too long.

    If you added reminders, to-do items or acceptance criteria into the task list. Transfer these to the Notes field.

    If you can't guarantee you will be able to update all detail tasks in the schedule during project execution.

    If there are tasks with durations shorter than 1% of the project duration (1%-10% rule).

•    Is the WBS clear to all project stakeholders?
All stakeholders like your customers, suppliers, upper management, team members and support staff need to fully understand the WBS. If you don't understand it as a project manager, nobody will. If an outside reviewer doesn't understand it, chances are some other stakeholders won't either.

•    Project management overhead tasks, if present, should extend over the entire duration of the project. It does not make sense to stop managing the project halfway.

    Do the overhead tasks (like project management) extend over the entire duration of the project?

    Do the status meetings, as recurring tasks, continue over the entire duration of the project?

    Are there as few as possible task bar splits in the schedule at the end of the planning phase of the project? Task bar splits often require a fair bit of maintenance and should be applied with restraint. During the execution phase you will see enough splits appear when updating your schedule with actuals.

Estimates

•    Are the estimates reasonable given the work that needs to be performed?
You will need some technical expertise to verify if the estimates are reasonable. If you don't have this technical expertise, you could review the schedules of previous but similar projects. You can ask your team members who have the technical knowledge to peer review each others' estimates or you can ask a subject matter expert (SME) to review the estimates.

•    Are the estimates that you collected consistent with the working hours entered in the Standard (Project Calendar)?
If they are not consistent, the resulting schedule may be too short or too long.

    Gross working time estimates should be entered in a schedule with gross working hours (typically 8:00 AM-5:00 PM).

    Pure working time is 100% productive time. Pure working time estimates should be entered in a schedule with pure working hours. Note that 100% productive working hours corresponds to a shorter working day, for example, 8:00 AM-3:00 PM. For most organizations, the percentage of totally productive working time lies between 60% and 80% of the working hours.¹
Let's say your normal workday has 8 hours. If you estimate that the productive hours are 70% of the hours worked, the working hours should be 70% * 8h = 5.6 hours, let's say 5.5 hours (68.75%). Working hours that correspond to this are, for example, 9:00 AM-12:00 PM and 1:00 PM-3:30 PM. We prefer that you set working hours like these on the project calendar. You can set other working times as long as the total number of hours adds up to 5.5. To review the steps to set working hours.

Dependencies

•    Is the network of dependencies complete?
A complete network allows the schedule to update itself and displays the correct Critical Path. The network is complete if the task bars of all detail tasks are tied up at both ends. However, the network can have multiple starting points, but only one ending point. Only then will the Critical Path calculation be correct. For more discussion. The following questions will help determine if the network is complete:

    Is the logic only set on detail tasks and milestones?
If dependencies run over summary tasks as well, it takes too much time to check if the network is complete. It is also too hard to trace the Critical Path and understand it. Only with a complete network will the schedule be a fully dynamic model of the project.

    Are all the starts of the detail tasks and milestones linked to at least one other detail task or milestone? Exceptions to this rule are:

-  All tasks that can start when the project starts and that are driven by external forces or deliveries rather than by hand-offs within the project.

-  External delivery milestones with a Start No Earlier Than constraint date.

-  Recurring tasks

-  Overhead tasks

    Are all ends of the detail tasks and milestones linked to at least one other detail task or milestone?
A loose end, hanger or dangling task is a detail task that does not have its finish tied to any other task. In any project, there should only be one loose end, the project finish milestone (ignoring the summary, recurring and overhead tasks).
Exceptions to this rule are:

-  The project end milestone

-  Recurring tasks

-  Overhead tasks

    Do you have SS and FF dependencies properly linked up?
If you used SS or FF dependencies in your schedule, you should filter and display all those tasks with SS and FF dependencies and check on loose ends manually. What you should look for is:

-  Does a task with SS in the Successor field also have an FS or FF successor that ties up its end?

-  Does a task with FF in the Predecessor field also have an SS or FS predecessor that ties up its start?

    Are there tasks with an unreasonably large amount of Total Slack?
You can check this by doing a descending sort on Total Slack by choosing Project, Sort, Sort by… and selecting Total Slack from the Sort by list. Check if the tasks with most slack were expected to have a lot of slack. If not, you have found missing logic.² Even after you have given all detail tasks a successor, you should still apply this check, because even if each task has a successor, it does not guarantee that you haven't forgotten important links. Checking the Total Slack will actually lead you to where you forgot to set important dependencies in your model of the project. This check is very effective in catching missing logic in schedules. Remember that if you miss just one essential dependency, your critical path is wrong, your forecasts are not valid and your model is not dynamic.

    When a change is entered into the schedule, does it update the rest of the schedule automatically and appropriately through dependencies?
Is the entire schedule still valid? Where the schedule is not valid, an essential dependency might be missing. If you have to check the entire schedule after each change, you don't have a dynamic model.

Remember, the logic should be helpful, especially during project execution when you update your schedule regularly.

•    Is the Network Logic simple enough?
If the network is simple you can use it to explain impacts to your team. Project managers should be able to explain the network to their project team, otherwise the network is too complex. Are there redundant dependencies that make the network too difficult to explain and maintain:

    Are there dependencies that leapfrog each other?

    Are there dependencies that run in parallel on detail tasks and their summary tasks? If that is the case, keep the detail task dependencies and remove the summary task dependencies.

    Can you, as the project manager, explain the network to your project team?

•    Does the network have circular logic?
Circular logic does not make sense, because it is not clear which task should be scheduled first. Microsoft Project warns you not to set circular logic within a single schedule.

•    Does the logic of the network make sense?
The schedule is now entirely driven by dependencies. After the previous checks on dependencies are done, you should perform one more high level check to see if the resulting schedule actually makes sense. You can check this best by showing only the first outline levels of the Work Breakdown Structure and checking if the timing of the deliverables (or phases) makes sense on this high level. You can use the button on the Formatting toolbar to display Outline level 2 or Outline level 3 depending on the size of your project. Even though you may not be an expert in the field of this project, you can always pick up on common sense things like design scheduled before construction, write before print, etc. Realize that if you followed our recommendations and minimized the number of constraints and entered all dependencies, the start and finish dates of the tasks are entirely driven by the network of dependencies. If the resulting schedule does not make sense, you probably overlooked an essential dependency.

Deadlines, Constraints and Task Calendars

• Is the project deadline date captured in the schedule?
  It can be set using the Deadline feature date or using the Constraint feature in Microsoft Project. The deadline or constraint date needs to be set on the project finish milestone. Using a deadline date or a constraint date depends on how hard the project target finish date is.
• Are there as few Task Calendars as possible in the schedule?
  Task Calendars have a very specific purpose and should only be used in those situations.
• Does the schedule have as few as possible schedule constraints?
  Constraints make the schedule rigid and jeopardize a dynamic schedule. However, constraints are legitimate on:
  •     Recurring detail tasks, like status meetings 1, status meetings 2, etc.
  •     External dependencies, such as delivery of supplies or arrival of materials.
  •     Activities that have to take place on a certain agreed-upon date, like deliver presentation and conduct training. In general, these are activities in which a group of people is involved.
  •     Do-or-die-by dates, like the December 31, 1999 deadline for Y2K projects as we all perceived it before that date.
  •     Activities affected by (winter) weather conditions, i.e., in Canada asphalting the streets Starts No Earlier Than April 1^st, because of the cold. You can also use the feature of Task Calendars for these situations in Microsoft Project. Task Calendars would be a better way in the case of the multi-year planning of infrastructural works; unlike constraints, task calendars will push a job automatically out to the next year if it does not fit within this year any more.

Resources

Resources and assignments are important in projects in which it can be expected that limited resource availability or huge workloads will influence the project end date. They are also important if there is a budget and the cost needs to be managed.

• Are all resources identified in the Resource Sheet?
  This is the case if all resources that could have a potential impact on the project are entered into the Resource Sheet. There can be impacts on scope, quality, duration or cost of the project. Resources and assignments should be entered for projects:
  •     Where it can be expected that limited resource availability or huge workloads will affect the end date of the project.
  •     If you have a cost budget for the project and you are responsible for staying within that budget.
  •     If you have a budget expressed in person months and you have to stay within this effort budget. This is quite common in government IT projects.
  •     If you foresee a quality or scope impact on the project depending on which resources you will get.
• Are all resources named completely and consistently using a naming convention like <first name> <last name> or <last name>-<first name>?
• Are there no overlaps between the resources or duplication of resources?
  If there are overlaps or duplications, Microsoft Project will still aggregate the workloads of the resources, but these total numbers will be useless when you check on over-allocations. If Bill Tan is listed twice as a resource (as Bill Tan and William Tan), you would have to sum all time-phased workloads in order to determine if he is over-allocated. The workloads in the Resource Graph and in the Resource Usage can appear to be smaller than they really are when duplicate or overlapping resources exist.
• Is the availability of the resources appropriately modeled?
  This can be assessed by asking you the following questions. For a detailed discussion on each question.
  •     Does the availability of individuals not exceed 120% as captured in the resource field Max. Units or the availability profile in the Resource Information dialog, tab General?
    We set an arbitrary limit and choose the maximum to be 120%. We think it is unreasonable to ask resources for more than 120% availability for periods longer than one week. When you ask resources to work overtime for extended periods of time, their productivity goes down dramatically. (OSHA, So, apart from the fact that it is unreasonable to ask resources for much overtime over extended periods, it does not make sense either. In your organization, the actual threshold may be different from 120%.
  •     If the Max. Units are less than 100%, is there a valid reason for this?
    Valid reasons are that the project manager works with pure work time estimates or that the resources have other ongoing work or other concurrent projects. Or the resource may be a part-time resource.
  •     Are the vacations of individual resources captured in their resource calendar?
    Vacations need to be entered, particularly when there are important deadlines close to the vacations. To check if they are entered, choose View, Reports, Assignments…, Who does what, click , click tab Details, check Calendar, and click . In print preview, you will now see individual vacations listed under Exceptions, as well as the exceptions from the project calendar. Look carefully to verify if the individuals' vacations are listed. You can copy this changed report back into your Global.MPT using Tools, Organizer to have it ready for future schedule analysis.
• Are the costs of the resources appropriately modeled?
  The following guidelines will help determine this:
  •     Are human resources entered as Work resources in the resource field Type?
    Are facilities, machines and materials entered as Material resources?
  •     Do Material resources have an appropriate Material Label to indicate their unit of measure? For bulk resources or consumable resources the material label should reflect the unit of measure, for example, the material label for cabling could be yards or meters.
  •     Are the rates entered in the appropriate fields?
    • -  Time-related costs for Work resources in the Std. Rate field
    • -  Unit-related cost for Material resources in the Std. Rate field
    • -  Time-related cost for facilities and machines as Material resources using two fields: the Std. Rate field, where you enter the per-unit cost, and the assignment-related Units field, where you indicate the number of units used per time unit, for example, 2 rooms each day should be entered as 2/day
    • -  Use-related costs in the Cost/Use field
    • -  Overtime costs in the Ovt. Rate field, but only if the overtime is paid and paid at a higher rate than the standard rate.
    • -  Rates that vary over time in the Cost Rate Tables.
    • -  Multiple rates per resource in the five Cost Rate Tables and the appropriate cost rate table (A, B, C, D or E) selected for each assignment
    • -  Task- or deliverable-related fixed costs in the Fixed Cost field in the Gantt Chart.
  •     Is the cost scheduled appropriately?
    This is important for managing the cash-flow of the project: Can bills be paid when they are supposed to be paid?
    • -  Does the resource-related Accrue At field reflect when the cost occurs: at the Start or at the End, or Prorated with the time-phased amount of work?
    • -  Does the task-related Fixed Cost Accrual field reflect when the fixed cost will be incurred?

Assignments

• Are you using the task-related field Type for the detail tasks?
  The available types in the field Type are: Fixed Duration, Fixed Units or Fixed Work. With this field, you can control what Microsoft Project recalculates: duration, units or work. If you don't monitor the field Type, you are not controlling what Microsoft Project does.
• Are there no assignments on the summary tasks?
  If you assign resources to summary tasks, you can easily end up with over-allocations that cannot be resolved other than by removing the resource from the summary task again. If you assign only to detail tasks, you will never end up with this stubborn type of over-allocation and save yourself time when leveling workloads. Resolving over-allocations is challenging enough.
• Does each detail task have at least one human resource assigned?
  If there are detail tasks without human resources assigned, you have not captured all the workloads in your project. If workloads are missing, the schedule may be too optimistic, since leveling workloads typically leads to longer schedules and later forecasts. An exception to this rule is that recurring detail tasks do not need resources assigned to them. You can check on this in the Resource Usage view, there should be no detail tasks listed under the first category Unassigned.

Note that there may still be detail tasks with only material resources assigned if you check the Unassigned category, so the check is full proof.

Optimizing Workloads

• Is the total effort within the person hour budget of the project (if a person hour or person day budget is available)?
  You can find the total effort of the project by clicking Project Statistics on the Tracking toolbar and looking in row Current and column Work.
• Are the workloads for the resources reasonable?
  If the workloads are too high, the forecasts are too optimistic.
  •     We had to set arbitrary limits; the limits may differ for your organization. The workload for individuals should not exceed 150% of their regular availability within any week. The workload should not exceed 120% for periods longer than a week. These upper bounds may differ for your organization. We have arbitrarily set them at these levels to prevent burnout, attrition and dramatic loss of productivity.
  •     The workload of consolidated resources (groups) should not exceed their availability.
  •     The workloads should be fairly smooth, since there are hidden costs involved with erratic workloads.

Note that it is not enough to just check if there is any red in the Resource Usage view. Microsoft Project often highlights more resources in red than are truly over-allocated. If there is an over-allocation during only one business hour, the resource will already be shown in red. Use the Go To Next Overallocation tool on the Resource Management toolbar to check the over-allocations. This tool is more selective and more reliable. However, even this tool does not always find all over-allocations, and it also highlights the 1-hour over-allocations.

Optimizing Costs

• Is the cost modeled using the right fields and in the appropriate way?
• Is the total cost within the budget of the project (if a cost budget is available)?
  You can find the total cost of the project by clicking Project Statistics on the Tracking toolbar and looking in row Current and in column Cost.

Optimizing Time

• Are there as many parallel paths as logically possible in the network of dependencies?
  Novice schedulers tend to schedule all tasks in one long sequential chain. In that situation there are many soft dependencies that make the duration of the project unnecessarily long. When optimizing for time, it is important to schedule in parallel what logically can happen simultaneously.
• Are there any unresolved conflicts between the task calendars and resource calendars?
  If there are conflicts, the forecasts may be too optimistic. You can find the conflicts by looking in the Indicators column for the icon .
• Are the deadline dates and other constraints met in the schedule?
  You need to find the tasks with a deadline or constraint that have negative slack. When deadline or constraint dates are not met, the schedule may forecast a project end date that is too optimistic.
• Does the schedule have a Critical Path or a Resource-Critical Path?
  The (Resource) Critical Path tells you which tasks drive your project end date. You can check the Critical Path by applying the Tracking Gantt view. This view highlights the Critical Path in red by default.
  •     If a schedule is extended when the workloads are leveled, a Resource-Critical Path needs to be identified. Resource-critical tasks need to be marked manually.
  •     The (Resource) Critical Path can only consist of detail tasks and milestones. It should not contain level-of-effort tasks (overhead tasks or recurring tasks) or summary tasks (since the logic and the resources should be kept on the detail tasks).
• Does the (Resource) Critical Path provide a complete explanation for the project duration?
  You can check the completeness by displaying the (Resource) Critical Path and then checking if it has gaps. Normally, there are no gaps, and every business day has at least one critical task (unless there are lags on critical dependencies). If you find gaps, the (Resource) Critical Path is fragmented, and the tasks that are most critical need to be identified in the schedule.

Reporting

• Is there a one-page status report available as a separate View object in your project schedule that displays the major milestones relative to the baseline?
  •     Are the milestones filtered in this view instead of listed together in the WBS?
    Many project managers put the major milestones at the top of their schedule to create a one-page overview of the project. This makes the network of dependencies very complex in the Gantt Chart, because the dependencies run up and down with long arrows. This makes it very difficult to check if the network of dependencies is complete. Instead, we advocate using a separate view that displays all milestones using the Milestones filter.
  •     Are the appropriate milestones chosen to represent the status and to forecast a large project?
  •     Does the one-page view report give an appropriate impression of the health of the project? Executives like to see one page reports.
• If your schedule has a Resource-Critical Path, is there a separate view object that displays it?
  The view should have the resource-critical tasks flagged in the field Marked or a Flag field.

Updating

The following guidelines are important if the project should have started, which is the case if today's date is later than the project start date. The schedule needs to show updated information with actuals and revised forecasts.

• What is the quality of the baseline in the schedule? The schedule needs a good baseline, because it will be the standard for comparing the progress.
  •     Is a baseline present?
    Keep in mind that projects planned far into the future and that aren't approved yet, do not necessarily need a baseline.
  •     Is the baseline complete?
  •     Is the baseline original?
    The baseline cannot be reset without formal approval of the appropriate project stakeholders.
  •     Is the baseline relevant?
    If the project deviated too far from the baseline, a new baseline needs to be negotiated. The baseline should provide a meaningful standard of comparison for the current schedule. You can check this by looking at how far the current schedule is removed from the baseline. Does the project have a fighting chance to catch up with the baseline again, or is it a lost cause? If it is a lost cause, you should submit a change request.
• Are the appropriate options selected in Tools, Options for the chosen updating strategy?
  •     For task updating (revising the task-related Actual Duration and Remaining Duration fields), the options should be set as follows:
    Tab Schedule: Split in-progress tasks
    Tab Calculation: Updating task status updates resource status
  •     For assignment updating (entering numbers from the time sheets into the assignment-related Actual Work and Remaining Work fields), the options should be set as follows:
    Tab Schedule: Split in-progress tasks
    Tab Calculation: Updating task status updates resource status
    If you keep this option selected, you should not enter % Complete on tasks, because this may override time sheet data. In Project 2003, overriding can be prevented by the Project Server administrator by locking in time sheet periods.
    
  •     For updating both the tasks and the assignments, the options should be set as follows:
    Tab Schedule: Split in-progress tasks
    Tab Calculation: Updating task status updates resource status
    You cannot enter both types of information unless you clear this option.
• Is the Status Date set to an appropriate date?
  The Status date in the Project, Project Information dialog should be set to a date that is close to today's date. If it is too far in the past, the schedule may be out-of-date. If it is too far in the future, the project manager is guessing the progress instead of entering factual progress.
• Is the task type of soon to be updated tasks set to Fixed Units and non Effort-driven?
  When you update the schedule, you change the durations (task updates) or the work (assignment updates). We recommended Fixed Units and non Effort-Driven, because you would typically like to see what the schedule looks like when the same resources continue to work on the task. You can always re-optimize the schedule.
• Is the schedule up to date as per the Status date?
  •     Are all actual durations (actual work / actual hours worked) scheduled in the past?
    The actuals are scheduled in the past if they are earlier than the status date. Otherwise, the schedule does not have up-to-date forecasts. When you bring actual durations to the past, all their dependent tasks may be rescheduled earlier as well, thus improving the forecasts. This is why rescheduling is important.
  •     Are all remaining durations (remaining work) scheduled in the future?
    The remaining estimates are scheduled in the future if they are later than the status date. You cannot leave unfinished work scheduled in the past. If you leave unfinished work before the status date, you are scheduling more work to be done in the past even though the past is gone. The work should be moved to the future to update the forecast dates of all dependent tasks. Otherwise, the schedule does not reflect up-to-date forecasts and you have created a status report, instead of a forecast report.
  •     Are the remaining durations (remaining work) revised?
    Otherwise, the schedule may not reflect up-to-date forecasts. If the project manager has been revising the remaining durations of detail tasks, the differences will be displayed.

In Closing

This material is used with special permission from International Institute for Learning, Inc., the copyright owner. It stems from the book “Dynamic Scheduling with Microsoft Office Project 2003” (Uyttewaal, 2003)