Estimating your efforts: better safe than sorry
When it comes to managing your projects, the only thing you can be 100 percent sure about is that you can’t be sure about anything for 100 percent. Yep, that’s our reality. As Socrates quoted about 2500 years ago “All I know is I know nothing”, that’s a wise man right there. And the paradox is, the deeper you get into the matter, the more this statement is true. Wonderful!
This is why every great project manager needs to master the art of estimations. Reasonable estimates give us a sense of security in terms of expectations. We might not know exactly when something is going to happen, but at least we have some range of time (for example three to five days) to cover up for it and plan ahead using this information.
Now this will seem contradicting (because everything in PM is contradicting something. Depends how you look at things) because every PM knows that deadlines are important, and strict, precise deadlines are even more important. Well, if you can pull that otherworldly, accurate planning of everything off (including the clouded future, possible natural disasters, a few meteors dropping here and there and also alien invasion) then skip this article.
However, if you can’t, you are going to need some pretty damn good estimation skills. In fact, those skills will save you from very tight situations and open up some breathing room for you and your team.
The art of estimation
A good estimate of a project (or a part of it) is basically a good excuse (making perfect excuses is another useful thing, but we will get to that some other time) in case anything fails or doesn’t go according to plan. This is your personal backup plan, which you can rely on to save yourself pretty much every time.
What’s important about estimation, is that you need it to be as precise as possible, (so they need to be as close to the real deadline that you have in mind as possible) while at the same time stretched enough to be in the safe zone (further from that deadline so that it won’t mess up your planning). This is something that needs practice: it can’t be learned with a book or lecture, experience is your best friend with this one.
So this is what you do:
1. You break down the project into milestones using whatever methodology you prefer. A milestone is essentially a part of your project, defined by a goal for a list of tasks you plan to achieve. Successfully completed milestones equal successfully completed projects. So focus on those ones carefully.
2. Set some actual deadlines for each of those small parts (do this as precisely as you can, but don’t stress yourself too much over it)
3. Set reasonable estimates for each of those deadlines (suppose you need something finished on Oct 5, you set an estimate Oct 4-6, or 3-7, depending on the amount of work to be done, possible problems, emergencies and what not) A solid way to do this is to calculate two outcomes: when everything goes smoothly (which technically never happens, but it’s possible in theory) and when everything goes as bad as it could go (this sounds more realistic). Then set the estimates according to those outcomes.
4. Always save your past project estimates to look through in the future. You need your experience and the statistics you gathered to make each coming project better.
Point number three is the core here, but the thing is, if you take an estimate that’s too close to the actual deadline, you might mess up in two ways:
1. You may finish the job on the actual deadline (considering the deadline and estimate are close) which is good obviously, but because of estimations , it might mess up your project plan that you made beforehand, and you will have to go back and redo it again.
2. If your estimate is too close, the time may not be enough to make it and you will go over the estimated deadline. This is when you will find yourself in deep… trouble -)
However, if you stretch the estimate too much, then:
1. You might not hit the overall project goals in the time needed, because you took too much time. This will lead to very unhappy clients, possibly failed projects, losing money and a ton of trouble flying your way. You don’t want this.
2. Your team will might get used to the type of comfortable working atmosphere, when they have a lot of time to spare. What happens when we have time to spare? We start wasting it. We get lazy. What’s even worse, if people get used to a comfortable regime, it will be harder to work intensely (when there is no time to spare) if a time like that comes in the future. In other words, longer estimates will lead to productivity loss, the last possible thing you want to get (not counting meteors: that would be pretty bad)
If we analyze those two cases, this is what we gather: Better safe than sorry.
Both too short and too long estimates are bad for the project, but with shorter ones, at least you don’t kill the productivity of your team and fail the project at the end. Yes, you might need to redo all of your planning from scratch, but that’s an acceptable fate compared to the other outcome, agreed?