4 Fallacies of Typical Project Management Thinking (Part 3)
Written by Ryan Downing
Part 3 – Providing a Very Detailed Schedule
As this series continues, we will explore another area of managing projects that many deem to be an essential element. However, my purpose for writing this is to make project managers aware that they do not always have to manage their projects in the same manner. There are definitely times when a fresh approach is needed.
#3 – Providing a Very Detailed Schedule
A day does not go by as I’m reading the news that I do not come across a story of a project that is called out for being significantly overdue. Headlines like “the project was scheduled to be completed on January 15 and now it is months late” give readers the impression that the project team is not doing their job.
When I read stories like this, I can empathize with the project managers because I’ve been a part of my fair share of project like this in the past. I would set a very detailed schedule with exact dates like January 15 or October 3 and then when the project moved past those dates, there was a sense of failure for not finishing on time.
What I have learned in that setting of exact dates – especially ones that are far into the future – is risky for project managers to do. One thing that happens when an exact date is given is that it can be marked on calendars and if the project goes past that date, it is very obvious that a date was missed which paints the project manager and project team in a negative light.
The way I have been able to avoid doing this is to set more general timeframes and only commit to an actual date on the calendar when I have a high confidence that my team will be able to make that date. For example, I will say that an activity like this typically will take 2-3 weeks. That way, there is no actual date given that can be written down. Then even if the date extends past the deadline, there was never a firm commitment that it would be completed at a certain time. This gives the project manager the ability to still provide a customer with status updates but not over commit to actual deadlines.
I was on the other side of this once and the company that I was working with needed to get my team information. On multiple occasions, they gave specific dates like, “we will have this information to you by Friday”. When they did this, I put a calendar reminder in for the day they gave me. When the information was not provided, I asked the very same day and they gave a new exact date. Again, I put a reminder on the day and this date was also missed. After several iterations of this, my project team lost most of our confidence in that company to be able to deliver according to its promises.
The lesson I learned from this situation and others like it is that it is better to provide schedules as more general timelines based on historical norms than it is to give an exact date. For if an exact date is missed, it reflects much more poorly on the competency of the project team.