How to Deal with chronic time issues?

Question

I have a developer on my staff that chronically overshoots deadlines, and estimates. On several projects the last week or two everyday I hear "It should be done by the end of the day". This developer does good work.

I have already spoke to him about his problems. He seems genuinely frustrated, and miffed about what to do to correct them.

My Questions are:

1. What kinds of punishments for passing a deadline are effective?
2. What ways can I coerce this employee to police his actions (time estimates, etc.,) himself?

UPDATE: Based on the responses; here's what I have figured out.

1. Punishment is a bad idea.
2. It is natural for an employee to be unable to fix estimating problems without intervention.
3. Don't make deadlines unless there's company consequences (lost contract) for not being done by then.
4. Utilize available methods (Agile, Joel's checklist) to help the developer estimate better.

Thanks for the links and information. Also thanks for updating my thinking.

Answer 1

What kinds of punishments for passing a deadline are effective?

None. If you anger him, he won't do the work, or he'll find another job. You should help him figure out why his estimates are off. There is a book by steve McConnell about making estimates. i would start there.

What ways can I coherence this employee to police his actions(time estimates, etc.,) himself?

By helping him find the right way to make estimates.

Answer 2

I don't think the problem is that he is missing these deadlines.

I think he has a real problem in estimating the amount of time it will take to complete a task.

Have him start keeping a journal of what he says a task will take and how long it actually took him to complete the task. Eventually, this journal will become a sort of guide for him to create better estimates. Once he becomes better at estimating, he shouldn't feel as rushed or harried.

Answer 3

So the developer does good work, but is poor at estimating the amount of time for delivery? I'm not sure you have a punishment situation on your hands just yet.

Maybe going forward for some time, have him walk you through his process for estimating a delivery point. This can be an opportunity to ask him why steps X,Y, and Z take certain amounts of time. He may find himself revising his estimates simply by doing the exercise at what is almost certainly a slower pace.

Answer 4

Set Milestones and try Agile as @OTisler suggested.

Answer 5

I don't think you should punish him. Just get him to understand how to make accurate estimates.

As a team lead I've had my team members tell me that it will be "no problem" to finish X feature by the deadline. Then I usually sit down with them and go over what tasks and sub-tasks I think need to be done in order for the feature to be finished, and how long the developer thinks each will take.

After we do this exercise, and add up all the task and sub-task estimates, it will inevitably take much longer than the developer thinks in their original estimate. I usually only have to do this exercise with them a few times before they start making more accurate estimates.

Answer 6

If your first question is what kind of punishments to be considering I think you're on a loser straight off. If you feel he does good work you may have to look at the deadlines/estimates and see if they were realistic in the first place. Who set them, if the developer in question was not involved then that may be part of the problem.

I agree with @OTisler that pair programming and possibly a regular end of day progress review with yourself can help him through... although if the deadlines/estimates were unrealistic to begin with thats not where your problem lies.

Closer monitoring on a few specific tasks should highlight where any issues lie.

Answer 7

There is an interesting article by Joel Spolsky: Evidence Based Scheduling

1) Break ‘er down

When I see a schedule measured in days, or even weeks, I know it’s not going to work. You have to break your schedule into very small tasks that can be measured in hours. Nothing longer than 16 hours.

This forces you to actually figure out what you are going to do. Write subroutine foo. Create this dialog box. Parse the Fizzbott file. Individual development tasks are easy to estimate, because you’ve written subroutines, created dialogs, and parsed files before.

If you are sloppy, and pick big three-week tasks (e.g., “Implement Ajax photo editor”), then you haven’t thought about what you are going to do. In detail. Step by step. And when you haven’t thought about what you’re going to do, you can’t know how long it will take.

Setting a 16-hour maximum forces you to design the damn feature. If you have a hand-wavy three week feature called “Ajax photo editor” without a detailed design, I’m sorry to be the one to break it to you but you are officially doomed. You never thought about the steps it’s going to take and you’re sure to be forgetting a lot of them.

The main point is that he (and you) should learn from his mistakes, and take them into account on the next estimation.

Also, if you are a developer, I would do regular code review at the end of the day to get a better insight into his development process.

And, of course, smaller iterations and more granularity with tasks. Set the maximum task duration to 1 day. That's the rule we have.

Answer 8

To your questions:

