Building a Project Schedule

Estimating

Estimating time and cost accurately is important because those estimates affect your project schedule and budget which in turn could determine whether it makes sense to run the project.

If your estimates are low a project might get approved when another project would deliver better results. In addition, low estimates make meeting expectations almost impossible.

If you estimate too high a worthwhile project might not be approved or a project could take longer and cost more because people tend to take the time and money you give them.

Estimating accurately is challenging because estimates are nothing more than educated guesses. There are two things you estimate in projects: time and cost.

For time, you need to estimate hours of work because labor costs are based on the amount of time people work. In addition, other time-based resources affect your cost, such as how long you rent equipment or lease office space.

Second, you estimate costs that aren’t time-based, like materials you need or travel required.

Having reliable people to assist in estimating is crucial; typically you work with a project planning team made up of people knowledgeable about the project. This planning team helps you develop your initial estimates.

Another option is to hire outside experts to help you with estimating. Later on during the executing process you can obtain more accurate estimates from the people assigned to do your project work. they understand what has to be done, know how long it will take them based on their experience and they’re more motivated to live up to the estimates they've made.

When possible, base your estimates on the results from similar projects that are complete. If that isn't possible there are several techniques you can use for estimating.

With parametric models you calculate work and cost based on some measure such as the number of square feet for construction it’s a pretty easy approach because you can enter your numbers into a spreadsheet or program and get a quick answer. The disadvantage is that you can only build a parametric model when you have many similar projects in your database.

The program evaluation and review technique abbreviated to PERT uses the best, worst and most likely results to estimate a project. It’s a good approach if a project is unfamiliar or had a lot of uncertainty. Estimators think about what can go wrong or right with tasks which helps produce better estimates.

The Delphi technique counts on several heads being better than one. First, you ask several experts to produce estimates independent of one another. You then share the results with the group keeping, the estimates anonymous. You keep them anonymous as you don't want anyone to be influenced by the reputation or authority of a co-expert. You then ask each expert to estimate again. Repeat this step a few more times and then use the average of the last round as your final estimated value.

You can estimate from the top-down or the bottom up.

Top-down estimating is effective for large projects or early rough estimates. You estimate phases or major components and then break those estimates into smaller pieces until you get to individual tasks.

estimating from the bottom-up means you estimate each task and then add them up until you have the estimate for the entire project.

For large or complex projects add time for complexity, communication, interactions, travel, management and so on. There is no good rule of thumb for how much to add so you have to base your increases on experience.

On the other hand, watch out for people adding time to their estimates as a safety margin. The best way to prevent these issues is to set aside time and money that everyone can share. Contingency funds can be used if a task need more people to finish on time for example. You can use contingency time too.

In fact critical chain project management includes time buffers to help deliver projects in less time than you could otherwise.

Consider the project you're working on and decide which estimating method makes the most sense. Then identify the people who can help you estimate. Finally ask management to set aside contingency time and money so you can be proactive resolving problems that arise.

Creating dependencies between tasks

Creating dependencies between tasks

A key part of building a schedule is getting tasks in the right order. When one task can start or finish is often controlled by the start or finish of other tasks.

For example, you have to create your sales documents before you can print them. By linking tasks you turn a list of tasks into a sequence that defines when your project work will occur.

A task dependency is when one task controls the timing of another task. Because each task has a start and finish there are four types of task dependencies:

Finish to start dependencies are the most common. The finish of one task controls when other tasks start. For example you have to finish a flight reservation before someone can get on the plane.

With a start to start dependency the start of one task triggers the start of the other. When tradeshows start your sales team starts the presentations in the booth.

A finish to finish dependency means the finish of one task controls the finish of the other. When the sales team finishes working on the presentations the graphics department finishes their work on the materials.

Start to finish dependencies don't occur very often. The start of one task triggers the finish of another. So in this case the task in control occurs after the one it controls. For example the start of the tradeshow breakdown determines when sales presentations end no matter how interested the customers are.

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 first one in the dependency.

• Does the start of finish date of the first task control the second task? That identifies whether the dependency begins with start or finish.

• Do the first task controls the start of finish of the second task? That identifies whether the second half of the dependency is start or finish.

Task dependencies put tasks in the sequence so you can build your project schedule. Now that you're aware of the different types, try to identify all the Task dependencies in your project.

Understanding work, duration, and units

By understanding the relationship between work duration and units you can assign people to work on tasks to get the schedule the way you want.

