Ask HN: Software project - too big scope too little time, what are the options? | Hacker News Reader

Ask HN: Software project - too big scope too little time, what are the options?

4 pointsJanezStupar4 comments

This is the data.

estimated development workload: 3000 man/days team size:technical lead, 4 database designers, 4 application designers, 9 developers, unknown number of testers. available time: 5 months

The team was brought together from all sides a month ago. Team quality is "usual" (half is quite experienced - half interns). Four members of team have substantial experience in the field (3 application designers and technical lead). Other members of team have no experience in the field.

The team's opinion is that optimistic ETA for delivery is 12 months (with p~0.7), unless scope is cut. TPTB declare that this is not an option and are willing to pursue various arcane options (basically throwing money at problem).

The team estimates that max. 30% (you are allowed to assume 50%) of projected scope is subject to potential replacement with "off the shelf" components where the most optimistic scenario is assumed to cut the time spent on these modules by 50% (due to evaluation, modification and integration).

What I'd like to ask is - what are your experiences in such situations? I strongly suspect that adding more people will only amplify the problem in our current situation. So I insist that scope needs to be cut or deadline needs to be renegotiated. As mentioned - both appear to be non-negotiable.

Is my reasoning flawed? What other options are there?

1) Are you all aware of the Mythical Man Month by Fred Brookes? If not, read it, throwing more bodies at the problem will not solve it.

2) Your team already sounds quite big for a supposed 5 month project. Feels like people will be stepping on each others toes, and someone will be tearing ther hair out trying to manage everyone modifying the same codebase whilst it is so immature.

3) The Iron Triangle - this is the relationshp between scope, resources/cost, and deadline dates. If you can't build what is in scope, with the resources you have by the date specified then somethings got to give. Hint: increasing resources is the least effective way of doing this, see 1) above.

4) Have you tried approaching this in an Agile manner? Prioritise all the functionaltiy thats in scope, tackle the most important first. Continually refine the priority of functionality as you develop the system. If that deadline is immovable, and you're not going to get all the functionality in, at least you've delivered the most important parts of the system. What you might find, if everyone gets Agile, is that they realise you won't hit the deadline early on and they start buying into this approach, by prioritising they are in effect reducing scope without realising it.

5) in conjunction with 4) monitor the productivity and efficiency of your team using burndown charts. Note that this is different from speed of development. The concept of technical debt is integral in all of this; productivity & efficiency take into account technical debt and implies you are trying to manage it, speed usually increases technical debt.

6) Finally, tell people "things take as long as they take". Just because someone says they want it by yesterday doesn't mean that it can be built by then.If they want to bake some bread it will take them approximately an hour or so, if someone told them to do it in 20 minutes they wouldn't be able to knead the dough and bake it in that time - and get something edible at the end. Essentially that is what you are being asked to do.

My two-penneth

Good luck!

Yes, I have read Mythical Man Month. I am aware that I can't handle more people or that working double shifts won't get us anywhere.

I am already looking for triage opportunities - what I need to do is somehow convince TPTB that we are on collision course no matter what they might divine up. And thus should strap the cargo, check the hull seals and brace for impact. It is clear to me that we should enter damage control mode.

But my perception is not reality - that is why I'm asking for experience.

Thank you for your contribution - Burndown chart is a concept I wasn't aware of.

I can empathise. I am in a similar situation: after months of development and me (amongst others) banging on about how we are giong to be waving at the deadline as it whooshes past. TPTB have finally stood up took note, and are now getting their asses in gear over how to sort this. I ensured we kept burndown charts, measures of productivity and efficiency. We then used these to do projections on where we would finish based on optimisitc/average/pessimistic figures.Do this on an ongoing basis and hopefully people will realise sooner rather than later whats going to happen. Oh and ensure your governance is in place. Make sure reporting to TPTB is regular and as close to warts and all as you can keep it. That way if things blow up and people start pointing fingers there's lots of information to back you up!

First question that you should ask is "Why is date not negotiable?" This should provide you the rationale for prioritizing features. Identify the core features and push for negotiation on the other set of features.

Looks like money is not the problem. In that case be aggressive on your search for 'off the shelf' apps (open source or commercial). Can you buy a working product and develop the addons? Can you buy an application and modify it to meet your requirements? When all that fails then see if you want to develop the app using third party components.

Easier said then done but it's better to spend time on questioning the rationale for each high level technical decisions and feature request.

Reply on news.ycombinator.com