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 4 of 9: Deadlines for Milestones

Deadline hanging over you? A good schedule needs to have deadlines hanging over every milestone

Deadlines are your schedule's fuel-gauge

Milestones are meant to serve as early-warning detectors (see Placing Milestones Strategically). So it shows good project management skills when a PjM (Project Manager) specifies milestones with deadlines. The benefit of a deadline constraint is that two visual indicators appear the moment tasks for a future milestone will be missed:

• red diamond: this icon appears in the info column
• red tasks: predecessor & successor tasks in the critical path for this milestone turn red (will cover how to make the critical path turn red automatically in a future blog)

Having a visual indicator sounds like a small benefit. But think of these visual indicators like the fuel gauge & the fuel gauge indicator on your car dashboard. Remove those two indicators and you'll have to constantly worry about whether your car is running out of gas. You'll have to constantly read the odometer to see if you need to fill up the tank.

A PjM without the deadline constraint in the milestone (and the resulting red diamond & tasks) will be analogous to the driver constantly reading the odometer instead of the fuel gauge. He'll have to read the dates for hundreds of tasks in his schedule. On all my projects, I always specify a deadline on each of the seven milestones (see Do You Have Too Many Milestones). And so I see automatically, rather than manually searching, missed milestones months in advance.

Create deadlines for milestones

As the screenshot shows, setting a deadline is fairly straightforward and takes only a few seconds to set up. So really, there's no excuse for not setting up deadlines on your seven or so milestones.

Fig. 1: Make sure all milestone tasks have deadlines specified

1. Double-click on a milestone task
2. Go to advanced tab
3. Specify a date for the field Deadline

Bottom line: Spend a minute or so on your schedule to ensure that all your milestones have deadlines

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.

Notes - Record Notes for Tasks

Memory like an elephant: Project Managers don't need the memory of an elephant to remember the details of each task in a schedule

PjMs are Information Managers

Most PjMs (Project Managers), of which I am one, have to juggle four to six projects a week. And each project may have several hundred line items in the schedule. And on weekly calls with stakeholders, we're expected to remember the details of each line item for literally hundreds of line items per project.

Many PjMs manage this info by recording notes in weekly meeting minutes (docs or emails) that they then send out. I personally dislike this approach since now you're increased the places where info is stored. For a 30-week project for example, you now have project info scattered between the project schedule and 30 emails. And then, on status calls, PjMs bring up the previous week's meeting minutes to identify what happened to a particular task. Or they leverage the knowledge of a task owner who is on the call to remind everyone what happened with that task and identify next steps.

And once they're done creating the meeting minutes, they may switch to the project schedule and cover the necessary line items pertinent to the call. And this does a dis-service to the schedule since new tasks were identified in the meeting minutes that were not added to the schedule. Or dates and deadlines have changed which have to be updated by the PjM after the call (wasting his limited time). And what's worse, stakeholders don't always see the connection between topics discussed on the call and the relevance to the schedule. Remember, people on the call are multi-tasking (or surfing the web) and so won't be actively trying to connect the dots.

One of the tasks of a PjM is information management. And a good PjM should be able to manage all this info to make it more palatable.

Put all info in your schedule

The way I manage all this information is to use the Notes tab for the task in MS Project. During my status call, the primary document that everyone sees is my MS Project schedule. We review all active & late tasks (see Show Active Tasks & Keep Tasks Green) by checking the notes tab for those tasks.

1. Access the notes tab by double-clicking on a task > Notes
2. Record notes from a status call live as team-members provide status
3. Click OK to save notes
4. The notes icon appears in the information column to indicate there's more detailed info about that task

I record notes for a task during my status calls live so my team sees what I understood as well who made those comments. This way, my team will correct me if I've misunderstood the conversation around the task. But I don't just wait for weekly status calls to make updates to the schedule. I also paste email snippets into the notes tab on a daily basis.

I've found pasting email snippets to be extremely helpful in connecting the ton of emails I get to the project schedule. In fact, when I find emails discussing a task that's not recorded in my schedule, I create a new task as a result of that email.

