Section 9.4. Creating the Project Schedule

9.4. Creating the Project Schedule

You've created a list of all project work (the WBS), estimated the duration of each task, and put them in the sequence that makes the most sense at this point. The question is, how long will these tasks actually take? The sequence of tasks may be dependent upon resource availability, but the schedule is definitely dependent upon resource availability. Some of that is related to the estimated duration of a task. If Resource A is needed for Tasks 1, 2, 5, and 6 (see Figure 9.5), you have a problem since Task 5 and Task 6 are currently sequenced to run in parallel. These are the types of conflicts that should come to light during the sequencing and/or scheduling phase. Since Task 5 is on the critical path, it means you'll need to find another resource to complete Task 6 if you don't want to put the project at risk. If some of the tasks have enough float, this may resolve the conflict, which is why creating a more detailed network diagram (see Figure 9.6) can reveal those elements as well.

You should document any assumptions you're making about your schedule so that you can be very clear about what is and is not going to happen. It might be acceptable to assume that a promised resource will be available when you need it, but if it might put your project at risk, you should list it as an assumption. We'll discuss risk later in this chapter, but for now, list any assumptions you're making about the schedule so that they are explicitly stated. If those assumptions are incorrect, your project team, subject matter experts, or the project sponsor can clearly see those assumptions and challenge or correct them.

Once you've sequenced your tasks, you can enter them into your project management software program so you can begin to develop your schedule (if you aren't using PM software, you can enter your tasks in Excel or in a table in Word, on a white board, or on a piece of paper). A sample project schedule is shown in Figure 9.8 and shows a Gantt chart, which is a graphical depiction of the schedule. The summary tasks are indicated by the long black bars that run from the start to finish of a group of sub-tasks, in this case in rows 1 and 9. These are the "roll up" of the tasks beneath them and are not in themselves distinct tasks.

Figure 9-8. Sample Microsoft Project Schedule

In creating your project schedule, there are several areas that might trip you up. We've listed a few common things to watch out for so your schedule has a good chance for success right off the bat.

Present timeline information in a format that matches the audience needs (executives need high-level milestones, while project participants need detailed schedules, etc.).
Identify areas of potential organizational conflict including vacations, holidays, company events, or other large project dates.
Identify areas of resource scheduling conflicts and resource competition (coordinate with other project managers, functional managers, vendors, etc.).
Provide supporting detail when necessary (risk assessment and contingencies for the schedule, resource requirements, timing or estimates, alternative schedules).

9.4.1. Skills and Scheduling

Placing tasks in their most logical and optimal sequence is the first step in creating your IT project schedule. The second step is to identify the resources needed for each of these defined tasks (or work packages). You have already identified needed resources and skills for the project, but now is the time you have to match those skills and resources (people and equipment) to specific tasks that are scheduled at defined times. There are a lot of moving parts at this point, so start by matching skills and resources to tasks. After you've created your optimal pairings, you can then go back through and look at areas where resources may be double-booked, have conflicting schedule requirements, or have no resources assigned. Remember, the first step is to create the most optimal schedule and then modify it to match reality. If you start with reality first, you will almost certainly miss opportunities for optimal scheduling.

Enterprise 128 …
Start, Stop and Duration

Every task must have a start and stop date in order to have a duration. One inexperienced project manager wanted to create tasks that only had stop dates because he said he didn't care how long it took someone to get it done, as long as it was completed by a certain date. The problem was that he was managing the high-level tasks and was not looking at the lower-level tasks of the WBS. If all you care about are completion dates and someone else is actually managing the lower-level details, you may want to use milestones for those completion dates and roll up those lower-level tasks into a master project plan. One way or another, all tasks have to have a start and stop date in order for work to be completed on time. Milestones can be used to indicate required completion dates, but a project with nothing but milestones is a summary, not a project plan.

9.4.2. Schedules: Padding Versus Reserves

