Friday, August 13, 2010

Is On Time Often Over-rated?

Is delivering something on time more of a goal for most of your projects?

Many projects never set firm end dates because they understand that the project requirements may change throughout. When the project ends, typically past the original end date we celebrate! Right? Yes! Cake for everyone because we knew upfront the date would slide.

Now what about the project that has set requirements and you blow by your initial end date by months and the product is full of bugs? Cake for everyone! Why? The project needed to be completed and the lessons learned were that we didn’t have the right durations for the timeline.

Now what about an end date constraint? We hit the end date, but several of the requirements needed to be dropped to meet the timeline. Cake for everyone!

Many times on time is defined by the organization. Many organizations understand that dates may be pushed, or requirements dropped or added, or finished software may have bugs. If this is business as usual then you may be eating a lot of cake!

The true indicator is how risk adverse the sponsor is to a slipping timeline? They may be the first to market for a product so they may have a low threshold for slippage. Or if they are building a software package that is a must have for the business, but they have an older system in place that is working fine, then they may have a higher threshold for the timeline to slip.

How do we control this slippage? Make sure you have all of the right stakeholders at the start to define the requirements and build the timeline. Bonus structure. I’ve seen and have worked for organizations that have given a bonus to the PM (and sometimes other stakeholders) for meeting a milestone like the end of the project on time. Communication!  Remember 90% of managing a project is communication.  Or you can “Let them eat cake”!

Related links:


  1. If you fail to maintain the integrity of the baseline, you can't expect to have a completion date "on or before" the planned date.

    Requirements change, so should the baseline. Changing requirements in the absence of assessment of the cost and schedule impacts makes you late and over budget. You get what you deserve at that point.

    Tolerating this behavior is simply bad project management.

    All elements of the project are random variables, managing in the presence of this uncertainty means understanding the impacts of change and acting accordingly.

  2. Ryan, that's a great post! Thanks for giving me a heads-up about that on my post at I love your insights and your writing style. Thanks for being a clear voice for project managers!


Your comment will be reviewed to determine if it is appropriate. If you are adding links to your products, your comment will not be posted.