Well again, I think I still wouldn't call it a failure just because the deadline is missed. I think you can label it a failure if the outcome is bad. If you're talking specifically about software development, if the release is a buggy piece of crap, that's a failure.
So if your manager sets the goal to implement a bunch of new features by a certain arbitrary, but they instead implement those feature later than that deadline, and then it's all good and everything works great, that doesn't seem like a failure to me. If, instead, they drop some of the proposed features for that release, but still release a substantial high-quality update by the deadline, that also doesn't seem like a failure to me. Sometimes you might include some aspirational goals that you don't expect to reach anyway, but as long as you get done the things that actually need to get done, by the time they need to get done, that's a success.
However, if management insists on reaching arbitrary goals by arbitrary deadlines, and the result is a bunch of overworked developers pushing out buggy updates with crappy half-finished features, then that's a failure. That's bad management.
In disciplines like Operations Research the rule is to never fill the work queue greater than 75% . Otherwise if anything goes wrong you're hosed.
I guess my point here would be, if you fill it to 100%, or even 120%, but everything is properly prioritized and you're ok with only that 75% getting completed, then what's the difference?
I might give someone 20 tasks to do before a set deadline with the understanding that they'll only complete around 7 of them. Why? Because I could be wrong. Maybe he can do 10. Or 15. There's no reason for anyone to run out of things to do. I could be wrong in the other direction, and he only completes 5. The important thing is to prioritize, and to know which tasks actually have to be completed. It might be that we really only need those 5 tasks completed before the deadline and we're fine. Or it could be that we needed him to complete 6 tasks, in which case, we'll have to push the deadline back. And that might be fine as long as that deadline is arbitrary. It's still not a failure, and doesn't necessarily need an analysis of what went wrong, because nothing really went wrong.
If I'm giving 20 tasks and a deadline that only allows 7 tasks to be completed, and I still expect all 20 to be complete, that's when there's a problem. If only 7 tasks got completed when you really needed 20 by the deadline, and the deadline wasn't arbitrary, then that's a failure that requires analysis.