0

I'm working on a project with many unknowns like moving the app from one platform to another.

My original estimations are way off and there is no way I can really know for sure when this will end.

How can i deal with the inability to estimate such a project. It's not that I'm adding a button to a screen or designing a web site, or creating and app or even fixing bugs. These are not methods with bugs, these are assumptions made in the overall code, which are not correct anymore and are found step by step and each analyzed and mitigated with many more unknowns.

Jas
  • 14,493
  • 27
  • 97
  • 148
  • 2
    Please pay some attention to text markup; adding a paragraph or two wouldn't hurt in this blob of text. It looks quite unreadable in it's current form (which is why I won't read it...) – ChristopheD Oct 19 '10 at 20:53
  • We can't justify your phony balogna job for you. If your sole purpose is to estimate the inestimable, quit now while you still have some sanity left. – nmichaels Oct 19 '10 at 20:55
  • 2
    Tell him sometimes software projects reach the state where the cost of maintenance and the risk involved is greater than starting over. – Paulo Scardine Oct 19 '10 at 20:55
  • 2
    I'm voting to close this question as off-topic because it is not about programming. – Vadim Kotov Oct 23 '17 at 08:39
  • just to update (7 years passed since this project finished : but a new comment came up here which made me recall this project). I have completed this project back then successfully with delays. but it completed successfully and all were exceptionally happy! at first it looked like one hell of an impossible task, but step by step uncovering all that should be done, tuning estimations, not giving up, pushing the edge, was the best roller coster of my life! I personally thank everyone giving me this giant task. I now understand everyone involved were afraid of this project. – Jas Oct 23 '17 at 12:19

5 Answers5

5

I happened to write a master thesis about software-estimation and there are lessons I've learned:

-1st Count, 2nd compute, 3rd judge - this means: first try to identify items in your work which are countable e.g files, classes, LOCs, UIs, etc. Then calculate using this data the effort (in person/days). Use judgement as the last ressort.

-Document your estimation! Show numbers. This minimizes your risk, thus you will present results not as your opinion, but as more or less objective figures. (In general, the more paper the cleaner the backside)

-Estimation is not a commitment. Commitment is one number, estimation is always a range - so give your estimation as a range ( use cone of uncertainty to select the range properly http://www.construx.com/Page.aspx?hid=1648 )

-Devide: Use WBS, devide your work in small pieces and estimate them separately. The granulity depents on the entire length, but at most a working-package soultn't be bigger than 10% of entire effort.

-Estimate effort first, then schedule, then costs.

-Consider estimation as support for planing, reestimate on each project phase (s. cone of uncertainty).

I would suggest the book http://www.stevemcconnell.com/est.htm which deals all these points, in particular how to deal with bosses, who try to pull a commitment from you.

Regards, Valentin Heinitz

Valentin H
  • 7,240
  • 12
  • 61
  • 111
4

There's no really right answer for coming up with an accurate estimation, because there's no way to know it.

as for estimating the work itself, think about how each step can be divided into separate sub-steps, and break those down even smaller, until you can get a fair picture of as much of the work as you can, with chunks small and discreet enough to give sound estimates for. If you can, come up with both an expected time and a worst-case time, to get a range of where you could land.

Another way to approach this is to ignore the old system. It sounds like a headache. Make an estimate of scraping the old system and implementing a new one from scratch, or integrating a 3rd party, off the shelf solution. If there's a case to be made for this, it is worth at least investigating it.

SingleNegationElimination
  • 151,563
  • 33
  • 264
  • 304
  • starting from scratch is a good thought; but be *very* careful with that also; as the current system has very possibly implemented fixes for many tricky bugs already. (Though to be fair; this is very dependent on the current systems code quality...) – wom Oct 19 '10 at 21:05
4

Sounds like a post for postsecret not SO. :)

I would tell him that it will be done when its done, and if thats not good enough, he can learn to program and help you. Then again, I think that you might get fired, but hey that sounds like it might be better.

Joel Berger
  • 20,180
  • 5
  • 49
  • 104
4

Tell him more or less what you told us. The project is too volatile too give an accurate estimate and the best you can do is give an estimate for a given task. As long as the number of tasks is unknown so will be the estimate. If he is at all worth his salary he would rather hear this than some made up number. This is not uncommon when dealing with a large legacy code base.

Nick Van Brunt
  • 15,244
  • 11
  • 66
  • 92
2

It's not that I'm adding a button to a screen or designing a web site, or creating and app or even fixing bugs.

That is a real problem. You can not estimate what you don't have experience in. The only thing you can do is pad your estimate until you think it is a reasonable amount of time. The more unknowns you think there are the more you pad. The less you know about it the more you pad. I read the below book and it spoke at length about accuracy vs precision. Basically you can be accurate but have a very large range. For instance you can be certain the task will be between 1 day and 1 year to complete. That is not very precise but it is really accurate.

Software Estimation Demystifying...

Some tips for estimating

Kenneth Parker
  • 93
  • 1
  • 7