Being dependable on task estimates makes you look good to those in power, who have a tendency to remember who lets them down and who comes through when it counts. If you consistently deliver when you say you will you become eligible for more responsibility later on. Because of this, accuracy in task duration estimates is a crucial building block to a blossoming career. If you cannot be counted on to complete work when you say you will, more complex responsibilities and the even greater rewards that come with them will never be challenges you are faced with. When you demonstrate the ability to deliver on time, you will next be given the opportunity to prove yourself with more complex problems across a wider scope. Other chapters in this book can help you with the details of more responsibility, but without mastery of the most basic element presented here, you will never get the chance.

Establishing that foundation of predictability goes hand in hand with preparation for your performance evaluation through the task logging daily exercise. When you force yourself to record how you spent your day, you have a historical record you can refer to when a similar task comes up at a later date. Just about every kind of problem has been solved before. It is up to you to notice the patterns specific to you and the kind of work you do so that you can achieve more consistent delivery on new projects. As a bonus, you will give yourself a wealth of information from which to make your performance evaluation argument.

• Part 1, Introduction
• Part 2, The Lego Exercise
• Part 3, Teaching yourself better estimation
• Part 4, Understanding your scheduler
• Part 5, Padding leads to the dark path
• Part 6, Be good to yourself and your teammates
• Part 7, Final Thoughts

While in the throes of a schedule, there will come a time when you are interrupted by a teammate for a piece of information or an unscheduled mini-task that will distract you from completing your current task. Do you help you coworker and risk being late yourself? Or is it better to stay on task and help them when you are done? Picture yourself at a meeting where you and members of your team are communicating status to your scheduler. Which statement is a worse reflection on you:

Coworker: “I was late on my Menagerie design task because failed to get back to me on a piece of information, I am deadlocked, and cannot make any further progress until he/she gets back to me.”

or

You: “I was late on my Kobayashi Maru documentation task because I had to help with his Menagerie design task.”

Either statement will make you look bad, but the first one makes you look worse. If a situation like this comes up, it is really a failure to recognize a functional dependency earlier in the scheduling process. It is much better to make your teammate look good at the cost of making yourself look bad than it is to have a colleague make you look bad in front of the scheduler. In cases where the scheduler is also your boss and the one who fills out your performance evaluation this is especially true. When faced with the choice between making a teammate look bad or yourself look bad, choose you. There will be time to make up for the mistake later and pointing fingers at someone else makes the situation worse.

Not only do you have to be good to your coworkers, you have to be good to yourself too. One of the down sides of being “that guy” are statements like, “I haven’t taken a vacation in 3 years and I’m beginning to lose days because my vacation bank is full.” Everybody appreciates hard work, but if you are not taking the vacation days that the company gives you to the extent that you are beginning to lose them, you are cheating yourself. When you do this, you are essentially giving your company money. Companies of a certain size have to keep cash on hand to reimburse you in the event that you leave for another job and you still have vacation days left. When this happens, you are monetarily compensated for the days off you never took. This is why most employers cap vacation time accumulated. If you exceed the cap on the number of days that your company allows you to accrue, you lose that money should you choose to leave.

Even if you never leave your great company, they give you a certain number of days off per year and they give them to you for a reason. There are times where 60-80 hour work weeks are needed to meet critical schedules. Just as important, though, is taking time off to recharge yourself both mentally and physically. Even the President of the United States heads off to Camp David every few months. Is your job more important than his?

If you go take that week in Hawaii every once in awhile, you might be surprised that the building did not burn down and your company did not declare bankruptcy in your absence. A tired, cranky, overworked employee does no one any good. Do not become one.

At the same time, you need to be sensitive to schedules to a certain degree when planning your time off. Again, notice to your scheduler is the key. There are certain events that cannot be predicted, but most time off is planned at least a few weeks (if not a few months) in advance. As soon as you know about your vacation time, make sure your scheduler is informed or if you are starting a new schedule after you have already planned something, let the right people know as soon as possible (a good scheduler will ask about planned time off at the beginning of a new schedule, but do not count on that). You have a right to that time off and almost no boss will ask you to change your plans if you give enough notice. If your boss does, that may be a sign that you need to find a different boss.

• Part 1, Introduction
• Part 2, The Lego Exercise
• Part 3, Teaching yourself better estimation
• Part 4, Understanding your scheduler
• Part 5, Padding leads to the dark path
• Part 6, Be good to yourself and your teammates
• Part 7, Final Thoughts

