Rules of thumb for scheduling

Many project managers mean well when they set the launch date for a project well in advance to the exact day. They often even specify 31 December and communicate this to the stakeholders to give them the feeling that the project will be completed within the year. This calculation may work for smaller projects, but for larger projects with a longer duration of several months or years, it becomes difficult.

This feigns a level of precision that often cannot be maintained and harbors the risk of experiencing what feels like a huge delay in the event of a small delay. I can't imagine that it is possible to plan so precisely so far into the future. Or so much reserve is built in that it is no longer reliable. Something can always come up: unplanned absences of project participants, delays in decisions, delays in deliveries from external suppliers, etc. Murphy's Law can apply to any project: 'If something can go wrong, it will go wrong!' This behavior is typical of a complex system and must be accepted and managed.

Accordingly, there are the following rules of thumb for planning:

1. Communicate a different level of accuracy for important delivery dates depending on the time horizon: the shorter the term, the more precise, the longer the term, the more approximate.
   This is mainly about external communication, but you can of course plan more precisely within the project. For example:
   • Up to three months in advance: specify to the day (1 January 2025)
   • Four to twelve months in advance: Specify to the month (April 2025)
   • More than one year in advance: Specify to the quarter (third quarter of 2026)
   Note that time is moving on. At the beginning of 2025, the date ‘April 2025’ is already short term and should therefore be specified to the day. This results in rolling, e.g. monthly planning, so that the delivery dates become more and more precise as the project progresses.
      
2. Do not enter the last day of the calendar month in the planning, but the first day of the following month (e.g. 1 January 2025 instead of 31 December 2024).
   There are psychological reasons for this. If the project is only one day late, it is ‘worse’ if it is not delivered in the old month or year, but in the new month or year. The project then feels one month or one year late, even if it is actually only one day late. However, if you specify the first of the month as the planned delivery date and make it to the second, this one day is usually manageable.
   With a suitable term, this can be supported very well linguistically. Instead of using a retrospective expression such as ‘system launched’, call the launch date ‘launch of the application’ on the first of the month, looking forwards. This also creates a customer-centered language.
      
3. Don't plan everything for the last day.
   Testing is often carried out on the last day and you are surprised when an error occurs. Testing is good, but earlier. Cyril Northcote Parkinson already stated in Parkinson's Law that time should always be used to the end: 'Work expands in proportion to the time available for its completion.' Plan to finalize the project one to two weeks before the official launch date, for example with a technical delivery date.

These are rules of thumb. Rules of thumb must be adapted to the respective situation and are often, but not always, applied. For example, there are projects that have to deliver on a fixed date right from the start, such as a data migration or system replacement. This makes it all the more important to plan in sufficient reserves. Otherwise, I have done very well with these rules of thumb in recent years. Good luck.