Bottom line: You should be able to connect all conversations, status calls, emails, etc the project schedule by pasting a snippet of that discussion in the schedule. If not, you're missing a task in your schedule.

How do I display open tasks?

Shortcuts are faster: Only display active tasks in your project schedule by filtering for incomplete tasks

Philosophy
One of my pet peeves is, during weekly Webex status calls, a Program/Project Manager (PM) displays his project schedule and he continues to display all the closed or completed tasks i.e., tasks that are 100% complete. While this may not sound significant, remember that one of the tasks of a PM is information management. And information management is the art of delivering (or displaying) only the key information that stakeholders need to see. I certainly don't like having to visually wade through tasks that are no longer relevant to the project. PMs should only display open or incomplete tasks (i.e., tasks that are less than 100% complete).

Or if you need the research of why less info is more to be convinced of the benefits of keeping things simple (kinda like Apple products), check out this book "Made to Stick." This books explains beautifully why some ideas stick to people's minds and others do not. One of the six core elements of making ideas (or in our case, schedule info) sticky, is to keep it simple. Yes, KISS!

Steps

The screenshot above shows how MS Project makes it really easy to display only open (incomplete) tasks. There are two ways:

1. Point & click: Project > Filtered for: Incomplete Tasks > Incomplete Tasks
2. Shortcuts: [ALT] + P + F + N

How I display open tasks 
My favorite way, because it's the quickest, is to use the shortcuts. When I'm walking through the schedule with my project team, I typically have the tasks already filtered to display only open tasks. But every now and then, I've had to display all tasks (open & closed). Because I've practiced it so much, my fingers automatically hit [ALT] + P + F + A (to display all tasks). And once I'm done showing my team the closed task they had asked about, I automatically hit [ALT] + P + F + N (to filter on only open tasks).

Or when I've closed out a task by marking it at 100% complete, my fingers automatically hit the shortcut to hide the closed task. A closed task should be hidden the moment it's been marked as closed. Out of sight, out of mind, right?

Try practicing both these shortcuts for a few days to make it come automatically to your fingers.

How do I automatically show active tasks?

Active tasks: Use light-bulb icons to indicate which tasks have started

In my weekly project calls with stakeholders, I use light bulb icons to identify which tasks to discuss, update with status info, etc. 

Because my project schedules typically have a few hundred line items, I really don't want to be reading each line in the schedule to see which task is active. Believe it or not, other project managers actually read start dates for each task (out of hundreds of tasks) to see which tasks to ask for status or discuss!

My philosophy is simple: look but don't read. So I stuck in a simple formula for MS Project to use to automatically display light bulb icons for active tasks (start date >= today's date).

Time needed: <3 min

1. Insert a column (preferably to the left of the "Task Name" colum)
   • e.g., right-click on Task Name column > Insert Column > Field name: Text 1
   • Title: Start
   • Align data: Center
   • Ok
2.  Add a formula to determine whether a task will finish on time, finish semi-late or finish really late
   • e.g., Right-click on "Start" column > Customize fields > Highlight Text1
   • Select formula > Ok > Formula
   • Paste this formula in box: IIf([% Complete]<>100,IIf([Current Date]>[Start]-1,1,0))
   • Ok
3. Add graphical indicators to the formula
   • Click on Graphical Indicators button
   • Indicator criteria for: Nonsummary rows
   • Test for "Finish on Time?"
     • equals    1.00   [Select image of lighted light bulb]
   • Ok > Ok

Keep Tasks Green

A green schedule: Make sure that all tasks in your schedule are green

Philosophy of green schedules

As part of my weekly status calls with project stakeholders, I review two types of tasks:

• Open tasks: light-bulbs indicate whether someone should be working on the task (see light-bulb blog-post)
• Late tasks: red & yellow tasks are tasks that have missed or will miss their finish dates (see traffic light blog post)

