Why software projects take longer than you think – a statistical model

Re:Why software projects take longer than you think – a stat... by taneq on Tuesday April 16, 2019 @08:33AM (#19673061)

Oh yeah. This is why I'm always very careful about quoting prerequisites for any deliverable. "We can do X in 5 weeks after receipt of Y, Z and W." Then when they say "why don't we have X," I politely inquire after Y, Z and W.

The most important part of this process is getting it in writing so that you can slap them with it later.

[ Parent | on HN ]

Re:Why software projects take longer than you think – a stat... by chii on Tuesday April 16, 2019 @08:45AM (#19673145)

> after receipt of Y, Z and W.

the problem comes when you didn't know you need Y, Z or W until the work actually starts.

[ Parent | on HN ]

Re:Why software projects take longer than you think – a stat... by afarrell on Tuesday April 16, 2019 @10:20AM (#19673825)

Which is part of why I think the most valuable part of an estimate isn’t the number. Its the task breakdown and identification of risks.

1) You improve your foresight so you can get your manager rolling on getting resources early.

2) You have a concise record of what you think you need. If you notice something else mid-project (which does happen even in otherwise-straightforward implementation projects), you have a concrete point at which to raise a flag to stakeholders.

If you have zero confidence in an estimate from the beginning, then there is no point where its natural to realize “oh hey, this is going to overshoot and I need to communicate about it.”

[ Parent | on HN ]

Re:Why software projects take longer than you think – a stat... by taneq on Tuesday April 16, 2019 @10:08AM (#19673723)

That's the difference between a research project and an implementation project. Research, you don't know Y, Z, W, or Q. Implementation, you know the full path from spec to deliverable.

[ Parent | on HN ]