Frustration Management Tips for Microsoft Project Users

Many Microsoft Project veterans have learned these tips the hard way; for those of you who are not veterans in the world of Microsoft Project, here are several tips that will save you hours of frustration at some point in your scheduling career.

Scheduling Best Practices:

• Only link tasks where true dependencies exist: Although you may choose to link tasks initially to create a 'pretty' schedule, if those dependencies don't truly exist and those tasks are actually performed in a different order, then you have a mess on your hands. Do not add dependencies in your Microsoft Project schedule simply to resolve resource overallocations.

• Use dependencies with lead and lag times, rather than 'spacer' tasks: Only add tasks to your project schedule to track work of interest, not to space tasks apart. If activities are being performed by someone outside of your group (i.e. a contractor) and you don't need to track their effort or progress, then perhaps those activities don't belong in your schedule.

• Verify that most tasks have predecessors and successors: For a truly dynamic project schedule, nearly every task is driving another task or event, and nearly every task is being driven by another task or event. If a task is not driving something, then there is less incentive to complete it! Obvious exceptions include the first and last items in your schedule.

• Minimize the use of task constraints: Task constraints (i.e. Start No Earlier Than, Must Finish On, etc.) impose scheduling roadblocks in your project schedule, therefore making it less able to react to the inevitable changes that will occur. Use sparingly.

• Add task notes to include additional helpful information: The 'Notes' field, accessible via the 'Task Information' dialog box, can hold very useful information that does not belong in the task name, including where or how the task should be performed, as well as other scheduling considerations.

• Add task notes to indicate unusual scheduling situations: If you or one of your colleagues is reviewing your project schedule at some point in the future, it may not be obvious why a constraint was imposed on a task. Perhaps it was even an accident caused by pasting start or finish dates in the schedule...? If you purposely imposed a scheduling constraint, add a quick note describing why.

• Add formatting to indicate unusual scheduling situations: Use custom formatting in the Gantt Chart or in the tables to highlight activities or events that you want to stand out, such as new tasks added through change control, overdue tasks, or critical tasks.

• Standardize your formatting: Try to be consistent with the formatting that you apply to your project schedule, and if you often share your project schedules with others, then work with them to agree on formatting standards that everyone will understand.

• Standardize your task naming: Try to be consistent with the task names in your project and standardize task names across all of your projects, including those managed by other Project Managers.

• Use brief, yet descriptive task names: Use task names that describe the tasks well... without being too verbose. Avoid short task names like "Test" or "Travel", but also avoid writing a long task description (use the 'Notes' field instead).

• Limit task name lengths: Avoid using task names longer than 50 characters. This helps those who are reading the task names in timesheets or reports.

Scheduling 'No-No's:

• Do not use the 'X' buttons to close Microsoft Project: This can cause checked-out projects or project schedule corruption in Project Server. Use 'File' > 'Close' and 'File' > 'Exit' instead.

• Do not manually enter task start or finish dates: This imposes constraints onto the tasks, therefore limiting the dynamic nature of your project schedule. If you must impose a task scheduling constraint, then use the 'Task Information' dialog box.

• Do not assign resources to milestones or summary rows: Milestones represent accomplishments or deliverables, rather than activities requiring work effort, and summary rows are intended for organizing collections of related activities, so neither should have resources assigned to them.

• Do not link summary rows: This increases risk of creating circular logic in the project schedule (try using manually scheduled summaries to control scheduling of phases). If an entire phase must be completed before kicking off the next set of activities, insert a milestone at the end of the phase and use that for linking.

• Do not duplicate task names: This increases ambiguity within the project schedule, on Project Server timesheets and task pages, and in reports. If tasks are repeated in multiple phases or sections of your Microsoft Project schedule, then name them appropriately for each phase (i.e. "Phase 1 Design" rather than simply "Design").

• Do not add blank task lines to your schedule: Although it makes your Microsoft Project schedule easier to read, this creates empty records in the Project Server databases and can contribute to project schedule corruption. Other formatting tools (font sizes and colors, cell background formatting, etc.) are available to make your schedule easily readable.

• Do not manually type names into 'Resource Names' column: This increases likelihood of duplicated resources and does not account for the work hours or units for each assignment. Use the 'Task Form' or the 'Assign Resources' dialog box instead.

• Do not use special characters anywhere in the schedule: This can create corruption in the Project Server databases, as well as problems with reporting. Use this general rule of thumb: avoid any character that is not a letter, a number, a space, an underscore, or a hyphen.

Any More to Share?

If you have other Microsoft Project scheduling tips, best practices, or pitfalls to share, please leave them in the comments.

Good luck!