> if downstream ops are expected to cope with, say, a deviation of 20 %, that tolerance kind of becomes the goal for the forecast accuracy. I think a forecasti

> if downstream ops are expected to cope with, say, a deviation of 20 %, that tolerance kind of becomes the goal for the forecast accuracy. I think a forecasting target of 20% shouldnt be necessary unless you want to be around 19% deviation. Which might be the case if trying to reach 0% has diminishing returns and isnt actually cost effective. In other words, targets make sense when you are literally targeting a sweet-spot. If 0% deviation is desired, then the directive is still the same - try to be as accurate as possible. If "as accurate as possible" is consistently falling below 20% (which is the importance of measuring and data) then you need to address that. Maybe forecasting is broken or infeasible. On ops side, they might not be expected to handle deviations over 20%, but the directive is probably the same either way "do the best you can to manage the deviation". >For me, setting limits on certain metrics is something different from a target. It is a thin line between those. I agree with this in general. It can be tricky to communicate "here is a boundary that absolutely cannot be crossed, but keep in mind you should be nowhere near that boundary anyway" without it impacting peoples personal optimization strategies. You really have to weigh the consequences of what actually happens when that limit is reached, and if it's worth a possible depression of performance from the team.