On the topic of estimates and deadlines, I might have already mentioned this, but did you consider using "agile planning"? It's one of those rare "bureaucratic" methods that seem to actually make sense and work.
Basically, instead of estimating your tasks in terms of "hours needed", you estimate them in terms of "size", and you score them relative to each other. So, say a large 3D model with complex textures and animations is an 8, a simpler model with fewer animations might be a 3, etc. It's important to always rank them relative to each other, and to keep a reference of what a 1, 2, 3, 5, 8, 13, 20... looks like (the weights I gave are the weights usually allowed, they're meant to resemble the Fibonacci sequence because the multiplicative factor between each number approximates the way a human loses precision as scale increases). If your tasks score in the 20s and above, then breaking the task in smaller sub-tasks can help increase the precision.
Afterwards, you consider how many "points" you completed every couple weeks (between 2 and 4, traditionally) and observe the rate at which you score "points", which can THEN be converted into a time estimate.
The idea is that our own time estimates are generally very bad, but that if we formalize our estimates and then look at how they correspond to actual progression, the estimates become more accurate.
I also like a slightly more complex variation of this planning where you also give estimates based on your worst-case and best-case estimations, which then gives you a ballpark of when you're done, instead of a vague end-point that might be way off.
At work we do something like this, and we also give ourselves an "efficiency rate" when people are sick, new, in formation, or on vacations. For instance now a lot of us are on vacation and our efficiency is ranked at 70% of our normal point-scoring rate. It's all quite subjective, but the point is to at least give *something* to look at and measure, even if it's vague. Dwelling on it is unnecessary since it rarely adds a lot of precision beyond a couple minutes of reflection.
Basically, instead of estimating your tasks in terms of "hours needed", you estimate them in terms of "size", and you score them relative to each other. So, say a large 3D model with complex textures and animations is an 8, a simpler model with fewer animations might be a 3, etc. It's important to always rank them relative to each other, and to keep a reference of what a 1, 2, 3, 5, 8, 13, 20... looks like (the weights I gave are the weights usually allowed, they're meant to resemble the Fibonacci sequence because the multiplicative factor between each number approximates the way a human loses precision as scale increases). If your tasks score in the 20s and above, then breaking the task in smaller sub-tasks can help increase the precision.
Afterwards, you consider how many "points" you completed every couple weeks (between 2 and 4, traditionally) and observe the rate at which you score "points", which can THEN be converted into a time estimate.
The idea is that our own time estimates are generally very bad, but that if we formalize our estimates and then look at how they correspond to actual progression, the estimates become more accurate.
I also like a slightly more complex variation of this planning where you also give estimates based on your worst-case and best-case estimations, which then gives you a ballpark of when you're done, instead of a vague end-point that might be way off.
At work we do something like this, and we also give ourselves an "efficiency rate" when people are sick, new, in formation, or on vacations. For instance now a lot of us are on vacation and our efficiency is ranked at 70% of our normal point-scoring rate. It's all quite subjective, but the point is to at least give *something* to look at and measure, even if it's vague. Dwelling on it is unnecessary since it rarely adds a lot of precision beyond a couple minutes of reflection.