1. If you choose to punish people for missing deadlines you will not get good results. They will be demotivated and feel belittled. If you keep pushing people to meet deadlines the quality of work will suffer and you will end up with a lot of time spent bug fixing afterwards.
2. To improve his time estimates you could try using Joel Spolsky's evidence based scheduling which has a nice feedback loop to improve the resulting estimates.

But I have some questions that I think you need to think about.

Is he later than everybody else? If so why - is it because he is an over optimistic estimator or a slow worker? Over optimistic estimates are easy to fix - just multiply all his numbers by a factor as per evidence based scheduling above. If he is a slow worker why? Does he get distracted? Is he very careful to produce very low defect code? Is he over engineering solutions? Is he not re-using code effectively?

Do the deadlines matter, or are they just arbitrary dates based on the estimates for the purposes of reporting progress up the management hierarchy? If the latter you can solve this by tweaking his estimates yourself.

Answer 9

First, make sure you are crystal clear in your requirements.

I hate to say it, but in my experience, blown deadlines are just as often a matter of unclear requirements or weak specifications on the part of a supervisor. First thing to do is to make sure the problem isn't either originating with, or exacerbated by, you.

Also, make sure your requirements are realistic, as well as his estimates.

Make sure that your own expectations aren't pushing him to make unrealistic estimates in order to meet unrealistic requirements.

Remember, you do the requirements, but the developer ALWAYS does the estimates, and should not be swayed with "can we do this any faster" unless you are also specifying functionality to be dropped.

Then, make sure he is tracking his time/tasks accurately, so you can get a good view of what is going on with the project.

This process will show any lack of proper time/task tracking, which may end up being the first step to improvement. If you can't see after the project how long a particular item took, that is probably the cause of the problem right there - not enough definition in the estimate, or missing "dependency" tasks that are discovered mid-project, but never estimated.

You HAVE to know how much time was spent doing what, accurately, before you can find out where the creep was, or what can be done about it.

Then, see where his estimates are failing and figure out why. Go over an estimate of a blown project, make that into a project itself - a problem to be solved.

Once you've determined that his estimates are indeed the source of the problem, go over an estimate that went over with him, and perhaps another developer, and figure out why.

This will help you figure out what the cause of the problem is. A solid understanding of the problem will likely be the actual solution.

Lastly, if you actually reach a point where you have to try punishment or coercion, it's time to fire him and start over.

Punishment and Coercion are appropriate responses to willful wrongdoing in certain situations.

However, if this developer is actively trying to do a good job, then you would only worsen the situation by generating negative attitude and frustration.

If the problem can't be solved, and you are sure the problem is with him, and not you, then it's time to fire him and get a developer who can meet deadlines. Great work doesn't mean much when your costs are blown up and profit goes out the window.

Answer 10

What kinds of punishments for passing a deadline are effective?

You stated the point and missed it. The obvious punishment for passing a deadline is death. If the developer is still alive after passing a deadline the "deadline" obviously was not a real deadline. Do you think it's funny to put developers under pressure using martial language?

Fix your wording.

Answer 11

What amazes me is that you only have one of these guys.

Engineers are horrible at estimating how much time something will take. I bet if you look carefully at your other developers' estimates, you'll find a lot of padding. Sometimes the padding isn't necessary, but the task expands to fill the available time anyway.

The solution to this is to change around how you do estimates - for everyone. Developers may be bad at estimating absolute time, but they're pretty good at relative time. So on Monday, instead of "how long will it take to add a whoosiwhatsit?," ask "what can you get done on the whoosiwhatsit in less than a week?" That becomes their task for the week.

The following Monday you look at how it went. "Well, I got the floogle installed in two days but it turns out it impacted the mcphee...so this week I need to decouple those guys so the whoosiwhatsit files don't get overwritten." Ok, there's their task for the week.

You might think it won't help, because you still don't know when the whoosiwhatsit is going to be ready. That's true. You have two choices here:

If you need a deadline, then you have to force your errant developer to pad his estimates like everyone else. It won't take him long to get the hang of it, and in no time at all he'll be taking "2 weeks" to write something that should have taken a day.

Your other choice is to trade the fictitious estimates for more visibility. In the long run this approach gets you more productive and much happier engineers.

Answer 12

Okay, this is fairly common--developers being optimistic. It's the job of Management to deal with it. If anyone should be punished, it's the manager (you?)

I'm glad you at least asked, It looks like you got some good answers off this list, I hope they help and you find a way to actually implement some that work.

When I was young, my first good manager dealt with it this way:

First of all, he had me come up with an itemized list--breaking tasks down to hours, and estimating each one with a very liberal estimate--no period should be less than 4 hours regardless of how small the task was.

Then he looked at them and told me to double all my estimates. (Developers, especially younger developers, don't think about the fact that you are only productive for about 1/2 the day, if you're lucky--and half of that is spent at things you didn't expect to have to do).

Then, before creating his schedule, he doubled all my estimates (Without telling me).

He turned them in this way regardless of schedule requirements from above. A good manager should realize that saying it needs to be done in 2 days, doesn't make it possible.

As I got better at estimating we both noticed and adjusted accordingly.

A managers job isn't just to make a project, it's to build a team. More often than not that's going to require training of some sort. This is also the reason that an engineering manager that is not an engineer is unacceptable, they can't really help with this kind of thing.

Failure of a project or schedule is VIRTUALLY NEVER the fault of the developer (except in a few chronic cases where he isn't really fixable or of any worth and needs to be fired). The manager has made bad decisions either in hiring the developer, trusting him, managing him or staffing the project.

And really, what is fault anyway? I suppose if the manager isn't very good at making the project happen, he's going to need someone to point at... If HIS manager is any good, he'll ask why it got this far, what you did to fix it, etc.

Hiring a manager is hiring someone to solve the problems. To make the developers productive. If he can't make them productive, he isn't the right person.

Answer 13

ask yourself this: What entails your job?

If you're just blindly passing estimates from developers (who you know can't give good estimates) up the management line, and not deciding for yourself whether that estimate is achievable, then you're not doing your job.

Try to think in terms of "value-add" (One of my old employers used that term a lot , and I hated it, but it probably works for you in this situation). What value are you adding? If you're just passing stuff in both directions between upper management and the developers, then ultimately you're not earning your money. You could be removed , and nothing would change.

The best manager I ever had was one that looked through a set of requirements given to him by another team , and told them straight out that almost a third of them was bull, and had them removed, before I ever even saw the list. The worst one I ever had made me write all this extra management-type documentation which none of the other managers I'd ever had asked me to do (I really got the impression I was literally doing his job for him), didn't even give me project due dates, and hardly turned up to work. They were both in the same company , bizarrely enough.

Answer 14

Motivation

First of all: Read Peopleware

Next. Why do you think punishment will be an effective way to manage people that is supposed to be creative? I think you have to rethink the whole approach to management vs. team.

As I see it the managers first, and most important, role is to make sure that the developers can be creative and productive. Not that they are productive. There is a big difference in those small words. To be creative you need a safe environment. By being constantly under pressure from both deadlines and threats of punishment you create the exact opposite of safe.

Also, as a manager, you need accurate information on which to base decisions. This also requires a safe environment. If there is a risk for punishment for being honest and outspoken you are guaranteed to get lies and absence of information. A very dangerous base to take decisions from.

Estimates

As other as pointed out, estimates are estimates. In our team we don't do any individual estimates at all, we do estimates as a team. (I'm a bit reluctant to call what we do Scrum, but most of it tries to emulate if nothing less) I think this is a really great way to do estimates: Each team member is given a deck of cards consisting of numbers 0,1/2,1,3,5,8,13,20,40,60,100 and when estimating a task each developer picks a card (the cards are hidden until everyone has picked a card to avoid influencing estimates) and the average of the selected cards is taken as the estimate.

Notice how the numbers gets progressively less accurate. This is by design because large estimates are by necessity less accurate.

For our team we have opted to use the unit "ideal man days" for estimates. As far back as any of us can remember an ideal day hasn't occurred yet, but it is a good basis when you know how to translate calender days to "ideal man days".

As Scrum prescribes, development is done in sprints of two weeks after which the new version is deployed in the production environment. After each sprint we take the sum of the estimates of the completed tasks and divide that by the planned man days for the sprint. This factor is then the basis of estimating how many "ideal man days" the team can spend in a two week period.

Actual work items done by an individual developer don't need an estimate. The first approximation is always 1/2 - 1 day to complete. If this estimate turns out to be false you just grab a fellow developer and do it together to get it done. Or you break down the work item in smaller tasks so it can be distributed better.

Answer 15

90 hours is one common short project deadline. The easy way is instead of estimating "your time", you measure another. Computer programmers shoudn't make time estimates for their projects since evidence shows calculating one's own time results in larger error than observing another.