During the earlier section on the daily logging exercise, you probably thought to yourself, “Why should I go through that hassle when what I really need to do is pad my estimates so I will have extra time to get tasks done?” That is a very fair question. Think about what you are doing when you pad your estimates, though.

In absence of teaching yourself how to make good predictions through the daily exercise described in the earlier section (or some other method), any other estimate is going to be a guess based on your memory of your experiences. The padding you add to that is essentially another guess, designed to cover the inconsistencies of the first guess. The synthesis of two uneducated guesses does not give you a more accurate estimate. Instead, it leaves you with the expectation that you have no idea what you are talking about to begin with, and your promise to your scheduler/boss is based on little more than whim. Do you really want your next raise determined by the correctness of multiple guesses added together?

Admittedly, an estimate is a fancy word for a guess that implies greater accuracy. The daily logging exercise is meant to make your uneducated guesses educated, thereby turning them into estimates. Padding is essentially an excuse to make up some arbitrary number of scheduling wiggle room to account for the inaccuracies in your estimation process. If you know enough about yourself and your own experience with similar tasks to begin with, your original estimate will be good enough to not need the extra padding in case you are wrong.

Instead of padding, the better approach is to isolate the sub-parts of your tasks for which there are unknowns, such as those dealing with technologies that you have not used before, into their own tasks. Estimate them as best you can, but be honest with your scheduler that there are things about these particular items you simply cannot predict with an acceptable amount of accuracy. These tasks are ill-defined and needs to be watched carefully. This signifies to the people in power that these pieces of work may be risky and lets them make more informed decisions accordingly. When you make this discovery while the schedule is under way, it is important to follow this same set of steps and clearly communicate the situation (and any alternative approaches) to your scheduler as soon as possible.

Usually when a task is unpredictable, it is because not everything surrounding it is a known quantity. When possible, try to learn more about the unpredictable task before starting it so that there are fewer unknowns to deal with before you spend too much more time on it. Sometimes that may not be feasible for scheduling reasons, but when it is it can help you increase the accuracy as much as possible without relying upon padding to somehow save the day.

• Part 1, Introduction
• Part 2, The Lego Exercise
• Part 3, Teaching yourself better estimation
• Part 4, Understanding your scheduler
• Part 5, Padding leads to the dark path
• Part 6, Be good to yourself and your teammates
• Part 7, Final Thoughts

Someone in your department will be responsible for building and maintaining a schedule for your current project. This person will more than likely use a tool like Microsoft Project to help him or her track individual tasks and their interdependencies. Also, this person probably has some influence on your performance evaluation, so it is a good idea to leave a positive impression with him or her. How can you make this person’s life easier and, in turn, your evaluation better?

First, there are two kinds of time in which a scheduler is interested. “Duration” is the amount of time it will take you to complete a certain task, assuming that you are working on that task and nothing else during your normal work day (whose ratio of productive vs non-productive time you have already determined with the logging exercise). “Calendar Time” is the amount of time it will take you to actually complete the task, taking other factors into account such as vacations, training, and other tasks that must be completed during the same scheduled period.

When reporting the length of your tasks to your scheduler, it is typical to do so in duration, but be explicit when communicating your time that it is indeed duration. Also, be sure to tell him or her about other things you may have going on that will cause your calendar time to grow. Nothing annoys a scheduler more than having someone report on a Tuesday that you are going on a two week vacation on Thursday. Again, this is about setting expectations. The point is not that you are not entitled to time off - you absolutely are. Rather, it is that you need to tell the right people about it so that you do not inconvenience them in the process of taking time off.

Unless you are told to do otherwise, report your task duration lengths in quarter day increments. The reasoning for this is similar to the 15 minute rule for the task logging. When the task length is shorter than this, it is harder to enter data into the project tracking tools and longer than this de facto standard can exaggerate the overall schedule inadvertently.

Also, if you have a duration that exceeds 5 days, find a way to break it into two tasks. If a task takes you 50% longer than you anticipated, there is a big difference between the amount of surprise on a 10 day task compared to a 5 day task. Shorter tasks make it easier for the scheduler to uncover risks as the schedule is progressing. Larger tasks are more difficult for both you and the scheduler to keep track of given that they likely have unspecified subtasks within them.

Figure 1: A schedule for making a peanut butter and jelly sandwich

Figure 1 (click on it to see a bigger, more readable version) helps illustrate a few key concepts that your scheduler has to deal with. By understanding them, you can make life easier on your scheduler and enhance your standing with him or her. The figure shows two people working on eleven different tasks whose ultimate output is a peanut butter and jelly sandwich. The schedule starts at 8:00 am, each task has a duration of one minute, and the entire project is complete after 6 minutes. For each minute, you can see what task each person is working on by looking at the block of time that has their name (Samir or Lumberg) next to it. When the details are explored in a moment, the coloring and connected lines will make more sense.

