28

Let’s say you estimated time for a case to be 3 days. In day two you notice that the case is growing and new scenarios are popping up which were not counted when the time estimation where done. The new finding leads to 2 days extra (total 5 days). This is a typical problem that you will face sooner or later as developer.

  • Which strategy can be used when you are going to notify project leader the new time of delivery?
  • Often you get the question why? How do you motivate the new time of delivery?

The fact is that many projects don’t put much time on analysis & design during SDLC.

EDIT: In very complex projects no matter how much reasonable time you put on Analysis & Design there are always surprises since the business rules are too complex. However in such cases I believe the project leader must be aware of the complexity and have right attitude when unexpected surprises comes up. The question is how to tackle project leaders who don’t understand the complexity.

3
  • 2
    I think the better question is, what do you do when the estimate was correct? Most of the time, it won't be.
    – user131
    Dec 17, 2010 at 7:56
  • @Tim Post You are right about "Most of the time, it won't be" I wanted to be reserving. Dec 17, 2010 at 8:03
  • 1
    +1 - Thanks for the EDIT which contains words of wisdom. The fact you highlighted (""In very complex projects no matter how much reasonable time you put on Analysis & Design there are always surprises since the business rules are too complex.)"" is very true. Jan 20, 2012 at 6:05

11 Answers 11

18

Delivering Bad News

You absolutely need to raise the matter promptly, however if you can do so in a reasonable timescale (that is a few hours, not more) you should do a bit of an impact assessment before you do.

As with all bad news it's best to provide detailed information (rather than just blurt out "it's going to be late") so provide as much / many of:

1) Revised estimates / timescales for the tasks which have slipped.

2) Revised estimates / timescales for future tasks which you now think, in light of knowing that some things have already over run, may take longer.

3) Very brief reasons why the slippage has occurred (don't spin, just the truth, but don't sound like you're making excuses). In this case you state "We estimated based on rules X and Y but they've now included Z which was never mentioned". He may be able to use this in explaining the delay to clients and educating them on the importance of being thorough in the first place.

4) If possible alternatives to bring things back on track (usually reducing scope but there may be other options - other parts of the project may be ahead of time and it may be possible to move tasks around).

Remember with slippages the psychological / credibility impact is culmulative. You may be able to get away with one but the second one will be a lot tougher and the third on tougher still.

That's why point 2 is important - revise not just what's already slipped but also future tasks which you now think may take longer than originally anticipated. Slipping happen in ITs, not learning from your mistakes is a bigger sin.

Preventing Having To Deliver Bad News

There are two scenarios here: first, you didn't do the estimates yourself in which case there's not much you can do other than to push to be involved in the estimates next time round.

Second, you did do the estimates yourself in which case you need to look at how to do better estimates. For me the key phrase in the question is "there are always surprises since the business rules are too complex".

With respect, if it always happens, it shouldn't be a surprise. If you only ever get half of the business rules then you need to assume that in your estimates and allow for the feature creep.

You can either do this by increasing the estimates for the rules you do have (it works but you're not educating anyone as to what's really happening), but better is to state with your estimates "Historically the rules we get are a simplified version of what they really want. The rules they've stated will take 3 days to implement, however we should allow another 3 days contingency for the rules that haven't been mentioned but are likely to be discovered during development and testing."

If the PM questions this then you need to remind him of all the times it's been true (with examples - it's hard to argue examples) and also gently suggest that it's in his interest to deliver on time as well as yours so isn't it better to be conservative?

But the bottom line: if you always underestimate because of a specific factor (in this case feature creep) then figure that into your estimates.

4
  • 3
    +1 "As with all bad news it's best to provide detailed information" However everyone doesn’t understands the details/complexity of the problem. Dec 17, 2010 at 9:41
  • @Amir - I've added a bit more, though as the person who does understand the complexity the simple truth is that it's your responsibility to explain it. They're not going to learn any other way. Dec 17, 2010 at 9:52
  • Good points! "with examples - it's hard to argue examples" & "gently suggest that it's in his interest to deliver on time". Regarding "if it always happens, it shouldn't be a surprise", the problem is that extra time for surprise are not constant. So you may not even take an average on them, since they tend to have large variation. Dec 17, 2010 at 10:25
  • 1
    +1 "Remember with slippages the psychological / credibility impact is cumulative." Jan 20, 2012 at 6:12
