Making yourself easy to be scheduled: Part 4 - Understanding your scheduler
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.
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
Labels: Reference
0 Comments:
Post a Comment
<< Home