How to screw up your IT project
I’ve seen a lot of computer projects catch fire and fall into chaos before my eyes. Today, I’m going to give you the perfect recipe to screw up your IT project. Everything burns.
Schizophrenic scope
At the beginning of an IT project, you have a plan. You and your colleagues had some big coffee and went to a room to make drawings and put it all on paper. Well, this reflection has to be shit. It’s super important, because it’s the basis.
To make sure your IT project fails, your starting scope has to be blurry and incomplete. Get out of this meeting with a stupid post-it, throw it at the first developer you see and tell him that it’s due for tomorrow. This is by far the best start. You haven’t even started yet but you’re already punching your project in the ribs. It’s not enough.
Your scope and the features need to keep moving. It’ll be easy to do if the basics of your project are not clear. And there are no rules here. Go crazy ! Change everything. Add features, change them at the last moment, go back and contradict yourself in the same sentence. To make sure your IT project fails, your scope must evolve as much as possible. The scope has to be completely schizophrenic from start to finish. It’s important that every changes make no fucking sense. You need chaos. This will also keep the stress level very high.
Anxiety as a service
Again, this is really a metric that you have to monitor and maintain throughout the project. To make sure that your IT project fails, you need to generate and maintain maximum pressure. Constantly changing the scope is a good start. When your development team proudly finishes a feature, just delete it from the specification.
If you’re a manager, you need to communicate all your stress to the whole team. If you’re a developer do the same with other developers. You really need everyone in panic mode.
In order to maintain an unhealthy level of anxiety, there’s something you can do right away. To make sure your IT project fails, you need to set a crazy deadline. That’s kryptonite for everyone. Here’s a tip : don’t let the development team do the technical time estimate. That’s central, too. Have someone who doesn’t know anything about the technology used. Better, who knows nothing about the technical side in general. The time estimate must be a huge joke. Everyone must agree that the situation is untenable. Everybody, except the person who decides.
As a developer, when faced with a situation like this, you’ll immediately produce absolute garbage code to go faster. Normal, classic, we like it and above all it’s essential for any project that sinks into chaos. As the base of the project is shaky and the scope is unstable, very quickly, the first technical problems will occur. At this point, there is a absolute golden rule to keep in mind.
Always blame others
It’s not your fault! Never. It’s other people’s fault. To make sure your IT project fails, no one has to take responsibility. You have to be always defensive and hostile to any remark. Because if you accept criticism, rightly or not, you will focus on how to fix the problem. This could lead to progress ! To make sure that your IT project fails, everyone has to point fingers at each other. No one works on the problem anymore since everyone is too busy blaming everyone else. The chaos is total and your project is doomed.
A long time ago in a galaxy far, far away, I worked on a microservice that I had to ship in an internally managed cloud. I’ll pass on the details of why, but my thing wasn’t working. More accurately, it wasn’t working in that internal system. It was weird. Innocently, I just asked a single dude, using private email, if there were other cases with the same problems or if I was an isolated case.
A week later, no answer. By that time I had solved my problem on my own. It was indeed my implementation which was absolute garbage. Classic.
But without knowing it, I had started a war between three different teams. My service behavior was déjà vu. They all started pointing fingers at each other using e-mails. This went so far that the direction has to intervene. A week’s work lost. No progress and a bad atmosphere. And that was possible because everyone was working on their own stuff.
Working in silo
It’s super common in big company. There’s a lot of teams doing a lot of things all over the place. You’re on one of those teams. It’s very important that you refuse to share your work and that you close communication. To make sure that your IT project fails, everyone has to work in their own corner. It’s best when everyone is working on the same thing without knowing it. It’s beautiful when you realize it months later. You realize it months later because you don’t communicate.
To make sure that your IT project fails, communication must be non-existent. If there’s one piece of advice you need to remember, it’s this one : no communication, zero. Maybe answer an email once or twice a week. Just send that you’re “too busy to talk”, works every time. And if you run into people in real life, look at the ground or kind of turn around and run. Avoid interaction as much as possible.
It is also important not to say anything about potential problems you spot. Zero transparency. When you see a huge problem, keep it to yourself. Zen, let it go. To make sure your IT project fails, forget about risk management. Everything’s fine. Remember, it’s not your fault. Don’t start mapping out risky areas. You could change course and solve a lot of problems with this method alone. This is easy to avoid when you don’t have any process.
No process, no standards.
Work processes, methodologies and best practices : forget about it. It’s for the weak who don’t know how to work independently. To be sure that your IT project fails, you should not apply any process or standards. The problem is that it allows everyone to work the same way. It saves time and you’re injecting stability into your project. That’s not what you want !
Also, force all your developers not to document what they do. Each piece of code must remain a mystery to those who will pass over it afterwards. And this lack of process should also be felt in the way you communicate.
To be sure that your IT project fails, important changes must be made by email or orally. If you manage to drown a change of specs in the middle of an endless chain of e-mails you get bonus points. You don’t want a structured source of truth like Jira, Trello and others. You don’t ! Because then you can’t just go, “No, but if you remember, we said so at this meeting.” And this card is important, because it’s going to help you explain that it’s never your fault.
Also, quality shouldn’t be one of your goals. I’m not worried, you’ll be fine if you don’t have standards. Your only goal should be to deliver something on time. It doesn’t matter how bad your project is. And what matter even less is the state of your team.
Despise the human
To make sure your IT project fails, you have to recruit the wrong people. You have to take people who don’t get along with each other or with the company in general. One bad recruitment can jeopardize your entire project. It’s much more efficient than you think. Insist that that HR send you toxic people, this will really have major impact on the project.
Once you get people who hate each other to work together, all you have to do is make the most of them. To make sure your IT project fails, you have to despise everyone. There are a couple of techniques to be effective in this.
You can force everyone to work a minimum of 80 hours a week. When people no longer have a personal life, it is with undisguised pleasure that they will shit inside your project.
A little “You take your afternoon off ?” when someone leaves at 7pm is exactly what we want. It doesn’t cost you anything to say it, but for the person receiving the remark it’s incredibly unpleasant. You can also ask a junior to do a senior job and pay him like shit. In short, frequently despise everyone a little bit and people will go crazy.
The Holy Grail for your project is someone doing a burnout. Priceless ! If on top of that it’s a dude who made himself indispensable JACKPOT! You’ll have a lot of indispensable people because you have no standards and no documentation. Your project will then end its race in hell while this person leaves with critical knowledge to finish it.
Epilogue
Now, if you apply everything I’ve just said, you can be sure that your IT project will be a disaster. A lot of projects do this and that’s why IT project fails so much in tech. Sure, there’s a lot of other things you can do to screw it up. You have the comments below to share tour thoughts.
