While management certainly can delay projects, and holding meeting asking why people are late doesn't help (and I've seen lots of both), management CAN help make projects happen faster.
The 1st step is the truism "Good, Fast, or Cheap, pick any 2". By actively deciding which of these are important, and living up to the decision, management can help a project--or certainly hinder it by changing focus or not acting in line with the decision. Management can also help provide special resources when necessasry--money for technical consultants, for example. Occasionally management can help make key decisions--not of detailed technical issues, but tradeoffs in the product definition when a stumbling block is found.
I think the point of this discussion is that there is a LOT of bad management, but managers who really care (about customers, employees AND stockholders), and follow through on that caring, CAN make a difference.
No, I'm not a manager, I'm a technical marketing guy who works closely with customers and our development team. I've seen lots of bad managers, and a few very good ones. The very good ones are priceless!
At a place where I once worked I complained about small parts volume, such as resistors replenished from corporate one at a time. A visiting manager explained to me that at $1.30 retail each they could not afford to keep many resistors in stock. He was not too pleased when I suggested that if they did not ship one at a time they would not have to be valued at $1.30 each.
I firmly believe that management can add delay to a project, but there is certainly nothing they can do to "pull it in". Usually all efforts to do so only cause the opposite to happen.
But I also believe the universe included the effect of excessive management in its planning. "Managers" have been around since man first gathered in groups larger than one.
I did have to explain to the folks at one place where I worked that if they kept some of the more standard parts on hand that tasks could indeed be finished in much less time. This was a place that would not intentionally stock 2 extra #4 washers, much less any slightly valuable parts. Ordering screws, nuts, and washers will add quite a bit of delay to a project. I am aware that a department with no stock of any kind is much neater, but that the resulting delays bother customers. My solution was to create my own stockpile by dismantling scrap equipment during my lunchtime. The customers that I was responsible for supporting were always pleased to find that I had the needed repair parts in hand and ready to go, rather than needing days to get the parts. Alas, it did not go with the company culture to provide instant customer service, and I left for a much better job.
My favorite analogy to engineering project schedules is world maps made in the 1500s. See: http://en.wikipedia.org/wiki/Theatrum_Orbis_Terrarum
They had no idea what the actual shape of the California coast was, but they knew it was probably there somewhere, and they made sure they put enough detail in that it looked like they knew exactly what it looked like. Did the experienced sailors look at or trust those maps? No. It was for the management and funders of the project. And maybe for the junior sailors.
"There Be Dragons" on your engineering schedule.
"The only way to finish sooner is to start sooner."
this is a very clear way to say the truth - I like it :-) But I believe its mostly true for smaller projects I think - when the organization becomes larger the general inefficiency gets bigger too.
A former colleague had put it that way: if the engineer to manager ratio is smaller than 10% then the schedule starts to loose predictability dramatically.
(actually he used this equation reciprocally and called it project-screw-up-factor ;-) )
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...