18

Time-based estimates are guesses about the future, and that will always fail in the long run. It's a pointless battle you can't win.

Stop estimating in days and start using relative estimation instead. Here is a simple example:

  1. Assign a number to each task. The toughest task may be 10 and the easiest task 1.
  2. Start programming to complete your tasks.
  3. After one week, stop your work and sum all completed tasks' numbers. Lets say you end up with 14. That's your weekly velocity.

Next week, repeat the process again. I bet your velocity will change, but not much. After a few weeks with this, your velocity should be pretty stable and that is what we are aiming for. Now you can start making plans with confidence. Pick tasks that sums up to your velocity and your PM can be quite certain it will be completed as promised. That is how you should tackle your project leaders.

4
  • Can you give an example how you keep track of the size of the tasks? Do you create a table with task types (like "create a new form", "add a method to webservice X") or is it more a gut feeling?
    – cringe
    May 5, 2011 at 19:09
  • Just compare with tasks you have estimated and completed earlier. May 5, 2011 at 20:23
  • +1 - "Time-based estimates are guesses about the future, and that will always fail in the long run. It's a pointless battle you can't win." This is the first time I am learning about relative estimates and it is definitely a food for thought. Thanks. Jan 20, 2012 at 6:17
  • What a brilliant idea! I will definitely explore this further.
    – meetpd
    Jul 4, 2018 at 4:46
4

As soon as you see the estimate being wrong you need to raise the alarm bell. Inform those who expect the delivery about the delay.

Ask for help from team-mates if possible. Make sure that you still deliver as high quality software as possible.

A short-cut will most likely do more harm in the end, and everyone involved should know this. Or atleast should it be possible to explain it to them.

4

This happens so often that no experienced project mananger will make much of a deal of it. Just be honest about it and don't make too optimistic new estimations; when you see it will take much longer, say it. Don't say "I need a bit more time" on a daily basis.

You will have to explain to the manager: was the estimate wrong in the first place or were adverse circumstances (spent a day hunting a bug) the reason for the delay? In the first case, something is wrong with the estimation process, maybe it's too optimistic or naive. In the second case, it's a case for the buffer that was hopefully included in the project plan.

3

Always keep the relevant stakeholders aware of your progress, including (especially!) the fact that your estimates were overly optimistic. They won't be happy, but they'll know where the project really stands and can plan accordingly.

Ideally your list of features will have been MoSCoWed - Must, Should, Could, Won't.

When you're heading for overrun, cut the Coulds, then the Shoulds. Cut features so you can ship on time: your project usually doesn't live in isolation, and you going past release date means the downstream projects will now also overrun their schedule.

Ideally you'll only have ~60% Musts. If you have to cut those you're in very deep trouble (having a very serious overrun), in which case you'll have to cut corners.

Make sure that you give yourself enough time after release to clean up the mess made by cutting corners!

