I've had this discussion almost verbatim with several project directors (the guys that project managers report to).
It's scary when they ask you to explain why adding manpower would make it later, and they don't understand. It's called Brooke's Law, and any project director who doesn't understand it doesn't understand project management.
It's scarier when they ask you to explain it, and they DO understand Brooke's Law, but they're just asking specific details about the project.
It's scarier because if you can't explain it, you have no justification for them not throwing another resource onto the barbie, which will make you later. If you can explain it, you're quite possibly talking yourself into a "promotion" to a project manager position you don't want.
At one company, I'd had this discussion with two different project directors a total of seven times on seven failing projects. The result was I had two standing offers to become a PM if I ever wanted to throw my hat in the ring. On the upside, having the ear of your PM's boss does come in useful, especially when the PM tries to pin failures on the engineering team...
A compiler-construction book I read decades ago said that if a compiler takes 1 person 3 years to write, it'll take 10 people 1 year to write, and a team of 100 people will never finish it.
(See also 'How Big Things Get Done' by Flyvbjerg and Gardner. IIRC, it's *mostly* about how big projects usually fail!)
That's another discussion I've had dozens of times.
I worked for a product based company. Perhaps it's fairer to say that I worked for a company that believe it was product based.
They did built commercial and civic infrastructure. Their first few projects were one offs, and after that first three or four, the next one would look at the previous ones, figure out which one it was closest to, clone that, and work from there.
Eventually, they decided to create a database with all the features from every project, and a test framework for it, and call it Product. From thereon after, all projects would be based on Product.
The problem was that they believed it was product, when really all it was was a reference platform. It was like building a dictionary based on English, French, and Italian, and saying it supported all language. Then the German project fails because umlauts are disappearing. The architects say "that's a special case". Then the Tokyo project fails because it doesn't support Hiragana. And the Delhi project because it needs Tamil. The Mecca project needs Arabic, the Tel Aviv needs Hebrew, the Moscow needs Cyrillic, the Beijing needs Pinyin, etc., etc.
I've seen PMs and architects seriously argue that Product worked for "the general case" when 28 out of 30 projects failed.
When your architecture only covers two out of thirty projects, you don't have a product, you have a reference platform.
One overlooked detail when adding or removing members from a team is that the team’s chemistry changes. Like Tuckman's stages of group development: Forming, Storming, Norming, Performing. It also takes time to onboard new members. And the larger the team becomes, the more complex communication gets.
I was the third member of a team that grew to twelve in about three years. The manager was an excellent manager when the team was three, four, or five people. At six, things started getting lost because of poor communication, and by ten, it was complete chaos.
He had a great informal, word of mouth based communication system, and a very informal decision making process. Those are great in a small, tightly coupled group, but it doesn't scale.
Conversely, I had another manager who was great at delegation and process, but terrible at making decisions. A one day decision could take him three weeks. He could control a team of 80 people, but he couldn't keep up with a team of 3; his processes simply got in the way.
They each had their place, it was just a matter of senior management realizing it and applying them properly.
PMs think if they assign a pregnancy to nine women, the baby will be born in one month.
I've had this discussion almost verbatim with several project directors (the guys that project managers report to).
It's scary when they ask you to explain why adding manpower would make it later, and they don't understand. It's called Brooke's Law, and any project director who doesn't understand it doesn't understand project management.
It's scarier when they ask you to explain it, and they DO understand Brooke's Law, but they're just asking specific details about the project.
It's scarier because if you can't explain it, you have no justification for them not throwing another resource onto the barbie, which will make you later. If you can explain it, you're quite possibly talking yourself into a "promotion" to a project manager position you don't want.
At one company, I'd had this discussion with two different project directors a total of seven times on seven failing projects. The result was I had two standing offers to become a PM if I ever wanted to throw my hat in the ring. On the upside, having the ear of your PM's boss does come in useful, especially when the PM tries to pin failures on the engineering team...
A compiler-construction book I read decades ago said that if a compiler takes 1 person 3 years to write, it'll take 10 people 1 year to write, and a team of 100 people will never finish it.
(See also 'How Big Things Get Done' by Flyvbjerg and Gardner. IIRC, it's *mostly* about how big projects usually fail!)
It will become Agile...
The problem with agile is that people forget that there's a silent "fr" at the beginning.
"We don't have the time to do it right, but we always have time to do it over."
That's another discussion I've had dozens of times.
I worked for a product based company. Perhaps it's fairer to say that I worked for a company that believe it was product based.
They did built commercial and civic infrastructure. Their first few projects were one offs, and after that first three or four, the next one would look at the previous ones, figure out which one it was closest to, clone that, and work from there.
Eventually, they decided to create a database with all the features from every project, and a test framework for it, and call it Product. From thereon after, all projects would be based on Product.
The problem was that they believed it was product, when really all it was was a reference platform. It was like building a dictionary based on English, French, and Italian, and saying it supported all language. Then the German project fails because umlauts are disappearing. The architects say "that's a special case". Then the Tokyo project fails because it doesn't support Hiragana. And the Delhi project because it needs Tamil. The Mecca project needs Arabic, the Tel Aviv needs Hebrew, the Moscow needs Cyrillic, the Beijing needs Pinyin, etc., etc.
I've seen PMs and architects seriously argue that Product worked for "the general case" when 28 out of 30 projects failed.
When your architecture only covers two out of thirty projects, you don't have a product, you have a reference platform.
One overlooked detail when adding or removing members from a team is that the team’s chemistry changes. Like Tuckman's stages of group development: Forming, Storming, Norming, Performing. It also takes time to onboard new members. And the larger the team becomes, the more complex communication gets.
I was the third member of a team that grew to twelve in about three years. The manager was an excellent manager when the team was three, four, or five people. At six, things started getting lost because of poor communication, and by ten, it was complete chaos.
He had a great informal, word of mouth based communication system, and a very informal decision making process. Those are great in a small, tightly coupled group, but it doesn't scale.
Conversely, I had another manager who was great at delegation and process, but terrible at making decisions. A one day decision could take him three weeks. He could control a team of 80 people, but he couldn't keep up with a team of 3; his processes simply got in the way.
They each had their place, it was just a matter of senior management realizing it and applying them properly.