Work also called effort is the number of hours or days someone works on a task.

Duration is the length of time between when a task starts and when it ends.

So let’s say you estimate that it will take 10 hours of work to print and assemble sales packets to be handed out at your event. If you spent two hours per day then the duration is five days. If you spent five hours per day the duration is two days. The work stays the same but the duration varies.

The term of the percentage of time a person spends on a task is often called units.

In the project world units are based on a typical workday, eight hours in a lot of cases. So in someone works full time, eight hours a day, units are 100%.

Now let's look at what happens if you work only two hours per day. Two hours out of a possible eight hours is 25% of each workday, its like you take a workday and divided into four pieces. So for your one workday task is going to take four pieces of the task to make one full day's worth of work. Because you work 25% of each day you now have a task 4 days long, so your duration is four days. If you assign more than one person to a task you still change the units, but in this case the duration of the task decreases.

For example, start with the same one-day task. If you assign 2 people to the task they can each work at the same time. That’s like taking the one-day and dividing it into two half-day tasks. By assigning two people to the task the duration shortens to half a day.

Then there are tasks that don't get shorter no matter how many people you assign. Meetings of the classic example. One-day meeting is one day whether three people attend or 10.

Because of the relationship between duration work and units you can assign people in different ways to make the schedule do what you want.

Using milestones

Milestones get their name from the past when people placed stones 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.

First milestones are great as the first and last tasks in your project schedule. By starting a project with a milestone you can easily reschedule the project start date just by moving the starting milestone to a later date. The last task in a project schedule is almost always a milestone. By looking at the final milestone you can tell whether the project is on time, late or ahead of schedule

Second milestones are great for highlighting 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.

Third if you're waiting for someone to deliver something add a milestone to flag that delivery.

Fourth 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

Remember milestones don't have any duration so you can add as many as you want your project without affecting the amount of work or the duration of the project.

Making a realistic schedule

It's important to make your project schedule realistic, so your projects actual performance is as close as possible to what you plan.

First, assigned people to tasks using the actual number of hours they work on your project in a day. People don't work 100% of their time on their project tasks. Other activities chew up time, such as attending department meetings, filling out timesheets, training or time off. Even walking across campus or riding the elevator uses off work time. So do your best to estimate the actual number of hours people work.

Second, assign part-time workers using the amount of time they are available. Part-time workers don't work as many hours in a week as full-time workers so have to increase task duration.

Third, adjust task hours based on how fast the assign workers are. For example, someone is a whiz with building presentations on a computer. She won’t need as much time to build the slideshows as someone who can’t type.

Fourth don’t assign someone to work on more than three tasks at a time. Multitasking negatively affects productivity. Switching between tasks means a person has to switch focus which introduces a small delay. If a person is in great demand and you have to assign him to several tasks adjust those assignments to reflect his decrease productivity.

As you assign people to project tasks think about all the factors that affect people's productivity. The closer you model your resource assignments to reality, the easier it will be to keep your project on time.

Understanding the critical path

The critical path is the sequence of tasks in your schedule with the longest duration. The critical path is important, because any delay on that path delays finish date of the project. Just as significant you can shorten the project schedule if you can figure out how to shorten the critical path.

So what makes tasks critical? Put simply they don't have any slack. In project management slack is also called float.

Just like the string without slack, critical tasks have no leeway to move without affecting the schedule. For example the developed handouts, print handouts and ship materials tasks, all occur one of the other with no slack. If any of these three tasks are delayed, the finish date of the project moves later in time.

Conversely if a task has slack it, can start later without delaying the tasks that come after it. For example the print business cards task could delay as much as eight days before delays the project finished date.

Now let's look at how you identify whether or not a task has slack. A task has two sets of start and finish dates that bracket when the task can occur. The early start and early finish at the earliest possible dates the task can start or finish based on its dependencies with other tasks.

For example the print business cards task can start as early as August 10 and finish on August 16. The late start and late finish are the latest possible date the task can start and finish without delaying tasks that follow. The late start and finish dates are August 22 and August 26, that means the task has eight working days of slack and is not on the critical path. On the other hand, the early and late dates are the same there is no slack. That’s why print handouts is on the critical path.

The good news is that you don't have to perform these calculations. When you use project scheduling programs they take care of figuring out the critical path for you.

Understanding the critical chain method

