5

My project manager assigned me a task to estimate the development time for an iPad application. Lets assume that I gave estimation of 15 working days. He thought that the number of days where too many and client needed the changes to the application urgently (as in most of cases).

So, he told me: "I am going to assign two developer including you and as per my understandings and experience it won't take more than seven working days."

Clarifications

I was given the task of estimating development time for an individual. How could I be sure that 2 developers are going to finish it within 7 days? (I am new to team & I hardly know the others abilities)

Questions

  • Why do most of project managers / team leaders have understandings like:
    • If one developer requires N days,
    • Then two developers would require N/2 days,
  • Do they think something like developer = s/w production machines?
  • Should a team member (developer, not team lead or any higher post) estimate other developers work?

I didn't deny anything in the meeting and didn't said, but what should be the appropriate answer to convince them that N/2 formula that they follow is not correct?

Improve this question
8
  • Stack Exchange supports Markdown for posts, please avoid HTML in your questions. You can read all about it in the Markdown help page. Also one form of emphasis is usually enough, you don't have to put words in bold AND in italics AND capitalize them, we get it even if you just put them in bold OR in italics (please never again in all caps).
    – yannis
    Commented Nov 25, 2011 at 7:41
  • @YannisRizos - OK. I will keep in mind. Thanx for valuable suggestions. I do appreciate that.
    – sagarkothari
    Commented Nov 25, 2011 at 7:47
  • To be able to extract a formula out of a behaviour, the behaviour must follow some kind of pattern. If this happened just this one time, then it's possible your project manager is correct, and he estimated 7 days because he knows your abilities and the abilities of the other developer you'll be working with. For your question to make sense, this has to be a repeating behaviour. Is it?
    – yannis
    Commented Nov 25, 2011 at 7:53
  • 3
    Ok then, it's definitely a pattern. I'd suggest you buy the Mythical Man-Month as a Christmas present for your project manager.
    – yannis
    Commented Nov 25, 2011 at 8:06
  • 1
    Brooks's law it's not meant to be taken 100% seriously, Brooks himself labelled it an "outrageous oversimplification". The other expression of the law is closer to your situation though, "Nine women can't make a baby in one month". Anyway it was a comment, not an answer, not meant to be taken 100% seriously either.
    – yannis
    Commented Nov 25, 2011 at 8:15

2 Answers 2

Reset to default
5

Only really experienced developers are able to estimate properly. The reason is that the repetitive comparison between his estimations and what really happened (errors) teach him intuitively to increase his abilities.

Very few experienced developers or managers are able to estimate for others. Estimating for a whole team is even more complicated, and I personally believe it's impossible without proper tools.

That's why collective estimation such as planning poker coupled to velocity tracking is the way to go.

Planning Poker helps team avoid being affected by cognitive bias (thoughts being influenced by beliefs, environment, etc), while velocity tracking, later used in planning helps the manager to convert subjective estimations to realistic estimations.

Improve this answer
3

This is a standard estimation trap most people get into when higher authorities are do not have deeper insight into the problem. The crux of the problem is not estimate. Not even details, but typically it all boils down to perceptions (or in some case, competitive quotes that marketing guys needs to match).

Most project managers tend to pad estimates; and most people who manages PMs, knows this, and a vicious circle or the bargaining for estimates goes on. I haven't seen a PM who would won such a bargain!

In general, when you think that it is difficult to win over estimate arguments, it is time to implement Agile or iterative. In a nutshell, try to do most important thing first and invite the customer (or reps) to validate.

As a general rule, i would try to convince them with only a first firm release what everyone confirms as most important and a few milestone after that - many a times on the ground that balance depends on the understanding till this point. The more iterative you get, the better is the visibility of the project and people tend to appreciate the problems at hand better.

Second, Identify key risk areas earlier. Identify which are the key goals and milestones which has pivotal role in making project success or failure. And ensure what is the minimum time you can take to get there. Be clear and appraise anyone when potential issues (specifically requirements being still open ended) in the light of which the worst case best case ratio can still swing a lot. Identify and highlight key technology challenges. One might don't know or may be assuming that things might be easy to do.

Last, but important: Avoid getting more resources to reduce time lines.

Read this
1. article How to Deliver Quality Applications On Time and Within Budget and
2. book Rapid Development.

The essential teachings is that while most people demand fast schedule, they really need (and want) a reliable schedule. Bringing predictable, stable and more visible way of managing project brings all the desired confidence with which the why part of estimates becomes broadly more acceptable.

Over time, when people trust you more, you will see that estimation traps slowly goes away.

Improve this answer

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.