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

#1

Post by captain_crabs » Mon, Oct 20, 2014, 3:43 PM UTC

New developers (I consider myself here) will always estimate wrong. They will also feel bound to their estimates as deadlines.

I've seen this happen with myself, and now with another developer I've been helping along (we both do consulting & build websites for people). Strikes me as the sort of problem we didn't know we had until we get in the thick of it, and I wasn't satisfied with my answer for her.

I know this is a basic question, but figured I'd ask, what's the high value way to demonstrate willingness to share estimate revisions promptly and transparently? What's important to remember when you start getting stressed out?

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

#2

Post by hcho » Mon, Oct 20, 2014, 4:07 PM UTC

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.

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

#3

Post by munirusman » Mon, Oct 20, 2014, 4:16 PM UTC

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.

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

#4

Post by Mithaldu » Mon, Oct 20, 2014, 4:17 PM UTC

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.

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

#5

Post by brudgers » Mon, Oct 20, 2014, 4:19 PM UTC

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.

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

#6

Post by ExpiredLink » Mon, Oct 20, 2014, 4:31 PM UTC

Don't let yourself be fooled:

http://www.quickmeme.com/meme/3u8ysq

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

#7

Post by trjordan » Mon, Oct 20, 2014, 4:32 PM UTC

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.

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

#8

Post by codva » Mon, Oct 20, 2014, 4:32 PM UTC

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.

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

#9

Post by pushplay » Mon, Oct 20, 2014, 4:36 PM UTC

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.

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

#10

Post by mindfulgeek » Mon, Oct 20, 2014, 4:41 PM UTC

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!