For a scheduler, there are two key types of dependencies. On a scheduling graph like the one shown in Figure 1, task dependencies are typically shown with an arrow between them. For example, Task 8 (Spread peanut butter on left slice) is dependent upon both Task 7 (Open jar of peanut butter) and Task 6 (Place two bread slices on plate). The different kinds of dependencies have different root causes that create the relationship between tasks.

The easiest dependency to understand is a “resource dependency”. Here, the resource is you. The idea behind this type of dependency is that you cannot perform two tasks at the same time. What follows is that you cannot be scheduled to work on two tasks simultaneously without changing the calendar time accordingly. For example, in Figure 1-1, Samir is responsible for Task 1 (Getting the bread from the pantry) and Task 2 (Getting the peanut butter from the pantry). Instead of asking people to juggle multiple tasks at the same time, it is typically better to let people focus on individual tasks. Because of this, it is presumed that Samir cannot complete both Task 1 and Task 2 simultaneously and they show up on the schedule being completed serially.

Your scheduler is usually responsible for determining the tasks that are resource dependent and a key job of theirs is to optimize the schedule accordingly. One method of schedule optimization is balancing resources. In Figure 1, Samir has idle time at 8:03 am, meaning he is not slotted to do anything while he is waiting for Lumberg to complete Task 6 (Placing two pieces of bread on the plate). His salary still counts against the budget for this project during this time that he is not responsible for anything, making the cost of building the sandwich more expensive than it needs to be. Because of this, schedulers generally try to have as little idle time in a schedule as possible. To remedy this, the scheduler could give Task 6 to Samir to remove that resource dependency and improve the overall scheduled completion time. Alternatively, the scheduler might add more resources to the project, say a third person named Michael. As stated before, Tasks 1 and 2 are resource dependent because Samir cannot do two things at the same time. Michael could take on one of those tasks to remove that resource dependency. Bringing Michael into the schedule, however, increases its overall budget. This kind of “time to market” versus “delivery cost” trade-off is common to many schedules and is typically decided based on other factors not considered in this simple example, like the actions of competitors, revenue generation potential of the product, and other things.

The second type of dependency that a scheduler worries about is called a “functional dependency.” This occurs when one task must be completed before another one can start. From our example, when making a peanut butter and jelly sandwich, you cannot spread the peanut butter prior to opening the jar. As such, Task 8 (Spread the peanut butter on the right slice) is functionally dependent on Task 7 (Open jar of peanut butter). It is also functionally dependent on Task 6 (Place two slices of bread on plate). Unlike the resource dependencies, you are usually responsible for determining the tasks that are functionally dependent. Your own tasks will likely form some functionally dependent hierarchy with each other and they may functionally depend on tasks from others as well. So, when reporting your tasks to your scheduler, it is important to identify the functional dependencies in your task list, emphasizing the functional dependencies you have on others and those that others have on you.

The concept of “critical path” is the other scheduling term that is important for any engineer to understand. When putting together a schedule, the tasks will group themselves together in “paths” that are dependent upon each other. The longest of these paths is called the critical path, shown in red in Figure 1-1, so named because if it slips, the entire delivery of the project will also slip. Through balancing resource dependencies, the scheduler will try to reduce the critical path as much as possible so as to put the schedule at the smallest amount of risk. In the examples given previously, giving Samir Task 6 would reduce the critical path by one minute, but bringing in Michael to take Task 2 does nothing to shortening the overall delivery of the end product.

It is important to know if the tasks you are responsible for are on the critical path, as Lumberg’s are, or not because that lets you know if you have any leeway in their completion. This is not to say that if you are not on critical path you can slack off and deliver your tasks late, but it lets you know how much pressure you are under. If you are late in delivering a critical path item it is a much bigger deal than delaying the completion of a task that is not on the critical path.

Lastly, you can become a favorite of your scheduler by providing timely updates regarding your progress. For high pressure situations at the end of a schedule may dictate that they be more frequent, but this is usually a weekly communication. When in doubt, over-communicate your status on task completion. It is better to annoy your scheduler with too much information than to provide him or her too little information to judge how far ahead or behind you are on your tasks. Even if you have not made progress, no news is still news to the person tracking the schedule.