Every status call invariably has a few tasks with yellow or red traffic lights. Some tasks show up late even though they completed on time.

Remove red & yellow lights: Change the finish dates to get green tasks and thus see if major milestones will still finish on time

This normally happens if I, as the PM, was not on the email chain mentioning the task had been completed. In which case, I close the task once notified. And the late indicator disappears.

But there are frequently tasks where the task owner says that the task requires more time or he hasn't started working on it. In which case, I ask for the new ETA and update the finish date. At which point the late indicator should  turn green.

Benefit of green schedules

Setting new finish dates, as opposed to leaving finish dates unchanged, helps show how finish dates for downstream tasks are changed. And as a result, whether major milestones are impacted. If red diamonds (late indicators for milestones) appear as a result of a task owner's new finish date, the whole team on the call sees the impact. And then it's trivial to negotiate for an earlier ETA.

Of course, you see this benefit only if you've correctly defined your predecessors & successors. But that's a topic for another blog post.

How do I Automatically Show Late Tasks?

Late indicators: Balls change color automatically depending on whether task will finish on time

Follow the three steps below to get  late task indicators such as shown in the screenshot. Colored balls indicate whether a task will finish really late, semi-late or is on track for finishing on time. 

Time needed: <3 min

1. Insert a column (preferably to the left of the "Task Name" colum)
   • e.g., right-click on Task Name column > Insert Column > Field name: Text 1
   • Title: Finish on Time?
   • Align data: Center
   • Ok
2.  Add a formula to determine whether a task will finish on time, finish semi-late or finish really late
   • e.g., Right-click on "Finish on Time?" column > Customize fields > Highlight Text1
   • Select formula > Ok > Formula
   • Paste this formula in box: IIf([% Complete]<>100,DateDiff("d",[Finish],[Current Date]))
   • Ok
3. Add graphical indicators to the formula
   • Click on Graphical Indicators button
   • Indicator criteria for: Nonsummary rows
   • Test for "Finish on Time?"
     • is less than    1.00  [Select image of green ball]
     • is less than    3.00  [Select image of yellow ball]
     • is greater than or equal to   3.00  [Select image of red ball]
   • Ok > Ok

That's it! You're done. Now MS Project will automatically display which tasks will finish on time, will be semi-late, or really late. Key rules to keep in mind:

• NO BALL: Task has completed. Only incomplete tasks (< 100%) will have colored icons indicating whether it's late or not. Summary tasks (complete or incomplete) also will NOT have any colored icons
  
• GREEN BALL: Task has a chance of finishing within 1 day of the planned finish date
• YELLOW BALL: This semi-late task is missing planned finished date by 1-3 days  
• RED BALL: This really late task has missed planned finished date by more than 3 days
• To change the criteria for the tasks that will finish late or really late, just change the # of days (currently set to 3 days) to the # of days you prefer

Automatically Color-code Milestones

Fig 1: MS Project will automatically format tasks such as milestones if the text style is defined

Philosophy of color-coding milestones

My basic philosophy with the schedule is to keep it simple: look but don't read. Which means that the 5-7 milestones (see blog post on Too Many Milestones) should visually stand out. I shouldn't have to look for 0-day duration tasks to identify when I'm looking at a milestone.

MS Project provides a nifty way of automatically formatting tasks (milestones, critical tasks, etc).

Steps to auto-format milestone tasks

