Creating a Schedule

Since we are on this wavelength, let's go ahead and review the key steps involved in building a project schedule. The steps are also summarized in Figure 8.4. We will follow-up this section with a more in-depth look at a few of these:

1. Identify the work tasks to be done (WBS) Reviewed in Chapter 6, but may need to be revisited as you iterate through the process.
2. Estimate the effort for each work task Based on specific resource types, the amount of effort each task will task. Covered in Chapter 7, but may need to be revisited as well until resource assignments are finalized.
3. Determine task relationships (network diagram) Identify which tasks have to be done before others can begin and which tasks can be done at the same time (in parallel).
4. Assign resources Assign the roles, personnel, and equipment that will perform each task.
5. Develop preliminary schedule If you have not already, capture all of these inputs using your preferred scheduling software.
6. Perform "reality" check A key, often overlooked, step in the process to make your schedule realistic. This step includes a review of resource allocation and calendar setup.
7. Shorten the schedule In this step, you will determine the critical path and look for ways to reduce the time required to complete the critical path tasks.
8. Account for risk responses If any of the risk responses includes adding a contingency buffer to any specific task or to the entire schedule, make sure to include this in the schedule too.
9. Walk through the schedule In this important step, the proposed schedule is presented for review and feedback. At a minimum, the schedule should be closely reviewed by the core project team first, and then by the key stakeholders (management, customers).
10. Finalize schedule Incorporate feedback from stakeholders; make any adjustments for actual resource assignments, final risk responses, and success factor tradeoffs; get formal acceptance of schedule.

Figure 8.4. The ten steps involved in creating a schedule.

tip

Due to the number of inputs, tradeoffs, and feedback points, the schedule development process is a natural, iterative process.

Expect to continuously loop back through this process and refine your inputs until a final, approved schedule is achieved.

Let's take a closer look at a few of the key steps.

Determining Task Relationships (Sequencing the Work)

In this step, we think about what needs to be done first and what can be done at the same time. We want to capture the logical relationships that exist between the tasks in our WBS. The traditional technique used to capture these relationships is the network diagram. An example of a network diagram is pictured in Figure 8.5.

Figure 8.5. Example of a partial network diagram showing logical sequence of tasks.

Unlike most introductory project management books, I'm not going to spend 510 pages (or more) on traditional network diagram topics such as types of network diagrams (Activity-on-Node, Activity-on-Arrow, GERT), dependency types (Finish-to-Start, Start-to-Finish, Start-to-Start, Finish-to-Finish), or mathematical analysis scheduling techniques (Critical Path Method, PERT, and Monte Carlo simulation). Why? Because unless you are in a specialized industry, these techniques are not used very often, and most project scheduling software will take care of most of this for you (if you know how to use it). Of course, if you plan to take the PMP, you will need to hone up on these concepts.

The whole idea here is look at your work visually and think about in what order (sequence) the work needs to occur. This is an exercise in logic. In many cases, this step is an excellent team activity. At this time, you don't want to concern yourself with resource constraints: just focus on logical sequence of the work. When you complete this task, you want to be clear on three things:

• For each task, what others tasks must be completed first?
• For the project, what tasks could be done at the same time (concurrently, in parallel)?
• For the project, where are your external dependencies? What tasks need an external event or task to complete, before it can start?

caution

A common reason for unrealistic schedules is that the schedule does not account for all the logical dependencies that exist. The schedule will generally reflect an earlier completion date than what is actually possible.

tip

Become knowledgeable and proficient at the scheduling software you use. Many unrealistic schedules originate with a project manager who does not understand how to best use the tool

 

Building the Preliminary Schedule

Now that we have our key inputs (WBS, task relationships, effort estimates, and resource assignments), we are ready to build our initial schedule. There are a few keys to remember here:

• Use scheduling software and get properly trained in how to use it.

  VALUE OF SCHEDULING SOFTWARE

  In case you are not an advocate of scheduling software, or you need to help convince someone else in your organization, please note the following benefits provided by scheduling software:

  • Critical path analysis
  • Project and resource calendars
  • Schedule calculation
  • Resource leveling
  • Baseline management
• If you've done the other steps well up to this point, this step is much, much easier.
• For each task you want to schedule, you need want to enter the following information:
  • Task name
  • Estimated effort
  • Predecessor task
  • Assigned resource
• Understand the relationship between work, duration, resources, and productivity.

  The duration of a task is dependent upon the number of resources (and their productivity rate) that are assigned to the total work effort.

• Using the scheduling software, locate the critical path. Often, the software will differentiate the tasks that comprise the critical path in some way, such as showing these tasks in red font.

  The critical path is the longest path through your network and represents the minimum amount of time it will take to complete the project.

• While the overall schedule development process should be a team-based activity, a single person generally performs the construction of the actual schedule, due to the nature of the software.

caution

Avoid entering start and end dates for tasks unless you have a hard, fixed milestone date that must be honored.

These dates establish constraints in the scheduling software and can give you unexpected results.

A team-based schedule development approach should be pursued whenever possible for two primary reasons:

• Higher quality schedule
• Team ownership of the schedule

A schedule is considered "preliminary" until resource assignments are confirmed.

 

Perform "Reality" Check

In this step, we need to make sure the schedule is reasonable and is aligned with the organizational culture. The primary checkpoints are listed here:

