One of the quality expected from a good project manager is the ability to estimate the size of a task.

In engineering and software field, a good way to do this is to ask someone who has experience or has done similar task. Which means asking an experienced engineer or analyst from within or outside the team, or if the manager him self is also an experienced engineer he can do it himself.

I my self is in that position currently. I have recently been promoted (more like falling upward) to development management, and I often found my self having to estimate or having to get estimates from my team for higher ups or for customers.

Being a developer my self, I have been told by my peer that my estimates are often too detailed or covering too many contingencies, a situation where customers does not always apriciate. Because it will all eventually be translated to time and then to dollar values.

When I was just a developer, my superior had less problem with me providing detailed estimates albeit limited to the tasks on my plate.

I aspire to be good manager one day. Is there any way I can guard my estimates without compromising the quality of information I provided. Maybe some recommendation on how to choose my wordings.

  • medium.com/@nezihtinas/… Dec 20, 2023 at 6:17
  • 1
    The level of detail you provided to your old manager is probably not the level of detail that upper management or customers care about. Would it be possible to obtain how your old manager communicated your estimates as developer onward? That might give you an idea on how to translate the detailed developer estimates into what the customer needs. Dec 20, 2023 at 8:15

2 Answers 2


The only good estimates come from the people doing the work. Project managers, development leads or managers who aren't 100% committed to the development effort, and people outside the team are not good estimators. Although they may have insights that are useful to the team, estimates are used by people to make decisions and the people doing the work need to be able to stand by those estimates. Otherwise, they become targets and plans and not estimates.

There are ways that senior developers and development leads/managers can help the team estimate, though. One way is by teaching good estimation practices and there are plenty to choose from. One way would be to help the team decompose the work into smaller, easier to estimate pieces, and then recomposing those estimates into a whole. This is a task that is inherently hard for more junior developers or people are new to the context (of the development organization, the project, or the technologies used). Maintaining historical data and making sure the team has access to it or helping the team develop analogies with or proxies for the work being estimated can help the developers doing the work. Facilitating group discussions and teaching the team these (and other) estimation techniques is also something that I would consider to fall squarely onto the shoulders of a development lead.

How to present the estimates is more of a risk management effort. You can spend a lot of time thinking through details and contingencies. However, not everything that you think of is bound to happen. Being able to identify the risks to the project and communicate the liklihood and impact of those risks to stakeholders is key. Being able to understand the threshold at which a risk needs to be considered when communicating an estimate is crucial.

When a team wants to estimate, my recommendations would be to involve the whole team and make estimation and risk management a group activity. The best thing that a project manager or a development manager can do is to teach risk management and estimation skills and facilitate the team's work. Then, when you communicate estimates, never communicate a single value. Always express estimates with a range and/or confidence interval, along with key assumptions.

Assuming that you do need to estimate, there are entire books written about estimating software development. I can recommend McConnell's Software Estimation: Demystifying the Black Art, Dinwiddie's Software Estimation Without Guessing: Effective Planning in an Imperfect World, and Cohn's Agile Estimating and Planning. DeMarco and Lister's Waltzing with Bears: Managing Risk on Software Projects is one of the best books on software risk management, but McConnell's Software Project Survival Guide, although on the older side, does address risk throughout various development activities.

However, estimation is inherently flawed and often an exercise in futility for complex software systems. I would strongly recommend taking approaches such as Vacanti's When Will It Be Done?: Lean-Agile Forecasting to Answer Your Customers' Most Important Question or Duarte's NoEstimates: How to Measure Project Progress Without Estimating instead.

  • +1 for Vacanti's approach. And if you just have to remember one thing: forecasts and estimations always imply a confidence level. So: we should all learn not to say "We can complete this by the end of March" but instead say "We can complete this by the end of March with 85% confidence" (adjust dates and confidence as required) Dec 28, 2023 at 15:47

In general, for every level information moves up, it loses some detail. This is necessary because, for every level of authority, the breadth of the person's responsibility increases.

I expect that your previous superior, who was managing you as a developer, accepted that this is the kind of estimates that developers give, and did the detail-removal himself. Now this is the skill you will have to learn in your new role.

For me, the key was to start with the kind of detailed estimation I would do as a developer; and then make a second pass and try to look at it as a higher-up who neither knew nor cared about the technical details (because they trust the folks who are doing the work to handle that, so that's actually a good thing). There are a couple ways you might do this:

  • Look at your detailed estimates and try to write an executive summary: what's the bottom line? What are the optimistic/average/pessimistic estimates for the larger project-level units that your management is tracking? Which are your least-certain estimates: do you want to add more contingency to those items, or just call out the risk? Estimates with error bars & risk notes are probably all you need to report up. (It took me a long time to stop fretting about how much information I was leaving out that was important because what if I was wrong? I was a lot more worried about that than my higher-ups were: not because they thought I'd never be wrong, but because they know estimates can be wrong & they'll handle it if it happens.)

  • Or, if you'd be more comfortable with an intermediate step before the executive summary, try grouping your estimates into 3 to 5 size categories, along the lines of the Fibonnaci sequence or something similar. Take the min/median/max for each category, & multiply each by Ntickets to get an overall min/median/max for each category. Apply gut-check correction if necessary; add some contingency. Tada, you have reduced your detailed estimate to a handful of numbers. For another level of abstraction, take the min(mins), median(medians), max(maxes). Now you have a single overall estimate with a range.

There are more ways to do this kind of thing, but it is an art as well as a science, and your management probably understands that. Try out different approaches; look for resources on release planning.

Bart's comment about geting in touch with your previous manager for some examples of what he used to turn in is a good one. I might also ask your current manager if you could see some examples of estimates that he receives from other direct reports.

Good luck, it's a process, you'll get there!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.