Sandeep Kaur

…to meet the deadlines?

When I was in my second year at University, that’s when I was introduced to the concept of ‘Software Project Management.’ I was taught all the basic concepts that it involves but we were also told (rather cautioned)that it was very rare that projects actually end up meeting the deadlines in real world. Every time this was mentioned, I couldn’t stop thinking as to why this happens. Why is it that deadlines can’t be met?

And then I started internship at AXA-IM after my second year. We did have projects there but we were not that exclusively into Agile Project Management. Besides, I was the only resource (along with one developer)when it came to the projects that I worked on. As a matter of fact I used to decide my own deadlines for the projects, I used to stick to them and so I didn’t really get the answer to my question as to why projects fail to meet the deadlines. It never happened with me that I missed them! So, my question still remained intact.

I came back to uni for my final year and this time I had ‘Software Project Management’ as an in-depth module. I was taught about resources, contingencies, dependencies, blockers, financial aspects etc. and was given real life examples where projects failed drastically (with huge financial impacts!)

So, at this point I decided that I need to see this happening or be part of it in real life, no matter what! I had finished uni and was looking for graduate jobs. I was applying for various graduate schemes but somewhere deep down I always wished to nail it with a company where I could get hands-on with Agile Software Development. Lucky, as always, I nailed it with the Financial Times.

I was excited to see all the theoretical knowledge from uni being applied to projects! It was like a dream come true but it was also time to hit the ground running and get working.(Remember, I wanted to see why projects fail to meet the deadlines?) We followed Agile Methodology at FT. I started to observe things keenly and minutely. My projects still finished on time. The maximum contingency, if any, was that of couple of weeks altogether. So, once again it got me thinking as I still didn’t have any proper answer as to why projects get delayed by months and months. Then I decided to compare as to what could have been different in the way my projects were carried out (because I needed an answer!)

I noticed that the delay in finishing projects could be because of the (manager) approvals that people need to take at every stage of decision making. I often see that when people develop software they have to stick to given requirement/s and their reasoning power is stripped off them. I never let this happen to me. If I see a better way of doing things, I do it. I follow a different approach though when it comes to doing it. I don’t ask for permission for doing it! I do it and prove it first to myself and then to everyone else that there is a better approach to do things.

In this case, if you go for approvals first, you are more likely to be asked to stick to traditional methods because managers don’t want to risk failure, time and resources. They would want to do things based on their experience. My first ever manager in the professional world taught me one mantra. “As you move up the ladder, you automatically start expecting people to be able to answer your questions in the least amount of time and using least number of words. So, when talking to a manager try not to speak verbally alone but also through your work (in action.)” Keeping that in mind, imagine there are two people following two different approaches to get things done:

Person A (to his manager): Hey! I was thinking of doing it this way. Is it okay if I take this approach and see what happens?

Person B (to his manager): Hey! I tried this different approach. It made work really quick and smooth and here’s the working prototype in action which helped us save X hours of time!

I am sure you can spot the difference between the two conversations. The first one is likely to get you a hesitant answer or even a negative answer (if you don’t happen to be in your luck)while the second one is likely to be more affirmative or it would help you build a further discussion on that. If you take the latter approach it is likely to save you a lot of time which is otherwise lost in approvals and can help you to put forward your way of thinking as well.

The second possible reason behind stretching the projects beyond the deadlines could be lack of people leading from the front. It should not just be left with the (Project)Manager to plan out things. If you see there is a better way of managing things or running them in parallel, take charge and do them because eventually they have to be done at some point as part of the project. You can rise to the situation/occasion and propose to do things in a different way. Once again, here too, if you go prepared with a practical approach of planning things in a different way, you are more likely to get a ‘Yes’ as an answer and thus cutting down the time to finish a project!

You must be thinking as to why I didn’t write anything about deciding on the realistic deadline/s in the first place, I can explain why. To start with there are always two type of timelines; with and without contingency. So, I believe the contingency factor should cover the realistic part. If its not, then contingencies definitely need to be revised.

These are some of the things based on my observations of why the projects get delayed. Feel free to share any other factors which you think could be responsible for software project failures/delays, based on your experience!