“We are rushing too much, we will miss many details, this will not end up well”. These were my words to the director on a project we were rushing to deliver. The odd part is that in times like that, working 10 hours a day, on weekends late at night and earlier in the morning. You may try to predict what will go wrong, but I guarantee you won’t be able to cover all details needed when running that much.

Many times risks are acceptable, and you may want to hit a deadline and deal later with the consequences of the rush, but it needs to be clear that it is a trade-off, “Move fast and break things” may not be an option, but rather a consequence.

When you see things on fire, and simple details being missed, it does not mean necessarily that everyone on the project does not know what they are doing. But rather they may rushed to deliver it and did not have time to consider all the details.

Smell of problems in the future of a project ?

Planning / Design taking longer than the coding

“We took longer to design, but now the implementation will cover all the corners”. Planning and design are supposed to be a small fraction of the project, when they are bleeding to the time you are supposed to be coding, that is a big smell of future problems. No, it won’t. You need/must test your design in real life to ensure it is viable and the decisions made are good. Code it, and just then, you may know it was a good design, one cannot know in advance.

Dev team is constantly pressured to give expected ETAs, not the reality

“Can it be delivered today?”, “Is it possible to deploy on Monday morning?” (This is Friday 7pm and the task is not even started) Coding is not like building a wall, and most of the systems are extremely complex. There are trade-offs when in a project the dev team is put over and over again to meet deadlines instead of looking at the tasks as they are, this is a matter for latter. Time boundaries are important though, a project where no time boundary is ever considered will be a smell of a never-ending project on the other end. ETAs given in weeks rather than hours may be a good indication, (again no one will give an ETA for a week to solve an outage, that kind of problems must be solved in minutes;here we are talking about projects with defined scope).

Leaders leaving before the project is finished

“I would love to be here to see this project fly, but the next offer is amazing.” This one should be obvious, but when managers are quite close to delivering an important project, it may be a good indication to re-evaluate if that project should be re-assessed; bringing people in the last minute may help, but for a 2 years project, 2 months of “saving” tasks won’t be enough. When managers quit, engage an open conversation about the challenges to come is completely needed; most of the time they would not tell the truth, but nevertheless consider any small tip of concern as a great threat to the project and go after it deep, “There could have to beeing more investments in the project!” can read “We were absolutely under understaffed and only covered the bare minimum with the resources we had”.

Conclusion

Rush is needed sometimes, and the time will come in your career when you will find yourself rushing to deliver a project, just keep the eyes open and communicate the risks to make sure they are acceptable. I like to take challenging impossible projects and make them successful, not in all cases it is possible to impose your opinions, and you need to deal with the consequences of the rush, nevertheless being the “I told you so” person is not a good option. Having made the risks clear for everyone, and also being there to deal with the issues you anticipated would happen, will show you are a team player and will give you the opportunity to be heard in the next projects.

The key to success is communication and ownership, be clear honest and direct, don’t blame others, and don’t act like a victim, lead the team and situation to success even in the craziest situations, but make sure you document the problems and the feelings you had, so you don’t repeat the mistakes in the future.

The project I mentioned in the being of this post was a great success in the end, except a few hiccups in the first days after the deliver, in the end the team was proud, the goal was achieved and the company was happy with the result.