Ask HN: Software answering “How long will this project take with N people?”
* I want it to know that someone can only do one task at a time (I don't see how to do this with Smartsheet, at least). * I want it to know that unassigned tasks are blocked on people finishing other tasks and becoming available. * I want to be able to see how long things will take if I add or remove N people from the project. (For example, if only one person is on the project, the total project time should be the sum of the time of all the tasks; if enough people are on the project, the time to completion should be the length of the longest sequence of dependent tasks.)
I am surprised this doesn't exist, or at least that I can't find it (it's a feature and not a product, but feel free to take the idea and run with it if you want). AFAICT, the major project management tools in this space don't do this. But I hope to find out I'm wrong. :)
13 comments
[ 329 ms ] story [ 3064 ms ] threadYou should read The Mythical Man-Month. If that doesn't persuade you, lots of people use Microsoft Project to do what you describe -- generate Gantt charts that only bear a passing relationship to reality and prove incrementally less useful for estimating project completion.
I don't really understand the point of your comment. That projects never go faster when more people work on them? That estimating project length is useless?
Being able to figure out "we can do it in a year with three people, or six months with five people, and six months is as fast as it can get done" is, in practice, useful.
> length of the critical path
and
> six months is as fast as it can get done
unless "length of the critical path" accounts for the quadratic(ish) increase in communication overhead as you add more people.
I think that is a little unclear from the question: is the length of the critical path the sum of times one person would take to do those tasks or the sum of the times an overhead-laden person would take to do those tasks?
That is your problem. If you listen, what you are hearing is that life is not so simple. People are people, they have a mix of skills, some more, some less, some communicate well. Bigger projects suffer communication problems in different ways. What you could be hearing is the voice of experience. It comes from being bitten too many times, mostly by people who believe in such charts.
In 40 years in the business I have never seen this work, no matter how talented the team and project manager. I'm not saying it can't work, just that I have not seen it happen and I am not aware of any technique.
In any software project the individual personalities and team dynamics drive the project and set the pace. How do you express that on a Gantt chart? Unexpected things come up because no one can plan a non-trivial project with complete and consistent requirements.
The only approach I know that mostly works is incremental development. Set shorter targets and deliverables specified well enough that the team can give realistic estimates. Do that (call it a sprint if you want), regroup, adjust velocity based on what you learn. Software projects often have what looks like a fast pace and lots of progress early on, then bog down so that the team spends 90% of the actual time on the last 10% of the schedule. Incremental development (I won't call it agile because that means almost nothing anymore) at least gives you forward progress and an increasing (rather than decreasing) ability to estimate time to finish.
Good luck.
Of course, this is only useful at the initial stage of a new greenfield project. For me, the more useful part is the dependency graph between tasks (actually mini-projects). Estimates are for managers. And even then they can be multiplied by 3 and still be wrong - i.e. it's guesstimation.
For general feature delivery work, a Shape Up[3] appetite (the amount of time we want to spend on a project, not an estimate) will work better. This is a fixed time budget - a variable scope.
--
[1] https://en.wikipedia.org/wiki/Program_evaluation_and_review_...
[2] https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...
[3] https://basecamp.com/shapeup/1.2-chapter-03
> making a baby is an atomic (blocking) task with time estimates ranging from 23 to 40 weeks.
Look, we need that baby by end of the fiscal year. Just get as much as you can done in 26 weeks and we'll ship that. We can plan for phase 2 once it's in production.
If our Sprints are 26 weeks long, we can split the BABY-123 Jira ticket into two, Phase 1 in this sprint, and Phase 2 in the next sprint.
It should be able to do all of what you ask although I don't it will do what you ask in your third bullet point unless you specifically assign extra people to tasks.
However, as others have pointed out, how much a task will benefit of extra people is really something down to domain knowledge and experience and the tool is just that, a tool to help you.