How can I avoid creating a time plan for remaking software i have zero documentation of?

Question

I'm an intern and my work consists in rewriting existing scripts running on a proprietary platform, using technologies (javascript, css, html and php) very different from the original ones (mostly vb6 on client's machine). I work in a regional detachment of the company and I'm the only one developing all our "regional" scripts.

The project manager understandably wants me to create a plan and give her general deadlines for each of the scripts: the problem is, there's insufficient (and in some cases zero) documentation on the original software. My senior stood up for me, but he's too being pressure to make functional requirements for those scripts (and all the people who worked on them don't work here anymore, so noone knows what they do in details).

These scripts are vital for the migration of the platform and the central company is pressuring every department to migrate, without giving us the resources to do so. Needless to say, we're all in deep shit, but how do I prevent myself from taking the blame if I screw up the time effort in the plan I need to make?

Answer 1

Don't run away. This is good experience, and something you'll deal with from time to time over your career. I don't think you can (or should) avoid this activity if you value this job and want to keep it.

You're not going to get any documentation, or even requirements, before your estimate is due. So your only option is to estimate the work based on having to spelunk through the source code to figure things out.

You need to do some analysis on the scripts to develop an idea of roughly how long each script will take to modify/recreate. Estimation is just dealing with averages, so it doesn't have to be precise, but more accuracy, is better, of course.

Ask the manager to allow you a couple of days to do the analysis on one of the scripts -- one that is a good proxy for the average script. Do enough work to get an idea of the work involved and how long it takes you to do it (all of it: analysis of the script, coding, testing, documenting).

Once you have an idea of what an average script might take, you can extrapolate the rest of the estimate and put it on a timeline that accounts for your schedule.

You should collaborate with your senior developer to have him/her check your work. You also need to factor in dependencies on the requirements. Your scripts aren't done until the requirements are done and you've implemented all of them correctly. So keep that in mind as you schedule the work.

When dealing with estimates and schedules, remember all estimates are wrong. Some are just wronger than others. We want to do our best, but we can't know everything that will need to be done.

It is a little sketchy of a company to lay the job of estimating work on an intern with so little experience. But it's a good way to get experience. If your senior developer will help you, you'll be ok. If not, you should factor in a lot of extra time for figuring things out on your own.

Good luck!