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.


  1. Excellent points. We should be more concerned about developing estimates that support "the real" end date.


    1. Vicki, your comment requires some elaboration as clearly the majority of estimates are born out an intention to support "real" end dates.

  2. Fanatical attention to dates, or manage for value? Good point.

    Any suggestions on how to take this message to business owners?

  3. Great question, Craig. Sadly, I have no clue. Our PMO director, who I think the world of, doesn't seem to get this concept at all. Part of that is that our organization is date driven like no other I have ever worked at and talking till I am blue in the face hasn't changed that. If anything, its gotten worse over the last few years as the economy has refused to turn around quickly. Hard work can get things to finish faster, but not without the risk of burnout for your team. I'm all for stretch goals as long as everyone realizes people are not Gumby.

  4. Sorry to dampen your enthusiasm but there is something unreasonable in the perception that ‘we finish the project when we finish the project’. This mentality is only prevalent when we play with other people’s money, not ours. I wonder how you would portray this scenario should you be the sole owner of a business where a delay in delivery is costing you big $$$’s every day.

    Project delays are not just a reflection of an inaccurate estimates. Certainly, uncertainty can result in misguided estimates but this is not the only scenario that can unfold. Quite often missing deadline are a result of team member’s lack of appreciation to keeping on priorities and inappropriate time management. Reviewing the time line and exploring inefficiencies in the process can address such issues, as well as ‘reminding’ the team that dates and commitments are not arbitrary and should be taken seriously.

    Cheers, Shim

    1. Shim, I take your point. Teams need to be creative in finding ways to deliver within constraints.

      However many teams find their options for creativity and innovation stiffled by the bureaucracy than mandates particular methods, activities and and so on. Additionally systems issues such as bottlenecks in the workflow and collaboration barriers at internal organistional boundaries are often not addressed, at least not on a timescale that is useful for a project.

      These issues along with mandated dates make for a hard time meeting deadlines. At least with tools like earned value or velocity we can put up the data that says when the job is likely to be done with facts backing you up.

    2. Which means your discussions about what to do can be evidence based and changes to the operations of the projects can be measured and validated.

      Which is what we all want.

      But somehow politics and other things get in the way. What's to be done?