The project schedule is a culmination of most of the project planning activities we've undertaken up to this point. Many of the things we've talked about, including the WBS, the task list, network diagrams (these show the activity dependencies), and resource needs, are linked to the project schedule.
Don't make the mistake of thinking that the project schedule is the project plan. The project plan includes the scope statement, the WBS, the communication plan, the risk management plan, and the project schedule. Other documents created along the way such as the resource lists are also part of the project plan.
The project plan is everything we've done up to this point plus the quality plan and the budget. The project schedule is a part of the project plan and should not stand in as substitute for a project plan. The project schedule is an important part of the plan but it does not list project risks, quality requirements, or critical success factors. Substituting the schedule for the entire plan could lead to an unsuccessful outcome because you're only seeing part of the picture.
The budget is derived after the project schedule is completed. Since you don't yet know what the final schedule looks like, it's difficult to come up with a project budget. Say you're contracting resources to complete a particular activity. Until you finish the project schedule, you don't know exactly when the resources are needed, what other activities these resources may be dependent on, or how long you'll need the services of those resources. Most experienced project managers establish the project schedule before working on the budget.
Project Schedule Components
The project schedule details the activities and work of the project in a format that outlines the work from start to finish. The schedule is usually displayed in some type of graph or chart form. We'll look at different ways to display the schedule itself in a later section.
The project schedule is built primarily from the WBS, task list, and network diagram. Each activity is plugged into the project schedule according to the dependencies shown on the network diagram. Start and stop dates are entered for each activity, and resource assignments may be noted on the project schedule as well, depending on the format you're using for the project schedule.
In Chapter, "Breaking Down the Project Activities," we talked about estimating activity durations and came up with the number of work periods it takes to complete each activity. We derived these initial estimates by asking team members, subject matter experts, and so on. There is one more technique you can use to derive activity estimates, which we'll talk about in the next section, called the PERT method. (You can also use PERT to calculate total project duration.)
Typically, the project duration is calculated by plotting all the activities on the project schedule. Most project schedule software programs automatically calculate the duration of the project based on the difference between the start date of the first activity and the end date of the last activity. However, don't just simply go through your activity list and add up the number of work periods for each to come up with the total duration. That method would apply only if you were the sole resource on the project, and even then it still might not be accurate.
Some activities can be completed simultaneously, which means that the project schedule is not lengthened by the duration of the lesser activity. For example, if Activity A takes five days and Activity B takes three days, the total duration is five days because Activity B can be completed at the same time Activity A is being worked on. If Activity B were dependent on Activity A to finish before it could start, then the project schedule would be eight days. Let's look at one more method for making activity and project duration estimates.
Program Evaluation and Review Technique
The Program Evaluation and Review Technique (PERT) was developed by the United States Navy to help determine estimates for a complex engineering project called the Polaris Missile Program. The project team needed a way to estimate the project schedule and forecast it with a high degree of reliability. PERT was developed as a result and is widely used today.
Program Evaluation and Review Technique (PERT)
Uses the expected value, or weighted average, of critical path tasks to determine project duration by establishing three estimates: most likely, pessimistic, and optimistic.
We'll look at PERT in its simplest form here. Keep in mind that PERT is typically used for highly complex projects, but I think you'll find that the simplified technique described here can be used for any size project. It's a reliable and accurate technique for determining estimates.
The Big Three
PERT relies on three estimates for activity durations instead of one. The three estimates are used to calculate the weighted average, which then becomes the final activity duration. PERT calls this weighted average value the expected value
The weighted average of PERT's three estimates: most likely, pessimistic, and optimistic.
The three estimates you'll use to calculate PERT are the optimistic estimate, the pessimistic estimate, and the most likely estimate. An explanation of each is shown below:
Optimistic estimate: The optimistic estimate is the ideal. This is the estimate you're looking for; it assumes that everything goes according to plan, that no risks interfere with the activity, and that everything regarding this activity falls into place almost effortlessly.
Pessimistic estimate: The pessimistic estimate is the opposite of the optimistic estimate. It assumes that almost everything that can go wrong will go wrong, that problems will come up, that resources won't cooperate, etc. The pessimistic estimate determines how long it will take to finish the activity assuming that problems will appear on the project.
Most likely estimate: This estimate is a balance between the optimistic and pessimistic estimates. It is the most likely duration of the activity.
The PERT Formula
Now that you have those three estimates, what do you do with them? You guessed it—plug them into the formula. As stated earlier, expected value is the weighted average of the three time estimates. The formula to calculate expected value is as follows:
Now let's look at an example. Suppose you're heading up a project to write a new software program for your company that automates the existing employee leave system. The employees will then be able to enter their leave requests online via a form on the intranet. This system also allows the management team to access leave reports and leave balances through one of the programs available on the system. You interviewed the lead programmer in the engineering department and asked for the three estimates you need to calculate expected value for this programming activity.
The lead programmer has given you these three estimates: optimistic is 45 days, pessimistic is 120 days, and most likely is 90 days. Let's plug them into the formula and see what we get.
The expected value for the programming activity is 87.5 days. Repeat this process for the remaining activities on your project to determine an expected value for each activity.
Note:You may want to use this technique judiciously because it's time consuming and can be costly. Consider using this technique for those activities with the greatest risk and use other estimating methods, like expert judgment, for those activities that are not critical to the project.
To calculate the total project duration, add up the expected value for each activity that has a Finish to Start dependency. The activities that do not have dependencies do not influence the project schedule, as we talked about in a previous section, so don't include them in your sum.
How Confident Are You?
Suppose you're very confident that the programming activity will take 87.5 days. The lead programmer who gave you this estimate is reliable and has consistently given you good estimates in the past. As a result, you might assign this estimate a 95 percent confidence factor, indicating that you (or the person you got the estimates from) are very confident that this activity will be completed in that amount of time. The confidence factor in this case is based on the experience level of the lead programmer who gave you the estimate. In this example, the lead programmer has performed similar activities to this one many times in the past and is confident in the estimates given for this activity.
The level of confidence you have in the estimate that's been calculated.
As you may have suspected, there is a mathematical way to calculate a confidence factor if you don't like using the experience (or seat-of-your-pants) method. This method gives even finer detail to the project estimates. This gets a little complicated and you do not have to go this extreme for small projects, but it's good information to know. Showing that you've calculated the confidence factor for your key project activities will also impress your boss at your next project meeting.
PERT calculations follow a bell curve. This means that most of the time the work will finish within plus or minus three standard deviations of the PERT calculation. Without getting too deep into mathematical and probability analysis, keep the following in mind:
Calculating Standard Deviation
Where does the standard deviation figure come from? I'm glad you asked. We'll calculate the standard deviation for our programming activity to plug into the confidence factors shown above. This will give us a range of days for each of the confidence factors to work from. Remember that in this example we're using days to calculate estimates. If we were using hours, minutes, months, etc. for estimates, the results of the calculation would be in the same increments of time we're using for estimates. The formula for standard deviation is as follows:
Now we'll calculate the range of date estimates for the 95.44 percent confidence factor for this programming activity. Add two times the standard deviation (12.5 × 2 = 25) to the expected value and then subtract two times the standard deviation from the expected value to determine the estimate ranges. Our expected value is 87.5 days. Here is the formula to determine a 95.44 confidence factor for this activity:
Now we can say with 95.44 percent certainty that the programming activity will finish between 62.5 and 112.5 days.
The remaining confidence factors are calculated the same way. Use the number of standard deviations shown in the other confidence factors, adding and subtracting from the expected value to determine the confidence level.
Be aware that the higher the standard deviation for an activity, the higher the risk. The confidence measurement calculates the difference between the pessimistic and optimistic times, so the greater the spread, the higher the number. And of course the opposite is true—the lower the standard deviation, the lower the risk.
Getting to the Estimates
You will have to enlist the help of some other folks to get at the estimates you're going to use for PERT. There's no getting around it; when you work on projects, you're going to be involving people at all levels. None of what we've done or will do throughout the remainder of this book can be accomplished without the assistance and cooperation of a team of folks. Brush off those communication skills and get to know the team members and stakeholders.
Their opinions are valuable, and you're much more likely to gain their cooperation throughout the life of the project when you involve them in important project activities and decisions.
Note:PERT is a good estimating method, but you'll still rely on other people's judgment to come up with the initial estimates you need in order to use this technique. Consider interviewing subject matter experts, vendors, experienced team members, experienced managers, and others for estimates. And don't forget to look at historical information such as previous projects of similar size and scope
Unfortunately, there are no magic formulas for determining estimates. Many industries do have tools they use to help determine estimates, but these tools are usually based on predetermined criteria. If the project fits those criteria, the estimates are probably reliable. Generally speaking, rely on your subject matter experts to determine the estimates the way they are most comfortable, whether it's with an established tool or based on their own experience.
Calculating the Critical Path
The critical path is the longest full path on the project. This means that when the durations for each of the tasks or activities in one sequence (those that have dependencies) are added up from the beginning to the ending of the project, the path with the longest duration is the critical path. Any task on the critical path is called a critical path task.
The longest path through the project made up of activities with zero float.
Here we have an example critical path diagram for our software project.
Each task shown in the diagram has the duration of the task in the upper lefthand corner. The topmost path with activity numbers 1-2-3-7 has a duration of 100 days, and path 1-4-5-6-7 has a duration of 144 days. Path 1-4-5-6-7 is the longest full path on the project, so it is the critical path.
Warning:When you change the duration of a critical path task, it always changes the project duration. Noncritical path tasks will not change the duration of the project since they can be completed at the same time as the tasks on the critical path.
You may be wondering how to determine which tasks are on the critical path. All tasks with zero float time are considered critical path tasks. Keep in mind that tasks with float time need to be completed in order to consider the project complete. The project wouldn't be considered complete if you finished all the critical path tasks but left the tasks with float time uncompleted. But tasks with float time are flexible. Their starting and ending dates do not influence the other project tasks, so you can schedule them when it's most convenient for the project team.
The amount of time you can delay the early start of a task without delaying the finish date of the project.
Now let's look at how to calculate float time for the project tasks.
Critical Path Method
TheCritical Path Method (CPM) is used to calculate the duration of the project. It calculates several dates for each task, including:
Critical Path Method (CPM)
Determines a single early and late start date and an early and late finish date for each activity on the project.
Once these dates are known for each task, float time can be calculated by subtracting the earliest start date from the latest start date. If the float time is equal to zero, the task is a critical path task.
Here are the steps we're going to use to complete the CPM calculation for our project, as shown in below Table. Please note that these calculations do not take weekends or holidays into consideration.
Table critical path calculation
The total duration for this project is calculated by adding up the duration for all tasks with zero float. Task numbers 1, 4, 5, 6, and 7 are the critical path tasks and their durations total 144 days. This calculation matches the network diagram constructed previously. Either of these methods can be used to calculate the critical path.
Most computer software programs designed to perform project scheduling calculate the critical path automatically. But it's important for you to understand what makes up the critical path, including the start and finish dates and float times. If you don't understand the basics behind the critical path, you won't be able to make schedule adjustments where needed, and you may not focus the team on the right tasks at the right times.
Working with the Project Schedule
You've calculated the start and finish dates, you know the critical path, and now it's time to assign resources to each of the tasks. At this point you'll put individual names with each task. You could add a column to the above spreadsheet showing the resource name, and you'd have all the information together in one place.
Now you have the perfect schedule for the project. The problem is you don't work in a perfect world. Some resources are not going to be available when the schedule says they're needed. Most folks don't like working through vacations and holidays, so we have to take business schedules and personal schedules into account. Or, the project duration may not be acceptable to management (99 percent of the time they think the project duration is too lengthy).
Let's look at some of the ways we can work with the project schedule to accommodate the situations stated above. First, we'll look at resource issue.
When creating the project plan, you'll need to know some basic information about the organization and about each of the resources you're planning to assign to the tasks in order to make adjustments to the schedule.
First, you need a calendar or list of all the company holidays. As you calculate the task start and end dates, take the company holidays into consideration by adding the additional days into the start and finish date calculations.
Next, you must determine the normal working hours for the organization. Do most employees work eight hours a day or do most employees work flexible schedules? Are all the resources full-time employees or are some part-time? You'll need the answers to these questions in order to adjust the schedule tasks according to your resource schedules.
Then, you need to determine individual vacation schedules. If one of your key team members is planning a wedding or taking some maternity leave, for instance, you'll need to adjust the schedule to accommodate these times.
If your project calls for the use of certain types of equipment at different times on the project, make certain you and the vendor are aware of the times the equipment is needed so that the schedule can stay on track. Don't forget to consider all the resources that could have a potential impact on the schedule. For example, your project may be dependent on the release of a new version of software or a new product release. You'll have to account for the release dates when building your project schedule.
One of the things you should consider when constructing the project schedule is adding time to the tasks for unforeseen circumstances. Especially if your project has a lengthy duration, you should consider that employees sometimes get ill, have family emergencies, and so on that will require unscheduled time off from the project. Projects that fall into this category should also have contingency plans in place for key employees who may leave the project.
Tip:Projects with long durations need contingency time added into the schedule for unforeseen events.
Even though most of us follow a regular eight-hour workday schedule (I know, many times it's more like 10 or 12 hours, but stay with me on this one), we aren't working the full eight hours on the project. There's e-mail to answer, phone calls to make, the game scores to discuss, and those vacation pictures to share with our teammates. Typically, you can count on people being productive about 80 percent of the time. Given a 40-hour workweek, you'll likely get 32 hours of productive work on the project. Don't forget to account for this time in the project schedule.
Administrative time is another time-killer that many project managers don't think about. For example, you'll require the team members to fill out status reports on a periodic basis, show up at team meetings, meet with users or stakeholders when appropriate, and meet with you one-on-one.
Keep in mind when calculating activity estimates and start and finish dates that personal and administrative time should be accounted for in the schedule. Many project managers add a percentage to the project schedule to account for this kind of time. The percentage used depends on the project manager and the type of project. My area of project management expertise is Information Technology, and I typically add an additional 15 percent of the total project duration to the project schedule to account for administrative activities such as status reports and meetings and unforeseen circumstances.
Warning :Be careful with this tactic, however. You can be accused of "padding" the schedule if your percentage is off and you consistently bring projects in ahead of schedule. The stakeholders will come to expect that your estimates are incorrect from the get-go and will be looking for the projects to complete sooner than you've promised. This can haunt you when you're working on a project that is going to need that additional time. After you've gained some experience with the projects and the project team, you'll be able to determine percentages fairly accurately.
Adjusting Project Schedules
Remember that you have some flexibility regarding the start and stop dates for the noncritical path tasks. They can be scheduled when it's most convenient. This might be early in the project or late in the project, depending on when you have the resources available.
Critical path tasks can't be changed without impacting the project duration. If you lengthen a critical path task, you'll lengthen the project schedule. Sometimes you'll find that due to resource constraints or resource schedules you have no choice but to lengthen the project duration. This will require approval from the project sponsor and key project stakeholders.
After you've determined an initial schedule, chances are high that you'll have to make adjustments to it. Here are some tips to help you when adjusting the project schedule.
Estimates: Stay within the most likely range duration estimates for your tasks. As you gain experience at this, you'll learn when you can use the optimistic estimate and when you should use the pessimistic estimate.
Task estimates and duration: Task estimates and duration are not always the same. If you have more than one resource working on the task, the duration of the task is usually shortened So determine the number of resources you have available to perform the task, and adjust the schedule accordingly. For example, the duration for the "Write programs" task is 88 days. The expert who gave you the estimates assumed that only one person would be writing the code. If two people who have equal experience work on this task, the task can be shortened to 44 days.
Warning: Adding more resources to a task will not always solve your problems. Sometimes too many resources actually lengthen the task because they're stepping all over each other instead of being productive. And it's not always possible to add more resources. When stakeholders on projects at my office start insisting that we add more resources, the team members start reciting one of their favorite project management sayings: "Nine women cannot have a baby in one month." Adding resources is not always the answer.
Another situation to consider is tasks taking much longer to complete than what the estimate says. For example, the "Train users" task has a task estimate of 10 days. However, the users are over a three-state area, and one of your trainers will have to fly to each location to perform the training. That means that the duration of this task is actually longer than the 10 days stated on the schedule.
Shortening the Project Duration
"Is it really going to take that long?" is a question you're going to hear many times throughout your project management career. Sometimes the answer is,"Yes, it's going to take that long." When stakeholders or sponsors insist that the project duration be shortened, you can consider doing several things:
One more set of adjustments you might need to make to the schedule involves resources. Once you've assigned names to the tasks, you may discover that some resources are used too much and some not enough. Still others may not be available when the schedule calls for them.
Resource leveling is a fancy term for distributing the workload among the team members. You'll smooth out the task assignments so that those folks who are overloaded have some of their work assigned to other members of the team who are underutilized.
Attempts to smooth out the resource assignments so that tasks are completed without overloading individuals and without negatively impacting the project schedule.
Mentoring is good technique to use when you're faced with this situation. I've had lead programmers on many different projects tell me that they are the only one in the whole wide world who can do the particular task you've assigned to them. Don't always fall for that line. You'll find many times that this a great opportunity for a senior programmer to mentor a junior programmer. By assigning the task to the junior team member (with the senior team member acting as mentor), the senior team member still has oversight control so they don't feel as though you've completely cut them off, and the junior member has an opportunity to learn something new. In the process you've successfully leveled the tasks. You can use this technique for partial tasks also. Consider splitting tasks so that the easier portions of the task can be assigned to a junior team member, leaving the more complicated portion for the senior team member. Use your judgment when using this technique, and do consider the validity of the senior team member's comments about the experience level needed to complete the task.
Schedule Display Options
There are several different methods you can use to display your project schedule. You can draw the schedule yourself using software tools or even pen and paper. However, most software scheduling programs give you all the display options we'll talk about here, so get familiar with your project scheduling tool and the different ways to display the schedule. The Gantt chart view and the calendar view were produced using Microsoft Project 2000. Keep in mind that these schedules do not take weekends or holidays into account, and I used the early start dates in the samples you'll see in the coming sections.
Gantt charts are easy-to-read charts that display the project schedule in task sequence and by the task start and finish dates. This image shows the tasks from the programming project plotted on a Gantt chart.
The black bar displayed on the first item, Software Project, indicates a milestone on the project. The Duration column for this entry shows 144 days, which is the total duration for the project. All the tasks listed under the milestone entry show their duration, and since these tasks are related to the milestone entry, all of their durations are summed to show the total duration.
It's also possible to add resource names to this view so that the name of the resource assigned to task appears at the end of the bar. That's a good first check you can perform when resource leveling because you can see at a glance whether certain resources are overloaded. Most software programs also have resource reports that will allow you to view, determine, and adjust resource loads.
You have several display options for the Gantt chart, including hours, days, weeks, and so on. Choose the appropriate view depending on the length and complexity of the project. If your project has a lengthy duration and you choose to display the Gantt chart in the week view, for example, you'll end up with pages and pages of printouts for the chart. Try to keep the Gantt chart printout to one or two pages for easy viewing by the stakeholders and sponsor. The project team may want a more detailed view, in which case you could print out all the pages and tape them together on a wall in the project team meeting room.
Calendar views are useful for small projects or as a high-level view for larger projects. Record the task start dates on the calendar, noting the resource assigned to the task and the expected duration. I like to note the finish date on the calendar as well.
You can also use calendar views to manage multiple small projects and to easily track resource usage among the projects or on an individual project. Use different colors to track the projects or resources.
The next image shows a sample portion of a calendar view of our project tasks. You can see that the "Deliver hardware" task begins on March 1 and is the only task on that day. March 2 shows two tasks beginning on that day, "Test hardware" and "Write programs."
A precedence network diagram like the one shown here is another alternative to displaying the project schedule. This diagram typically shows the task number, the task descriptions, the duration, and the start and stop dates. The dependencies are shown as well.
Milestone charts can be used to display the project milestone and due dates. This is a good reporting tool to use in the project status meetings to show stakeholders the progress of the project.
Project Management Related Tutorials
|Business Analyst Tutorial||Strategic Planning for Project Management Tutorial|
|Software Development Lifecycle (SDLC) Tutorial|
Project Management Related Interview Questions
|Business Analyst Interview Questions||Strategic Planning for Project Management Interview Questions|
|Network Monitoring Interview Questions||Software Development Lifecycle (SDLC) Interview Questions|
|Business process outsourcing (BPO) Interview Questions||Project Manager Interview Questions|
|PMP Interview Questions|
Project Management Tutorial
Building The Foundation
Developing Project Management Skills
Initiating The Project
Defining The Project Goals
Breaking Down The Project Activities
Planning And Acquiring Resources
Developing The Project Plan
Executing The Project
Controlling The Project Outcome
Closing The Books
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.