How to answer whether or not something is going to be done and finished on a certain date

Question

After months of not having deadlines, my boss is asking me whether or not something is going to be done on 2 weeks. I have been working with very different concepts and different software, all inside the same project, and I generally lack experience (so my speed hasn't been spectacular in my opinion, but nobody has told me it was a break dealer since the idea is, and was, to develop while learning, not necessarily work with something you already knew prior to work here). However, for this particular task I have 0 experience whatsoever. I don't know how to answer accurately, I've never seen this problems before.

She is pushing to get a yes or no answer. I'm afraid of saying yes, and not being able to get it done, but I don't see any other option than saying what I've stated above (and my boss knows) that yes I will have it even if I haven't been in this situation before.

E: Another problem that I wanted to touch when I mentioned that I lack experience is the inability to think or compromise to a date. I simply don't know, I can wish, but I'm finding problems at every step, some of my own, some that come with the nature of what I'm trying to do. So the range is rather big: I could say, less than a year but that helps no one, it would be great if everything is done by September. It would also be fantastic if it could be done tomorrow but I don't feel it's going to be done by then, but then again, I don't know when is it going to be done.

Answer 1

Flip the question the other way around. What are you absolutely confident that you can have done by the date your boss has set?

There's nothing worse than having a finger-in-the-air estimate, where someone gives you a set of tasks and a deadline without any estimation of what is possible by the deadline. Break down the tasks into smaller, manageable sets that you can estimate. Look at that list of timeframes you have, and see how many fit into the deadline. Of course, some may be higher priority, and others may be prerequisite to other tasks.

Then go to your boss with your estimates. Show her your plan, and tell her that you can definitely have tasks A, B and C done, and possibly D. This is how you can give accurate time frame for tasks. Break them down, estimate the bits. Then rather than guessing if you can get done in time, you know exactly what you can get done by that time. Your boss can then either extend the deadline, or limit the scope.

It doesn't sound like she is trying to push you to get done by a date as much as wanting to know what you WILL have done, so she can forward plan her team's time.

Answer 2

Estimating tasks is a requirement of software development. Get used to it. We never have perfect information for estimating.

What you do is break it up into tasks and estimate each one individually. Then you add an uncertainty factor of 30-200%, depending on how uncertain of your figure you are, per task. That is the time per task you give. Do not specify the uncertainty factor as a separate item in the spreadsheet you build. Just add it to the figure of what you think it will take. Then add it all up.

Then the next trick is to not assume an 8 hours day when determining the deadline from the total hours. If the total hours are 142 to accomplish the tasks, then divide by 6 not 8 to get the total number of days and determine the deadline. This accounts for unavoidable delay, time off, being asked to work on more urgent issues, required HR meetings and other admin tasks like timekeeping, etc. For a short project this may not be as important or you could get away with dividing by 7 but you need to start accounting for this in doing your estimating unless you want to spend the rest of your life working to unreasonable deadlines and working overtime to do so.

In determining tasks, make sure you include time for meetings, email reporting and other management communication that is required during the project. Also include other related tasks, like unit testing, creating a source control repository, responding to QA issues, deploying to other servers, etc. One of the biggest problems I have seen in estimating is that devs often only estimate the actual programming time, but all the other tasks added up often take as long or longer.

If your boss pushes back on your estimate, show him the details and ask what he thinks is too high and why. Ask him if there are steps you can skip. Ask him to prioritize the steps so that you get the most out of the actual time you have. Ask him if the scope can be reduced for this deadline. Find out what is the most important thing to get done.

You may find that if he needs it by a certain date, that he might expect you to work overtime. This is not unusual in this industry either especially when it is getting close to the deadline. It is not in your best interests to complain about that at this point as you may already be perceived as not contributing (this is my guess based on what you wrote about how little you seem to have done so far).

Next, it sounds as if you are feeling pressured to meet a deadline. Welcome to the real world, we all work on deadlines and have the pressure to meet it. You can't get away with making no progress from now on. You need to have something to show daily that you accomplished. This is not school where you can throw together the final project in the last weekend before exams. Every day, for the rest of your career you will need to be able to show what you did that day. This is a high pressure career, you need to learn to cope with that.

You also need to stop making excuses. Everyone knows you are new, but you need to be seen as digging in and working on accomplishing the task. If people perceive you as not working or being unable to do the work then that will have a negative impact on your pay, the type of work assignments you get and ultimately your employability. You need to manage your boss's perceptions of you at all times in the work world.

You also need to get rid of the attitude that you can't do this, right now. If you can't, then you don't belong in the profession. Maybe that sounds harsh, but the real world is harsh, you need to step up and perform. You can accomplish a huge amount in two weeks if you actually focus on work. Even if you miss the deadline, you need to be able to show that you accomplished something in that time beyond some nebulous research. If research is all you did because it is truly a complex problem, then be prepared to show documentation of that research. If I had someone do nothing but research for two weeks, I would expect to see several hundred pages of research notes.

Answer 3

"I will give you an answer in X days"

Your first job is to find out how long it is going you to take. Dive into the problem until you have an idea what the entire task/project is going to take.
Take your time to list the actions, break down into smaller parts, plan for those, etc.

You will have to make an estimate now how large X is, but that's easier than trying to guesstimate the entire project.

If you have the idea that X is already going to take a week, then all bets are off: it is not doable in two weeks. If you have a good idea of the final answer before X days are over, report immediately, especially if the answer is going to be 'It is not doable in two weeks'.

Whether you or she like your answer, is hardly relevant. You both have to deal with reality in a professional way.

Answer 4

This isn't really a yes-or-no question. If you are working on something that should take a small number of hours, and I ask you "will this be finished today?" you can say "yes" or "no, because I need about two more hours and I am leaving for the day in an hour." But with things that go on for weeks or months, you don't have that kind of certainty. The closest to yes you have is:

That's the plan!

And the closest you have to no is:

At the moment I can't make the dates work. We might need to lower scope or add resources.

If you have a lot of uncertainty:

We would have to be very lucky on X, or get some help on Y or perhaps drop Z

Or

That's the plan, but I have a lot of uncertainty around A, B, and C

Estimating how long something will take is a different skill from doing it. Some people do a thing for years but never really notice how long it takes. Some are constantly surprised and delayed by things that others expected and allowed for. Some people put a schedule together in a way that allows working on one task while another is blocked; others don't. These are skills you should have been learning right along with the concepts and software you're using. Unfortunately, not many people explicitly teach these things; they just expect them of you.

So what you should do right now is make a written plan. Use some sort of ranges or colour coding to distinguish things where you're confident how long they will take from things that have uncertainty. If all goes perfectly, when will it be done? At what points will you gain more information (eg you get the API working with the other components) and be more confident about the finish date? If you establish that it will take 4-40 weeks, it most certainly will not be done in 2 weeks. If it will take 7-20 working days, it might be done in 2 weeks, but probably not. If it will take 3-9 working days, then it probably will be done in 2 weeks.

Taking this approach doesn't just help you answer your boss about whether it will be done. It helps the two of you tackle questions like

• is there a piece you could give to someone else to speed things up?
• where is the biggest uncertainty and worry?
• is there a piece you could release then, to show progress to those funding the project?

You really shouldn't have been working without a plan. When you started getting questions about completion dates, you should have made a plan. Your boss should have at minimum asked for a plan, and more reasonably helped you write one, but not all bosses lead you the way you need to be led. Make a plan. Accept that it will be incomplete and there are things you don't know. Answer your boss and have the backup details that will be required. Be able to go way past yes/no.