Building a Schedule

The first step in building a schedule is to review the key inputs. The following five key inputs are required:

·        WBS—List of organized tasks, the work to be done.

·        Effort estimates—Amount of effort and time each task will take.

·        Task relationships—The logical dependencies that exist between work tasks.

·        Resources—The actual personnel and equipment needed to perform the work between work tasks.

·        Risk responses—Measures taken to deal with the uncertainty surrounding

·        effort and resource estimates. Usually, in the form of additional time

·        (contingency buffer) added to the schedule.

Due to the amount of important information and the critical nature of two of these inputs (developing the WBS and estimating the work packages), we

reviewed them in previous posts. In this post, we take these two key inputs together with the other three (sequencing the work, develop schedule, and

finalize schedule) to develop a realistic schedule, as depicted in figure below:

Due to the number of inputs, trade-offs, and feedback points, the schedule

development process is a natural, iterative process. Expect to continuously loop through this process and refine your inputs until a final, approved schedule is achieved. Now let’s go ahead and review the key steps involved in building a project schedule:

Identify the work tasks (WBS)—Identify the work tasks that need to be

performed.

Estimate the effort for each work task—Based on specific resource types, estimate the amount of effort each task will require.

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).

Assign resources—Assign the roles, personnel, and equipment that will

perform each task.

Develop preliminary schedule—If you have not already, capture all these inputs using your preferred scheduling software.

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.

Shorten the schedule—In this step, you determine the critical path and look for ways to reduce the time required to complete the critical path tasks.

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.

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).

Finalize schedule—Incorporate feedback from stakeholders; make any adjustments for actual resource assignments, final risk responses, and   success factor trade-offs; get formal acceptance of schedule.

The figure below depicts the above-mentioned factors required to build a schedule:

A common reason for unrealistic schedules is that the schedule does not account for all the logical dependencies that exist. The schedule generally reflects an earlier completion date than what is actually possible. Many unrealistic schedules originate with a project manager who does not understand how to best use the tool. So become knowledgeable and proficient at the scheduling software you use.

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 shown below:

The traditional network diagram types (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) are not used very often unless you are in a specialized industry, and most project scheduling software will take care of this for you (if you know how to use it). Of course, we need to hone our knowledge of these concepts hence we’ll cover up these in details in our future posts. As of now our focus here is look at our work visually and think about in what order (sequence) the work needs to occur.

In many cases, this step is an excellent team activity. Currently, 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 other 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?

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

team ownership of the schedule. Team collaboration tools like Mindjet’s MindManager can be very effective for these activities.

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 be properly trained in how to use it.

·        If you’ve completed the other steps well up to this point, this step is much, easier. For each task you want to schedule, you need 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 differentiates 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.

·        Although 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.

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 to check for proper allocation of resources and to check for proper use of calendars. When checking for proper allocation resources, you want to do two things:

remove unrealistic work allocations and optimize the use of your resources.

This activity is commonly referred to as resource leveling. Most scheduling

software systems provide a function to do this for you, but proceed with caution —the software does not always get this right. As a result, you can have a less than-optimal schedule.

Hence, if you are just beginning, that you manually level the allocation of your resources. As a result, you will learn more about your scheduling software and become more intimate with your schedule. Review the resource schedule and look for any allocation that is more than the maximum hours per day or per week. In other words, if an Analyst is allocated for 16 hours on Monday, you have an unrealistic expectation. An adjustment needs to be made. The three common responses to resource over-allocation situations are the following:

·        Utilize other resources. Assign one or more of the affected tasks to an available resource.

·        Establish a predecessor relationship. If Analyst is the one who must perform each task make the start of one task dependent on the finish of the other(s).

·        Modify the priority level of one or more of the tasks and let the software perform its resource levelling function.

To check for proper use of calendars, verify the following:

·        Are non-working days accounted for (holidays or weekends)?

·        Are the number of work hours per day consistent with the organization’s expectation? Are eight 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?

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 might be able to complete the project sooner.

·        Any slippage in the completion of a critical path task pushes out the completion date for the entire project.

The common techniques to consider are detailed in figure shown below:

In our pursuit of both a more realistic schedule and a schedule that our stakeholders feel ownership for, you need to walk through the schedule with at least two groups—and if 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.

Presenting the Schedule

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 figure shown below:

This is end of today’s topic. Our focus for the next post will be on “Determining the Project Budget”.