How do you schedule the time you will need to do a task at your work?

You have to ask a lot of questions before an answer can come close to giving an estimate on the time-frame involved. In the business world, it comes down to this: “Do you want it to be cheap, fast, or of good quality? Pick two.”

@Pied_Pfeffer , I think FAST is the answer, but I would like it to be QUALITY. I love my work and I want it to be as it should, nothing less than great.

Take note of how long it has taken you to do some tasks in the past. Use that to create your time estimate, and then add a fudge factor in in case something goes wrong.

@Ranimi23 That is where the questioning comes in. If you want to keep your standards of quality and they need something fast, then it is okay to just say “no.” There is absolutely nothing wrong with this. The person asking has many other options. Your personal advice as an expert should be valuable enough.

Whoops…I just realized that you are talking about work-related projects and not personal requests. Please accept my apology.

I worked in a dept. that designed, developed and deployed online and classroom training. No one understood the amount of time involved in creating effective training…they just think it is something that can be whipped up.

Your supervisor should be the buffer for what is on your plate and when you or someone else could eventually get to their project. Something that has helped the dept. is by taking classes in project management and instructional design. Both train someone in learning how to plot out the proper questions to ask on the front end and then plan the process. Yes, there are always going to be unforeseen events that can derail the initial proposal. Just remember that you are the expert, and it is always best to paint a realistic picture of the process than saying “yes” and not being able to deliver.

I have always kept careful records of how long it took me to do specific jobs, not just in terms of hours but in terms of the nature and difficulty level of the job. I track my time to the nearest quarter hour, which yields an error of + or – ½ hour, and that is the optimal interval for me. I can give a pretty close estimate on a very long job.

But writing code or fixing a bug is almost impossible to estimate. A software engineer I used to work with would respond to that question (“How long is it going to take you to fix those bugs?”) by folding his hands behind his head, leaning back, and saying, “How long is it going to take you to find your car keys?”

My software rule of thumb, learned from a senior programmer-analyst in my young days, was to think of the longest time I thought it could possibly take, and then double it.

But bug fixes are an entirely different critter because you aren’t building something, you’re diagnosing and solving a problem. If you’re working with spaghetti code or if your predecessors didn’t bother to document anything, you simply can’t guess what it will take.

I did get pretty good at devising tests to home in more and more narrowly on the bug. But it’s still a crapshoot.

So—the bottom line is: they have to ask, and you have to not answer.

You should be able to predict how long it will take you to document something. Use your own history as a guide.

anyone who thinks you can simply nail down a specific time to do something that may include many facets seems to me to be new at their job. Many a good worker have had to move on to other jobs thanks to sups who may have been unrealistic in their expectations. Such a waste.

Follow the Montgomery Scott principle. Make an estimate and multiply it by 4.

KIRK: Mr. Scott. Have you always multiplied your repair estimates by a factor of four?

SCOTTY: Certainly, sir. How else can I keep my reputation as a miracle worker?

There are dozens of books about this. There is no easy answer.