The big mistake while estimating a project deadline

Are you aware that rushing toward a goal is a sublimated death wish? It's no coincidence we call them deadlines.

Over the years in my IT experience, I have gradually realized that there exists a big missing piece in the puzzle of estimating a project deadline which is mandatory to be fitted in place. But, to my surprise, at most of the workplaces this piece is very casually ignored or nobody pays any heed to it resulting in delay of the project delivery. Today I will discuss about it and the pitfalls we should avoid to more accurately estimate the timelines.

All IT folks would be aware that once any new project or work comes, the first thing we must do is calculating the final date of the delivery of the project. And how do we go about it? We basically follow below mentioned bullet points -

• We split the work in smaller functionalities like login screen, search page, add user page, dashboard page etc.
• We ask development team to put forth their estimates i.e. how much time they would take to complete these functionalities.
• Then we ask QA team how much time they would take to test these functionalities.
• We create a project plan mentioning the dates on which a particular functionality would be completed giving us the final date of the completion.
• Alternatively, if we go the agile way,then we put the work in short sprints and ask the team how many sprints they would take to complete all of the functionalites which would give us the the final date of the completion.

Above mentioned approach may not be strictly correct but at almost all the IT workplaces it is followed in more or less the same way. You must be thinking what is wrong in that and if we don't calculate this way then what is the other method for estimating? No. There is nothing wrong and the approach taken is also absolutely fine but there exists a Voldemort like villain here which is not visible immediately but it is there, hidden, waiting for collecting it's strength and then attack suddenly, just out of the blue! And that villain is - multiple teams coordination!

Let me explain in a bit detail.

Whenever any new project/work comes, many a times it happens that there are multiple teams involved in it. For e.g in case of login functionality, it might happen that one team would be involved in creating the login page which, in turn, would use an API and that API could be handled by a separate team.

Suppose A team is assigned the task of creating the login page. The login page would use an API for registering/authenticating the user which would be handled by, let's say, B team. Now the time required for login functionality completion will include - estimation from A team + estimation from B team ( because the work is sequential ). Team A says they would take 2 days to deliver it and Team B says 3 days to deliver their work so the final number of days to deliver would be - 5. On a high level it appears fine but the problem starts once both the the teams start integrating their work. Because both the teams are working separately, they might implement their work as per their own understanding for e.g. A team could be expecting a parameter returned from API and B team might not be returing anything thinking that it won't be needed anways. Believe me, it really happens many a times!

The result? Once they start integrating, the full functionality would fail!

Another deadly result? The deadline will get pushed because the teams will have to modify their work.

So the villain I was talking about previously is -

Not considering the fact while estimating that there are multiple teams involved in the delivery of the work.

If you think I am referring here towards DevOps then please note that this is not DevOps. DevOps is a different animal which provides solution to totally different scenarios. What I am talking about here is regarding the estimates of completion of the Dev & QA work. While estimating the work, we usually don't consider that there are multiple teams involved for developing the project and that's where we reap the seed of getting last minute surprises of not meeting the timelines. If, while analysing the timelines, we take into consideration the count of teams involved and review their integration strategy we can greatly increase our chances to achieve the deadlines successfully thereby mitigating the duplicate efforts of our dev and qa resources. And believe me whenever I have considered these things while leading the project delivery and team, I was almost always able to hit the deadlines and whenever I neglected them, almost all the times, I missed the milestones.

Accepting the fact that there are multiple teams involved and then incorporating some strategy for the same would gift you with definite timelines of the delivery which will be highly achievable.