My Problem with some Project Managers


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:

  1. Marketing communications
  2. Key events such as a World Cup, or Wimbledon which you can’t move
  3. 3rd Party dependencies
  4. 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.

2 thoughts on “My Problem with some Project Managers”

  1. Interesting blog, keep it up – the ‘physics of agile’ was neat.

    Having worked with PMs who set deadlines before even talking to a dev, I feel the date issue is symptomatic of the tendency some PMs have to view devs as chess pieces that can be moved about on a Gantt chart. Context switching is a costly process and a PM who keeps shifting priorities because they are driven by arbitrary milestone dates will waste a lot of developer time and create frustrated staff.

    Encouraging developer ownership of delivery and having the PM act more as a monitor definitely results in better outcomes. There is no better way to improve productivity than having small deliverables where devs have a constant sense of achievement.

    1. Thanks Wayne.
      Sorry for the seriously slow reply. I’m getting used to blogging and this was lost among comments which were spam.
      I completely agree, in fact I have a post on trust in draft…

Leave a Reply

Your email address will not be published. Required fields are marked *