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.

Notes - Format your Notes

Format Who & When: Make your notes visually stand-out

Beautify Who & When

This is an optional item that you could do to make two pieces of info in your notes tab (see Record Date & Source) visually stand-out. Format the who & when pieces of info so it doesn't feel like you're reading a wall of text. It barely takes a second to switch formatting in the notes tab.

• [CTRL] + B --- toggles bold formatting
• [CTRL] + U --- toggles underlining

Admittedly, the value-add for formatting the notes is small. It's a nice-to-have visual aid that improves readability (as you can see from the screenshot above).

Notes - Record Date & Source

Who & When: All your notes should specify who said what and when they said it

Who, what and when?

Some PjMs (Project Managers) do a good job recording what was said but not who or when that comment was made. This creates the problem of figuring out how long a task has been open or if notes are too cryptic, who we can contact to understand the task.

As you can see from the above screenshot, I always include three pieces of info in the notes tab of MS Project:

• What was the comment made about the task?
• Who was the source of the info?
• When did he make the info?

Keeping the notes tab well-documented is actually not time-consuming at all. It takes me less than 30 minutes a day per project to ensure all active tasks are updated (see Update Daily).

Another benefit of this tab is that it proves extremely valuable whenever projects are transitioned to different PjMs. There's been times when I've handed my project over to a new PjM. And while I dial into the status call to support the new PjM, because of the notes tab, the new PjM is able to conduct the weekly call without any help from me. The notes tab provides a rich source of high-level info for PjMs to get up to speed on a task very quickly.

On the other hand, when I take over projects, I have to hold multiple knowledge-transfer sessions with the team to get context on the hundreds of line items in a schedule.

Notes - Update Daily

Update notes daily: Updating the notes tab in your project schedule is a MUST to stay on top of your project

An update a day ...

I normally spend at least 30 minutes a day updating the notes tab for active tasks. I don't wait for the weekly status call to make updates. Rather, as emails or conversations occur around active tasks (tasks with light-bulbs), I copy and paste snippets of notes into the notes tab.

I've found this very useful in getting a much deeper understanding of a task. Think about it: info will obviously be easier to remember if you're actively connecting emails and conversations back to specific tasks in a schedule AND you're pasting that info into the task notes section.

I've had directors challenge me on why a task has slipped or why the task is important and within less than 30 seconds, I'm able to skim through the notes tab for the task and give him a good answer. I've even been able to use the notes section to remind task owners what they had committed to weeks or even months earlier.

In fact, I make it a point to ensure that I only move emails out of my Outlook inbox into a a project folder only after I've copied a snippet of that email and pasted it into the notes tab for that task in MS Project. Obviously there are some emails that delve too deeply, technically, into an issue. So I don't copy info from those emails into the notes tab.


Bottom line: This 30 minute daily task for each project schedule helps ensure your schedule is always up to date. And your schedule will thus be a very convenient source of info for creating meeting minutes, weekly reports, etc.