Pick up some books in the Agile Software Development series
A theme that was repeated there is that project management techniques are overhead. They are absolutely critical and necessary overhead as a project gets larger, but overhead they unquestionably are. You neither want too little or too much management overhead, and the subject of that series is figuring out where the happy medium is.
Here is my capsule understanding of the theme, for which I will neither guarantee accuracy or completeness.
You should try to figure out what your actual needs are, and aim for the least intrusive project management regime which is sufficient to your needs. Note the phrase "sufficient to your needs". Nothing will not do. But neither is it useful to apply a methodology scaled for 20 people to a project with 5. The two groups have different needs, and therefore require different methodologies.
So how do you judge "sufficient to your needs"? Experience helps. As does understanding what needs a methodology addresses. Here are some of those needs:
- Keep people from having to talk to each other. 5 people have 10 lines of communication to manage. 10 have 55. 20 have 190. It doesn't take long before people spend almost all of their time just talking to other people trying to learn things that they need to do to do their job. Appropriate organization and documents can channel communications and cut down how much time needs to be spent in conversation. These do not have to be bureaucratic in nature, for instance prominently placed whiteboards can eliminate a lot of repeat conversations.
- Allocate resources. Projects need resources. Resources need to be allocated from somewhere. Knowing the resource requirements ahead of time on projects allows management to allocate them properly, and also identify when you are overcommitted so that you can cut projects out of the pipeline.
- Reliable scheduling Businesses need to be able to plan ahead. Should we be planning to advertise the new product? Will we have resources to tackle another project in the planning stages? You don't want to be committed to an answer and then have to change it.
- Identify risks Good development processes aren't good because they do something really right. They are good because they avoid a lot of wrong things. An primary among them is having a plan that basically boils down to hoping that everything goes right. Because something is going to go wrong, you don't know what, you don't know where. But you want to be ready for it and you want to know how to address it when it does. Just knowing simple things like who is critical path helps.
- Control interruption rates This is special for programmers. Programmers become much more productive after about 20 minutes of focussed concentration. The average office environment interrupts you far more often than that, so you never get productive. Project management is one of many tools to arrange that your developers can have long periods of scheduled time where they can focus.
So those are the basic needs that official management addresses. The question that you need to ask is whether your team loses more time to the above factors than you have to lose with the paperwork of a more intrusive management regime, and the sheer deadweight of adding people whose job is to be (in Barry's words)
...a glorified secretary, sit there and take notes.Cheers,
Ben
Computer Science is no more about computers than astronomy is about telescopes.
-- Edsger Wybe Dijkstra (1930-2002)