Build a project schedule

Put tasks in sequence.

- [Instructor] A big part of building a schedule is getting tasks in the right order. Mealtime goes a lot
better when you cook dinner before you eat it. By putting tasks in order, you turn your WBS into a
sequence that defines when project work should occur. In the project management world, network
diagram is the name for the diagram that shows the sequence of tasks. Each task appears in a box with the
task name and perhaps other task info. Arrows drawn between boxes show how the tasks are linked. Even
if you build the sequence by putting sticky notes up on a whiteboard, you're creating a network
diagram. The links between tasks aren't just about which task starts first. A task dependency is when one
task controls the timing of another. The task in control is called a predecessor, and the one being
controlled is the successor. Each task has a start and finish. So, there are four types of task
dependencies. Finish-to-Start dependencies are the most common. The finish of one task controls when
the other task starts. For example, you have to analyze the current scheduling processes before you can
start designing new ones. A Finish-to-Finish dependency means the finish of one task controls the finish
of the other. For example, the dev team finishing the scheduling features controls when they finish testing
the features with a small delay to test those last bits of customization. Start-to-Start means that the start of
one activity triggers the start of the other. This dependency type can cause trouble if the predecessor takes
longer than it's supposed to as shown here. If writing takes longer, the reviewing task looks like it
finishes before writing does. That would mean either some writing isn't reviewed or the reviewers have to
wait until the writing is done. In this example, the correct logic is actually Finish-to-Finish. With a Finish-
to-Finish dependency, if the writing finish date is delayed, so is the finish date for reviewing. An example
of a true Start-to-Start dependency is pouring concrete and troweling it. Because concrete hardens with
time, the start of pouring concrete controls when troweling starts. Start-to-Finish dependencies don't occur
very often. That's a good thing because they can be confusing. The start of one task triggers the finish of
another, so the task can control occurs after the one it controls. Consider the shifts at a retail store. The
first shift can't finish until the clerk for the second shift shows up. You can figure out which type of
dependency to use by asking a few questions. Which task controls the other? That tells you which task is
the predecessor. Does the start or finish date of the first task control the second task? That identifies
whether the dependency begins with start or finish. Does the predecessor control the start or finish of the
successor? That identifies whether the second half of the dependency is start or finish. Adding task
dependencies to your tasks in a network diagram, gets your project tasks into sequence. Now that you
know all the dependency types, build a network diagram for the tasks in the partial WBS in the exercise
files.
How to assign resources to tasks
- [Narrator] Your project tasks are in sequence and you've estimated their durations. The final piece of
your scheduling puzzle is how many people work on each task and when they're available. With that info,
you can see how long tasks take and when they should occur. You assign resources only to work packages
the lowest levels in your WBS because they represent work that must be done. Summary tasks roll up
work from lower levels so you don't assign resources to these tasks. Milestones don't have duration so it
doesn't make sense to assign resources to them either. What happens when you assign resources to work
packages depends on whether you estimate task duration or work. Let's say you estimate duration and
assign the number of resources you expect to get. Your scheduling tool will calculate the work those
resources can perform in that duration. Let's say you're expecting two vendor resources full time to design
scheduling features. The task duration estimate is two weeks. Two people working full time for two
weeks is 160 hours. On the other hand, if you estimate work your scheduling tool uses the work
estimate and the resource allocation to calculate the task duration. Some tasks don't get shorter no matter
how many people you assign. Meetings are the classic example. A four hour meeting is four hours
long. Whether three people attend or 10. When resources are available also affects when work occurs. For
example, your schedule might show the equipment installation starting on November 9th. If your IT folks
are wrapping up another installation and the team won't be available until November 18th, guess
what? You have to delay that task in your schedule to when the resources are available. Don't forget to
assign other types of resources you need like materials, equipment, and ancillary costs. With all resources
assigned you finally get a good idea what the schedule looks like. To practice, work through the
assignment exercise in the exercise files.
Learn to use milestones
- [Instructor] Milestones get their name from the past, when people placed stone by the side of a road to
mark each mile. In projects, milestones do a similar job, but they show progress and other key project
points, rather than distance. They show when you've completed key tasks or portions of a project, and
they make it easy to see how much you've completed and when it finished. Milestones are great as the
first and last tasks in your project schedule. By starting a project with a milestone, you can reschedule the
project start date just by moving the starting milestone to a later date. By looking at the final milestone,
you can tell whether the project is on time, late or ahead of schedule. Milestones also help highlight
progress you've made in between the project start and finish. When all the work leading up to that
milestone is done, you have the satisfaction of marking off another milestone as complete. If you're
waiting for someone to deliver something, add a milestone to flag that delivery. Finally, use a milestone to
flag decisions that determine what happens next in a project, or use a milestone for an approval that
determines when the work after the approval can start. Milestones help indicate progress in a
project. When you link them to work tasks, you can also use them to reschedule portions of a project. For
practice, add milestones to the network diagram in the exercise files.
Make a realistic schedule
- [Instructor] It's important to make your project schedule realistic so tasks occur as close as possible to
the dates you planned. One way to build reality into your schedule is to estimate task duration based on
the hours people work on the project each day. People don't work a hundred percent of their time on
project tasks. People don't even work a hundred percent of every workday. Things like staff meetings,
paperwork, training, and time off, chew up work hours. Even walking across campus uses up work
time. So do your best to estimate the number of hours people typically work. Another dose of reality is
adjusting estimated task hours based on how fast the assigned workers are. For example, if someone is a
whiz at getting computers connected to the network, you can change the task work hours to reflect her
productivity. Third, to keep people productive, assign resources to work on no more than three tasks at a
time. Switching between tasks means a person has to switch focus and that introduces a small delay each
time. When resources are in demand and you have to assign them to several tasks, adjust those
assignments to reflect their decreased productivity. When you make adjustments like these, add a note to
your schedule to document the change and the reason why. That way you'll know what to do if other
changes come up in the future. The closer you model your resource assignments to reality, the easier it
will be to keep your project on time. Complete the assignment exercise in the exercise files to practice
assigning resources to tasks.
Understand the critical path
- The critical path is the longest sequence of tasks in your schedule. Why is the critical path so
critical? Because any delay on that path delays the finished date of the project. Just as important. If you
can figure out how to shorten the critical path, you can shorten the project schedule. How do you tell
which tasks are on the critical path? Simple. They don't have any slack, also known as float. Just like a
string with no slack. Critical tasks can't move without affecting the project finished date. In this simple
example, the system and training tasks occur one after the other with no slack. If any of these tasks are
delayed, the project finished date moves later in time. On the other hand, if a task has slack like the
reports task here, it can start later without delaying the tasks that come after it. The reports task could
delay by a few weeks before it delays the project finish. Let's look at how you tell whether or not a task
has slack. A task has two sets of start and finish dates. The early start and early finish are the earliest
possible dates the task can start or finish based on its dependencies with other tasks. You calculate these
with what's called a forward pass. That's where you start at the project start date and use task durations
and dependencies to calculate when they finish. For example, the reports task can start as early as October
26th and finish on November 27th. The late start and late finish are the latest possible dates without
delaying tasks that follow. You calculate these dates by working backwards from the end of the
project. You got it. The backward pass. The late finish for the reports task is December 18th, so working
backwards, the late start is November 16th. The task has several weeks of slack so it isn't on the critical
path. Critical tasks have no slack. In other words, the early and late dates are the same. That's why the
training task is on the critical path. The good news, you don't have to perform these calculations. When
you use project scheduling programs, they calculate the critical path for you. The critical path is the place
to look when you want to keep your project on time or deliver it early. To test your understanding,
calculate the late dates for the tasks and the exercise and use them to identify the critical path.
How to shorten a schedule
- [Instructor] Stakeholders can be an inpatient bunch. You estimate when the project will finish and more
often than not, they ask if you can deliver it sooner. Or maybe your project gets delayed and you need to
make up time. Let's look at a few techniques for shortening the project schedule. Fast tracking means you
overlap tasks that normally occur one after the other. Let's say you want to finish design more
quickly. You can have some folks start designing software features before the system design is
complete. Fast tracking is simple. You just add an overlap to two tasks with finish to start
dependencies. The best tasks to fast track are the longest tasks on the critical path. Remember, you
shorten the whole project when you shorten the critical path. Fast Tracking the longest tasks on the
critical path shortens the schedule and also introduces the fewest number of risks and changes which
brings us to the disadvantage of fast tracking. It increases risk. For example, changes to the system design
could result in redoing work on the software design. The second technique, crashing, means you spend
additional money to shorten the schedule, like paying for more people or expedited delivery of key
materials. The critical path is still the place to look for tasks to crash. Think about it. Why would you
spend money to shorten tasks if they aren't going to shorten your schedule? You also want the alternative
that shortens the schedule, the amount you need for the least amount of money. Start with the least
expensive tasks to crash and move on to tasks with higher price tags. Remember, you crash tasks
only until you've shortened the schedule by the amount you need. A crash table makes it easy to see
which tasks to crash. It shows the cost to crash each critical task and the duration you eliminate by
crashing them. Choose the tasks with the lowest crash cost per week. If they have the same crash cost per
week, crash the longer ones first. That way you crash the fewest tasks. You can take crashing only so
far. At some point, adding more people won't shorten the duration because people start getting in each
other's way and on each other's nerves. New people take time to get up to speed and they can slow down
existing team members who have to help them get oriented. Keep in mind you review the critical
path after every adjustment. An adjustment could change the critical path. You want to make sure the next
task you work on is still on it. The third method for shortening a schedule is to cut project scope. If the
tasks for deleted scope are on the critical path, cutting scope shortens the schedule. Fast tracking,
crashing and cutting scope help shorten the project schedule. Each has its pros and cons so choose the
method that makes the most sense for the project at hand. Look at the schedule in the exercise files. What
techniques would you use to shorten the scheduling project and which tasks might be involved?
Document the baseline
- [Instructor] Once the stakeholders have approved the project plan, it's time to define your project
baseline. The baseline is a collection of the approved project documents. like requirements, the
schedule, budget, spreadsheets, and more. Basically everything you want to control with Change
Management Process. With baseline documents, you can compare actual project performance to the
baseline to see how the project's doing. Because the baseline is controlled by the Change Management
Process, any changes to baseline documents show up as change requests. How you define the baseline
depends on what you're defining. First, save the baseline version of plan documents. If something
changes, you flag those changes in a revision of the corresponding baseline document. Next, baseline the
values in your project schedule. Project scheduling programs typically provide a feature for saving a
baseline. The baseline includes the approved values for start and finish dates, task duration, work, cost,
and so on. As you record progress or make changes to the schedule, the program will show any variances
from the baseline. Once you document the project baseline you're ready to use it to evaluate progress and
project performance. For practice, what documents would you include in the scheduling project
baseline, and where might you store these documents to make them easy to access?
Challenge: Network diagram
(upbeat music) - [Instructor] The exercise files include a scenario where additional work is needed in the
scheduling project to support tracking and managing costs for hospital procedures. In this
challenge, spend about 15 minutes developing a network diagram for the task sequence that minimizes
the time needed to complete this work. After you create your network diagram, compare it to the one I
built.