Nine ladies don’t deliver a baby in a month.

While estimating migrating our persistence layer from server-side encryption to client-side encryption, my team estimated our project will require 60 developer weeks. The team created a detailed plan for each milestone and estimates for each, giving a high confidence date for each project. And then stated with multiple developers we can reduce the total time. Which obviously makes sense, when I asked so with two developers can we deliver it in 30 weeks, and three in 20 weeks. Some of my team members agree with visible hesitations on their faces. As theoretically 60/2 is 30 weeks and 60/3 is 20 weeks, so their engineering brain agreed but experience struggled with that answer. So, we agreed 30 weeks is not the answer, and I asked what would happen if I put two people on this project, or even three, my engineering lead struggled with the answer in coming up with an estimate. He asked for an additional week to determine that level of detail to conclude what will our expected delivery time.

While the above scenario is common, but often unanswered, and my team and I struggled with this very question i.e., can nine ladies deliver babies in a month. As business and project space become more ambiguous, identifying details of each deliverable and surrounding complexity often impacted our project plans and delivery windows. We heavily relied on cushions and ensured the team had necessary time to weed out complexity while meeting project timelines.  But even after baking in cushions, the team was up against the timeline and barely delivered projects or needed few more days near the end to deliver big projects.

While, as I expect last minutes delays and last days push is part of our delivery experience, I wanted to take an opportunity to document some observations and identify learning opportunities for future self.

Why multiple engineers don’t necessarily double the speed of delivery?

Cost of Increase in Collaboration (a double-edged sword):

The obvious part I missed while adding multiple engineers on the same project is that multiple engineers come with cost of increase in collaboration. Keeping multiple engineers equally aware of project space required the engineers to share context, ensure each task is detailed that enable the other engineer to effectively deliver on that task independently. Creating benefits of better detailed documentation, while maintaining each engineer on the same page requires more communication, and sometimes rework due to non-alignment. And, as of right now I have never accounted for a collaboration multiplier while adding multiple engineers.

Is Divisible:

When dividing projects tasks, I often miss can I really assign a task to multiple people at once. If all tasks can’t be assigned to multiple people, how many tasks can only be done by a single engineer at a time. And, if each project such as design, launch coordination, security reviews are singleton tasks, how do we bake them in our planning. Historically, long term projects will still have up to 20 percent of task that require individual to derive them in the beginning, and post implementation, up to 10% of a project estimate time i.e., an individual to coordinate launch and release efforts with multiple stakeholders. Leaving only 70% percent of time for implementation that can be parallelized between multiple engineers. While 70% percent tasks can be parallelized, it does warrant a close analysis especially for short term projects and 70% percent parallelization between multiple engineering will come with the cost of collaboration highlighted before.

Estimate Accuracy?

My team that does a very detailed job during design has figured everything about the implementation, so why we are still falling behind. When we discussed this among our team, we realize we often do great job in reviewing documentation and have a great idea what we want to implement. But engineering components much like life don’t behave exactly how we originally estimated. Additionally, each engineers bring their experience that changes the implementation from the original design. Such variations and challenges during implementation continue to require us to add some percentage of cushion to our original estimates to ensure the team has the necessary time to recover from any delays. I generally prefer to keep up to 20% to account for unplanned off days, sick days, re-work in implementations, and any technical delays.

Project timeline estimates with risks listed above:

·       Estimated dev effort: 60 weeks.

·       Projected Dev effort: (60 weeks + 20% of 60 weeks) i.e., 72 Weeks

·       Projected Single Dev effort: (20% of inception i.e., 72 weeks: 14.4 Weeks + 10% of launch coordination i.e., 72 weeks: 7.2 weeks:  22 Weeks (14.4 weeks + 7.2 weeks))

·       Projected Divisible effort: (70% of 72 Weeks) = 50.4 Weeks

·       Number of projected engineers: 2

·       Cost of collaboration (TBD by team: in my team: .2): (50.4 *.2)/2 = 5.4 weeks

·       Total Project Divisible effort time (Estimated Effort + total cost of collaboration): 25.2 + 5.4 = 30.6 weeks

·       Total Projected time to deliver: 30.6 + 22 weeks = 52.6 weeks (round to 53 weeks)

What did I miss in the above timeline: Unplanned long vacations, team attrition.