Most project models are sort of useless in the modern office environment.
Waterfall is useless because nobody ever follows it. I agree that it’s sort of the “default” mode, but show me a project that didn’t go back and change something from a previous step.
Agile stops working the moment you need to sign any form of contract with anyone, because nobody is going to sign a contract that doesn’t tell them what they are going to get for X amount of money. Its processes are sort of fine on the smaller scale because it breaks project tasks into neat to-do-lists, but it’s utterly useless for actual project management because estimates are a lie and delivering on time is what is required to drive a project successfully.
Then there is everything in between from the various stage-gate models to UP and what not, and they are all equally useless because nobody ever really follows them and because they can’t really apply to every type or project which is what organisations tend to want.
I haven’t worked in a FANG or whatever you call the big American tech companies, but I have worked in the European Public sector and it’s affiliated private sector companies for years, and nobody has a magic project model in my experience. In many ways the most successful companies tend to be the ones who simply use some sort of Kanban board and refrain from giving estimates in intervals lower than weeks. I fully understand why organisations waste resources on this area of course, I’ve been in the trap myself many, many times and I’ll likely end up in it again, but the simply truth is that every project manager or business process person that you have is one less developer, and these helper functions don’t really add anything to your value chain the moment they start making up work for the sake of having the “right” processes in place. The best way to handle project management is to hire good developers who know how to deliver projects that are build safely and maintainable. That’s not easy, but no amount of project management is going to make up for the lack of them.
And I’m not saying you shouldn’t need project managers or have an organisational strategy, but if you’re hiring more support staff for your developers than you would for the tradesmen you’d hire to build your house then I think that you’re doing management wrong.
We build an entire city hall, a process that took almost a thousand different employees from very, very, differently ones of work and we did it with 1 project manager, 1 architect and 10 lead engineers. We did it on time and under budget, and that is how we build our IT projects as well. It’s sort of waterfall, because it’s what we default to like the author gets into, but maybe that’s because it works?
> Waterfall is useless because nobody ever follows it. I agree that it’s sort of the “default” mode, but show me a project that didn’t go back and change something from a previous step.
The issue is not if they change something from a previous step but When and how often does this "checkpoint happen"
You want an example of Waterfall?
The SLS: https://en.wikipedia.org/wiki/Space_Launch_System in development since 2011 and most probably will get scrapped once it finishes becasue the market sittuation has changed completly since then.
> The best way to handle project management is to hire good developers who know how to deliver projects that are build safely and maintainable.
The best way to do that is to train your senior devs to act as part time PMs.
In an environmental consulting environment (not software) all projects except for really big, multiyear government contracts were managed by engineers that were the project leads. That is literally what "lead" meant - the person who led (managed) the project. We only had one actual project manager, and he was as much sales/contract development as anything else.
I was a junior engineer, and I still managed small projects. That included costing, tracking hours/labor, and making sure that deliverables were complete.
Then when I started in software development/operations, I had to deal with non-technical PMs and wasted tons of time explaining why what they wanted was either not possible as specified, or otherwise a waste of time.
IMO, if your PM is not a technical person with expertise in the area of your project, you mare wasting money by paying their salary. Get your lead devs to manage your projects as part of their professional progression. Non-technical PMs are pretty useless.
> Agile stops working the moment you need to sign any form of contract with anyone, because nobody is going to sign a contract that doesn’t tell them what they are going to get for X amount of money.
Plenty of companies sign contracts like that, and it's not particularly controversial. Pay $X, get Y developers to work for T amount of time, with no guarantees what those developers are going to deliver.
I'm not at liberty to disclose company names, but I live in Finland and I can tell you it's normal here. It's basically equivalent to "renting" workers. I would be willing to bet that "rent-a-worker" industry exists in Denmark as well, and that it also includes IT work.
But rent a worker is small scale. It is not signing a multi million euro contract.
Consultants are a thing here, and they may be the closest companies get to not knowing what they buy.
I mean, I’m not saying that the other way works. All our major IT systems are delayed and over budget, but there are detailed and outlined requirements that aren’t delivered.
I've seen deals where a company sells a pack of consultants to a multi-year project with a price tag of over 1M euros. I don't know if this happens when the scale is 10M+, but it does happen at 1M scale.
> Agile stops working the moment you need to sign any form of contract with anyone, because nobody is going to sign a contract that doesn’t tell them what they are going to get for X amount of money. Its processes are sort of fine on the smaller scale because it breaks project tasks into neat to-do-lists, but it’s utterly useless for actual project management because estimates are a lie and delivering on time is what is required to drive a project successfully.
It's totally normal to do software development contracts with agile processes, and well-understood how to structure them. Estimates also suddenly don't get better just because they're made fixed at the star, and at the same time agile doesn't mean "there is no plan where this is going at all".
Waterfall is useless because nobody ever follows it. I agree that it’s sort of the “default” mode, but show me a project that didn’t go back and change something from a previous step.
Agile stops working the moment you need to sign any form of contract with anyone, because nobody is going to sign a contract that doesn’t tell them what they are going to get for X amount of money. Its processes are sort of fine on the smaller scale because it breaks project tasks into neat to-do-lists, but it’s utterly useless for actual project management because estimates are a lie and delivering on time is what is required to drive a project successfully.
Then there is everything in between from the various stage-gate models to UP and what not, and they are all equally useless because nobody ever really follows them and because they can’t really apply to every type or project which is what organisations tend to want.
I haven’t worked in a FANG or whatever you call the big American tech companies, but I have worked in the European Public sector and it’s affiliated private sector companies for years, and nobody has a magic project model in my experience. In many ways the most successful companies tend to be the ones who simply use some sort of Kanban board and refrain from giving estimates in intervals lower than weeks. I fully understand why organisations waste resources on this area of course, I’ve been in the trap myself many, many times and I’ll likely end up in it again, but the simply truth is that every project manager or business process person that you have is one less developer, and these helper functions don’t really add anything to your value chain the moment they start making up work for the sake of having the “right” processes in place. The best way to handle project management is to hire good developers who know how to deliver projects that are build safely and maintainable. That’s not easy, but no amount of project management is going to make up for the lack of them.
And I’m not saying you shouldn’t need project managers or have an organisational strategy, but if you’re hiring more support staff for your developers than you would for the tradesmen you’d hire to build your house then I think that you’re doing management wrong.
We build an entire city hall, a process that took almost a thousand different employees from very, very, differently ones of work and we did it with 1 project manager, 1 architect and 10 lead engineers. We did it on time and under budget, and that is how we build our IT projects as well. It’s sort of waterfall, because it’s what we default to like the author gets into, but maybe that’s because it works?