How do you communicate if you won't hit an estimate?

<i>How do you communicate if you won&#x27;t hit an estimate?</i><p>Immediately, with brutal honesty, and positively.<p>1. Immediately: <i>Never</i> delay communication. Most people will be less upset about the schedule than the fact that they weren&#x27;t informed.<p>2. With Brutal Honesty: Explain exactly what&#x27;s going on. You may end up with a pleasant surprise. &quot;Oh, can we just have xyz then?&quot; or &quot;How can we reduce the scope?&quot; or &quot; How can we help you make this easier.&quot; An informed customer&#x2F;boss is a resource to be used.<p>3. Positively: Find a way to deliver <i>something</i> by the deadline. &quot;ABC will be delivered as planned on October 31, but we have run into unexpected issues with Feature xyz, so it may not be fully implemented at that time.&quot; sounds a whole lot better than, &quot;We won&#x27;t hit the October 31 deadline.&quot; You may even give them options in terms of features &amp; dates. They may not like it, but once they make a decision, they feel more a part of it and you will have bought some goodwill for a while.

My favorite question: &quot;Is the date slipping, or has it slipped?&quot;<p>What you really need to do is help the person setting the deadlines plan. There are things they&#x27;re doing that are synchronized with finishing the project, and there are things that simply depend on the project. Marketing may want to publish a blog post. Sales might want to promise a delivery date (or already has). Management might want to claim victory for a Q3 delivery. All of these things are outside your knowledge, and they&#x27;re frequently based on your initial estimate.<p>So, over-communicate, but also slip once, and slip hard. If you&#x27;re a week out, and going to miss by a day, slip the date a week. Fuzzy, frequently communication isn&#x27;t useful, because nobody can plan around that. Make sure you are clear about the moment in time you want the project manager to go from &quot;I&#x27;m worried about date X&quot; to &quot;We&#x27;ve change the date to Y&quot;, because while it&#x27;s fuzzy in your head, it needs to be clear in theirs.

You should tell them right away. Be honest and upfront. Sleep easy at night. Work without it hanging over your head. Here’s why:<p>- The person who you inform may have others within their organization to update. It reflects badly on them too when they find out last minute something won&#x27;t be on time and can break all of their internal assumptions about their timeline. They have goals too.<p>- Delays pile up. 2 days here, 4 there, a week on that other thing… before you know it you’re a month behind schedule. It’s much easier to discuss things incrementally than it is to spring the totality of all delays on them when they believe they’re much closer to a completion date than they really are. “But we’re only a week away, how is it going to take another MONTH?”<p>- Finally, though we’d all like to think otherwise… clients often make some changes during projects. When those changes occur and you’re already on the same timeline, it’s much easier to discuss how the changes the client is requesting are going to affect the delivery date. This helps with their confidence in you, and their capacity for accurate internal debate about project changes&#x2F;additions and what it will do to the delivery date.<p>Estimating development time is incredibly difficult; most methods involve some kind of padding which is obviously not an exact science. There are always hidden rabbit holes, unexpected problems and tasks that were completely unaccounted for. If you’re transparent with the client and communicate when there is good news (hey, check out the xyz feature we just finished) as well as bad news like delays, most of them will understand.

The key is to divide your milestones in very small tasks in hours and communicate this detailed hourly plan with your total estimate. Update your manager&#x2F;client about your progress as frequently as possible. Twice a week if not daily.<p>During the project, if you realize that your estimates were originally wrong, fix it asap and communicate immediately. Frequent communication is the key.

Estimates are notorious for all developers, not just new ones :)<p>Most people have a hard time realizing they are stressed out -- you are suddenly completely freaking out! If you wait until there is a problem, you&#x27;ve waited too long. Risk shows up way before it manifests.<p>Daily gut checks are an easy way to notice risk. Ask yourself &quot;how is the estimate aligning with the actual work left?&quot;<p>Once you know there is misalignment, the most valuable way to discuss is focusing on work left.<p>The most important thing to remember when you know you are stressed out is to take a deep breath and relax. Understanding how you are evaluated for success and primary business drivers will allow you to discuss risk and delays in a language that can influences others and address what is more important.<p>Things that really help estimations: 1. Thinking about work in relative complexity rather than time allocations. More complex work increases time exponentially. Unknowns are almost always filled with gotchas. Any work that is more than a medium in complexity is best experimented on in spikes or broken down into smaller pieces of value.<p>2. Use your gut. It knows better than your head because these problems are often too complicated and deep to really have any idea how long they are going to take<p>3. Firm up definition of &quot;done.&quot; There is a lot of overhead beyond coding the solution that makes something complete. Having a well known definition of done that everyone agrees on will help consider all the things that are often forgotten.<p>Go easy on yourself. Your estimates aren&#x27;t wrong, they are off. You don&#x27;t make good money because you are solving easy problems with well known solutions. You are creating simple solutions to complicated problems. Estimating anything when its complicated is most often inaccurate...<p>When all else fails default to Uncle Bob&#x27;s standard answer: 3 weeks :)<p>Good luck!

