Tag Archives: estimates

Project Math, or How to Double Project Timeline

Project math really follows its own rules. You don’t get linear benefits from adding to the number of people on a project. Sometimes it seems like throwing four people at a project makes the project span 4 months, when a single person could have completed the work in a couple of weeks.

Yes, if you have one thousand letters to write, and each worker can write their own letters, this works. That sort of thing might linearly scale.

But on most projects, your communication lines are O(n^2) (actually, (n^2-n)/2)… 2 -> 1, 3 -> 3, 4 -> 6. If you’re not doing mostly independent pieces, you’re creating an unofficial management position for every 2-3 people you sign up. Realistically, 6 would be 15 units and 12 would be 66 units, so a mere doubling in time is really optimistic unless the 6 extra workers are making sure that project managers and customers don’t bug the workers actually building the car.

Worse still, usually, the extra 6 workers will need to be brought up to speed mid-project by the other 6 workers on top of introducing the extra ongoing communication complexity.

In other words, (ノಠ益ಠ)ノ彡┻━┻

How Long Will This Simple Concept Take to Build?

How long does the business person asking for it think it will take? Double that.

Is there a model system that it is being compared to? Double your estimate again. Double your estimate again if it’s being compared to more than one system.

Is it the design going to undergo audits for standards or compliance? Add 50% for each.

Does Agile mean “work before requirements are figured out in a process that’s really Waterfall”? Add all the effort up until your last new specification to the end of the project timeline.

Is “concept” or “pilot” being used in the place of “live production product that will be expected to scale and configure from day 1”? Double your estimate again.

Congratulations! You now have a very conservative estimate for how much effort things will take.