
How do you communicate if you won't hit an estimate? - captain_crabs
New developers (I consider myself here) will always estimate wrong. They will also feel bound to their estimates as deadlines.<p>I&#x27;ve seen this happen with myself, and now with another developer I&#x27;ve been helping along (we both do consulting &amp; build websites for people). Strikes me as the sort of problem we didn&#x27;t know we had until we get in the thick of it, and I wasn&#x27;t satisfied with my answer for her.<p>I know this is a basic question, but figured I&#x27;d ask, what&#x27;s the high value way to demonstrate willingness to share estimate revisions promptly and transparently? What&#x27;s important to remember when you start getting stressed out?
======
edw519
_How do you communicate if you won 't hit an estimate?_

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.

~~~
captain_crabs
You're the fucking man or woman

~~~
frandroid
"You're the man" is a non-gendered statement.

~~~
seekingcharlie
Haha! Not really, honey.

------
trjordan
My favorite question: "Is the date slipping, or has it slipped?"

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.

~~~
pseudometa
I second the "Slip once, and slip hard" tip. Saying "one more day" a
second/third time as it is both confusing and annoying to others.

~~~
cpeterso
Fred Brooks wrote, "How does a large software project get to be one year late?
Answer: One day at a time!" If a team never admits the project is slipping,
then they won't examine whether they need to adjust requirements to meet the
date or adjust the date to meet the requirements.

------
nerdy
You should tell them right away. Be honest and upfront. Sleep easy at night.
Work without it hanging over your head. Here’s why:

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

------
munirusman
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/client about your progress as frequently as possible. Twice a week if
not daily.

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

~~~
ThomaszKrueger
How do you account for the hours you spend "communicating", and will there be
hours left for real work?

~~~
munirusman
It doesn't take much time if we use right tools. I've found Asana really good
for task management with your team. As software dev, all you have to do is to
tick completed tasks or write short comment if you are missing deadline for an
individual tasks.

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

~~~
anthonye
Any advice for easily communicating with non-technical clients who wouldn't
use technical tools?

~~~
munirusman
I have faced many non-technical clients in past and trust me it's not easy.
The best thing I could do is to double (sometimes triple) the original
estimated timelines.

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.

------
mindfulgeek
Estimates are notorious for all developers, not just new ones :)

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!

~~~
fleitz
Estimates are always inaccurate, that's why it's called an estimate.

No battle plan survives first contact with the enemy.

------
hcho
As soon as you realise you won't. This will give your customer a bit of leeway
in managing expectations, preparing alternatives or what have you.

------
buro9
As early as you are aware, you communicate it.

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.

------
Scarblac
One of the things that McConnell's "Software Estimation" repeats a lot is that
estimates are _intervals_. I'm a bit surprised not many people here have
mentioned that.

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.

------
codva
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/or software specification document.

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.

~~~
adamors
> 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/or software specification document

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.

------
pushplay
If you're managing your project in a tool like JIRA you could provide your
client with a burn down chart. It's the easiest way to tell at a glance how a
project is going, and takes next to no effort to produce.

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.

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

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.

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

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.

------
Mithaldu
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 +/\- 3
_orders of magnitude_ and that you will be revising it as you go along.

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

~~~
SerpentJoe
6 orders of magnitude is the difference between minutes and years. I don't
think I've ever heard of an estimate with that much variance.

~~~
hga
Indeed. However months to years is all too common.

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

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

------
brudgers
The way to handle estimates is to have milestones. At the milestone, scope,
cost and schedule changes are formally decided.

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.

------
scotty79
Don't. Never provide an estimate unless asked. Same goes for reestimation.

If anyone asks you why estimate wasn't accurate provide him with list of all
the things you've done since estimating related to the task, if he inquires
further also unrelated.

If you see anyone that thinks that estimate is a promise or a price, remind
him that it's just poorly informed guess, and any decission based on a guess
is gambling. And you can't win them all. You can't even win enough to break
even.

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.

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.

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.

------
PMPThatcher
I think part of the problem here is the way we estimate duration. Estimates
won't always be right, but they shouldn'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.

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

------
ColinDabritz
You bring up a specific challenge, how to handle it when you realize a
deadline is probably going to be missed. That's one aspect, but you also need
to look at why your deadline is going to be missed more broadly.

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...](http://www.amazon.com/Software-Estimation-Demystifying-Developer-
Practices/dp/0735605351)

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.

------
albakes
HONESTY and just do your best. Be apologetic.

~~~
ExpiredLink
apologetic? because you missed _their_ wrong estimates?

------
jaf656s
How you communicate an underestimate will differ slightly if you are a
freelancer/consultant compared to an employee. The primary difference being
the level of technical sophistication of the person you are telling.

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.

------
ExpiredLink
Don't let yourself be fooled:

[http://www.quickmeme.com/meme/3u8ysq](http://www.quickmeme.com/meme/3u8ysq)

~~~
hga
That, unfortunately, has been my #1 reaction to this discussion of estimates.
Far too often they were "negotiated" downwards and treated as deadlines.

