3 ms·

The thing is, when I'm in this situation it's not that I cannot possibly ever estimate it. Taking the original example of three projects X, Y and Z (and a coupl

by smcl 4y ago

The thing is, when I'm in this situation it's not that I cannot possibly ever estimate it. Taking the original example of three projects X, Y and Z (and a couple of others to add context) the issue with estimating Z can be a combination of: - I am in the middle of developing X right now - I am also handling some bug requests related to unmentioned, previously delivered projects A and B - I am in the planning stage for project Y, and working with client and analysts to pull some requirements together - I'm vaguely aware of how project Z roughly works, but there are a few big unknowns with the project that need to be cleared up which could be the difference between re-using much of project W or writing everything from scratch. I can give a vague t-shirt sized estimate, or I can maybe say "4-8 weeks" but that doesn't satisfy the request because I'm actually being asked for a number that gets plugged into a field that accepts discrete time durations not fuzzy English descriptions or ranges. And I won't have time to investigate the unknowns in Z until I've mostly delivered X, it's nearing production release and I've resolved the bug reports for A and B. That doesn't happen often, but when it does it can be hard to convince someone even if you're saying very directly "I will need to take time and effort away from priority tasks to analyse the project, eliminate some unknowns so that I can provide an estimate other than the vague 4-8 weeks". If you're suggesting "just give the upper estimate" then fine ... now you're going to be asked to break down exactly why you think it's as high as 8 weeks, "wait, why isn't it about the same as project W which we already completed...?" and you're back at explaining that you to dedicate time to the task before providing a breakdown. Basically - if someone demands an estimate when you're not ready for it, in some environments it can be quite stressful. I actually believe the author was correct in going above the manager to establish whether a very vague finger-in-the-air estimate was sufficient, rather than throwing out a known-inaccurate number.

willcipriano 4y ago
The parts of the job you can't estimate are actually your managers job to estimate. To illustrate that: > I am in the middle of developing X right now That one you can estimate likely. It is a task that you can complete on your own without the rest of the organization. As a individual contributor you should be able to give a time frame for a task like this. > I am also handling some bug requests related to unmentioned, previously delivered projects A and B Software is going to have bugs, but I've never worked at a org that labeled bugs correctly. In my experience about half the time a so called bug is a specification miss or a feature request (a management problem), the other half need to be prioritized (again, management problem). If they want you to work on a bug over a project, deadlines are going to slip, and that is a management problem to solve. Your estimate of two weeks doesn't include washing the CEO's car or whatever other random task they want to pull you off to do, two weeks is two weeks and they gave you less than two weeks so of course it isn't done. > I am in the planning stage for project Y, and working with client and analysts to pull some requirements together So far you have been responsible for resource management to a large degree. You have to know in advance how many defects your software is going to have, how long it's going to take for a pull request to get reviewed, when the other team is going to get you what you need to complete the work, how often you will get pulled off to work on other tasks, etc. Now you are writing the requirements? What exactly is the management team doing if it isn't managing the product or the people building the product?
- smcl 4y ago
  What I was trying to say was that there are very valid reasons that mean I cannot and should not turn my attention to a distant project while I have my hands full right now. It doesn't mean I'll never do it, but it does mean that "I don't know right now, I need to complete some work before I can turn my attention to this properly" is not only a reasonable response but ultimately the correct one, rather than throwing out a number that I'll possibly be held to at a future date.
  - willcipriano 4y ago
    "It's going to take me a couple days to put together a project plan, given that the project itself has yet to be fully defined. Shall I put project X on hold until I get that done?" Resourcing isn't a individual contributors problem, if it will take you a couple days to get a estimate, and they choose to prioritize that. Fine. If they don't want to give you the time, refuse to speculate, if they keep pushing, tell them it will take a year or some other large number that you could do it 2 - 3 times over in. If they say it won't take that long, ask them how they know since the project isn't defined.
    - smcl 4y ago
      Ah yeah those are some good strategies and they're usually how I approach this when it comes up so I think we are on the same page :) It's just tiresome to have to do, and I feel like in doing so despite being polite and calm I think I'm being thought of as obstinate or a troublemaker. Which is a shame because in fact I'm trying to reduce the uncertainty and chaos and make everyone's lives a bit nicer :) Oh well, like I said it doesn't come up often enough to cause me great stress and I'm experienced enough to sort of handle myself when it does. Just ... I wish it didn't :D

by smcl 4y ago

willcipriano 4y ago

The parts of the job you can't estimate are actually your managers job to estimate. To illustrate that: > I am in the middle of developing X right now That one you can estimate likely. It is a task that you can complete on your own without the rest of the organization. As a individual contributor you should be able to give a time frame for a task like this. > I am also handling some bug requests related to unmentioned, previously delivered projects A and B Software is going to have bugs, but I've never worked at a org that labeled bugs correctly. In my experience about half the time a so called bug is a specification miss or a feature request (a management problem), the other half need to be prioritized (again, management problem). If they want you to work on a bug over a project, deadlines are going to slip, and that is a management problem to solve. Your estimate of two weeks doesn't include washing the CEO's car or whatever other random task they want to pull you off to do, two weeks is two weeks and they gave you less than two weeks so of course it isn't done. > I am in the planning stage for project Y, and working with client and analysts to pull some requirements together So far you have been responsible for resource management to a large degree. You have to know in advance how many defects your software is going to have, how long it's going to take for a pull request to get reviewed, when the other team is going to get you what you need to complete the work, how often you will get pulled off to work on other tasks, etc. Now you are writing the requirements? What exactly is the management team doing if it isn't managing the product or the people building the product?

smcl 4y ago
What I was trying to say was that there are very valid reasons that mean I cannot and should not turn my attention to a distant project while I have my hands full right now. It doesn't mean I'll never do it, but it does mean that "I don't know right now, I need to complete some work before I can turn my attention to this properly" is not only a reasonable response but ultimately the correct one, rather than throwing out a number that I'll possibly be held to at a future date.
- willcipriano 4y ago
  "It's going to take me a couple days to put together a project plan, given that the project itself has yet to be fully defined. Shall I put project X on hold until I get that done?" Resourcing isn't a individual contributors problem, if it will take you a couple days to get a estimate, and they choose to prioritize that. Fine. If they don't want to give you the time, refuse to speculate, if they keep pushing, tell them it will take a year or some other large number that you could do it 2 - 3 times over in. If they say it won't take that long, ask them how they know since the project isn't defined.
  - smcl 4y ago
    Ah yeah those are some good strategies and they're usually how I approach this when it comes up so I think we are on the same page :) It's just tiresome to have to do, and I feel like in doing so despite being polite and calm I think I'm being thought of as obstinate or a troublemaker. Which is a shame because in fact I'm trying to reduce the uncertainty and chaos and make everyone's lives a bit nicer :) Oh well, like I said it doesn't come up often enough to cause me great stress and I'm experienced enough to sort of handle myself when it does. Just ... I wish it didn't :D