

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

This is the data.<p>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<p>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.<p>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).<p>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).<p>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.<p>Is my reasoning flawed? What other options are there?
======
wr1472
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!

~~~
JanezStupar
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.

~~~
wr1472
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!

------
bhattisatish
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.

