I will pick on project managers here because it is easy to spot this error in others, but what I am interested in, is how do developer manifest this same behaviour ?
Working on a project that has month bound delivery points, i.e. if you miss by a day, then you miss by a month.
The Key developer on the project raises the flag that we are not going to make the scheduled delivery date, there is just way too much still to do. Not specifically because the list of to-do's is still big, but simply because there is lots of integration that still needs to take place, an vast experience has shown that something will come up in this domain.
Now you would think, being outside of the pressure situation, the project manager would see this, understand and continue to clear obstacles out of the way… but wait no… because the pressure is on to make it happen, what does the project manager do, well the thing that the project manager knows best…. Set up a meeting to discuss the work that still needs to be done; create get new estimates on the out standing work, look for ways to shuffle the resources on the remaining work; Understand exactly how late it, etc etc
But why… surely the heart of project management is 2 fold
1) Remove obstacles, and
2) try to predict when there will be a slippage.
Now the interesting part to me is that in this case the slippage has already been detected, so why go through the PM exercises designed to determine if there is going to be slippage… we already know ! And the remove obstacles is always valid, but ironically the meetings ( there were 3 formal ones in this case ) were the obstacles in this case that needed removing. Everything that was done was in fact counter productive to the 2 key elements of project management.
So why ?
I would have to assume that this is because when the pressure is on, you go back to the thing that is certain and concrete.
Creating timelines is something you know you can do, and at the end of it you will have a real something to show the pressure above. Removing obstacles on the other hand is a soft science, and near impossible to show to the pressures above.
Imagine trying to explain to someone when they asked… “"So the project missed its deadline, what did you do to try and prevent it ?”…. “umm well I chose not to have ‘strategy’ sessions so I would not become an obstacle” … despite the truth I can understand what that would be a hard option to sell.
It is so easy to point fingers from the other side, but what do developers do that is similar when under pressure ? What are our technical crutches that actually get in our way when we ought not use them ?
