Wrapping things up:
10 reasons why an IT project can fail:
1. It is not because you succeeded before that you have to approach a new project with great confidence ➔ Be humble.
It is important to keep the fear of failure (negative thinking) to better avoid it.
2. If an excuse has already been used in a successful project, management will ignore it.
You always have to bring a problem WITH a solution.
3. Ambitions not aligned with company resources.
4. Starting development too late.
Cheap and quick failure is the best ➔ MVP method.
5. Too much hype ➔ The bar is too high.
It is dangerous to have an unbalance between the different teams of the project (like too many marketing people compared to devs).
6. Enabling preorders while the product isn’t even stable.
It is a risky bet as money made early is more valuable, but in case of a failure, it will cause immeasurable damages.
7. Self-made culture ➔ Never to this.
Buying software is the best because it provides a usually better ROI and it diminishes risk, as you put this part of the system in hands of other people.
Golden advice: update your dependencies AS SOON AS a patch has been released, because it’s the perfect opportunity for hackers to attack ➔ Stay alerted and follow the dependency’s feed.
8. No reuse ➔ Gross waste of resources.
9. Overtime (crunch) culture + remote work ➔ People can’t support each other.
Overtime culture is bullshit, as it kills the cognitive capacity of devs, which leads to bad quality ➔ Smart work over much work.
10. Motivating your competitors ➔ Keep your projects secret until the last moment.
Man, I was expecting a cute podcast like the one on Facebook or Volkswagen but that was genially insightful. Even if I disagree with some of the points concerning Cyberpunk’s case (like n°10), I can see how all of them can screw a project in another context. Would love a sort of sequel if you have more!
Also, I can relate to n°7 since we have the same thing in my company, and it is terrible: maintenance all the time, varying quality software since these are made with the means available (mostly interns and “learn on the field” people), and easily 6 years of software projects ahead of us.
Also, just a reminder for the future podcasts, you promised Agile, Bugs, and Security, I’ll wait patiently 😊
Wrapping things up:
10 reasons why an IT project can fail:
1. It is not because you succeeded before that you have to approach a new project with great confidence ➔ Be humble.
It is important to keep the fear of failure (negative thinking) to better avoid it.
2. If an excuse has already been used in a successful project, management will ignore it.
You always have to bring a problem WITH a solution.
3. Ambitions not aligned with company resources.
4. Starting development too late.
Cheap and quick failure is the best ➔ MVP method.
5. Too much hype ➔ The bar is too high.
It is dangerous to have an unbalance between the different teams of the project (like too many marketing people compared to devs).
6. Enabling preorders while the product isn’t even stable.
It is a risky bet as money made early is more valuable, but in case of a failure, it will cause immeasurable damages.
7. Self-made culture ➔ Never to this.
Buying software is the best because it provides a usually better ROI and it diminishes risk, as you put this part of the system in hands of other people.
Golden advice: update your dependencies AS SOON AS a patch has been released, because it’s the perfect opportunity for hackers to attack ➔ Stay alerted and follow the dependency’s feed.
8. No reuse ➔ Gross waste of resources.
9. Overtime (crunch) culture + remote work ➔ People can’t support each other.
Overtime culture is bullshit, as it kills the cognitive capacity of devs, which leads to bad quality ➔ Smart work over much work.
10. Motivating your competitors ➔ Keep your projects secret until the last moment.
Man, I was expecting a cute podcast like the one on Facebook or Volkswagen but that was genially insightful. Even if I disagree with some of the points concerning Cyberpunk’s case (like n°10), I can see how all of them can screw a project in another context. Would love a sort of sequel if you have more!
Also, I can relate to n°7 since we have the same thing in my company, and it is terrible: maintenance all the time, varying quality software since these are made with the means available (mostly interns and “learn on the field” people), and easily 6 years of software projects ahead of us.
Also, just a reminder for the future podcasts, you promised Agile, Bugs, and Security, I’ll wait patiently 😊