It all happened as I was taking my first steps in the role of a project manager. The client and I were working together to develop the requirements and couldn’t help imagining how wonderful it was going to be: an experienced developer, a captivating project, with its technical specification ready, with complete content requirements, and a set deadline. At that moment, I had no idea that everything would turn out so differently.
Quite soon we began to see the first programming results, and they were promising. The customer assured us that the content would be provided in time, and we started working on the server for the future application. However, the time for supplying content was running out, while the customer continued to make empty promises which I, in turn, continued to believe. That was the moment we should have realised that the project would not be completed on time. Now I understand that it was my third mistake: disregard of the obvious neglect on the part of the customer.
Incidentally, I did not even worry about the content when we were two weeks away from the initial deadline, because at that moment we had nothing to do with it.
Two weeks before the deadline, nothing was ready. The customer shrugged his shoulders, saying that he still did not have the content, but that all was well and that we were going to make it in time regardless. I believed him!… I believed his lies for an entire month prior, and yet he was somehow able to sell us the fact that he was managing. Through gritted teeth, I continued to believe him…
It is said that one of the main tools of a good leader is delegation. The situation above gives a great perspective on the fourth fatal mistake I made in our project — control delegation.
Let us go back to the moment when the customer finally began to supply the content. That was when we found out that it was not suitable for use in the system without some serious editing. The moral is simple: always describe the requirements as clearly and rigidly as it is humanly possible. One cannot trust that the client will figure things out on their own. This leads to project management mistake number two — insufficient specificity of requirements.
A kaleidoscope of difficult events followed: meetings with raised voices, reworking, and nightly gatherings… But eventually the project was launched; later than planned and in a different form, with plenty of nerve-racking and unpleasant experiences on the side.
I was saved by my wonderful colleagues. Only due to their hard work were we able to deal with the problems and come out of the hard situation.
Now one may ask themselves a reasonable question: ͞What about fatal mistake number one? How did it all begin? Dear reader, you have reached the most interesting part.
This mistake began to loom even before I was appointed to that project. The team attempted to choose a suitable development tool, although neither of them knew what the final system would do. After considering the vague specification outline, they decided that WordPress was the best choice and that using a template would help save time.
The mistake was made when, studying the project materials, I silently agreed with that decision. I did not even notice what a terrible idea it was!
Then there was mistake number five. As the project deadline approached, it was clear to me that we were not going to make it in time. Of course, I attempted to inform the customer and the sales department. Obviously, they were not happy. The customer did not want to hear about extending. They did not believe me, deciding instead that everything was alright and that all the problems would magically be solved by pushing just a little harder. And I caved. And the result was rather upsetting. They were certain that the product would be completed on time. Meanwhile, in practice, the result was far worse than I had expected, all because we had been too focused on trying to make things ͞work somehow, no matter how͟ due to pressure from the top. Do not give in to such pressure. If you believe that something is impossible, it is likely to be true. Inform your colleagues, and you may thus avoid the failure of your project.
Not too long ago, I read a book by Maxim Batirev called «The 45 tattoos of a manager. A guide to Russian leadership.». The author describes his journey as a manager using his and other people’s mistakes. Each chapter discusses a specific theme, which Maxim calls a tattoo.
In order to summarise this article, I have formulated my 5 tattoos for software development project managers:
- Always pay great attention to the choice of technology. This is often what determines the ability to implement changes and support for the future product.
- Always describe the product—and, more importantly, the customer duty—requirements as clearly and rigorously as possible.
- Always react to neglect of duty on the part of the customer or any third party in the project. Something was not delivered on time? The product release deadline must be pushed forward!
- Always control the development process yourself. Forget about control delegation. You must see the progress with your own eyes. If that progress is not visible, it is time to take immediate action.
- Always stand your ground. Nobody (and especially the client) can answer the question of how long it will take to complete the project better than you. Ignore any threats if you know that the deadline is unrealistic. Postponement in advance will ultimately be much less painful than having no product on the day of release.
This experience was very valuable, even though it cost both me and my company quite a lot. I hope that my article will help you. Good luck!