Search This Blog


30 January 2012

I don't believe in slipping dates

You're in the weekly project status update meeting. The agenda has been reviewed. Last week's minutes are quickly discussed. The PM asks for any new business and finally its time to do that last task we all dread...

Review the project schedule.

The PM opens up MS Project, filters by task end date and asks everyone in the room for a status of the tasks that will end during the next week. Its a painful process, takes at least half of the meeting and most everyone is checking email while their colleagues provide updates.

After all the updates are added to the schedule, the PM asks Project to calculate a new end date, only to find that the project just slipped two weeks.


Now the PM goes into panic mode. How did this happen? We were ahead of schedule last week and now we're going to be late! Where is the slack time? Who is on the critical path? Can we crash this thing back to baseline?

Or is it?

This situation has always bothered me in ways that I never really could put my finger on, but this week I think I finally understood why this bothers me so much. While on my commute, I was listening to the Back to Work podcast, featuring Merlin Mann and Dan Benjamin, and the topic focused on projects and slipping dates. Merlin's main points were not directly related to my epiphany, but it did get me to thinking some about the whole concept.

Here's the deal... I don't believe dates ever slip, no matter what happens in the project plan. Dates are fixed, and not just because some executives says so. The day a project is over, with whatever system or process changes implemented, is the day it was done. It doesn't matter if that day was weeks early or years late, that is the day the project finished. You can't go back and change that date and since it is now live, you can't go forward in time and make it go live again (at least not with that particular phase).

End dates are always fixed, but what isn't fixed is our understanding of that date. Its possible, maybe in probable, that at some point during the project, something will come up which alters our perceptions of the project and how close we believe we are to its end.

The end date did not change, only our ability to accurately see that end date.

Big deal, you say, the effect is the same. That is true, but I believe that understanding end dates in this way changes our perception of projects in general.

If dates 'slip', this is seen as a bad thing; like we're not doing our jobs or that something unforeseen has impacted the schedule in a way that is not easily recoverable.

If my view is correct, then new information has been assimilated and we now have a more accurate picture of reality.

I don't know about you, but I think my viewpoint feels a lot better.