3 ms·
I am a big fun of learning best practices but also of iterative “projects”. You know why most business projects fail? Because they are too big and to reduce ris
by kfk 6y ago
I am a big fun of learning best practices but also of iterative “projects”. You know why most business projects fail? Because they are too big and to reduce risks the tendency is to follow _only_ best practices. This doesn’t work because each project is different with its own set of challenges and unknowns. Prescriptions are a good guidance but only sticking to prescriptions is path to failure. These days I rather iterate to a solution the same way startups iterate to a product. In fact I started to call our team’s project managers product managers instead.
- AstralStorm 6y agoThat's the dangerous way of thinking. As far as I'm concerned and seen projects fail because their either build the wrong thing, or don't deliver (on time). The practices can slow you down, but they can also speed you up. Sometimes the failure to deliver is a managerial failure or the problem is too complex for the team tasked with it to deal on deadline. It's rarely because of "we keep code clean and production running" or "instrument everything". What I've seen instead much more often is that good practice is replaced with common practice or deviation (problem) is normalized. The latter leads to some rather interesting failures - bugs, and failing to deliver. Sometimes explosions if you're dealing with rockets. I've also seen bad workflows cause serious slowdowns and issues, while not being replaced because things are "done" on paper. I find this on par with lying to your boss, which it is. Also in case of bigger multiple teams, tardiness to implement improvements because someone might have to change something about their setup, instead of engaging them with a discussion, leaving it for a flag day. (When everything invariably goes wrong.)