5 ms·

From around here that's everyone's experience of tradespeople in every non-emergency task. "Sure I can do this in 3 weeks." Then shows up once every two weeks

From around here that's everyone's experience of tradespeople in every non-emergency task. "Sure I can do this in 3 weeks." Then shows up once every two weeks and finishes around the four month mark.

watt 8y ago
I guess he was estimating the effort (billable time). But was not estimating the actual total time until completion which must include all the lead time, waits and dependencies.
- taneq 8y ago
  This is another part of the whole 'communication with clients' thing. You have to be clear whether you're talking coding time or wall-clock time. To be safe, give both.
bigiain 8y ago
I see exactly the same routine in our game. "Yes we can do that in three weeks. We need the API documentation for _those_ two systems, network access to _those_ resources, and credentials to log in to _those_ services first." 2 months later we're still waiting on critical pieces of those prerequisites, while someone's screaming that the deadline they'd committed to with the customer was 5 weeks ago.
- taneq 8y ago
  Oh yeah. This is why I'm always very careful about quoting prerequisites for any deliverable. "We can do X in 5 weeks after receipt of Y, Z and W." Then when they say "why don't we have X," I politely inquire after Y, Z and W. The most important part of this process is getting it in writing so that you can slap them with it later.
  - chii 8y ago
    > after receipt of Y, Z and W. the problem comes when you didn't know you need Y, Z or W until the work actually starts.
    - taneq 8y ago
      That's the difference between a research project and an implementation project. Research, you don't know Y, Z, W, or Q. Implementation, you know the full path from spec to deliverable.
    - afarrell 8y ago
      Which is part of why I think the most valuable part of an estimate isn’t the number. Its the task breakdown and identification of risks. 1) You improve your foresight so you can get your manager rolling on getting resources early. 2) You have a concise record of what you think you need. If you notice something else mid-project (which does happen even in otherwise-straightforward implementation projects), you have a concrete point at which to raise a flag to stakeholders. If you have zero confidence in an estimate from the beginning, then there is no point where its natural to realize “oh hey, this is going to overshoot and I need to communicate about it.”

From around here that's everyone's experience of tradespeople in every non-emergency task. "Sure I can do this in 3 weeks." Then shows up once every two weeks and finishes around the four month mark.

watt 8y ago

I guess he was estimating the effort (billable time). But was not estimating the actual total time until completion which must include all the lead time, waits and dependencies.

taneq 8y ago
This is another part of the whole 'communication with clients' thing. You have to be clear whether you're talking coding time or wall-clock time. To be safe, give both.

bigiain 8y ago

I see exactly the same routine in our game. "Yes we can do that in three weeks. We need the API documentation for _those_ two systems, network access to _those_ resources, and credentials to log in to _those_ services first." 2 months later we're still waiting on critical pieces of those prerequisites, while someone's screaming that the deadline they'd committed to with the customer was 5 weeks ago.

taneq 8y ago
Oh yeah. This is why I'm always very careful about quoting prerequisites for any deliverable. "We can do X in 5 weeks after receipt of Y, Z and W." Then when they say "why don't we have X," I politely inquire after Y, Z and W. The most important part of this process is getting it in writing so that you can slap them with it later.
- chii 8y ago
  > after receipt of Y, Z and W. the problem comes when you didn't know you need Y, Z or W until the work actually starts.
  - taneq 8y ago
    That's the difference between a research project and an implementation project. Research, you don't know Y, Z, W, or Q. Implementation, you know the full path from spec to deliverable.
  - afarrell 8y ago
    Which is part of why I think the most valuable part of an estimate isn’t the number. Its the task breakdown and identification of risks. 1) You improve your foresight so you can get your manager rolling on getting resources early. 2) You have a concise record of what you think you need. If you notice something else mid-project (which does happen even in otherwise-straightforward implementation projects), you have a concrete point at which to raise a flag to stakeholders. If you have zero confidence in an estimate from the beginning, then there is no point where its natural to realize “oh hey, this is going to overshoot and I need to communicate about it.”