Lets 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 dont 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 dont understand the complexity.
What to do when time estimation goes wrong?
project management;development process;time;time estimation;sdlc
Delivering Bad NewsYou 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 NewsThere 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.