Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've founded a startup with my friends a few months ago, and—due to some personal issues like starting college and moving to a new town—I've found that I'm likely going to miss an important deadline for the project we're working on.

I'm stressing out about this, and I'm not sure what I should do. How can I handle this stress and communicate the delay to my team?

share

locked by Mark Trapp Jan 10 '12 at 21:17

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

10 Answers 10

up vote 51 down vote accepted

Communicating delays early is probably the most important thing to do.

A term that gets bandied about a lot is "manage expectations". That just means you should let people know early if there's a problem. If they're expecting that you'll be finished tomorrow, then there's pressure on you to deliver. If you told them at the start of last week "Not looking likely i'll be finished...", then midweek told them "No chance I'll be finished..." at least they know.

A lot of the time, the people you report to have to report to someone else. If you've been saying all along "yeah everything's great", they'll be passing the message on, and everyone will think everything's ok. Then when you get to the deadline and say "Not quite done...", they then are in a difficult position as they have to pass that message on, which can reflect badly on them...

Regular, honest, updates are always the best thing.

share
6  
+1 for the first sentence. –  blizpasta Sep 19 '10 at 13:53
3  
True, but how do you personally predict a workload when a lot of learning (like a new framework) is involved? –  Henrik P. Hessel Sep 19 '10 at 14:48
3  
@Henrik You adjust your prediction, frequently. –  Andres Jaan Tack Sep 19 '10 at 16:23
3  
+1 for the last sentence. –  Hippo Dec 1 '10 at 6:44
2  
+1 for the sentences in the middle. –  Andy Dec 14 '10 at 19:04

Almost everything is negotiable

  • The due date itself
  • Details in the spec
  • The availability of help
  • The business/client's stated requirements
  • The relative priority of other deadlines

Think about what you have right now to deliver. Write 2 plausible scenarios where you trade features for time and start a discussion with these. ("I can deliver features a...n in one month if we change x,y,z in the spec...")

Your 3 goals: Win a trade-off, either buying yourself more time or dropping/altering features. Show your client you're busting ass, trying to strike a deal palpable to all within your constraints. Get them thinking about what they really need and when.

The other commenters have given great preventative advice, but this is how I handle a deadline zooming by.

share

I hired a guy to do some work around my house a few months ago. He came highly recommended, I've seen work he's done, seemed like he knew his stuff. He made me a quote, I accepted it, I paid him part of it up front.

Then he vanished. When he turned up again there was no mention of the fact that his start date had blown by without comment. When I asked him, it was all "gee man you know how it is".

Thing is, I would have had NO PROBLEM with him starting later than he said, if he'd just told me that was what needed to happen.

Somebody on this thread said, "Deadlines get missed." In my view, that's the MAIN thing deadlines do. It happens literally ALL the time. And it's only a problem if you leave people out of the loop about what to expect.

share

Henrik, This may help: Keep in mind that this is not a black-white world.
You HAVE made SOME kind of progress, so be sure to let your customer know the most progress that you have indeed made. Often that will give them something to work with.
Also, in the time you have left, think about what you CAN deliver. Also think about the task from the point of view of your customer: What are the most important outcomes or deliverables? Give the best set of deliverables that you can give, in the time before the deadline. Then keep on going after the deadline, working on the rest of them.

And I strongly support all the other comments about letting the customer know early and often.

General Clayton Powell had a saying:
Don't let your psyche fall along with your position.
In other words, don't let this missed deadline stop you - learn from it and keep going.

share

As soon as you know you've got a problem, you need to be communicating that and managing expectations.

When something like this happens, it's important to take a look and figure what caused the delays - something like the Five Whys can be a good start. Incorporating this into something like an agile restrospective is the best way to talk about what's going wrong and how to improve it.

Then finding ways to act to prevent problems like this are important.

These things happen all the time. There's nothing wrong with making a mistake, only in repeating it.

share

You've been given plenty of good advice on how to handle missed deadlines: communicate delays early, stay aware of your progress, always be wary if unknown technologies are involved. Having that one covered, let me now tell you how to avoid them.

I've always been terrible when it came to setting deadlines for myself. Like most programmers, I often ignored "trivial" tasks and focussed on the interesting ones. But the trivial things are often the ones that make up the bulk of the work and also the ones that'll always come back to bite you in the ass at some point.

There's no way to easily account for these tasks. Instead, you should try to come up with an estimate for what you think you'll have to do and then double that estimate as a start (depending on how badly you miss your deadlines, you might even have to triple them). This will seem like plenty of time -- don't be mislead by your programmer machismo again, just stick to your estimate whenever somebody asks.

