-1

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?

8
  • 1
    If you can, avoid estimating a specific number of hours. Your (or anyone else's) ability to accurately estimate the scope of work at that level of granularity is virtually nonexistent. Instead, think about the number of whole days you think each task will take, and multiply by 8 to get hours. Do that for both the 'best case' and 'worst case' scenarios for each task. Split the difference, and report a range of '<midpoint> to <worst case>' hours. Because the best case almost never happens.
    – aroth
    Feb 6, 2016 at 2:06
  • 1
    On a simple task, I've learned I have to double my immediate instinctual answer. On a complex job.... as the estimate gets longer, the unexpected increases and so does the scaling factor.
    – keshlam
    Feb 6, 2016 at 2:22
  • 1
    You may get answers from a different perspective over at Project Management.
    – nvoigt
    Feb 6, 2016 at 13:07
  • Thanks @nvoigt, I didn't know this stackexchange site. I hope they don't mind the cross-posting!
    – Daniel
    Feb 7, 2016 at 4:12
  • @Daniel Please note that cross-posting is not an acceptable practice on the StackExchange network. Virtually all questions that are written properly and have been thought through will have a single site where they are most suitable. If you felt that your question should have been asked on PM instead and is on-topic there, flag your question for moderator attention and request a migration.
    – Lilienthal
    Feb 8, 2016 at 12:55

2 Answers 2

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.

1
  • This is a small an quite new company, with poor project management culture that we all have improve. They don't know how long this project will take, but they just want to hear "soon". Asking all this information (that they won't be able to give me), will be useful to remind them that the responsibility of managing the project, and giving deadlines based in actual data, is theirs.
    – Daniel
    Feb 7, 2016 at 4:11
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.

2
  • Although you are true, they are expecting an estimate. My goal is to turn the situation around without directly confronting them but without committing myself to a deadline that I don't know if I will be able to meet.
    – Daniel
    Feb 7, 2016 at 4:06
  • Then turn it around and ask them for an estimate. I never commit to an estimate unless I know I can make it. I'll only make a guestimate and make it very clear it could be wildly off until I know more. Ask them what timeframe they need it done in.
    – Kilisi
    Feb 7, 2016 at 4:55

Not the answer you're looking for? Browse other questions tagged .