1. Format > Text Styles (see fig. 1)
2. Items to Change: Milestone Tasks (see fig. 2)
3. Select the text color and background (I normally choose a lime green background that's bold)

Fig. 2: Select the task that you want formatted

How do I align text in columns?

Change titles: Unhappy with the alignment or labels for the titles? Just double-click the titles to edit them

If you're interested in changing the column for the graphical indicators after it's been created - change alignment or change column heading - just double-click the column header and you'll have five properties of the column that you can change:

• Field name: Text1
• Title: Finish on Time?
• Align Title: Center
• Align data: Center
• Width
• Header Text Wrapping

Why Show Late Tasks using Graphical Indicators?

• Key Point: Save time by using MS Project to automatically mark tasks that have failed to complete on time

On large projects that I've managed (200+ line items), it's always been a pain and a time-waster to actually read the "Finish By" dates to see if any particular task is late. I've seen some PMs who would, before their weekly status call with stakeholders, manually read through 100+ line items and manually highlight late tasks in red! And then on their status call, would ask the respective owners to provide new ETAs so the tasks would be on track.

But there's a better way of showing late tasks.

Automatically indicating which tasks are late in finishing is easy to implement: five minutes at the most. Moreover, as shown in the screenshot, MS Project has some nice visual indicators that you can use to indicate four states:

1. NO BALL: Task has completed
2. GREEN BALL: Task still has a chance of finishing on schedule
3. RED BALL: This really late task has missed planned finished date by more than a few days
4. YELLOW BALL: This semi-late task is missing planned finished date by 1-3 days

As you can see, it's easy for the eyes to focus on all the really late tasks (RED BALL) and semi-late tasks (YELLOW BALL). And in future posts, I'll show how you can filter on really late or semi-late tasks: management will like this filtered view since they're only in interested in focusing on problem tasks (late & semi-late tasks).

Knowledge vs Information

Knowledge = Information that is Practiced

One key point to emphasize is that this blog will heavily emphasize on implementing information so it becomes knowledge as shown in the knowledge funnel. All of us get tons of project management information from two sources:

• Literature (1-way medium) e.g., books, magazines, blogs, articles
• People (2-way medium) e.g., other project managers, general management, project stakeholders

These two buckets of information end up being filtered by our experience or things that we encounter or tasks with which we experiment. And knowledge is the processed information that pops out at the other end of this information funnel.

For example, I first read about  Monte Carlo simulations in Waltzing with Bears (literature). After talking to a Microsoft Solution Manager who actually had implemented this method (people), I tried using it for coming up with ranged estimates i.e., task X will complete within 10-15 days instead of single-point estimates (task X will complete in 10 days). Liquid Planner, an online alternative to MS Project, has Monte Carlo simulations  built in and is really cool for predicting the probability of completing a schedule by a certain date.

In fact, in one project, after putting together a schedule for a project, I had told my management that we only had a 10% probability of meeting the desired date and a 90% probability of meeting another date that was nearly two months later. While we decided not to share this info with our  client, at the end of the project, the Monte Carlo method had amazingly enough predicated the correct date to within a few weeks of accuracy!

But despite this very educational experience, I stopped using Monte Carlo because my consulting situation in another large firm didn't allow for online project management tools. And using the Monte Carlo method within MS Project 2007, the only authorized project management app, proved time-consuming. Still, it was valuable experience gained using this statistical technique.

So, whenever you read a post, my recommendation is that you try for a week or so what's been posted to see if the specific schedule management technique works for you. If it doesn't, please do drop me a note letting me know why it didn't work for you. I'm always interested in learning when specific techniques work and when they fail.

And don't worry.

In future posts, I'll spend less time pontificating and focus more on actionable information  that you can implement and thus turn into diamonds of knowledge.

A few, simple rules

In over 15+ years working with both cash-starved startups & Fortune 500 companies, I've seen and used dozens of project management tools:

• MS Office apps: emails, spreadsheets
• Desktop solutions: e.g., MS Project
• Online solutions: Smartsheet, Zoho Projects, BaseCamp, LiquidPlanner

And this is not including the countless books on project management (Critical Chain, Waltzing with Bears, PMP) and some of the ideas I borrowed from good project managers with whom I've worked.

But at the end of the day, all this info could be distilled and filtered down to a few principles and rules to follow to maintain a well-managed project schedule. On a weekly basis, I'll blog about these principles and specific rules that I use to tightly manage my schedule. I've seen some poorly created project schedules (yes, even with those with PMP certification) that could have been significantly improved by following a few simple principles.

Hope these principles I'll be blogging about prove as useful for you as they have been for me.