I’d like to start by saying my problem isn’t with project management, it is with a large number of people who are project managers of software delivery…..
In my opinion there are many ways to manage delivery, and when the delivery involves knowledge work (as software development clearly does) a focus on one blunt instrument is not useful or successful. That blunt instrument is the date of delivery, hence the date stamp image!!
Firstly being able to answer the who, what, where, when, why and how is important, missing this first step and jumping to when is a false economy. If you explain the why and the what to the team(s) who are going to work on the delivery you are more likely to get good answers to where, how and when.
Secondly you can ask for a critical path and you might be lucky that it falls out of a PMs Gantt chart, but more likely if you are working on anything with any complexity you would be better off making sure each delivery is valuable and de-coupled first then only managing the “critical path” for key deadlines where things need to line up. If you need a critical path, I think it is far better to think of the variance and likelihood of each teams delivery (by asking them) as a compound distribution / tolerance stack-up. This problem of variance can then be addressed by helping teams lower variance, often by creating clarity of requirements and focus on less scope, more iterations and therefore faster feedback.
There are times you might want to be date driven, for example:
- Marketing communications
- Key events such as a World Cup, or Wimbledon which you can’t move
- 3rd Party dependencies
- Impacting on people (e.g. you are automating a process and they are managing the date to roll off some contractors doing manual work)
I believe each of these challenges can also be met without obsessing over the date. While you can’t move the start of the World Cup you can plan in advance, the World Cup date is know well in advance. 3rd Parties can be managed with the same principals as internal development, such as defining an interface (be that JSON web-service or internal library) and then managing the variance again.
In summary I think the date is a mind-set / blunt tool used to communicate, where a clearer focus on the goal and the data used to track progress and iterate towards the goal are far more powerful. These tracking approaches can be joined with a focus on abstracting the biggest challenges and explaining them to stakeholders, rather than trivialising down to a Gantt chart.