Immediately, with brutal honesty, and positively.

1. Immediately: Never delay communication. Most people will be less upset about the schedule than the fact that they weren't informed.

2. With Brutal Honesty: Explain exactly what's going on. You may end up with a pleasant surprise. "Oh, can we just have xyz then?" or "How can we reduce the scope?" or " How can we help you make this easier." An informed customer/boss is a resource to be used.

3. Positively: Find a way to deliver something by the deadline. "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." sounds a whole lot better than, "We won't hit the October 31 deadline." You may even give them options in terms of features & 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.

Stuff happens. Good project managers will adjust and move on.

Additionally, if you are being blocked by something external, you MUST let your project manager know ASAP! One of his primary jobs is to remove impediments, so you can do your job.

In particular step 3. You will get all of this, some of this, and none of this, is an especially good approach.

Part of your Product Manager/Product Owner's job is to educate stakeholders that you are giving them capacity - not deadlines. Once this education is in place it's easier to have these conversations.

On a sidenote, this is part of what makes Agile so effective. It gives you a framework to have these discussions.

It also helps if you know what is the highest priority and what can get sacrificed.

If you're late, talk about it in your retrospective. Taking time to look back will help you make better estimates in the future. Often times I gauge how reliable an engineer's estimate is based off of how many questions he/she asked me during the kick off meeting.

I would reiterate on the "brutal honesty" part. In some cultures, it is considered rude to say No and a lot of developers make that classic mistake of being hesitant in saying No. Even when they know that a deadline is going to be missed, they find it difficult to communicate. But no matter what you come from, you need to learn how to just say it as soon as possible because ultimately, the client will find out anyway and that will not be good.

Also, most clients are willing to negotiate even though they don't tell you that. Just this other day, I had a client bugging me for a very complex feature thinking I will do it for free. They said and I quote "We cannot go live without this feature and you must do it for us". I then went back with a paid estimate and set the delivery to 4-5 weeks, they immediately changed their mind and said "ok fine I guess we can go live without it for now but lets work on it together". Within a few hours, it went from "no can't go live" to "ok will go live for now"

Those you're speaking with will appreciate your willingness to have that kind of foresight (the effect of which will definitely offset some of the short-term disappointment).

What you really need to do is help the person setting the deadlines plan. There are things they'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're frequently based on your initial estimate.

So, over-communicate, but also slip once, and slip hard. If you're a week out, and going to miss by a day, slip the date a week. Fuzzy, frequently communication isn'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 "I'm worried about date X" to "We've change the date to Y", because while it's fuzzy in your head, it needs to be clear in theirs.

- 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't be on time and can break all of their internal assumptions about their timeline. They have goals too.

- 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?”

- 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/additions and what it will do to the delivery date.

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.

During the project, if you realize that your estimates were originally wrong, fix it asap and communicate immediately. Frequent communication is the key.

Also, committing code multiple times a day with meaningful comments also helps.

Make separate milestones for QA and UAT rounds.

Breaking the project in very small but presentable milestones helps in keeping non-technical clients updated and happy.

Providing an hourly schedule for a project as short as a week sounds completely crazy to me. Imagine how to pull that off for a month+ project. Maybe the sentence was phrased poorly.

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've waited too long. Risk shows up way before it manifests.

Daily gut checks are an easy way to notice risk. Ask yourself "how is the estimate aligning with the actual work left?"

Once you know there is misalignment, the most valuable way to discuss is focusing on work left.

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.

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.

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

3. Firm up definition of "done." 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.

Go easy on yourself. Your estimates aren't wrong, they are off. You don'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...

When all else fails default to Uncle Bob's standard answer: 3 weeks :)

Good luck!

No battle plan survives first contact with the enemy.

If you give a single number, there's a 100% chance that it's wrong -- you're never going to hit it exactly.

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).

If you do it honestly, the intervals have to be much wider you than you are used to -- the "two weeks" you would usually say is realistically more between 8 working days and six weeks, with 90% confidence.

A major benefit of giving intervals to people instead of fixed numbers is that it makes it really clear that it's not a deadline and can't be treated as one.

If they tell you this is unacceptable, then only give the high number, and McConnell's book.

The advantage of things like Scrum is that a 1 week sprint size should flag up slippage within a week.

It's hard for people to actually know they'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's just no hiding it and he can communicate it upwards.

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're going to communicate slippage up the chain (if the totality of the delivery trumps the deadline).

If this is all noise to you, then just do this:

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's bigger, it's a smell that you're estimating badly and don't understand each of the parts involved).

2. Order all of the pieces of work such that you are doing the most important things (decided by the project sponsor) first.

3. At the start of each week declare what you will finish that week, always the most important things you could be doing... and get to work.

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.

Granted, 90% of clients don'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.

I've also found that this is the best way to approach estimation. Granted, I'm not a freelancer, but at my current job we were quite dreadful at estimating so we had to figure out a solution.

Basically one of our developers sits down with either a client or QA/BA type person and for 1-2 weeks constructs a lengthy document (that can be later turned into user stories etc.). Based on these, developers can make estimates etc.

Then and only then we present the client with a timeframe. It worked out well for us so far, especially since it also acts as a filter and keeps clients who only have vague ideas out.

If you're not managing your project in such a tool then you should be. If you'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.

If they want a fixed date, take 60% of your velocity and you'll be pretty sure your math will work out to give you the project on time.

Anything not based on data is pulling numbers out of your ass, and it's hilariously disastrous every time.

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.

Once that is clear, the customer is prepared and will be expecting and able to handle estimate revisions whenever you make them.

Heh, sometimes the outer limit is infinity, it becomes clear it'll never get done and is canceled.

If you can't pick reasonable milestones, there's no way you can make a meaningful estimates. And without reasonable milestones there's no way to analyze where the process slips and to learn from it.

Here are some challenges that come to mind in software estimation:

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 "I'll get back to you with an estimate by ..." (e.g. tomorrow or end of day) that's even better.

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. "It will be done tuesday/take 5 working days"). Early or quick estimates may be ranges of 15x or more (e,g, "it will be eight hours to three full work weeks"). Don'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.

3. Know the difference between estimates, targets, goals, and commitments. Confusion between these leads to miscommunication and frustration. Often we'll make a guess like "maybe two weeks" 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.

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 "better" timeline can make everyone feel better in the moment, but will lead to problems later.

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'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 "change management", itemized / ticket based change requests, even explicit signoffs. If you have trouble here, find what works for you.

6. Learn from history. You won't get it right. A lot. Keep track of how you are doing, improve processes and spend more time refining requirements/acceptance criteria etc. Make sure commitments are negotiated and explicitly agreed to. Keep learning.

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'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's very human. The way to feel better about it, is to get better at it.

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 http://www.amazon.com/Software-Estimation-Demystifying-Devel...

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.

The basics should be the same with either party, though.

Always open the communication lines as soon as you know you are behind. You don't have to say "My project is definitely going to be late" but rather be honest. If you are behind on a milestone, speak up now.

Don'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.

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.

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.

There'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't done with your part.

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.

Be prepared for people to ask why you are behind though. Give honest answers. I hope your answer isn't "I underestimated the project so I thought I had a lot more time to surf HN", though.

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't much that can be done. The project is already late at that point.

This is when you get some real anger directed at you, because you screwed over the team by pretending there wasn't a problem. You also took away the team's ability to make adjustments to compensate and you know.. work as a team.

So really, how you bring up the fact that you underestimated part (or all) of your project isn't really as important as doing it right away. Be honest with everyone about where you stand.

You demonstrate willingness to do this by actually doing it.