• Check for proper allocation of resources In this activity, we want to do two things: remove unrealistic work allocations and optimize the use of our resources.

  This activity is commonly referred to as resource leveling. Most scheduling software systems will provide a function to do this for you, but proceed with cautionthe software does not always get this right. As a result, you can have a less than optimal schedule.

  I recommend, especially if you are just beginning, that you manually level the allocation of your resources. You will learn more about your scheduling software and you will become more intimate with your schedule.

  Review the resource schedule and look for any allocation that is over the maximum hours per day or per week. In other words, if Joe Analyst is allocated for 16 hours on Monday, we have an unrealistic expectation. An adjustment needs to be made. The three common responses to resource over-allocation situations are

  1. Utilize other resources. Assign one or more of the affected tasks to an available resource.
  2. Establish a predecessor relationship. If Joe is the one who must perform each task, make the start of one task dependent upon the finish of the other(s).
  3. Modify the priority level of one or more of the tasks and let the software perform its resource leveling function.
• Check for proper use of calendars In this activity, we want to check the following:

  Are the non-working days accounted for (holidays, weekends)?

  Are the number of work hours per day consistent with the organiza tion's expectation? Are 8 hours of productivity per day assumed or something different?

  For part-time resources or resources with special work schedules, are individual calendars assigned to them that reflect this reality?

caution

Over-allocated resources and misaligned schedule calendars are two of most common causes of unrealistic project schedules.

 

Shorten the Schedule

On most projects, your preliminary schedule will not be the schedule presented to the stakeholders for approval. Due to either stakeholder expectations or an external deadline that must be met, an effort must be made to compress or "shorten" the schedule without reducing the scope of the project. The key to this effort is the critical path.

The critical path determines the earliest (the soonest) your project can be completed given the current task relationships and estimated durations. As a project manager, you want to be very clear about which tasks comprise the critical path for two reasons:

• If you can reduce this critical path (or change it), you may be able to complete the project sooner.
• Any slippage in the completion of a critical path task will push out the completion date for the entire project.

The only way to shorten a schedule is to compress the critical path time.

The common techniques to consider are detailed in Table 8.1.

Table 8.1. Techniques for Compressing the Project Schedule

Technique	Definition	Key Issue(s)
Crashing	Adding resources to critical path activities only	Certain activities cannot be completed faster by adding resources. Additional resources often add overhead that can negate any time savings. Crashing can increase project costs.
Fast tracking	Performing critical path activities in parallel	Fast tracking is a high-risk technique that increases the probability of rework.
Process improvements	Gaining productivity increases based on different work processes, technologies, and/or machinery	New approaches can increase project risks. Process improvements are not always available.
Limited overtime	Increasing the number of hours per day or week available to work on project tasks	Overtime is most effective when used for limited periods of time. Overuse can lead to team morale and quality of work issues.

 

Walk Through the Schedule

In our pursuit of both a more realistic schedule and a schedule that our stakeholders feel ownership, we need to walk through the schedule with at least two groupsand if at all possible get a third quality-based review.

• Review with project team First, present the proposed schedule to your project team. Seek their feedback on all aspects: complete task listing, correct resource assignments, logical task sequence, reality factors, and so on. Make any necessary adjustments.
• Quality review This review is not always possible, but whenever possible, have an experienced and knowledgeable project scheduler review your proposed schedule before you submit it to your stakeholders. Especially if you are just gaining experience at this, this input and training can be invaluable.
• Review with project stakeholders Present the proposed schedule to key stakeholders. Seek feedback and questions on all aspects: verify resource assignments, risk responses, key milestones, and so forth. There are two keys to this step. One, the form and manner in which the schedule information is presented (making it as reviewer friendly as possible), and two, investing the time to have a real-time, interactive review session.

tip

Techniques to shorten the project schedule can also be deployed during project execution as a corrective action to a schedule variance.

Clearly document and communicate all assumptions used in building the schedule.

 

Presenting the Schedule

One element of project planning and project management that is often overlooked is effectively communicating the project schedule to the various project stakeholders. Although presenting a detailed, tabular view of the schedule to the core team is acceptable, the use of visual summary representations of the schedule is highly recommended when presenting the schedule to other stakeholders. The common methods of presenting a project schedule summary are detailed in Table 8.2.

Table 8.2. Methods for Presenting a Project Schedule Summary

Method	Key Attributes	Benefits	Notes
Milestone chart	This is a bar chart that shows start and end dates, major deliverables, and key external dependencies.	Highlights key decision and completion points as well as any external dependencies.	Milestone tables are also used (same information, no bar chart).
Gantt chart	This is a bar chart that shows the various levels of the WBS.	Easy to read, incorporates the WBS, and can easily show actual progress against estimates.	Usually does not generally show interdependencies.
Network diagram	A network diagram uses nodes and arrows. Date information is added to each activity node.	Highlights the critical path and shows project logic (flow).	For presentations, the summary task level of the WBS is generally used. Otherwise, a network diagram is best suited for wall display.
Modified WBS	Uses the project WBS organization with status information added to each node.	Shows progress against original work breakdown organization. Easy to read.	Similar to network diagram type representations.

The Absolute Minimum

At this point, you should have a solid understanding of the following:

• Schedule development is an iterative, team-based activity.
• The project schedule is a critical component of the project plan and integrates together all of the key planning activities.
• The project schedule drives the project budget and the resource schedule.
• The project schedule is the project manager's most effective tool in managing expectations regarding the key success factors (time, cost, and quality).
• There are five key inputs for the schedule are the WBS, the effort estimates, the task relationships, assigned resources, and the planned risk responses.
• Many reasons for an unrealistic schedule originate with an inadequate schedule development process and inadequate training with the scheduling software.
• Document and clearly communicate all scheduling assumptions.

The map in Figure 8.6 summarizes the main points we reviewed in this chapter.

Figure 8.6. Overview of developing a schedule.