Estimating your way out of trouble
In IT you are always put under pressure to say how long it will take to do something, typically it is how long it will take you to do something you have no idea how long it will take you. As you can imagine this can be a little annoying. Luckily experience plays a big part here but there are a few things that can be done to help you out, mainly by not putting the pressure on yourself to deliver in a unrealistic time frame.
Next time you are presented with a “how long would it take for…” question pause and have a think.
- How much research time do you need?
- How long would it take you if you were to do it perfectly?
- How much time would you need to hack something together?
- What else have you got on?
- What else could go wrong?
Always trust your gut instinct as well and what ever else happens, add on about a third extra time, things go wrong. Worse case senario you have some room for movement when people start pushing the deadlines down.
This approach means you really have thought about what you are trying todo and you have put in a number of mitigations if they are needed, if they are not needed then you have some slack which can bu used for making it better, delivering early or my favourite, finishing the work early and starting the next piece before you were meant to. Work is a lot more fun when you are working to your own deadline.
Get ahead
So you’ve spent some time estimating your work out, you are comfortable with your time frames, so you just need to meet each little daily milestone to get to your end goal? Wrong! you could do that but then you stand the risk of being behind again, never get behind as it’s a slippery slope!
Especially in the early stages of delivering a project get ahead, put in the extra hours, be a little more pragmatic on the solution if possible try and build up as much spare time as possible. By having the spare time you can then start kicking off bits of the project that are a few days / weeks away so that when you get there you have gained back some time that may have been lost.
This will take the pressure off of the tasks later and it also means you can still do the ad-hoc tasks that comes up as and when is needed. One of the reasons I like being ahead in what I do is that I can then typically choose to spend a bit more time on areas I really want to be better or on trying out some new technology as part of the process. Normally when doing these I work a bit more iteratively than normal so that I can still deliver the basic goal even if the new thing doesn’t work out.
There is also the opposite of giving your self too much slack, I know I said to build some in but you have to manage the delivery of the task so you don’t deliver it all in one big chunk nice and early
Summary
Be realistic with your estimations and be cautious, there may be people in the team that believe they can do the work quicker, better etc etc; let them. We’re focusing on what you can control, if you think it needs a bit more time then so be it, if it comes down to arguing over a bit of time here or there then give away some of the slack you built in, if it keeps getting tighter, change the way it is being done, get two people involved, split some tasks out, agree a smaller scope. You can not keep taking time out of what you are doing, you are being paid to deliver solutions not tasks, this means it needs to be slightly more robust than a matchstick but not as robust as a Zippo.
You also have to be cautious that your time frames are not stupid, if you thin it will take 30 mins allow an hour, but be prepared to discuss in detail what you are doing and why, all the checks that will be done subconsciously as you are doing the work. You do not want to get a reputation for not being able to estimate well, you need some slack not much, you need to manage the delivery of the tasks to appear in keeping with the time frame while using any spare time to get ahead.
soimasysadmin 