There is, of course, much more to project management than telling software engineers what to do. Nevertheless, part of the job will involve contact with the engineers working on the project, or with their team leader, depending on how things are structured.
I don’t think I’ve ever seen a project where there wasn’t a degree of friction between the project manager and the engineers. This seems an almost inevitable consequence of the necessarily different world views held by the two disciplines. It is sad, though, that project managers so often manage to fit themselves into the project management stereotype by acting in a particular way towards the engineers.
If you are a project manager, then my own pet hates are where you:
Point out to me that the current piece of work needs to be finished as soon as possible.
This is fair enough if I’m being given relative priorities on the pieces of work I’m working on, but if I have only one piece of work, then I’m likely to wonder why you feel this point needs to made. Given that I’ve been in the profession for more than a few weeks, it has already become amply clear to me that there is always too much work, and never enough time in which to do it. For you to state this blindingly obvious point implies to me that either:
All of these imply that you are unhappy with my peformance, yet what am I to do about it? Even putting in extra hours is not going to help. Software engineering is an intense activity, and those extra hours of work done while concentration is lacking due to tiredness will simply lead to mistakes that will take yet more time to put right later. Further, the accruing fatigue will cause productivity to fall even during the normal working hours.
Ask how long it will take to fix a bug.
The short answer is that if I knew what was wrong, I’d fix it now. The longer answer is that it is very difficult to assess how much effort is needed to fix mistakes until they have been fixed. This applies particularly where the original error was made by someone else.
There are really two sorts of bug. Firstly, those caused by trivial oversight. These can be fixed straight away once the location has been found. The smartass reply at the start of this section is particularly pertinent here. The other sort of bug is caused by a structural defect in the software. Fixing them involves repairing the structure, but knowing how much of the structure needs to be touched is, to say the least, hard. The best I can really offer is some lower limit. There is an upper limit, it’s the time taken to rewrite the thing from scratch, but that option, though it may ultimately be taken, is not usually the course initially pursued. It is a sad fact of life that fixing some bugs can cost more than it would have cost to do the whole thing again.
Challenge an estimate.
If you don’t want the answer, then don’t ask the question. If, having received the answer, you don’t like it, then substitute your own figure. There is absolutely no point in expressing doubt that my estimate is correct. Were I to exhibit the very normal human trait of wanting to please (doubtful in my case), you might be able to get me to give you a lower figure. That doesn’t mean that the task will take any less time. All it means is that there is a lower probability that the task will be complete within the estimated time.
What you can do is ask for an assessment of how reliable the estimate is. It may be the result of sticking a wet finger in the air, or it may be the output from a detailed consideration of the subtasks and inherent risks. If it turns out that the former is the case, you can ask for me to do the work necessary for the latter. Of course, I’ll need time for that.
Comment that a task has taken longer than was estimated.
This is another of those "what's the point?" type observations. An estimate is just that - an estimate. Some tasks are expected to take less than the estimated time. Others are expected to take more. How wide the spread is for a given task is a measure of the risk element. In all the years I've been working, and been asked for estimates, I don't think I've once been asked about the risk element involved in a task. The extent of the risk shouldn't affect the probability that the task will be completed within the estimated time, but in practice, the greater the risk, the higher the chance of overrun. This is probably a natural consequence of ones realisation that where estimates are substantially higher than the project manager's expectations, one will be asked to justify them. A project manager should always ask about the risk inherent in an estimate, and should probably inflate the estimate where the risk is high. As I've indicated above, bug fixing is always a high risk activity.
Try to be involved at the technical level.
The technicalities are what the engineers are here for. You don’t tell your dentist how to drill your tooth. You don’t tell the surgeon how to fix your appendix. Why do you feel that you can tell engineers how to design and implement software?
Don’t assume that you know as much or more about this than the engineers do just because you’ve ‘climbed’ the promotional ladder to become a project manager. Some software engineers have no desire to be anything other than engineers. Some will have vastly more experience in this field than you do.