One day, a young boy looked up at a nearby mountain. It’s towering presence amused and inspired him. On this day, he decided that he was going to climb the mountain and see what lies at the top. So he took his biggest bag, filled it with food and water and started the trek.
Two days later, his supplies were over and he had to walk back home hungry and disillusioned.
Apart from being a very poorly crafted storyline, the story above highlights dangers of not estimating and thus not planning.
A good number of software projects started out just like the adventure shared above, with a lot of enthusiasm and little respect to the available resources.
On this entry, we will be discussing the various tips and tricks you can use to ensure that you have reasonable estimates for your project.
Understand the work
As I always say, you can not develop concepts, you can only work on tasks. Before starting on any project, actually any task that will take more than a few hours, first decompose it and then estimate it.
This simple but useful habit will ensure that you have visibility on the work that you must do. It also acts as a buffer against underestimation by bringing to the fore items that would have otherwise disappeared in the collective.
Never give off the cuff estimates
I can’t tell you how many times the client has given a one sentence requirement such as “We want an event management platform” and then followed that up with a request for an estimate. Of course the estimate is needed immediately.
It is tempting to spit out the first value that comes to your mind. As much as possible fight this impulse.
Most people who hear your estimate will take it as a commitment and thus you end up in an awkward situation when it doesn’t pan out. In case you are wondering, it never turns out the way you expected.
Let the developers estimate it
Wouldn’t it be awesome if you could have a dedicated team of estimators who would tell you how long and how much each potential project would cost? Well give up on this dream, it will never happen.
The people best suited to give an estimate for the work are the people doing the work, period.
Have you ever noticed how everyone else work is easy? By letting other people work on the estimate for the developers, you are very likely to end up with gross underestimation.
Even more importantly, discussions on estimates surface issues that would have otherwise remain hidden. Eg if for developing a feature, developer A says it will take 10days and developer B says it will take 1 day. Then this presents an opportune moment to iron out the differences in understanding on what is actually required of the feature.
Estimate the mundane and obvious
While touring a new city, you are likely to see much more than the natives. This arises from the fact that the locals are so used to the environment they stopped seeing it. In the same way when estimating projects, it is at times possible to forget and omit important activities that never the less take time.
Some common activities prone to be forgotten include:
- Server/Environment setup
- Meetings and Demos
- Public holidays
- Leave days
- External tasks that the developers must do
Refine and course correct
Your estimates will always be work in progress. Just as the project evolves to better meet client expectations, your estimates must also evolve to reflect your current understanding of the project.
If at any moment you realize that your original estimate was wrong, bring it up as soon as possible and have the plans adjusted. It may be painful and awkward but that will not compare to missing a deadline.
How do you ensure you have dependable estimates? Talk to me in the comment section below or on my twitter @jchex