3 ms·

I know this is going to initially bother a lot of software engineers the wrong way but here me out: make a gantt chart and assign resources to each of the tasks

by ragnot 4y ago

I know this is going to initially bother a lot of software engineers the wrong way but here me out: make a gantt chart and assign resources to each of the tasks. You can add "future hires" to see how much of a work load reduction you get. Now depending on your work environment you can do one of two things: - Work environment is still "healthy": Show your gantt chart to your boss as a justification for the resource count addition but highly stress that the dates are not accurate or even valid estimates. That is what a dedicated planning session is for. - Work environment is not "healthy"/a bureaucracy: Come up with whatever justification you can that validates the number you came up with in a gantt chart (aka parallel construction) but don't show the gantt chart. They will take those numbers as gospel no matter what you say.

xtracto 4y ago
I second the Gantt chart approach. The way I modelled is in a spreadsheet, 1 cell = one week. Then on a top row write the number of engineers available. Discount 10%-20% for PTO (there's always someone in PTO). In the 1st column write the projects and next a column with your estimates of man-weeks required. Here is where you should modulate the estimate depending on how business looks at these things: Do they know it's an estimate planning tool? Add the 30% overhead of your estimate: Shit always happens. Does business take your estimates as law? Add 50% padding. Once you have that framework, get the milestones/end dates from business. These usually come as "having X feature in Q1", Y feature in Q3. So you have some leeway. Start mapping how many engineer weeks would you need for each task for each week to finish in the milestone, ensuring you dont get to negative in the top (total engineers) row. You also should consider the mythical man month: putting 10 engineers in a feature will most likely make it fail, not go super fast. Usually you want 3 or at most 4 ppl per project. This also depends on the size of the project. With this data, you'll be able to show business that additional prioritizing needs to be done. On the flipside, they will question you your time estimates. You can use that to push to sit down and clarify/detail the project, maybe even split it in stages: the Gantt will allow you to model feature releases of a large project. I used this framework successfully, and it served as a great communication tool between the CEO and myself (as head of Engineering).

by ragnot 4y ago

xtracto 4y ago

I second the Gantt chart approach. The way I modelled is in a spreadsheet, 1 cell = one week. Then on a top row write the number of engineers available. Discount 10%-20% for PTO (there's always someone in PTO). In the 1st column write the projects and next a column with your estimates of man-weeks required. Here is where you should modulate the estimate depending on how business looks at these things: Do they know it's an estimate planning tool? Add the 30% overhead of your estimate: Shit always happens. Does business take your estimates as law? Add 50% padding. Once you have that framework, get the milestones/end dates from business. These usually come as "having X feature in Q1", Y feature in Q3. So you have some leeway. Start mapping how many engineer weeks would you need for each task for each week to finish in the milestone, ensuring you dont get to negative in the top (total engineers) row. You also should consider the mythical man month: putting 10 engineers in a feature will most likely make it fail, not go super fast. Usually you want 3 or at most 4 ppl per project. This also depends on the size of the project. With this data, you'll be able to show business that additional prioritizing needs to be done. On the flipside, they will question you your time estimates. You can use that to push to sit down and clarify/detail the project, maybe even split it in stages: the Gantt will allow you to model feature releases of a large project. I used this framework successfully, and it served as a great communication tool between the CEO and myself (as head of Engineering).