One of the things that McConnell&#x27;s &quot;Software Estimation&quot; repeats a lot is that estimates are _intervals_. I&#x27;m a bit surprised not many people here have mentioned that.<p>If you give a single number, there&#x27;s a 100% chance that it&#x27;s wrong -- you&#x27;re never going to hit it exactly.<p>Instead, what you should be aiming for is to give an interval that is correct, say, 90% of the time (so still wrong 1 out of 10 times).<p>If you do it honestly, the intervals have to be much wider you than you are used to -- the &quot;two weeks&quot; you would usually say is realistically more between 8 working days and six weeks, with 90% confidence.<p>A major benefit of giving intervals to people instead of fixed numbers is that it makes it really clear that it&#x27;s not a deadline and can&#x27;t be treated as one.<p>If they tell you this is unacceptable, then only give the high number, and McConnell&#x27;s book.

As soon as you realise you won&#x27;t. This will give your customer a bit of leeway in managing expectations, preparing alternatives or what have you.

As early as you are aware, you communicate it.<p>The advantage of things like Scrum is that a 1 week sprint size should flag up slippage within a week.<p>It&#x27;s hard for people to actually know they&#x27;re going to miss a deadline, and they might feel that they can course-correct. But if you have a really clear definition of done, and work broken down into pieces that fit within a week, and you do planning each week... then you will know as soon as you slip, that you are slipping. And if the product owner is involved in planning, then there&#x27;s just no hiding it and he can communicate it upwards.<p>Things like agile and Scrum are core processes for this... they give you nowhere to hide, and that helps those who need delivery to get that feedback early so they can prioritise what they most want delivered (if the deadline is more important than the totality of the delivery) or how they&#x27;re going to communicate slippage up the chain (if the totality of the delivery trumps the deadline).<p>If this is all noise to you, then just do this:<p>1. Break your 3 month project down into logical pieces of work, each one small enough for you to understand roughly how to do it (realistic work effort) where no single piece of week should be larger than 1 week (if it&#x27;s bigger, it&#x27;s a smell that you&#x27;re estimating badly and don&#x27;t understand each of the parts involved).<p>2. Order all of the pieces of work such that you are doing the most important things (decided by the project sponsor) first.<p>3. At the start of each week declare what you will <i>finish</i> that week, always the most important things you could be doing... and get to work.<p>4. On Friday, see whether you finished everything you said you would. If you have not... you have slipped and it impacts next week and gets communicated.

It starts way before you are running over budget. Your entire sales and contracting process needs to reinforce the idea that there are no fixed cost estimates prior to the completion of the discovery process and sign off by the client on the wireframes and&#x2F;or software specification document.<p>Granted, 90% of clients don&#x27;t really work that way. In which case you need to gauge your comfort level with getting them to buy in, or in some cases, you simply have to walk away from the client that has a one page overview of a complex web site and wants a fixed cost, binding bid.

If you&#x27;re managing your project in a tool like JIRA you could provide your client with a burn down chart. It&#x27;s the easiest way to tell at a glance how a project is going, and takes next to no effort to produce.<p>If you&#x27;re not managing your project in such a tool then you should be. If you&#x27;re not breaking your job into small enough tasks that the chart looks reasonable then you should be doing that too. Both these things will force you to come up with better estimates and give you a record to learn from to provide better records in the future.

Don&#x27;t guess at how long it takes to complete work. Plan what you think you need, and then do a week of stories. Based on your velocity, make a confidence interval of dates. Next week, do the same thing.<p>If they want a fixed date, take 60% of your velocity and you&#x27;ll be pretty sure your math will work out to give you the project on time.<p>Anything not based on data is pulling numbers out of your ass, and it&#x27;s hilariously disastrous every time.