6
  • 4
    +1 @Frank Good point regarding "Cut features so you can ship on time". The problem here is that I'm not the project leader. Dec 17, 2010 at 8:57
  • @Amir In which case your customer is (kind've) your project leader. You say "I'm behind. I can either cut this feature, or that feature. What shall I do?" Dec 17, 2010 at 10:28
  • @Frank Since we do Scrum, and the case is moved from backlog into the sprint it's seems to be written in stone for PM to reduce the cases. However an experience PM may not have this kind of problem. Dec 17, 2010 at 10:36
  • I don't like MoSCoW. The only clever with it is the acronym. Just keep your tasks in a prioritized backlog. Dec 17, 2010 at 11:41
  • 1
    @Martin shrug "Must" means "if you don't ship this feature you have nothing at all". That's different information to a prioritised backlog, which is "which feature would you prefer first?" You'd still have a prioritised backlog with MoSCoW. Dec 17, 2010 at 12:34
2

I believe the best strategy is constantly refining your estimation. I know, I'm saying: your question is somehow misplaced.

Reading Introducing Deliberate Discovery by Dan North I came to the conclusion that placing the estimation effort in the inception phase equals to make a prediction exactly when your ignorance of the problem and the domain is at a maximun level. Face it, you cannot predict what's uncertain, especially if it's still unknown.

Agile methodologies solve this problem breaking the project's life span into several pieces (sprints, in Scrum), and repeating the estimation (sizing stories) each week. Each week, what you know about the problem is refined, and so is the estimation.

To me, an estimation cannot be true or false. It just can be increasily refined. An estimation is not a commitment. That's why it's called estimation.

The best you can do when you are late (and also when you "risk to deliver in advance", because the problem is the same: you have estimated badly) is to escalation and raise the fact to the customer as soon as possible. It's called risk management. The sooner you give a feedback, the more effective the counter-misure will be. Usually that means that, if you have evidences you cannot deliver everything, yu should talk to your customer, tell her you can deliver only the 70% of the commitment and let her decide what's has more business value for her and should deployed first.

I wrote about it here Wrong estimation, help! I’m late! Cut features and stop waterfalling!

2

Project estimation is gambling, plain and simple. There's no reward without risk.

If the manager doesn't understand this, that is the first thing I would explain.

The question is, who covers the risk?

If you're on a fixed-price contract, then you are covering the risk.

If time-and-materials, then he is covering the risk.

So when estimating, it's important to understand that you're guessing, and you need to have an idea how uncertain the estimate is, and who is covering the risk.

2

It's called an estimate because it is an educated guess. It is not an infallible description of the future, and I have little patience for people that treat software estimates that way. Ultimately, many things will take longer than you expect, in rare instances they may take an order of magnitude more time. This happens even to the finest programmers in the world. How could a manager expect it not to happen to you? If your manager doesn't understand that, she doesn't have much experience. If she pretends not to understand it in order to apply schedule pressure, she is being unreasonable.

The best approach is the most obvious. As soon as you have a clear idea that a feature is going to take longer than expected, discuss it with your manager. There are often ways to proceed that will solve both your problems and your manager's. That is, the portion of the feature that is slowing things down may be relatively unimportant or easy to modify in a way that makes more rapid progress possible. Whatever the case, though, don't be bullied into a second optimistic estimate.

1

Let the all team know it and try to find a solution. I recommend 3 solutions, from high to low in priority:

a. Try to find a temporary hot-fix, or a quick-around

b. The work that you can do it, do it best. After showing your excellent part of work to the client, ask for their help: we can do this, but there's some problem, and it may slow the productivity of your work... Maybe you can ask them if there is any unnecessary request/feature which can be dropped, or cut down.

Propose an alternative approach for their problem maybe a good idea.

c. Overtime-working

2
  • I updated my question. It is the project leader who will be notified. Dec 17, 2010 at 8:15
  • I don't quite understand. You are the project leader, or only a programmer? Dec 17, 2010 at 8:17
1

This is a common problem :)

One of the more simple approaches is to add a buffer to any estimation you do, as unforseen problems always occur. The size of the buffer depends on the size of the team and the uncertainty of the technology and problem itself.

Bigger teams have more people who might get sick and less people that know "everything".

New technologies are always riskier than the ones you already know.

And when you see that you won't be finished on the estimated date, communicate early with the stakeholders. Maybe you can re-prioritize stuff or delay certain features after speaking with the customer/stakeholder.

0

Options:

  • Cut features
  • Cut quality (leave bug fixes for later)
  • Increase productivity
    • Find and remove blockers
    • Break/rest
    • Cut personal/sleep time
    • Get more workforce
    • Get better tools
    • Training
    • Increase motivation
      • Free food
      • [Promise of] raise/promotion/vacation/bonus/etc.
      • Threats
      • Improve working conditions (better hardware, furniture, etc.)
      • Change environment - work from a coffee shop or move the whole team somewhere cool - a mountain lodge or a lake house?
2
  • 1
    It should be noted that every word of that is a SHORT TERM answer to the question "what to do when time estimation goes wrong". Most notably, threats increase motivation briefly, and then have the opposite affect.
    – Dan Ray
    Dec 17, 2010 at 13:13
  • I agree that threats suck, though I am sure they work for some people and in some situations, especially if you plan on letting them go anyway.
    – xyzzer
    Dec 17, 2010 at 17:38

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.