Set Deadlines for All Milestones but not All Tasks

 Is more better? Maybe. Adding deadlines to tasks in addition to milestones MAY be good to do in some cases. In general, add deadlines to regular tasks only IF there's a need

Use deadlines sparingly

There are very strong reasons for following this rule: Add deadlines for ALL milestone tasks (see Deadlines for Milestones). But I don't really have a strong reason for following this rule: Add deadlines only IF needed for non-milestone tasks.

My philosophy here is one of simplicity. Adding deadlines for milestones is trivial and easy to manage since there are typically only 5-7 milestones. But adding deadlines for non-milestone tasks takes more time since there are hundreds of line items in my typical multi-million dollar, 6-12 month projects. Besides, milestones with deadlines with the correct set of predecessors will automatically identify the non-milestone tasks in the critical path.

However, there have been times when I have specified deadlines for tasks. This would be when a task had a resource constraint: e.g., project members were going to be on vacation and would not be available to support a vendor with testing and training. The key tasks weren't major enough to be turned into a milestone since it didn't mark the end of a major phase. Since I had a real deadline on this task, I specified a deadline on a non-milestone task. And thus tasks in the critical path for that key task would turn red if anything slipped (even if the milestone itself was not impacted).

Bottom line: Specify deadlines for non-milestone tasks only IF necessary

Criteria 3 of 9: Place Milestones Strategically

Milestones are the legs in your schedule: Place these "legs" in the right places to establish a stable schedule. Stability ensures you can forecast when your milestones will slip

Early-Warning Detectors

The philosophy behind placing milestones in the right places is common sense: milestones are your early-warning indicators for schedule slips. They alert senior management and you to the phase of your project that will miss the deadline. As we covered in an earlier post (Do you have too many milestones?), it's much, much easier to manage projects containing hundreds of line items with a maximum of seven milestones.

But an additional criteria of a good schedule is to strategically place these milestones. Some PjMs (Project Managers) prefer to cluster their milestones near the end of the schedule. But on my projects, I don't want my stakeholders to feel like the impact of a late task won't be seen for months. So in my schedules, I have my milestones spaced throughout the project's SDLC (Software Development Life-Cycle). This way everyone sees the impact to the current project phase.

Waterfall Milestones

For example, in my waterfall-based SDLC, I have six phases. The purpose of each phase isn't important. But note that there is at least one milestone per phase.

1. Ideation
2. Initiation: M1 = project receives approval from sr. management to proceed
   
3. Planning: M2 = requirements are baselined and design work can begin
   
4. Execution (lab): M3 = Lab entrance + M4 = Lab exit
   
5. Execution (production): M5 = Production start + M6 = Production end
   
6. Close-out: M7 = Project end

As we all know, creating a milestone is easy. One way to create a milestone is to set the duration to 0 days and MS Project automatically classifies it as a milestone. And with the automatic color-coding of milestones (see Automatically Color-code Milestones), your milestones will be clearly distinguished from your regular work packages.

Of course, these milestones will prove to be poor early-warning indicators if you don't have your predecessors & successors correctly identified and if milestones are not assigned a deadline constraint. Both of which I'll cover in a future blog post.