Present a document with estimations of duration of work [closed]

Question

Two months ago, I joined a software development company. They have just assigned me my first big task that consist in overhauling all the front end of one of our Rails apps. The project is still in the design department, but I will start to work on it soon.

The problem is that management asked me the typical "when you will finish". The truth is that I have no idea. Writing the HTML and CSS is not really complicated, but the controllers are a mess and I expect to discover lots of problems.

In this two months I've seen quite a lot of peers sleeping under the desk - this is Japan - and this is something I am obviously not going to accept, so I want to make the risks clear before even starting.

This is what I thought I will write once I get the definitive design:

Project: Redesign of X app.

Scope of the project:
- Write all the templates of the new design using HAML language: X lines of
  code affected.
- Write all the new stylesheets using X framework: X lines of code 
  affected.
- Refactor controllers and correct possible inconsistencies: X lines of 
  code possibly affected.

Description of tasks:
- Page 1:      x hours est.
- Page 2:      x hours est.
- Page 3:      x hours est.
- Component 1: x hours est. 
...

Total estimation of project duration: XXX hours.

Risks:
- This is the first time that we replace all the front end of the
  application. All the estimations have been done without having a 
  real example to compare, but when we added Page5 and Page6  in the 
  Issue #xxxx, took x hours work. This is the metric I am using to predict
  the duration of the tasks.
- I have detected some issues in the controllers' code that will necessarily
  have to be addressed while performing this project. Other unknown issues
  are expected to arise.

For this reason, I predict _high probability of deviations_ on the original
estimation that I think should be taken into account.

Appart from the awful grammar (feel free to edit), is there any other point that should be added to this document?

Also, this text just came out of my head, but I am sure that there are methodologies that are already being used in other companies. Is there an standard way to communicate estimations?

Answer 1

I'd back up a few steps.

You're being asked when the project can be completed. It's a valid question, but answering with specific hours will come back to bite you. Turn the question around. Let them know the scope of what needs to change, and ask them how long the last front end took. If the likely event that they don't have an answer, ask what metrics are in place for you to leverage--logs of time spent, etc After all, it's not how fast you can type. It's how fast you can get a clear understanding, cooperation with materials, etc. if they don't know how and can't calculate how long it took to build the last one, how can you know how long the next will take? One is speculation, and the other is a fact!

The real number will be much larger than their expectations. No one wants to here "6 months" for something that feels like 3 months. But if it took 6 last time, and is sloppy, then why shouldn't it take longer this time?

They'll likely know the start and end dates. Add 20-40% based on your comfort level. Now expectations are set and their derivations is clear. Beat that expectation if you can.

Answer 2

In this situation I would outline the work to be done, but I wouldn't estimate a timeframe. I'd ask for a while to get a real feel for what is needed before estimating. Because realistically you don't know yet.

If pressured I would go with the biggest margin I could reasonably estimate and say it should be done by then and may be done quicker. I wouldn't go looking for midpoints yet.