• Part 1, Introduction
• Part 2, The Lego Exercise
• Part 3, Teaching yourself better estimation
• Part 4, Understanding your scheduler
• Part 5, Padding leads to the dark path
• Part 6, Be good to yourself and your teammates
• Part 7, Final Thoughts

A great high school math teacher once told his class, “I have the secret to doing word problems!” Like most people, the students in the class had long experienced frustration with this type of math problem that attempts to relate real life circumstances to specific concepts through words instead of more straightforward equations. After a pause, several of the students eagerly asked, in unison, “How?” The teacher grinned slyly and answered, “Do a million of them!” He was understandably greeted with a collective groan.

Word problems are like any other tasks - if you do them enough times you become pretty good at them. With repetition comes familiarity. You are, no doubt, a master at tying your shoes, brushing your teeth, and eating food, because these are tasks you perform regularly. If you were handed a sandwich, you could probably estimate pretty accurately how long it would take you to eat it at a comfortable speed. The same is true of work tasks. The problem, though, is that there are so many different kinds of tasks that it can sometimes be difficult to remember past similar tasks on which to base an estimate. The solution: Keep a log of what you spend your time on.

Even if you are not required to fill out a time card at regular intervals, reserve the final 15 minutes of your day to record everything you did and how much time you spent on each task. It might look something like this:

1.50 hr - Design meeting with Henry Jones, Jr.
0.25 hr - Coffee break
1.50 hr - Prepared slides for review meeting on Thursday
2.00 hrs – Requirements discussion with marketing
0.50 hrs – Responded to email
0.75 hrs – Cleaned out voicemail
1.25 hrs – Attended Webinar on new technology
0.25 hrs – Time recording

Be complete, but do not get stuck on minutiae. Using hours as the base unit, record your information in 15 minute intervals. Increments of less than 15 minutes tends to make things difficult to compute at the end because you have several leftover minutes to deal with and you will drive yourself crazy trying to get them to add up to the amount of time you spent in the office. More than a quarter hour leaves too large a window for smaller tasks to fit into, and you will accidentally allocate too much time to items that did not fill up the whole block. The “Coffee Break” item above probably did not take that full 15 minutes, but its estimate would be even worse if the data were recorded in 30 minute intervals instead.

For tasks that take less time than 15 minutes, just make your best guess and either throw them in with tasks relating to something similar or create an “other” bin. This is yet another reason to keep the intervals reasonably small - so that you do not accidentally allocate too much time to a throw away category. Recording in terms of hours is preferable since we tend to think of our work week in terms of hours instead of minutes.

Stick with this for at least a month, even though it may seem like a waste of time at first. After that, you will start to notice a few benefits of this simple recording system. Patterns in your day will emerge that reveal how much “productive” time you have (meaning time you are actually contributing to deliverables) versus “non-productive” time (like responding to small emails and voicemails). While it can vary based on the culture of your organization and other factors, a typical ratio is 6 productive hours to 8 hours at work. For example, in an effort to build camaraderie, your department might host a short cake and punch ceremony for any birthday, anniversary, or other occasion that everyone is expected to attend. While important, these ceremonies eat into your productive time relating to schedules, and you need to take them into account.

Similarly, you will start to notice how long it takes you to complete certain kinds of tasks. What is important as you notice this is that you do not compare your speed to that of anybody else. You are you. Some things will take you more time than they will take other people and other things will take you less time. If you get caught up comparing yourself to others, you will only end up getting competitive with people you are supposed to build synergy with and that is no good for a team. Remember that the point of this exercise is to achieve consistency so that you can set expectations correctly with the people who manage the schedule. Be interested in your consistency, not anybody else’s.

Once you put these ideas into practice, patterns of task categories will emerge. There might be several types of documentation tasks, a design task, and learning tasks, for example. Whatever those groupings of tasks are, they are probably unique to your engineering discipline, likely influenced by your department, and possibly special to you. Make note of these things and as new tasks come in, try to affinity group them with tasks you have already completed.

After some more time, you should begin to see tasks come in that are similar to ones you have already created. This is the first of two big payoffs of spending these 15 minutes per day logging your task times. When a new task comes across your desk, look through your archive of completed tasks for one that is similar. Gauge how much more difficult or simple, and how vague or concrete the new task is compared to the old one. When you are hypothesizing about how long the new task will take, the historical data begins to help remove ambiguity as a major influence. As time goes on and you begin to recognize a finite number of task types you are asked to perform, you will find that your estimation accuracy will improve.

