Some people like MicrosoftProject. Others don't like it, but are told by the PointyHairedBoss they have to use it because it's the corporate standard. Others because any other scheduling tool either a) sucks worse, or b) is very expensive.
A few tips for those who use it.
- Don't use automatic resource levelling. Will break any schedule. It can be made to work, but first you need to understand what "work" means for this. If you must use it, read a decent book on it first (it's not at all intuitive)
- Make all tasks "fixed duration", rather than "effort-based".
- Enter the amount of work in the Work field (which you'll need to add to the tables) not Duration.
- Avoid any dependencies other than finish-to-start. Absoulte lag (positive or negative) is OK; but avoid % lag.
- Never put dependencies on summary tasks.
- Decide--up front--whether you want to work with PERT or Gantt charts. If PERT charts, forget about using summary tasks; they just won't work. Switching between the two doesn't work well at all--if you enter your data in the Gantt screen, and look at it as a PERT, it will be spaghetti. Likewise if you go in the opposite direction.
- Don't change the start date of a started task (in Project parlance, a task that has "actuals"). If you do need to do this; then:
- Change it's %complete to 0%, making it an unstarted task
- Then change the start date
- Then assign it an appropriate completion percentage.
- Otherwise, you risk "split tasks", a source of weirdities in Project.
- Consider bringing in MicrosoftProject consultants/customizers. Quite a few of them out there, and they make it more bearable.
- Avoid "no later than" constraints. If the constraint is violated, Project treats this as a scheduling error (and does weird things while howling loudly) rather than a slipped task. Instead, use the "deadline" feature to specify that a task has a deadline.
- Keep a "scrub list" of tasks to do after schedule changes--it is still too easy to get
thanks.
General hints; not specific to MicrosoftProject:
- All tasks should have predecessors and successors. If a task has no predecessor, and isn't able to begin immediately, it's a problem. If a task has no successor (other than the end of the project), why are you doing it?
CategoryTips