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.

Criteria 2 of 9: Do you have too many Milestones?

Too many cooks spoiling the broth? There should only be 3-7 major milestones in your schedule. More than that and it tends to spoil your schedule

Philosophy of Less is More

On projects where I play a supporting role, the second thing I look for in a schedule is how many milestones it contains. Most projects I've been on have typically around 200-400 line items in the schedule (one day, I'll blog about projects I've been on with over 500 line items and why that's a bad idea and how that should be delegated).

I recently received a schedule from a vendor that had over 20 milestones!

It's obviously fine to have minor milestones within different phases of the SDLC (Software Development Life-Cycle). For example, to have a milestone for starting requirements gathering and another for baselining requirements in the envision phase of SDLC. And even then, those minor milestones are there only IF someone in the cross-functional team really needs it.

But at least color-code or have some sort of marker separating the minor milestones from the major milestones. And on my projects, even the muli-million dollar projects, have only had five to seven major milestones. There may have been times when I've ended up with eight milestones but I normally max out at seven milestones.

The magic number: Seven
The same reason we have seven-digit phone numbers is the same reason we stop at seven milestones: the short-term capacity for the average person is seven digits, plus or minus two. There's a fascinating article about the 1950s research about why our working memory can only hold seven digits (here). Perhaps that's why seven constantly comes up in history: seven deadly sins, seven wonders of the world, Shakespeare's seven ages of man, Harry Potter's seven horcruxes?

From a Project Management perspective, the major milestones are typically conveyed to management & senior management. And with the volume of information they need to deal with, looking at 20+ milestones is definitely not helpful in identifying what's important. But with 5-7 milestones, the task becomes much easier.

For example, the table below is an example of milestones I send out in my weekly emails after status calls with the project team. From management's perspective, they can see the major phases that will slip but which doesn't impact launch. This whole table is small enough, with only seven milestones, that it'll fit into management's working memory.

Phase Release Requested Forecast 1 Initiate 9/1 8/31 2 Envision 10/31 10/31 3 Design 11/5 11/5 4 Develop 11/10 11/16 5 Test 12/1 12/9 6 Launch 1/11 1/11 7 Close-out 2/1 2/1

Bottom line: Make sure your projects contain a maximum of seven milestones

Criteria 1 of 9: The Last Milestone

Target milestone: Do you know your target?

Philosophy

The first thing I do when I see another PjM's schedule, is look for the last milestone: the date when the project needs to be completed. More often than not, this milestone is listed. And it seems basic enough that this target date should be listed, right?

Well, yes, it tends to be listed in the project schedule. But sometimes, they make two mistakes with the milestone:

• Non-zero duration: it shows up as a task rather than a milestone. A milestone is a task that has a zero- day duration. And some PMs incorrectly specify the task as having a non-zero duration.
• Missing deadlines: Another common mistake is to leave out the deadline constraint for the milestone

Non-Zero Duration

This is a technicality that does make a difference when filtering for milestones. A task automatically becomes a milestone when you specify the duration as 0 days. Obviously, you can make a task that is five days long as a milestone by double-clicking on the task > Advanced tab > Check "Mark task as milestone."

But from a project management perspective, a milestone is like being pregnant. It's a binary condition: either you're pregnant or you're not. You can't be 25% pregnant. It's either 100% complete or 0% complete. That's why you use milestones in the first place: to clearly indicate that you've reached a key point in your project.

Besides, setting a milestone with a zero-day duration automatically marks the task as a milestone. Try creating a task with a zero-day duration, filter your schedule for milestones and you'll see what I mean. To filter for milestones, click on Project > Filtered for > Milestones. Only milestones will be displayed in your schedule.

Missing Deadlines

Another common mistake with milestones is leaving out a deadline constraint. Double-click on milestone in your schedule > Advanced tab > Deadline.

Do you have a date specified as the deadline in this tab?

If it says NA (not applicable), then you're losing out on an automatic warning alert that MS Project displays when a milestone is projected to miss a deadline. We'll talk later about the red diamond alert that is displayed for late milestones. So key point here is to specify a deadline for your major milestones.

On one project that I was on, the PM realized on a nine-month project that he was going to miss his delivery date only a couple of months before the due date! If this PM had specified a deadline for his final milestone, he would have been alerted months in advance by the MS Project red diamonds. On my weekly status calls, as the project team gives me new ETAs on slipped tasks, the whole team immediately sees the impact of that task on the delivery date.

A simple but very useful early warning feature in MS Project to forecast missed project completion dates.

Do I have a good schedule?

Confused by the schedule? There's only a few rules to follow to ensure that a project schedule makes sense

Philosophy

While not all team members on a project team need to understand a project schedule, it should be simple enough that a PM (Program/Project Manager) who is completely unfamiliar with the project is able to look at a schedule and figure out basics such as key milestones, view the critical path, etc. Some of the schedules I've seen, while good enough for the PM managing the project, is really difficult for other people to read.

I've been on projects where by the middle of a four-month project, the milestones are still missing predecessors & successors so critical paths are incomplete, red diamonds don't display even though the milestones will be missed, half the project contains ghost tasks, etc. If none of these points make sense, it'll become clearer in the upcoming blogs.

It may make sense at the beginning of a project to have an incomplete schedule, when a lot of the tasks needed to flesh out the schedule have not been identified. So yes, schedule development is a knowledge creation process: you learn more about the tasks needed to complete the project as you get deeper into the project. But by the middle of the project, you better have 90% of your schedule compliant with the content & presentation criteria below.

On my projects though, I typically have my schedule compliant with the criteria below at the beginning of a project even though I may only know 50% of the tasks needed to complete. You really don't need to know 100% of the tasks to have a good schedule. For me, a "good" schedule is one compliant with the following content & presentation criteria.

Content criteria

1. Do you know the requested date for the last milestone (here)?
2. Are there 3-7 milestones (duration = 0 days) in the entire project (here)?
3. Are milestones strategically positioned throughout the schedule?
4. Do milestones have deadlines assigned to them?
5. With the exception of the last milestone, are all milestones family tasks?
   • Family task = task with predecessor (parent) + successor (child)
6. Is the final milestone a sterile task?
   • Sterile task = task with parent but no child task
7. Are there only non-ghost tasks at the task level (i.e., non-summary tasks)?
   • Ghost task = task with no parent or child task
8. Is there a justification for having every single sterile task?
9. Is the info column clear of red diamond icons?
   • Red diamond = task will not meet assigned deadline

Presentation criteria

1. Are the following columns displayed?
   • Info
   • % complete
   • Start
   • Finish on Time
   • Task Name
   • Duration
   • Start
   • Finish
   • Predecessor
   • Successor
   • Resource Names
2. Do the project's main phases visually stand out?
3. Do late finish indicators show only green tasks?
4. Do light-bulb indicators show active tasks?
5. Are only incomplete tasks displayed?
6. Do all summary tasks have a maximum of seven tasks?
7. Are all major phases in the schedule visually separated from the rest of the schedule e.g., using highlighting?
8. Will tasks in the critical path for a milestone automatically turn red when a milestone deadline will be missed?
9. Do all summary tasks contain a maximum of 5-7 tasks?

The presentation criteria is somewhat subjective. You may have your own presentation style. But what I'm listing as the criteria is what I've compiled over the last 15 years from other PMs who have had schedules that were easy to follow.

In the coming months, I'll blog in detail about why each criteria helps make your schedule simpler and easier to follow.