If you are just starting out in your career and you are in an area where the bulk of your work will be project-based, then we would like to offer you a very useful piece of advice: keep a note on what tasks you are performing and how long it is taking you to do them. Over time this will give you a good feeling for how long any given task will take.

On this page:

• The Importance of Estimation
• Becoming Proficient in Estimating
• Utilizing the Work Breakdown Structure (WBS)
• Benefits of Detailed Breakdowns
• Enhance Your Project Management Skills

The Importance of Estimation

Unfortunately, in our early roles, we tend to work for technical managers who are happy to mentor us in the technical side of our work. Generally speaking, they feel that they are doing their charges a favour by shielding them from the Project Manager and from project-related administrative tasks, such as providing estimates.

However, whether you want to become a Project Manager yourself in the future or not, you will be working in project teams and, at some point, you will have to field the ultimate leading question: how long will it take? Unless you have been recording how long your work has been taking, you really have no basis for attempting to answer this. Not being able to provide reasonable estimates will frustrate the Project Manager and, no matter how good your technical work is, your name won’t jump to the top of the list when that Project Manager is acquiring a team for the next project.

Becoming Proficient in Estimating

So how do you become proficient in estimating? This is a question that many technical people ask, arguing that their work is highly unpredictable. Is it reasonable to ask someone to invent a new algorithm or device by noon Friday? But there are ways to break down your work so that you can provide scope for mistakes and re-work but, at the same time, provide useful estimates.

For instance, suppose you are starting out life as a computer programmer. You are tasked with coming up with an algorithm that will provide the necessary functionality, translating that algorithm into code, and then testing the code. These are three distinct schedule activities (as your Project Manager would call them), but each could encounter serious problems along the way.

What you need to do is to record the time taken to do the core work. This is something very few project workers do. How long does it take you to create a design artefact – a document, a blueprint, etc.? How long does it take to type in one hundred lines of code? How long does it take to create a test plan? How long to create the tests themselves? These are all predictable activities. Where the programmer becomes reluctant to commit to an estimate is when unpredictable work is involved. How long does it take to come up with the algorithm? How long will it take to get the code to compile? How many test runs will be needed before all the tests pass?

Again, these activities can be measured as you are doing them. If it took a day’s worth of research before the lightbulb went off in your head showing you the way to your algorithm, take note of this. If it took another day to compile the code, note this. If your test runs required several attempts and required changes to the algorithm and the code, then record not only how long the rework took, but how many times had you to revise your work.

Utilizing the Work Breakdown Structure (WBS)

This provides you with a more detailed breakdown of your tasks. If you ever find yourself in a Project Manager role and have undergone Project Management Professional (PMP)® training, you will already be familiar with the notion of the Work Breakdown Structure. So use this to describe to your Project Manager what your activities look like.

By breaking down your work into its constituent tasks, you can confidently estimate the routine tasks – creating documents, entering code, running tests, etc. Using iterations will help to build in contingency against mistakes. If you always have to revise your designs after a review, then factor in this as a step. If it has always taken three goes before the tests all pass, then factor in two test-and-correct cycles. If the new feature looks very difficult, add more iterations. In this way, you have built-in contingency explicitly into the schedule. If things run smoothly, these tasks will not be necessary and the Project Manager can record that this contingency was not needed.

Benefits of Detailed Breakdowns

Project Managers like to see breakdowns like this because it takes away the use of padding. It is much better to say explicitly that we are going to budget for three test runs than to triple the estimate for testing. The problem with padding is that work tends to expand to fill the time available for it.

Enhance Your Project Management Skills

Velopi’s PMP® exam preparation courses cover Project Time Management and various estimation techniques. They also cover Project Scope Management and the Work Breakdown Structure. For more details of these courses, please visit our training page, or contact us directly.