You'll most likely find that you end up with a deadline that leaves you plenty of room after you think you're already done. While it's great to finish projects way ahead of time, this is also likely to lead to false expectations. Instead, try to use some of that time for additional testing (you are testing your code, right?), documentation, refactoring and other polish. If you have time left after doing all that, feel free to hand in the project now. Few managers will complain if projects are completed too early.

Keep on doing this for the next couple of projects. Depending on how much time you have left after finishing the project (i.e. making it work), you might want to raise or lower your next estimates. As your perception of how much time you'll need is going to be highly subjective, nobody can really tell you how much you need to adjust that factor (I find that my factor usually lies between 50-100%, though it's shrinking now that my intuitive estimates get better). Just keep in mind that you'll always need to leave a small margin for unforeseeable problems along the road (e.g. delays, interruptions or personal reasons).

tl;dr: If your estimates don't work, double them and fine-tune them as you get a better understanding of how much time you need.

share
    
+1 not the answer to the initial question but very interesting advice how to avoid. i would add "after (sub-) project is finshed take the time to reflect and compare the initial estimate with the outcome. this way you learn to make better estimates" –  k3b Jan 11 '12 at 4:48

Since it sounds like you are a newer developer I think that there is one important point the other answers here miss.

DEADLINES GET MISSED.

Communicating the situation and explaining the reasons why are important, but I have seen far too many new devs work themselves into a ball of stress (or try to hide the problem in worst case) over blowing a deadline.

It happens, it will always happen. You try to minimize it but sometimes the work just isn't going to go the way you expect or something in life is going to get in your way.

I blew to deadlines last week. Requirements missed an important logical loophole in a work flow and the work flow would not have served it's intended purpose IRL without going back and addressing that, nobody on the team found a reasonable fix short of re-writing it, so I am.

Explain the situation as early as you know there may be an issue, try to minimize the impact, but sometimes it is going to happen sometimes. If the people you are working for/with cannot understand that (assuming you don't miss too many) you likely are not working for the right people

share
1  
Heh Bill, thanks for your input. I'm not new to this job, but the context is different because it's MY company I'm working for MY client. I worked for an big IT Firm in Europe but I wasn't that personal attached to the projects I did there :) –  Henrik P. Hessel Sep 19 '10 at 14:53
    
Sorry, I misinterpreted your reference to starting college, but still, just because it is a project you have some personal involvement in does not mean that you and your partners don't need to keep a realistic view of time issues. On the other hand, I too kick myself a bit more when I miss a deadline on a personal project so I understand the sentiment. In that case I would probably suggest you get with some of the other start up folks, go get a beer and discuss what to do about it. –  Bill Sep 19 '10 at 17:05

"How do you handle this stress and how do you communicate these delays?"

Communication is one of the main things in Agile programming. You should communicate your progress every day. This way, you can perceive the delay comming and then take actions to deal with it. Even if you can't use agile methodologies, stand-up meetings are a good way to start. Of course, you should take actions when you see the problems comming, otherwise, the meetings will worth nothing.

share

If you can't make a deadline, you need to discuss it as soon as possible with the person expecting you to keep to it. It is only fair to them to keep them informed. Discuss the problem, discuss realistic solutions, and come to a new agreement.

P.S. You should keep people in the loop if the possibility exists that a deadline won't be reached. In other words, if you're pulling all-nighters and not keeping people informed you're that hard up against the wall, you're not communicating appropriately. I can get really annoyed when developers on my team try to hide from me that they're behind schedule. I can't solve schedule problems I don't know about.

share

These questions might belong here and might not, but we're both "here" right now, so let's try and make something of it.

The best way I've found to assess the work you have, and make a deadline, is to start by breaking the big assignment into smaller tasks. Instead of thinking about Input, Logic, UI, or whatever you have in your app, try to think about the actual work required.

For example, Input might require you to learn how to programatically read XML files, or it might require you to set up a SQL database. If you've set up a DB before then you know how long it takes you to do it, if you don't then you can assess, or just assume it'll take you some time to learn it.

There are some great tools to help you break down your task, estimate times, and track your time. I work with FogBugz which is free for small startups and academic teams.

Regarding the stress... I find that keeping a good estimate of my times and managing my work and personal schedule keeps me calm. Feeling secure about a deadline will make you enjoy your work more, and certainly feel less guilty about your leisure.

Good luck,
Asaf

share

Not the answer you're looking for? Browse other questions tagged or ask your own question.