When it comes to building a project schedule (the same holds true for project budgets, which we'll discuss later in this chapter), many IT project managers are tempted to add in a bit of "fudge factor" to give them some wiggle room when things start to get off track. Many projects' schedules do start shifting to the right (later in time) once things get underway. However, that's no reason to pad your estimates. Let's look at the difference between padding and reserves.

9.4.2.1. Padding

Padding is the practice of taking an estimate and adding some number (usually dollars, hours, or percentages) to the estimate to give you some wiggle room. If you think a task will take 16 hours, you might record it as 24 hours to give yourself some cushion. There are two problems with doing that. First, you lose sight of how long you really think the task will take. Later, when you go back to review performance against plan, you really don't know what you're comparing. You'll know you're comparing actual against some number you made up, but what number and based on what? The second problem is that it becomes a bit of a problem having padded estimates all the way down the line. If David pads his time (or cost) estimates by 10% and Louisa pads her time estimate by 8% and Amadou pads his time estimate by 12%, you can see that your project schedule begins stretching out into eternity.

The danger? Your project sponsor might balk and consider canceling the project if you can't get it done any sooner than projected and you have no idea how long these folks really think things will take.

Another danger of padding is that in some instances, it becomes unethical or perhaps illegal. Though these are only time (or cost) estimates, they may become part of a contract, Statement of Work, Project Charter, or other legal document in which case there may be legal or ethical issues to consider.

9.4.2.2. Reserves

A better way to handle the uncertainty of time or cost in an IT project is to use a concept called a reserve. Rather than padding each task's time or cost estimate, you create a reserve amount (of time or money) for each major task. For instance, using our network upgrade project example, you might calculate 10% of your total server budget and add that to your server budget as a reserve. Then, if you need to upgrade a disk drive or add memory to one or more servers (or if prices increase by the time you purchase them), you're covered. You did not hide your estimated cost by randomly adding some amount to it. Instead, you listed your estimated amount and added to that a discrete, clearly defined reserve amount. You can do this with time as well. If your very best estimate is that it will take three days to set up and test each server, you have a nine day task (three servers, unless you create a separate task for each server setup). You might add one day to that task as a reserve amount. However, you don't change the task duration or time estimate, you add one day to your scheduled reserve. The reserve is an amount (percentage or actual number) that is placed into your schedule or budget to allow for time or cost overruns.

Reserve is then totaled up for each major task or objective and added to the schedule or budget. If a task ends up taking more time than scheduled, you deduct the overage from your reserve. If a task takes less time than scheduled, you can add the amount of unused time to the reserve. In fact, a reserve acts a lot like a savings account and should be used as such. Table 9.2 shows an example of schedule reserve for a hypothetical house-building project. Let's look at a few of the items in this table. The site location has a 15% reserve because it might take longer to get a site survey than you expect due to heavy market demand. Pouring the foundation has a 25% reserve because market demand for new housing is so high that concrete is in short supply. Framing has a low reserve because the framing takes only a few days and there are plenty of carpenters in your area. The exterior finishing has a 15% reserve because weather may delay some of the exterior tasks. Interior tasks will not be delayed by weather, so the reserve is 5%.Though landscaping may also be delayed by weather, it is a short job and has far more flexibility, so it's given a low reserve. Your total reserve, then, is calculated to be 24.25 days, which averages out to 11% of your total schedule (you may want to use a weighted average or the mean rather than a simple average). Thus, your optimistic schedule indicates that everything happens as you plan. The pessimistic schedule indicates you'll use every one of your reserve days. The "most likely" schedule is in between. There may be standards or industry practices in your particular field that are used for reserves and if that's the case, you can take some of the guesswork out of your project schedule. If you've done similar projects in the past (or even similar sub-sections or project phases) in the past, you can reuse those estimates. Make sure you look at project results versus schedules if you're using historical data so you can see what another IT PM thought would happen versus what actually happened. This will give you a good view into potential problems and may allow you to avoid some of those problems right from the start.

Table 9-3. Schedule Reserve Example
Task	Duration	Reserve %	Reserve Days
Site Location	90	15 %	13.5
Foundation	30	25 %	7.5
Framing	12	5 %	0.6
Roof	5	10 %	0.5
Exterior Finish	8	15 %	1.2
Interior Finish	16	5 %	0.8
Landscaping	3	5 %	0.15
Total	164	11 % (average)	24.25
Optimistic schedule	164
Pessimistic schedule	188	(optimistic + 100% reserve)
Most likely schedule	176	(optimistic + 50% reserve)

You may need to educate your project sponsor about this concept and about how reserves work. It's important that the project sponsor support your efforts to run a "clean" project and that you be held accountable for the total schedule and total budget (including reserves) rather than individual task time or cost estimates. If your project sponsor is reluctant to do that, have him or her read this section of the chapter.

Applying Your Knowledge

Some IT project managers are hesitant to use the reserve method because they're afraid someone from management will knock their reserve amounts down and push them into shorter schedules and tighter budgets. Let's face it: whether you use a reserve amount or padded estimates, you're going to be pushed to do the project faster and with less money. The key is how you record and utilize the reserves. If you create discrete time and cost reserves, you can utilize the "savings account" notion and track your variance closely. This gives you cleaner data about your project and helps you hone your estimating skills. When you go back and compare plan to actual, you'll be comparing your (or someone's) best estimate with actual. You can use this data to troubleshoot your estimates so your estimates will be more accurate in the future. If you find the variance was an anomaly, you can make a note of it and move on. Padding obscures results, creating reserves clarifies them. To become better at your job, use reserves and avoid padding. This means you'll need to educate your team and get them to give you real estimates as well. Though this might require a bit of education, assurance, and commitment on your part, once the team understands how reserves work, they'll come around.

The deliverable for this planning task is a "final" schedule. The word "final" is relative here because one of the major responsibilities of an IT project manager is to manage the inevitable changes to the schedule that will occur. However, you have to draw a line in the sand and start somewhere and this schedule, once approved, will become the baseline against which you measure variance and progress. Figure 9.9 shows the deliverable as a schedule to be included in your project plan for final project sponsor approval, which we'll discuss at the end of this chapter.