Six Estimation Tips
Deepa Tarak Balaji, PMP
Project Management Leader | Accelalpha | 22 Yrs Empowering IT Companies with Delivery Management, Software Development prowess
Boon of our existense or is it a Bane? Don't know which but an integral part of our lives. Software Project Estimation. A few tips.
1. Read the requirement
Read the specifications you have been given. Are you done? Read it again.
Multiple reads of the input is the simplest and most often overlooked step. Every reading gets you something new and new ideas.
2.Don’t be a yes man
The estimate needs to be a comprehensive one. If the inputs given are insufficient or the timelines are insufficient, put your foot down!!. An incomplete /shoddy job is going to please no one.
3. Don't reinvent the wheel
Completing an implementation from scratch often takes time and money. Something no you customer has in surplus. Or if they did, i am sure they wouldn't want to share it with you.
Can the specs be met with an off the shelf solution and minimal customization? Present that first.
If not would a combination of different solutions work?
Check your repository. Are there components you have designed in the past that can satisfy this need?
4. Not my cup of tea
Every cup of tea is not made keeping you in mind.
Be honest! If you're not the right person for this job admit it. There are plenty of other jobs out there waiting for you, much better suited to your skill sets and expertise.
5.Break it down into the smallest blocks
Every activity has many sub activities associated. Breaking it down has major advantages
One, you are able to clearly visualize each of the tasks and identify the time taken for each.The accuracy is much better this way.
Two breaking it down presents each of the sub activities to the customer so they can let you know if they have something different in mind.
6. The devil is in the details
Document the effort for every conceivable task.
Have you covered each deployment cost , associated documents, acceptable performance, operating system,hardware?
This way there is no ambiguity on what is covered and what is not.
Transformations, Data and Technology, Indian Administrative Fellow, Team Leadership, Projects, Engineering
9 年While there are few positive things here, it is not as simple as it looks. Few things are different for software applications compared to many other industries - details evolve over period, requirements/design and hence estimation are actually happen in successive elaboration. Even for buildings, railways, factories, requirements and design evolve successively but in those industries construction will not start until designs are signed-off. For softwares, even list of requirements are fluid and more are designs (functional and technical), construction often starts when requirements/designs are 50-60% clear (worse in agile where construction starts almost at the beginning of requirements identification, design and constructions get intertwined). There is pragmatism in taking this approach of starting construction while requirements are not fully clear - we can't sit and think of all possibilities, they strike as we progress with construction. Also, building applications are not equivalent to making things in factories where simply products are churned-out on frozen, well tested designs. Almost all application building have some degree of discovery, research which can add to lot of uncertainties. In the end, estimation is hard, we can make reasonable guestimates which can be solidified as projects progress.
SME at Nexteer India Software Center
9 年Very nicely and efficiently put!!