Estimating a project with many unknowns

Question

I'm working on a project with many unknowns like moving the app from one platform to another and with an original JDK that was abused (changed) with dependencies in code that do search for file path like \\ with calling other servers with shared directories etc and need to move it to Unix. I find that there are MANY unknowns.

My original estimations are way off and there is no way I can really know for sure when this will end. I have about 10 people helping with this project but it's huge and based on hundreds of programmers years codebase.

My question what do I tell my CEO? that I have no way of estimating this project because we are actually finding more and more unknowns and fixing them? 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.

What do I tell my CEO? Listen I can't estimate it? How can I tell him that? Am I not here to estimate stuff? I don't feel I have a way of estimating it, but I think it's a matter of months. I can't know. I don't know for which version I can deliver it. What do I tell my CEO?

Answer 1

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.

Answer 2

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.

Answer 3

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.