There is someone who OWNS the estimates, usually manager. So I just tell him that his estimates were wrong, same way I would open new bug report on software. For my own customers I provide revisited estimate and plan B if they decide to pull the plug.<p>There is lot of stuff about honesty and so on. After being maintenance programmer for a long time, I would just say: Do not stress about it, and always inform relevant people.

The most important thing is to state unmisunderstandably, before you start the project, that you are making an estimate which has an error range of +&#x2F;- 3 <i>orders of magnitude</i> and that you will be revising it as you go along.<p>Once that is clear, the customer is prepared and will be expecting and able to handle estimate revisions whenever you make them.

As many here said, immediately and honestly. Next time make sure you either have enough information to base your estimate off, or way-way-way over-estimate. Stick to your guns. If you finish early, fudge - make the estimate. This way you accomplish two things - you get the time you need and you are seen as reliable and accurate.

The way to handle estimates is to have milestones. At the milestone, scope, cost and schedule changes are formally decided.<p>If you can&#x27;t pick reasonable milestones, there&#x27;s no way you can make a meaningful estimates. And without reasonable milestones there&#x27;s no way to analyze where the process slips and to <i>learn</i> from it.

Don&#x27;t. Never provide an estimate unless asked. Same goes for reestimation.<p>If anyone asks you why estimate wasn&#x27;t accurate provide him with list of all the things you&#x27;ve done since estimating related to the task, if he inquires further also unrelated.<p>If you see anyone that thinks that estimate is a promise or a price, remind him that it&#x27;s just poorly informed guess, and any decission based on a guess is gambling. And you can&#x27;t win them all. You can&#x27;t even win enough to break even.<p>Estimate is such a misused word. It suggests that some process of estimation was performed and given number is result of that process. One might hope that some math was involved. In reality this word is used for numbers about the future pulled straight from someones ass.<p>To get an actual estimate of what will be done and for when involves a team, planning poker and few sprints to measure team velocity.<p>All above is for when you are employed. If you have your own customers pad heavily both the budget and the deadline. Even if you think you are pessimistic in the end turns out that you were still to optimistic, because task mutated.

I think part of the problem here is the way we estimate duration. Estimates won&#x27;t always be right, but they shouldn&#x27;t be always wrong. If you spend the time to break phases into milestones or smaller work packages your estimates will generally become more accurate.

Such huge debate about estimates - for what? Have you ever thought about estimate as a waste? Is it not better to manage the software development as a pull system? Instead of push the Estimate-driven development?

You bring up a specific challenge, how to handle it when you realize a deadline is probably going to be missed. That&#x27;s one aspect, but you also need to look at why your deadline is going to be missed more broadly.<p>Here are some challenges that come to mind in software estimation:<p>1. Estimates are almost always done too quickly, with too little information. If you can wait, spend more time, or reduce the unknowns, do so. If nothing else give it an extra fifteen minutes. If you can say &quot;I&#x27;ll get back to you with an estimate by ...&quot; (e.g. tomorrow or end of day) that&#x27;s even better.<p>2. Estimates are ranges, a probability that the work will be done across a range of time. but are often given as a specific date or amount (e.g. &quot;It will be done tuesday&#x2F;take 5 working days&quot;). Early or quick estimates may be ranges of 15x or more (e,g, &quot;it will be eight hours to three full work weeks&quot;). Don&#x27;t be afraid to capture that ambiguity in a range. Others may not understand ranges, so give them the high end if needed, but at least be aware that ranges exist. Often ranges, or high estimates get push back. This is your opportunity to specify what questions need answers, what requirements need refined, and what areas need more design and architecture to reduce ambiguity. These things can reduce ranges of estimates.<p>3. Know the difference between estimates, targets, goals, and commitments. Confusion between these leads to miscommunication and frustration. Often we&#x27;ll make a guess like &quot;maybe two weeks&quot; which is a wild instant estimate, and others will see how nicely that lines up with their target date, and believe you have committed to that goal. Commitments should be explicit, and part of your process.<p>4. Do not negotiate estimates. Managers are trained to negotiate, and a naive manager will almost always reduce estimates through negotiation, which is a distortion of reality. Developers should collect the information they need about the requirements, ask questions, then produce their estimate in isolation, and refuse to change it. The way to change an estimate is to change the requirements, often addressing ambiguity and questions, and re-estimate the work given the new information. This is hard to do, because a &quot;better&quot; timeline can make everyone feel better in the moment, but will lead to problems later.<p>5. Renegotiate when change happens, or when you are in danger of failing a commitment. This one answers half of the original question, to my mind. If you didn&#x27;t make a clear commitment, or requirements are changing with out any renegotiation, you have to fix those first. After that, keep a close eye on scope creep, and changes. Change happens, accept that, but make sure that those you have commitments to understand that change has impact on your commitments, and you can either commit to the original work and timeline, or you can commit to the new work, and a new timeline. Holding you to new work on an original timeline is not fair to you, and not a problem to be solved at the developer level. This one can be quite challenging, some people use &quot;change management&quot;, itemized &#x2F; ticket based change requests, even explicit signoffs. If you have trouble here, find what works for you.<p>6. Learn from history. You won&#x27;t get it right. A lot. Keep track of how you are doing, improve processes and spend more time refining requirements&#x2F;acceptance criteria etc. Make sure commitments are negotiated and explicitly agreed to. Keep learning.<p>7. You will make mistakes. If you uncover new questions, requirements, found work, it was in a certain sense an estimating error, but it has a different fix. If you had a reasonable view of the work to a fair level of detail and spent reasonable time on the estimate, and are still missing your commitment, you have made a mistake. That&#x27;s OK, especially early on, or in new areas for you, if a team has shifted etc. The answer is, communicate. Let your manager know immediately, as soon as you realize it, that you feel you are at risk of failing a commitment, and you need to revisit. From there, you can investigate the new work, or re-estimate based on your increased understanding of the problem. Perhaps note some data for your historical tracking. Learn. Next time, make a better estimate. It does feel bad to miss a commitment, or even to not make a deadline that someone else set up. That&#x27;s very human. The way to feel better about it, is to get better at it.<p>The above is based on my decade of experience as a software developer, and a solid foundation from Software Estimation: Demystifying the Black Art, By Steve McConnell <a href="http://www.amazon.com/Software-Estimation-Demystifying-Developer-Practices/dp/0735605351" rel="nofollow">http:&#x2F;&#x2F;www.amazon.com&#x2F;Software-Estimation-Demystifying-Devel...</a><p>I highly recommend the book as a learning resource, and having the whole team, managers included, read at least the first portions of it. It also has specific tools for various estimating challenges.

