Re: @Rocket Rabbit ... With maths and syntax like that
Dear Mr Sitkowski,
As a trained-software-developer-turned-project-manager, I can say that you are quite wrong.
You see, before something is a project that is being executed, there's a bit that is called "sales". Very often there are market pressure that sales people have to adhere to, and that means that often enough that a service is sold for less than what is effectively necessary to come in on budget. This is called "discounts". You then see that the end result of the discounting process is the project budget. This is incorrect accounting, however the project manager is then ultimately responsible for cost overruns, even though it was the business who decided to give the customer a large discount.
There's also unrealistic expectations set by clients, whereby clients cause project starts to be delayed (due to contract negotiation or holidays), but the same clients forget that that automagically means that the end date is shifting as well. Such clients are then normally very adamant that the end date stays the same, even though we're now 3 or 4 months delayed from a project start point of view only of themselves.
Only then are we starting to get into the game where a project manager can really influence the course of action.
And even if a project manager understands the technology (because he is / was a software developer), I've seen some very very bad examples, and I'll give you two:
1) Shit is hitting the fan, project manager states: I knew this was going to happen; yet "this" failed to registered on any risk log and was never mentioned to senior / programme management - so there never was adequate risk management. But clearly "I knew this was going to happen" means that the project manager understood very well what problems could arise
2) Multiple 3rd parties involved where the customer is not efficiently participating in multi-vendor management. This may mean that delays by one of the 3rd parties causes budget overruns for another 3rd party, as the customer still wants to stick to the project schedule. This might come to play when you *think* the other 3rd party is going to respond within 3 business days, you confirm this with the client, and the other 3rd party turns around and says that their contract stipulates 2 business weeks... Lots of delays, nothing to do with understanding technology...
So your statement is a bit sporty, and not always correct.