The critical chain is a slightly different take on the critical path. Using the critical chain approached, you might be able to deliver your project earlier than you would otherwise. In addition critical chain techniques help you prevent delays in the project finished day.

First the critical chain approach schedules tasks to occur as late as possible. One benefit of doing this is you don't spend money on the project until you absolutely have to. Because of this type of scheduling you adjust the schedule by moving tasks to occur earlier.

Second critical chain focuses on resource limitations. To identify the important tasks to manage, that's because resource constraints are often the toughest ones to deal with. You start by scheduling the tasks with the most limited resources so you use those people as effectively as possible.

Third, the critical chain uses buffers to give a project breathing room so it less likely to delay passage finished date.

The critical chain approach is like adding sheer time to the project. each task doesn't get its own time buffer, instead sequences of tasks share a buffer, that way only the tasks that actually need extra time use some of the buffer.

You apply a couple of different types of buffers:

• First you had buffers at the end of each sequence of tasks.

• Second, can you add a project buffer at the end of the project to protect the overall project finished date.

The critical chain approach helps deliver projects on time or earlier than expected. If you're interested in using this method I recommend you research it further to learn how to put its techniques into practice.

Shortening a schedule

Stakeholders often ask you to deliver project earlier than the first finish date you calculate.

There are two techniques you can use for shortening your schedule.

1. Fast Tracking

With fast tracking you overlap tasks that should occur one after the other. Fast tracking is fairly simple to do, because you just overlap two tasks with finish to start dependencies. The best tasks to fast-track are task on the critical path. That’s because you shorten the project schedule when you shorten the critical path.

In addition, fast-track the longest tasks on the critical path. They decrease the duration while introducing the fewest number of risks and changes to the schedule.

The disadvantage is at fast tracking increases risk. When you overlap tasks, work that is already complete could be affected by a decision that comes later, or by the way other work is done.

2. Crashing

Crashing increases the cost of your project because this technique means you spend additional money to shorten the schedule. Usually, the increased cost is for additional people you put on your tasks.

Apply crashing to tasks on the critical path. You don't want to spend money shortening tasks that don't shorten your overall schedule. The key to successful crashing is finding the alternative that shortens the schedule, the amount that you need for the least amount of money.

First you start with the least expensive tasks to crash. Then you crash tasks with higher price tags, only until you've shorten the schedule by the amount you need.

A crash table makes it easy to see which tasks you should crash. A crash table includes how much it costs to crash each task on the critical path and the duration you will eliminate by crashing them. Crash the tasks with lowest crash cost per week. If tasks have the same crash cost per week crash the longer tasks first, that way you crash the fewest number of tasks.

You can take crashing only so far, at some point adding more people won't shorten the duration because people start interfering with one another. new people are often less productive than existing team members until they get up to speed, and they slow down the existing team members who have to help them get oriented.

Whether you fast-track or crash, keep in mind that the critical path can change. Some tasks might become non-critical and others may turn into critical tasks. Be sure to review the critical path after every adjustment to make sure the next task you work on is still on the critical path.

Documenting a baseline

Once the customer and stakeholders have approved the project plan, it's time to save your project baseline. A baseline is the collection of your approved documents, budget and schedule. Your baseline is important because you compare your progress to the baseline to see how the project is doing.

Everything that you include in the planned baseline goes under your change control process, so that any changes in the baseline showed up as a change request. How you save the baseline depends on what you're saving.

First save the baseline version of your plan documents in your project notebook. Then something changes you flag those changes in a revision of the corresponding baseline document.

Second 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 your progress, or make changes to your schedule, the program can compare the current values to the baseline values to show any differences.

After you save the project baseline you’re ready to use it to evaluate progress and project performance

You can also check the following articles:

• Exploring Project Management

• The Project Initiation Phase: How to Start a Project

• The Project Planning Phase: How to Plan for the Project

• Building a Project Schedule

• Project Monitoring and Controlling: How to Run the Project

• The Project Closing Phase: The Project Conclusion

There are many sources of information to learn more about Project management. Here are some books I recommend:

• Successful Project Management: Applying Best Practices, Proven Methods, and Real-World Techniques with Microsoft Project by Bonnie Biafore

• Project Planning and Control by James P. Lewis

• Making Things Happen by Scott Berkun

• Fast Forward MBA in Project Management

• 101 Project Management Problems and How to Solve Them: Practical Advice for Handling Real-World Project Challenges by Tom Kendrick.

#ProjectRiskManagement