The other big payoff comes when it is time to prepare for your performance evaluation. When six, nine, or twelve months go by, it is easy to forget things you have worked on. With this task logging, you have a detailed record of the tasks you have completed. That is not to say that every single task you perform should be enumerated to your boss when the time comes to evaluate you, but the log can serve as a reminder to you for what you have done. It is up to you to highlight the important facts, but this method makes it easier for you to discover the facts to begin with.

• Part 1, Introduction
• Part 2, The Lego Exercise
• Part 3, Teaching yourself better estimation
• Part 4, Understanding your scheduler
• Part 5, Padding leads to the dark path
• Part 6, Be good to yourself and your teammates
• Part 7, Final Thoughts

Many things influence your ability to predict the amount of time that it takes you to complete a task. Not all of them are within your direct control, but many of them are. The following exercise will demonstrate this through the use of Legos, which most engineers like to play with inherently.

Go to your local toy store (or at least pretend to) and find the section that has Legos. Select a set with between 20 and 50 pieces in it. Before making your purchase, take a good look at the picture on the container, which shows what the completed set should look like. Be sure to get a bag and leave your new toy in the bag for a couple days.

Next, without removing the container from the bag, open it and spread all of the pieces out on a flat surface in front of you. The idea here is that you want to be able to get all the pieces out of the container without looking at the picture on the outside again. Give yourself one minute to look over the pieces. Everything you need to put together the set is at your disposal. After a minute and using only your memory of the finished product as shown on the container as your guide, predict the amount of time you will require to assemble the set. Write down your answer and start putting the set together, making note of your start time. When you think you are done, write down your finish time and compare your finished project to the picture on the box.

What you will likely find (unless you are already a pretty serious Lego hobbyist), is that it took you longer than expected to put your toy together, and that it does not look like the picture on the container at all. You might be thinking that this exercise is unfair because it asks you to complete a task without a clear understanding of what the end product should look like. Guess what? That happens in engineering projects all the time. At least here you have your memory of the picture on the box to go on. Imagine how much more difficult this would be if you had someone who has never put together a Lego set describe to you what the picture should look like. That is roughly the ambiguity that exists when an engineer talks to a marketing person about a new product.

The point is that you often are handed a vague description of what you are trying to construct, but you are asked to provide an accurate completion estimate anyway. Unfair? Absolutely. It is unfair, but it is often reality. How are you supposed to get good at predicting how long it will take you to do something when that something is never well-defined to begin with? It may sound odd, but the fact that projects are often vague is a fact in your favor. To see how, move on to the second phase of this exercise.

Take apart your Lego set and put it away for a few days. Then repeat the exercise exactly as you did before. How much better was your estimate this time? It was probably a lot better. Why? Because you did it once already and you were able to apply what you learned about doing it the first time to this subsequent attempt. This is the second point of the exercise – that, even if your marketing staff’s end goals are vague, you get better at estimating task durations the more times you attempt them.

While merely building the same thing again seems like cheating, it actually is not. Many of the tasks we are asked to perform as engineers – such as documentation, designs, and proof of concept investigations - are very similar to the same tasks we have done already for the last project or the previous iteration of the one on which you are working. The key is to capture those similarities so that what you are estimating is based on the differences, which tend to be smaller. How do you do that?

• Part 1, Introduction
• Part 2, The Lego Exercise
• Part 3, Teaching yourself better estimation
• Part 4, Understanding your scheduler
• Part 5, Padding leads to the dark path
• Part 6, Be good to yourself and your teammates
• Part 7, Final Thoughts

A basic tenet of engineering is that you must be able to accomplish tasks in a predictable amount of time. Via your salary and benefits, time is literally money to your management. Given this, management wants to spend money on you wisely and wants to understand how it is being used. Thousands of times in your career, you will be asked the following basic question: “How long will that take you?”

The exact format of the question may vary, but it comes down to the same basic idea. By asking this, your management is essentially asking, “How much money do I have to spend in order to get this task completed?” Every time your estimation is wrong and you take more time, in the eyes of the people who control the budgets you just cost them more money than expected. That last part is critical. The most important element in answering “How long will that take you?” is not the length of time you answer with - not even close. The key factor is the expectation you are setting. Disappoint on that expectation too often and you will paint yourself as undependable. Meet it consistently and those in power know what they are getting when you become involved in a project, which can pay big dividends for you later.

• Part 1, Introduction
• Part 2, The Lego Exercise
• Part 3, Teaching yourself better estimation
• Part 4, Understanding your scheduler
• Part 5, Padding leads to the dark path
• Part 6, Be good to yourself and your teammates
• Part 7, Final Thoughts