HONESTY and just do your best. Be apologetic.

How you communicate an underestimate will differ slightly if you are a freelancer&#x2F;consultant compared to an employee. The primary difference being the level of technical sophistication of the person you are telling.<p>The basics should be the same with either party, though.<p>Always open the communication lines as soon as you know you are behind. You don&#x27;t have to say &quot;My project is definitely going to be late&quot; but rather be honest. If you are behind on a milestone, speak up now.<p>Don&#x27;t assume you can just make up the time during the rest of the project. The worst thing you can do when your project is running behind is make it a surprise to everyone on the day of the deadline.<p>When you speak up early, this is also good for everyone else involved in the project. If you are a freelancer, you can work with your client to make adjustments to the scope to keep things on track or they can delay other parts of the project if it is a coordinated effort of more than just your work.<p>If you are an employee, your manager or team can assess the situation and make plans to make the project successful. This can include changing scope, getting you help from more senior developers, reassigning parts of the project, etc.<p>There&#x27;s no shame in this: the ultimate goal is to be part of successful projects not looking like a hero. Plus you look a lot better if you give everyone a chance to come up with a plan rather than just springing it on them at the last minute that you aren&#x27;t done with your part.<p>It is also a lot less stressful when your team is working together to work toward a solution. A lot of the stress from this situation is worry about letting the team down or trying to work too much to make up time.<p>Be prepared for people to ask why you are behind though. Give honest answers. I hope your answer isn&#x27;t &quot;I underestimated the project so I thought I had a lot more time to surf HN&quot;, though.<p>This means you need to be completely honest with everyone on your team and speak up early so plans can be made. Again, if you wait until the last minute to say something, after you tried working long hours to make up time (and failed), there isn&#x27;t much that can be done. The project is already late at that point.<p>This is when you get some real anger directed at you, because you screwed over the team by pretending there wasn&#x27;t a problem. You also took away the team&#x27;s ability to make adjustments to compensate and you know.. work as a team.<p>So really, how you bring up the fact that you underestimated part (or all) of your project isn&#x27;t really as important as doing it right away. Be honest with everyone about where you stand.<p>You demonstrate willingness to do this by actually doing it.

Don&#x27;t let yourself be fooled:<p><a href="http://www.quickmeme.com/meme/3u8ysq" rel="nofollow">http:&#x2F;&#x2F;www.quickmeme.com&#x2F;meme&#x2F;3u8ysq</a>