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”!