SchedulePlanning

THE COMPTIA IT PROJECT+ EXAM TOPICS COVERED IN THIS CHAPTER INCLUDE

• 2.12 Given a project scenario with many phases and activities, set milestones and measurable targets for completion.
• 2.13 Given a set of specific milestones and their descriptions, specify entry and exit criteria for each.
• 2.15 Demonstrate the ability to create an activity time estimate (in units of time).
• 2.17 Identify and list the components needed to generate a workable project schedule.
• 2.18 Given a scenario with necessary project documents, and given enterprise holiday and individual calendars, demonstrate the ability to develop a project schedule by doing various project- related tasks .

Once you have an approved scope statement, wouldn t it be great if you could just tell the client and the rest of the stakeholders that your team will complete the project as quickly as possible, but you don t know how long that will be? Everyone dreams of having a job with no deadlines, but without them, we have no measurements for when products and services will be released to the public. Revenue projections are based on when a product or service can be purchased, department heads need to staff for new systems, and functional managers need to know how long you need their staff as resources for your project. These are just a few of the reasons a project manager needs to develop a schedule before the actual project work starts.

Most of you are probably familiar with project schedules; you may have provided input to the development of a schedule or seen copies of schedules produced from a project management software package. At first glance, it would seem that a putting together a schedule is a pretty basic activity. The schedule documents the planned start and finish of all of the tasks included in the project. All you need to do is enter the work packages from the WBS into Microsoft Project, and you have the schedule. It can t be that big a deal; how much planning can this take? As you have probably guessed, the answer is that a good project schedule takes a lot of planning. Just think about everything you need to know to produce a schedule. All of the tasks must be identified; the tasks must be sequenced in the order they can be completed; each task must be assigned an estimated length of time to complete; and finally all of this data must be organized to come up with the overall project schedule.

The project schedule will be part of the project manager s daily routine until the project is completed. Progress is reported against the schedule and status updates are provided to the stakeholders on a regular basis. If the project manager doesn t take the time up front to do schedule planning, he or she will be spending a lot of time during project execution making changes to the schedule and explaining why deliverables are not being completed as anticipated.

Now that you understand how important the schedule is, let s take a closer look at each of the components of schedule planning.

Activity Definition

The foundation to developing a project schedule is a list of the activities required to complete the project. If you have not identified the work that needs to be done, there is no point in trying to put together a schedule. Activity definition is the process of breaking down the deliverables and subdeliverables in the work breakdown structure (WBS) that we discussed in Chapter 3. Although the industry standards set by A Guide to the PMBOK defines breaking down work packages into activities as a separate process, in reality activity definition is typically not a stand-alone process. It is part of the iterative process of decomposing the WBS down to a manageable level. Depending on how detailed your WBS is, this step may already be completed.

Many guidelines are available on how far down you should break an activity, and none of them are right for every situation. Were sure you have all seen a project manager with a schedule of detailed tasks so large it looks like youd have to wheel it around on a cart. Breaking down the work required to complete a project to the level of 15-minute tasks does not guarantee project success. In fact, the outcome is usually quite the opposite . Either the project manager spends all day just trying to keep the schedule current, rather than look at the big picture, or the schedule tracking effort is abandoned and the schedule binder starts collecting dust on a shelf.

The key to activity definition is to identify all of the tasks required to produce the deliverable and to confirm that these tasks are small enough to do time and cost estimates. This needs to be balanced with keeping activities at a high enough level that they can be managed effectively. You do not want to end up trying to keep track of each team members To Do list.

If you only get a status update from project team members on a weekly basis, it does not make sense to track tasks that are only a couple of hours or days. Unless your overall project is on a very short timeline, you should define activities that will take one to three weeks to complete. If you have a very critical short task, you may want to make an exception, but you need to do a special follow-up on the status.

Once you have all of your activities defined, you are now ready to start putting them into the sequence in which they will be completed.

Activity Sequence

Life would be so much easier for a project manager if all the project activities could be worked in parallel. Each person working on the project could be given a list of the activities he or she is responsible for, and once everything on the list is done, that person could return to his or her functional organization. Each team member could estimate how long it takes to complete the assigned tasks , and the project completion date would be based on the team member with the longest estimate. Unfortunately, completing project work is not that simple; many of the project activities cannot start independently. The project team has to identify activity dependencies , which describe the relationship between two activities.

Activity sequencing is the process of identifying dependency relationships between project activities. First, you need to identify the type of dependency; next comes the specific relationship between the activities. Using this data you can create a pictorial representation of the tasks that shows all of the dependencies.

Let s first take a look at the types of dependencies, and then talk about the different dependency relationships.

Types of Dependencies

You need to identify three categories of dependencies when you are doing activity sequencing. A mandatory dependency is created by the type of work the project requires. A utility crew in a new subdivision cannot lay the cable until a trench has been dug. A discretionary dependency is something that you choose to impose on the project schedule. An example is a decision to complete tasks in a specific sequence to conform to an established corporate practice, even if there is an alternative means to sequencing the tasks. An external dependency is a relationship between a project task and some factor outside of the project that drives the scheduling of that task. Installation of a new server is driven by when the vendor can deliver the equipment.

It is important to know the type of dependency because you have more flexibility with a discretionary dependency than a mandatory dependency. This distinction becomes important later on when you look at ways to complete a project in less time.

Once you ve identified a linkage between two tasks, you and the project team need to identify exactly how this relationship works.

Task Dependency Relationships

It isn t enough just to know there is a dependency between two tasks. You need to answer several other questions: How does the dependency impact the start and finish of each of the tasks? Does one task have to start first? Can you start the second task before the first task is done? All of these variables impact what your overall project schedule looks like.

Once you identify a dependency between two tasks, you need to determine what that dependency relationship is so that you can sequence the tasks properly. Before we look at those relationships, let s cover a few key terms that are critical to understanding task dependencies.

A predecessor is a task that exists on a path with another task and occurs before the task in question. A successor is a task that exists on a common path with another task and occurs after the task in question. Figure 4.1 shows a simple predecessor/successor relationship between Task A and Task B.

Figure 4.1: Predecessor/Successor Relationship

Four possible dependency relationships exist between the predecessor task and the successor task. Identifying the correct relationship between dependent tasks is critical to developing an accurate schedule. Depending on the type of dependency relationship, you may be able to schedule the tasks in parallel or the successor task may have to wait until the predecessor is completed. Getting this relationship wrong can have a drastic effect on the accuracy of your schedule. Let s look at the four alternatives you need to evaluate for your dependent tasks.

Finish to Start In a finish to start relationship, the successor task cannot begin until the predecessor task has completed. This is the most common task relationship. It is the default setting on most project tracking software packages. For example, the user interface must be coded before the printing module can be developed.

Start to Start Use a start to start relationship when the start of the successor task depends on the start of the predecessor. These are tasks that can be worked in parallel, but if the first task is delayed, the successor task cannot start. For example, user guide documentation can start when requirements definition starts, but if requirements definition is delayed, the user guide documentation will also be delayed.

Finish to Finish A finish to finish relationship has the finish of the successor task dependent on the finish of the predecessor. For example, a new product is finished when the customer manual is complete. If the customer manual is delayed, the release of the product to market is also delayed.

Start to Finish In a start to finish relationship, the finish of the successor task is dependent on the start of its predecessor. This relationship is seldom used. Perhaps an example would be that a technical support task cannot be completed until the formation of the technical support team has started.

Once the task dependency relationships have been identified, the project team has the data to create-a picture of when the various project tasks can begin and end. This picture is a network diagram.

Creating a Network Diagram

One technique used by project managers for activity sequencing is called a network diagram. Understanding activity relationships is fundamental to using this technique. A network diagram depicts the project activities and the interrelationships among these activities. Because you can actually see how the work flows, a network diagram is a great tool to develop with the project team. Using a white board and sticky notes provides an easy way to move activities around and make changes.

The most commonly used network diagramming method is the precedence diagramming method (PDM) . PDM uses boxes to represent the project activities and arrows to connect the boxes to depict the dependencies. Figure 4.2 shows a simple PDM network diagram of tasks with finish to start dependencies on this diagram.

Figure 4.2: Precedence Diagramming Method

Now that the activities are sequenced based on the task dependencies, we are ready to estimate how long it will take to complete each activity.

Activity Duration Estimates

We have defined our activities, identified all the dependencies between tasks , and developed a network diagram to depict the flow of the project work. We must be ready to complete the project schedule, right? Not quite yet ”we still need a very critical component: how long each task will take to complete. Activity duration is the process of estimating the time to complete each item on the activity list. The most common measurements used to define duration are days or weeks, but this can vary based on the size of the project.

Before we explain the techniques you can use to complete your duration estimates, let s make sure we have a common understanding as to what is meant by activity duration.

Defining Duration

When you are estimating duration, you need to make sure that you are looking at the total elapsed time to complete the activity. If you have a task that is estimated to take 5 days, based on an 8- hour day fully dedicated to that task, the actual duration estimate would be 10 days if the resource assigned to the task is only spending 4 hours a day on the task.

You also need to be aware of the difference between work days and calendar days. If your work week is Monday through Friday, and you have a 4-day task starting on Thursday, the duration for that task will be 6 calendar days, because no work will be done on Saturday and Sunday.

Figure 4.3 illustrates this situation. The same concept applies to holidays or vacation time.

Figure 4.3: A 4-Day Task Separated by the Weekend

Note

If you have estimated project activity durations in the past, you may not even think about talking about duration with your project team. This could lead to big problems down the road, so make sure that everyone doing estimating is in agreement up front as to whether the estimates will be provided in work days or calendar days. I recommend using work day duration estimates, as the project management software packages allow you to establish a calendar that accounts for non-work days and does not include these days when computing duration.

Now that we have a common understanding of duration, we are ready to discuss the different techniques used to create activity duration estimates.

Estimating Techniques

Where do those task duration estimates come from anyway? Although some cynics may tell you to use a dartboard to estimate duration, there are better ways. Some techniques are designed to provide a ballpark estimate with a wide margin of error when there is not a lot of hard data on the project available. The use of some estimating techniques is driven by the nature of the work involved in completing the task. There is no one right way to do task duration estimates. Just keep in mind that what is being done here is an estimate, and it is not a 100 percent guarantee of the length of time each task will actually take to complete.

Several techniques are used for activity duration estimates. We will take a look at three of the most commonly used and talk about some of the variables that can impact the accuracy of estimates made using each of these techniques.

Analogous estimating, or top down estimating. Analogous estimating (top down estimating) is the use of actual durations from similar activities on a previous project. This is most frequently used at the early stages of project planning when you have limited information regarding the project. Although analogous estimating can provide an approximation of a task duration based on the length of similar activities, it is typically the least accurate means of obtaining an estimate. No two projects are exactly the same, and there is the risk that the project used to obtain the analogous estimates is not as similar as it appears.

Results from analogous estimating will be most accurate if the person doing the estimating is familiar with both projects and may be able to better understand differences that could impact the activity durations.

Expert judgment. Expert judgment uses the people most familiar with the work to create the estimate. Ideally, the project team member who will be doing the task should complete the estimate. If all team members have not yet been identified, recruit people with expertise for the tasks you need estimated. How do you find people with the required expertise? If you do not have immediate knowledge of who the internal experts are, research the documentation on team members from similar projects or solicit input from your stakeholders. Ask for people who have completed a similar task on a previous project to assist with the estimates for your project.

The most accurate estimates based on expert judgment are those made by the person who will be completing the task, assuming that person can draw on past experience. One of the variables with project duration is the skill set and experience level of the team member performing the work. A duration estimate made by a senior tester will likely be shorter than that of a junior tester. If the person who is responsible for completing the task does not make the estimate, the project manager needs to make sure he or she validates the estimate with the person assigned to the task.

Quantitatively based durations. Quantitatively based durations are used when a certain quantity of work is produced, and there is a formula to gauge duration. To apply quantitatively based durations, you must know the productivity rate of the resource performing the task or have a company or industry standard that can be applied to the task in question. The duration is obtained by multiplying the unit of work produced by the productivity rate. If a typical cable crew can bury 5 miles of cable in a day, it should take 10 days to bury 50 miles of cable.

This type of estimate can be very accurate for tasks that are repetitive and have a lot of productivity data to assure that the standard productivity rate accounts for variations in skill sets and conditions under which the work is performed. To determine if using quantitatively based durations is applicable to a given project, the project manager needs to understand the criteria for the company or industry standard.

Most projects use some combination of the estimating techniques. If some of the project tasks fit into an established productivity rate formula, they are ideal candidates for quantitatively based estimates; other tasks require the input of an expert familiar with the work.

Once you have determined which estimating technique(s) works best for your project, guide the team members as they work through all of the tasks on the network diagram and assign a duration estimate to each task as illustrated in Figure 4.4.

Figure 4.4: Network Diagram with Task Duration

This will prepare you for the next process, schedule development.

Schedule Development

Schedule development is the establishment of a start date and a finish date for each of the project activities. Schedule development is where we put together all of the other work from schedule planning. An accurate schedule needs all of the activities, the sequence of those activities, and the length of each activity. With all the work we have done so far, you may think this part should be a piece of cake. In reality, putting together all of the data from the other schedule planning processes and creating a project schedule is one of the more complex processes.

Luckily, you can use a number of different techniques to develop a project schedule. We will talk in detail about three of the most commonly used techniques: critical path method (CPM), duration compression, and the use of project management software.

Project schedule development also includes the use of milestone dates, which mark a significant project event or the end of a project phase.

Let s get started with the techniques available to develop a schedule.

Schedule Development Techniques

Even though you have a huge pot of data with all of this information about all of the project activities, you still don t have a schedule. Although it may seem at first that the putting all of the activities together is an unwieldy process, you can use a number of techniques to create a meaningful schedule.

A Guide to the PMBOK lists a number of techniques for schedule development. We will focus on three of the most commonly used schedule development techniques:

• Mathematical analysis ( specifically the critical path method)
• Duration compression
• Project management software

Critical Path Method (CPM)

A Guide to the PMBOK defines mathematical analysis as calculating theoretical early and late start and finish dates for all project activities without regard for any resource pool limitation. In other words, you are not looking at when any of your resources may be available, but only at when each task can start and end based on dependency relationships with other tasks . A summary of the individual activity time periods provides the project time period.

One of the most widely used mathematical analysis techniques is critical path method (CPM) . The critical path in a project schedule is the longest activity sequence path in the project; therefore, it controls the finish date of the project. The purpose of CPM is to identify this path. The activities on the critical path have no float time . Float is the time a task may be started late or the additional time that can be used to complete the task without impacting project completion. Critical path tasks have zero float, which is why these tasks get so much attention. If a critical path task does not complete as scheduled and no other changes are made, the project end date will be affected.

Note

Chapter 9, Project Control will cover what you can do if you have critical path tasks that are taking longer than planned.

In addition to calculating the overall time to complete the project and identifying tasks on the critical path, CPM provides other useful data. You will be able to determine which tasks can start late or can take longer than planned without impacting the project end date. This information can be used during project execution to help the project manager focus attention on the tasks that have the most impact on the overall project completion date.

We are going to walk through a simple CPM calculation. CPM is rarely done manually, since a variety of software tools will do these calculations for you. But unless you understand the fundamentals behind what the software is doing, you cannot take advantage of what it is telling you.

The network diagram from activity sequencing and the task duration estimates are the key components of the CPM calculation. Refer to the precedence diagram shown in Figure 4.4 as we walk through this example.

Forward Pass The first step in determining your critical path is to complete a forward pass through the network diagram. This means that you are working from the left to the right of your network diagram. This will give you two calculations for each activity.

Early start is the earliest date an activity may begin as logically constrained by the network. The first activity on the diagram has an early start of 0. Add the duration of that activity to obtain the early finish for that activity. Early finish is the earliest date an activity may finish as logically constrained by the network.

In Figure 4.4, the early start for Task A is 0 since it is the first activity on the network. The duration for A is 3 days, so your early finish will be 3. The early finish for A becomes the early start for its successor, Task B. Continue to calculate the early start and finish dates for each activity on the network moving across the diagram until you reach the box marked Finish.

Table 4.1 shows the completed early start and early finish calculations for each of the tasks in our network diagram. Based on the calculations from this completed forward pass, the project can complete on day 20.

Table 4.1: Forward Pass

Task	Early Start	Early Finish
A		3
B	3	5
C	3	13
D	5	20
E	13	16

Backward Pass The next step to complete critical path is to complete a backward pass . This means you start at the finish of your network diagram and work back though each path until you reach start. This gives you two calculations.

Late finish is the latest date an activity can complete without impacting the project end date. Late start is the latest date you can start an activity without impacting the project end date.

In Figure 4.4, the final activity to complete is Task D. The latest it can finish is day 20. To calculate the late start for this activity, subtract the duration of 15 days from the late finish. Your late start is day 5. The late start for Task D becomes the late finish for its predecessor; Task B. Continue back through the network, calculating the late start and late finish for each task on the network diagram.

Then go back and compute the second path starting with Task E. Since the project finish date is day 20, the late finish for Task E is also day 20. By subtracting the duration of 3 days, you obtain the late start of day 17. Continue to calculate the late start and finish dates for each activity on the network.

Table 4.2 shows the completed late start and late finish calculations for our network diagram.

Table 4.2: Backward Pass

Task	Late Start	Late Finish
A		3
B	3	5
C	7	17
D	5	20
E	17	20

Float The final step in determining critical path is to calculate float for each activity on the network diagram. Float is obtained by subtracting the early start from the late start or the early finish from the late finish for each activity. Use the calculations from Tables 4.1 and 4.2 and start with Task A. The early finish is 3 and the late finish is 3, making the float 0. Continue through the network diagram until you have computed the float time for each activity.

Table 4.3 shows the float for each of our tasks.

Table 4.3: Float

Task	Float
A
B
C	4
D
E	4

You are now ready to determine the critical path. Remember we said earlier that the critical path is the path with no float. In our example in Figure 4.4, both Tasks C and E have float, which means they are not on the critical path. A-B-D is the critical path, as each of these tasks has 0 float. If any of the tasks on the critical path do not start on time or take longer than planned, the end date of the project will be impacted; it will not complete within the 20-day estimate. Remember that you must pay particular attention to the status of your critical path tasks over the course of project execution to keep your schedule on track.

Unfortunately, there are times when you complete the network diagram and calculate the critical path and you determine the length of your project is unacceptable to the project stakeholders or does not complete within a mandated legal requirement. If you find yourself in that situation, you need to utilize duration compression techniques.

Duration Compression

You have just learned how to develop a network diagram of your project tasks and lay out your project schedule using CPM. But what happens if your calculation of the total project duration is longer than your target project completion date?

This is where duration compression scheduling techniques come into play. These techniques can be used up front to shorten the planned duration of the project or during project execution to resolve schedule slippage. The two duration compression techniques are crashing and fast track.

Crashing

Crashing is a technique that adds more resources to a task to complete the task more quickly.

Note

Crashing may have an impact on your budget, so you will need to look at the impacts to both your schedule and your budget.

Warning

One common misconception regarding adding resources is that if you double the resources, you will cut the duration in half. If two programmers can write the code in 4 weeks, then four programmers can do it in 2 weeks. What happens in the real world may be quite the opposite . Typically, the original resources are initially less productive when you add new resources. The work must be reallocated, which takes time away from the work itself. There may be downtime while the experienced team members train the new members .

There is also the issue of diminishing returns. The more resources that are added, the less impact each resource will make on duration reduction.

Crashing can produce the desired results if used wisely, but it is not the solution for a timeline that is unrealistic based on the scope of the project.

Fast Track

When you fast track a project, you work tasks in parallel that would normally be done in sequence.

For example, suppose that you have a project in which you have to build four servers that are going to interact with one another. You might have initially created four build server tasks that were supposed to happen one right after the other. However, when you decide to fast track the project, you d probably ask the server administrator building the servers if he or she could build all four in approximately the same time. In a fast-track situation, the admin might assemble the server hardware for server one, then start the OS installing. Once that was going he or she might move to assembling Server 2 s hardware and so on. In this way you could shave precious time off of the project.

There is a great deal of risk in fast tracking. If you decide to compress your project schedule using this method, be sure and get input from the team members as to what could go wrong. Document all the risks and present them to your sponsor, your client, and other key stakeholders. Many project managers make the mistake of just trying to do the project faster without any communication as to the impacts on other areas such as quality. You need to make sure that everyone understands the potential consequences. For instance, in the example of the servers above, you can see that the main risk involved is that the admin may get confused as to which step he or she is at in the server-building process and make a critical mistake in bringing up one of the servers.

Project Management Software

Project management software is a wonderful tool that can save you a lot of time. It provides you with the ability to display a number of different views of the project, which can be a great communication tool.

The processes that we have covered in this chapter ”activity definition, activity sequence, and schedule development ”can all be completed using a project management software package. In fact, you may be wondering why we even bothered to walk through manual examples of these processes, when you can just enter your data in a software package and let it do all the work. In order to effectively use project management software, you must understand the fundamental concepts behind what the software is doing. Otherwise, you will not obtain the full benefit of what the software can provide. Worse yet, you may become frustrated because the way you have entered your tasks causes the software to do things you do not want it to do. Going through each of these processes manually will equip you with the knowledge and understanding to effectively use a software tool.

Keep in mind that even if you will be using software to track the progress of your project, the up-front work that you do as a team to create a WBS and define estimates can still be created manually using a white board and sticky notes. This data can be entered into a software package later for tracking purposes.

If your company provides you with a project management software tool and you have never used one before, ask to attend a class. If that is not possible, try to find someone in your organization who is experienced with the software to give you some on-the-job training.

A good understanding of project management software becomes more important when you start tracking project process, which we will discuss in Chapter 8, Project Execution.

Use of one or more of these scheduling techniques will assist the project manager in producing a schedule with a start and end date that accounts for all of the project activities and their dependencies. To make your schedule complete, all that remains is the addition of any required milestone dates.

Milestones

Depending on the specific methodology used and the policies within your organization, you may also need to include milestone dates in your project schedule. A milestone marks a key event in the project life cycle. Typically milestones are included in the project to identify the completion of a major deliverable . If you will be using milestones in your schedule, be sure that all of the activities required to meet the milestone are scheduled to complete before the milestone date.

Some project life cycle methodologies also use milestones to mark the end of one project phase and the beginning of the next phase. Milestones between phases typically have exit or entrance criteria. For example, a system development project milestone for moving from a test phase to a deployment phase could have a list of specific test scenarios that must be successfully completed before the testing phase is complete. This is the exit criterion that must be met before the test phase is considered complete.

Project managers need to pay close attention to milestone dates, as they are also a communication trigger. Stakeholders need to be informed when major deliverables are completed or when a project has successfully moved to a new phase. If these dates are not met, the project manager needs to communicate the current status, plans to bring the project back on track, and the new milestone date. The details of communications planning will be covered in Chapter 6, Additional Planning Processes.

Schedule Baseline

The project manager and the project team should review the completed project schedule to address any questions or resolve any outstanding issues. The project team needs to own the schedule and be committed to meeting the planned dates. To facilitate a clear understanding of the schedule, provide each team member with a copy of the schedule to review prior to the meeting. If the project schedule has been developed using a project management software package, you may be able to provide access via a shared folder.

Once the team reviews the project schedule and adds any milestone dates, it is time to establish the schedule baseline , which is a copy of the schedule prior to the start of project work. A baseline is a tool used by the project manager during project execution to monitor and communicate project progress.

The project manager communicates the baseline schedule to the stakeholders. The level of detail provided to the stakeholders will vary depending on the detail each stakeholder requires, but at a minimum cover the key milestone dates.

Juggling Project Time in the Real World

In the scope of our experience, the various IT teams we ve worked on have been smallish and incredibly overburdened with projects. On top of that, very little time could actually be devoted during the day to working on projects due to user problems and what we ve begun to call drive-bys (more on that in a minute). If, in fact, a person did find time to work on a project, it was usually after working hours when there was time to fully concentrate on the tasks .

As for project planning and good quality systems analysis and design? Fuhgeddaboudit! Generally speaking, based on the size of the organization, IT shops are either:

• Heavily segmented into IT job categories such as application development, open systems (UNIX, Linux, and Windows) server support, mainframe and mid- sized computer support, help-desk and PC-technicians, database administrators and so forth, or
• An all-one-shop that has one or two people working each type of the above job duties .

We have never run into a company that has a dedicated project team staffed with individuals from various IT persuasions, ready and anxious to work on projects, but we don t suppose that s an altogether bad idea. In any event, most companies staff IT with an eye toward maintaining the day-to-day IT activities and then only secondarily with IT projects in mind.

Drive-Bys ”the Non-Project Project

In the IT world, people are often involved with very small teams of people that have an expertise in a given subject here or there and that contribute to the overall health of the network, application development unit, or customer care center simply by bringing forward those bodies of expertise. You may, for example, be on a team of server administrators that has an email admin who basically does nothing but handle the email server farm on a daily basis.

Additionally, you ve probably got a backup person, someone who manages the file-servers, probably a database server administrator, and a security/perimeter person (running the antivirus, firewalls, DMZ, etc.). Additionally, you probably have some enterprise-class apps running such as an ERP system ”requiring some specialty administrators.

The point is, none of these individuals have time for projects! And yet, if you work in shops like I ve worked in, you must make time for projects that come your way. So you somehow apportion your day in order to get your routine server work done, plus your project work. But then, your boss comes by and wants you to drop everything so that you can go work with the guy in the attorney s office who s having a problem connecting to the email server.

Ever had that happen to you? Things are going along fine, and then, wham-o, you have to spend the next (important) two hours working with someone who doesn t understand how to drive Windows XP and Outlook 2000. Now you re way behind in both your project and your routine work.

Someone I work with gave these little boss re-directions a great term : drive-bys. The boss swings by on his way to another meeting and says By the way, can you run by so-and-so s office and check what s going on with his computer? He keeps calling me! You re not on the PC technician team, but today you re a PC technician and everything else suffers for it!

Here s the important element: How do you project plan for the inevitable drive-bys? In the scheme of things, when thinking like a project manager who has at your disposal a small team of admins, how do drive-bys fit into the whole resource-planning scheme?

This is tricky and, I think, somewhat isolated to IT shops. There s just only so much expertise to go around.

One way to deal with drive-bys in your resource planning efforts is to create a project called non-project work. Your human resources will keep track of the time that they spend on drive-bys by keying in tasks that they perform on a day-to-day basis that have nothing to do with the actual project itself. Included in these tasks will, of course, be the hours spent on the task. Thus, as the end of a pre-designated period, you can easily show how the drive-bys erode the total time allotted for a project, the result of which is a project that ends after its designated due date.

Since that s the situation, and you re concerned with juggling a busy IT shop s time so that you can get projects done, you need to understand time appropriation in the average IT shop s day.

Server Administrators Most server administrators begin their day by checking each of the servers log files to make sure there are no glaring errors. If there are errors, then, of course, they have to spend time figuring out what happened and how to rectify the situation. After that, server admins usually have several trouble calls they have to work on. (For example, so-and-so can t log on because his password has expired or the account is locked out due to too many login retries.)

After all that, if there s time left in the day, a server admin is available to work on new projects.

Database Administrators Database administrators (DBAs) also begin their day by checking each of the database log files to make sure nothing s wrong. If there are errors, they also have to spend time figuring out what happened and how to rectify the situation. After that, DBAs work on performance tuning, writing stored procedures, maintaining indexes and triggers, and working on new requests for column additions or deletions.

DBAs begin any new project work by developing a database schema , the initial layout and design of a new database. The whole database design component can be quite lengthy because it entails taking what the customer is requesting and converting that into a sensible database layout. Part of this effort includes the task of normalizing the database ”reducing each table in the database to the elements that most logically belong to it. Also, the notion of relating the tables by one or more keys also takes a great deal of time, especially when dealing with substantial databases.

Application Developers Usually you don t have the luxury of scheduling your applications programmers because they re sitting around waiting for something to do. Most programmers are busy working on other projects so it can be quite challenging to round up the help you need to get some development work done.

On top of that, your programmers may have different languages they re familiar with as well as different levels of experience. For example, your project might require a Java programmer with a good body of background experience ”one who s able to quickly get several modules written and functional while operating under a relatively short deadline. Clearly, a C# programmer couldn t fill the bill, nor could one with very little Java experience. You don t have the luxury of waiting while a more junior coder figures out how to write a certain piece of code.

Additionally, development shops typically aren t staffed to maximum capacity and, as if that s not bad enough, the senior, highly experienced folks are usually heavily engaged. They barely have enough time to answer a question from the junior folks, let alone take on another project module. The whole of this leaves you as a project manager scheduling key project tasks very far out there unless, of course, your project takes priority over everything else and managers tell the development department to drop all other work until your project is complete (not likely).

Telecommunications and Internetworking Specialists Very frequently telecommunications and internetworking folks are not even considered to be a part of the IT shop ”they re a separate arm, reporting to a different manager. But just as frequently they re needed for your IT projects. And just as frequently they re extremely busy with other priorities and projects.

Data Normalization and Conversion Takes Serious Time!

Some engineers in your company have created an Access database system that has become quite useful to their department. As a consequence, two things have transpired: The system has been significantly tweaked and refined so that it s extremely complementary of the tasks the engineers are trying to accomplish and, as a result, there are between 30 “50 people at any one time trying to access the system.

The problem is, Microsoft Access just doesn t scale well to such large concurrent user numbers . Access wasn t designed for that kind of use.

So now you re faced with an engineering department business request to take this system and convert it to a Microsoft SQL Server “based environment. SQL Server has a cool utility in it called Data Transformation Services (DTS), made just for the purpose of migrating data such as Access databases into SQL Server.

During your business requirements analysis, you ask a DBA to take a look at the database itself. She brings back some startling news: the engineers have done a great job of assembling a system, but they clearly have no idea about data normalization. The screens and reports are nice but the database itself is a mess and is going to take significant time to convert to a well-crafted SQL Server layout. She ll have to examine the Access database in order to figure out the best schema for the SQL Server database, then perform complicated data conversion routines to get the data into the proper tables and columns. Her estimate is 3 weeks just for this part of the project! Then there s the whole issue of recoding the reports (because they point to a new data source with columns that are in different tables) and screen redesigns.

There are also difficulties in making sure that the current SQL servers can handle the additional load and setting up new ODBC connections.

Microsoft Access (and to some extent programs such as dBASE, FoxPro, and FileMaker Pro) has made it very easy for neophyte users to create quick and dirty systems that meet a business need. But very often the number of users outgrows the capability of the system to meet everyone s needs. It is then that the IT shop has to get involved and spin up a project to convert the system to something with a little more horsepower. Users are almost always surprised at the amount of time that the project s going to take. It was simple to build ”why isn t it that simple to convert?

 

All of this may sound very doom and gloomish. How can you ever expect to get a project fully staffed and going if you have to wade through a labyrinth of scheduling difficulties? Part of the answer has to do with corporate priorities. If your project is an important one and you have a clear mandate to bring in the deliverables on a certain date, then you ve got leverage power to get the people you need to help. However, this leverage depends on whom the mandate is from. If, for example, the project emanates from the marketing department, you might be given a huge sense of urgency by the department s manager, but others in the organization don t share that same rush-rush feeling about it. If, on the other hand, the project you re on is something that the CEO wants to see happen right away, then you re going to have fewer problems lassoing the folks you need.

Managing projects in IT environments can be quite challenging simply because you don t have dedicated staff and the people you do have available may be unavailable for certain lengths of time. It s important that you clearly examine project schedules based on current workloads and communicate real expected finish dates as opposed to those that are overly aggressive .

Case Study: Chaptal Wineries ”a Closer Look at the WBS

After looking over your manually created WBS (Chapter 3) and thinking about the dependencies and dates, you ve realized there are areas you need to expand, timewise. For example, if you re going to be the one doing the server installation and user training, you re going to have to fly to each location, do your business, then fly to the next. Considering a flight from France to Australia, you ve got a minimum of 2 days on the airplane, plus the configuration time to get the server up and running. Then, you have to turn around and do the same thing again for user training, again planning on flight time as a huge part of the task time estimates.

The server installation itself should go fairly smoothly. Using Microsoft Windows Server 2003 and Exchange Server 2003, you ll set all locations up as distinct sites in the same organization. Provided WAN connectivity is set up and working, you should have few issues with the actual software installation. You ll also be setting up Internet Information Server (IIS) 6.0 as the intranet base web server while you re at each foreign location. You believe you can accomplish all installation work in 2 days time per location and you ve given yourself an additional day for any issues that might arise.

You re trusting the local internetworking vendor to handle the internetworking gear installation, as part of the contractual provision. Who better to install a Cisco router and get it working in France than a French Cisco system engineer (SE), for example?

Provisioning the WAN connectivity through the various local telcos seems to you to be the sketchiest part of the whole project. You have to work hand-in-hand with the local winery representative, mostly to provide you with telecommunications company contact info , to relay you important documentation, to give you anticipated installation lead times, and to make sure that the contracts are signed and installation dates set. Still, T1/E1 circuits are the bread and butter of most telcos ”you don t anticipate major delivery problems in the 30-day time constraint you ve placed. Budget is not a huge priority relative to the WAN circuits. Kim knows you need them, and you re not asking for anything huge in terms of bandwidth (a T1 circuit runs at 1.544 megabits/second).

After installing a copy of Microsoft Project 2002, you whip up your project schedule, keying in the changes and setting up what you believe are accurate task durations and predecessors. The graphics below show the output: the WBS and Gantt chart, respectively. A Gantt chart is a bar chart that shows the relationship between the project tasks and time. Project managers like to use Gantt charts because they quickly give people a visual representation of the tasks and how they play out over time. Project management software can automatically generate Gantt charts , along with the coupling lines that show interesting project features, such as milestones. The main program window in a Microsoft Project screen shows the tasks in the left-hand pane and the Gannt chart in the right-hand pane. In the graphics below we show the two panes one beneath the other.

You ve included the Early Start, Late Start, Early Finish, and Late Finish columns so you can understand how Project calculates them (based on the predecessors) and what your floats are.

Summary

Many critical processes are included in schedule planning. Activity definition takes the work packages from your WBS and breaks them down into assignable tasks. Activity sequencing looks at dependencies between tasks. These dependencies can be mandatory, discretionary, or external. Dependent tasks are either a successor or a predecessor of a linked task.

There are four types of task dependency relationships: finish to start, start to start, start to finish, and finish to finish. A network diagram is a pictorial representation of the task dependency relationships. Activity duration estimating is obtained using analogous (also called top down) estimating, quantitatively based durations, or expert judgment.

The most complex schedule planning process is schedule development. There are three commonly used schedule development techniques. The mathematical analysis technique critical path method (CPM) creates a schedule through the completion of a forward and backward pass through the network diagram and calculating float.

Duration compression is the technique used to shorten a project schedule to meet a mandated completion date. Duration compression can be obtained by applying either crashing or fast track. Crashing shortens task duration by adding more resources to the project. Fast track works tasks that were originally scheduled in sequence in parallel.

Numerous project management software tools can be used as schedule development tools. A project schedule may also include milestones, which mark major project events such as the completion of major deliverable . A completed project schedule becomes the baseline used to track and report progress of the project.

Finally, various IT professionals find that the nature of their work results in different ways of managing time. As an IT project manager, its your job to understand the day-to-day responsibilities of those IT professionals in order to determine when they will be available to take on new projects. Often, obtaining the resources and time needed to complete a project depends on who (which department) in the organization requires the help of IT.

Exam Essentials

Describe the activity sequencing process. Activity sequencing is the process of identifying relationships between the project activities.

Name the two major relationships between dependent tasks . A predecessor is a task that exists on a path with another task and occurs before the task in question. A successor is a task that exists on a common path with another task and occurs after the task in question.

Name the four types of task relationships. The four types of task relationships are finish to start, start to start, start to finish, and finish to finish.

Know and understand the three most commonly used techniques to estimate activity duration. Expert judgment relies of the knowledge of someone familiar with the tasks. Analogous or top down estimating bases the estimate on similar activities from a previous project. Quantitatively based durations are used if you can apply a unit-based formula to the activity.

Define the purpose of CPM. CPM identifies the longest activity sequence path in the project. This path controls the finish date of the project.

Explain a network diagram. A network diagram is used in activity sequencing to depict project activities and interrelationships among these activities.

Key Terms

Before you take the exam, be certain you are familiar with the following terms:

activity duration	float time
activity sequencing	forward pass
analogous estimating	late finish
backward pass	late start
crashing	mandatory dependency
critical path method (CPM)	mathematical analysis
database schema	milestone
dependencies	network diagram
dependency relationships	normalizing
discretionary dependency	precedence diagramming method (PDM)
duration compression	predecessor
early finish	quantitatively based duration
early start	schedule baseline
expert judgment	schedule development
external dependency	start to finish
fast track	start to start
finish to finish	successor
finish to start	top down estimating

Review Questions

1. Which is true for the critical path ?
   1. Has zero float
   2. Is the shortest activity sequence in the network
   3. Both A and D
   4. Controls the project finish date
2. You are a project manager for a major movie studio. You need to schedule a shoot in Denver during ski season . This is an example of which of the following?
   1. External dependency
   2. Finish to finish relationship
   3. Mandatory dependency
   4. None of the above
3. What is analogous estimating also referred to as?
   1. Fast tracking
   2. Expert judgment
   3. Crashing
   4. Top down estimating
4. You are working on your network diagram. Task A is a predecessor to Task B. Task B cannot begin until Task A is completed. What is this telling you?
   1. There is a mandatory dependency between Task A and Task B.
   2. There is a finish to start dependency relationship between Task A and Task B.
   3. Task A and Task B are both on the critical path.
   4. Task B is a successor to multiple tasks .
5. What is the most commonly used form of network diagramming?
   1. Activity on arrow
   2. Precedence diagramming
   3. CPM
   4. PERT
6. What are crashing and fast track techniques used for?
   1. Duration compression
   2. Activity sequencing
   3. Precedence diagramming
   4. Activity definition
7. Which is true for float or slack time?
   1. Calculated by adding the durations of all activities and dividing by the number of activities
   2. Time that you add to the project schedule to provide a cushion
   3. The amount of time an activity can be delayed without delaying the project completion
   4. Is only calculated on the longest path of the network diagram
8. Which of the following is not a tool used to determine a project critical path?
   1. Forward pass
   2. Duration compression
   3. Float calculation
   4. Backward pass
9. Activity B on your network diagram has a duration of 8 days. How do you calculate the early finish date for this task?
   1. Subtract 8 days from the late finish of the next activity on the path.
   2. Add 8 days to the late start date of Activity B.
   3. Take the early start date of Activity B and add 8 days.
   4. None of the above.
10. Which of the following is true for all activities on the critical path?
    1. The early start is always less than the late start.
    2. These activities are on the shortest path on the network diagram.
    3. The float is not important.
    4. The late finish is always the same as the early finish.
11. Youre working on a project in which the time to complete the project has been heavily restricted and funds are short. Part of the project consists of your server administrator preparing a halfdozen servers for use in a balanced web array. The servers will all look basically alike. What technique can you use to slim down some of the time required to perform this task in the project?
    1. Fast track
    2. Crashing
    3. Reducing the number of servers
    4. Purchasing a server that runs a number of virtual machines simultaneously
12. Why is it important to understand the critical path of a project?
    1. The tasks on the critical path are the most important.
    2. There is no float in the critical path tasks.
    3. The tasks on the critical path must be done first.
    4. The length of the critical path can change subject to new tasks being added to it.
13. Suppose that youre working on a project in which youve established this milestone: Database Servers Built and Functional. The following tasks are needed to get to this milestone:
    1. Build 3 database serverssee published burn doc
    2. Install Oracle 9i on each server
    3. Validate that Oracle is running correctly and can be connected to
    4. Install database schemas from development environment see schema build documentation
    5. Test 100% successful

    Which of the tasks above would represent entry criteria for the milestone?

    1. Task a
    2. Task b
    3. Task c
    4. Task d
    5. Task e
14. Youre working on a project that you and your team have estimated is going to take 15 business days. Given the work calendar shown below with a start date of Monday, November 24, 2003, how many calendar days are actually required?

    

    1. 15
    2. 22
    3. 23
    4. 24
    5. 25
    6. 30
15. A milestone differs from a task in that it (Select all that apply):
    1. Represents the end of a critical project phase
    2. Represents the culmination of a given set of tasks
    3. Represents the change of ownership in the project (from one sponsor to another, for example)
    4. Doesnt necessarily have to be removed from a taskthe completion of a given task can be the milestone
    5. Represents the movement from one process group to another
16. Youre in the process of developing a project schedule for a new project in which youve just completed the requirement-gathering and scope document elements. What would be the smart next step in figuring out what tasks go into the project schedule?
    1. Develop a network diagram.
    2. Sit down at your project management software and start hammering out the tasks.
    3. Ascertain whos going to be on the project team.
    4. Hold a white board and sticky note session that creates a network diagram.
    5. Figure out the critical path of the project.
17. Youve defined a task in a project schedule in which your team members will develop an XML application that uses a MySQL back end. While the DBA has plenty of experience with Oracle and MS SQL Server, hes pretty new to MySQL. What is the most likely element affected in the tasks of your project schedule?
    1. Resource allocation
    2. Task duration
    3. Task estimation
    4. Critical path
18. Youre the project manager for a project in which youre following a specific software development methodology. Some of the developers have observed that a new coding technique could improve the speed with which the code will be developed and ready. How will this affect the current activity duration for the project?
    1. There is a potential for a (large) decrease in the task duration.
    2. The will definitely be a decrease in task duration.
    3. The new methodology probably wont have an effect on task duration.
    4. There will probably be an actual increase in task duration should the new methodology be adopted.
19. The exhibit shows the steps in a network diagram. Task B must occur before Task C. Tasks B, C, and D must all occur after Task A and must all occur before Task E can be accomplished. How long is the critical path, in days?

    

    1. 13 days
    2. 20 days
    3. 27 days
    4. 30 days
    5. 40 days
20. The exhibit shows a series of steps in a network diagram . Tasks B through F must all wait for Task A to be completed and must all be complete before Task G can begin. Tasks B and C must occur before Task D, and Task E must occur before Task F. How long is the critical path, in days?

    

    1. 20 days
    2. 40 days
    3. 41 days
    4. 55 days
    5. 69 days

Answers to Review Questions

1. C. The critical path is the longest activity sequence in the network. It has zero float or slack time, and it controls the project end date.
2. A. A dependency such as weather conditions or a specific season that is outside the list of project activities is an external dependency. A finish to finish relationship means that the successor task cannot finish until the predecessor task completes. A mandatory dependency is created by the nature of the work.
3. D. Analogous estimating is also called top down estimating. It is used early in the project when there is not enough detail to do a detailed estimate. The estimate is done based on a similar project. Expert judgment relies on people most familiar with the tasks to complete the estimates. Fast tracking and crashing are forms of duration compression.
4. B. There is a finish to start dependency relationship between Task A and Task B. You do not have enough information to determine if the dependency between the two tasks is mandatory, discretionary, or external.
5. B. Precedence diagramming is the most used diagramming method. Activity on arrow is a less-used diagramming method that uses arrows to represent the tasks. CPM is a schedule-development technique. Although network diagrams are sometimes called PERT charts , PERT is actually a seldom-used, specialized schedule-development technique that uses weighted averages.
6. A. Duration compression involves either crashing the schedule by adding more resources or creating a fast track by working activities in parallel that would normally be done in sequence. Activity sequencing is the process of determining the order in which tasks must be worked. Precedence diagramming method, the most common form of the network diagram, is a depiction of the project activities and the interrelationships among these activities. Activity definition is the process of defining all the tasks required to complete the project deliverables.
7. C. Float or slack time is the time a task may be started late or the additional duration a task may use without impacting project completion.
8. B. The tools use to calculate critical path are forward pass, backward pass, and float calculation. Duration compression is a technique used in schedule development.
9. C. Early finish is calculated by adding Activity Bs task duration to its early start date.
10. D. The late finish is always the same as the early finish. Float is always zero on the critical path activities. The critical path is always the longest path on the network diagram.
11. A. You only have one admin, so crashing the project (bringing in multiple folks to parallel tasks) probably isnt the solution. You cant reduce the number of serversostensibly because by the time youve gotten to this step in the project, requirement-gathering has illustrated that you will need this many. Purchasing a VM server probably wont help because its as complex to bring up as the six individual servers, what with the underlying VM software and the individual partitions.
12. B. Tasks on the critical path arent necessarily the most important, theyre just the ones that have zero float timemeaning you have no wiggle room from start to finish. Because of that, the tasks on the critical path should, if represented well, represent the actual complete duration of the project. Tasks on the critical path dont necessarily have to be done firstbut they must be done in the order that youve defined with their predecessors and successors. Once youve defined the tasks and figured out what the critical path is (and obtained sign-off) you dont want to add tasks to it because this represents scope slippage.
13. E. Building the servers, installing Oracle on them, and bringing up the schemas represents work toward the milestone, but does not adequately represent that youve reached the milestone. Only task e, which says that youve successfully tested the servers as database servers, indicates that youve reached your goal.
14. C. As you can see from the answer graphic, you have to count the Saturdays and Sundays plus the holidays that are included in the projects calendar days. Even though the project only takes 15 days, youll require 23 to account for days off.

    

15. A, B, E. The 2000 Guide to the PMBOK (glossarypage 203) says that a milestone is a representation of a significant event in the projectoften the production of a major project deliverable . Therefore, when you shift from one project phase to another in your WBS, representing the completion of a group of tasks that resulted in that phase completion, or youve completed all the deliverables and youve now shifted from the Executing/Controlling to the Closing process group , you have achieved a milestone. There is a lot of room for gray area discussion about what actually makes up a milestone in any given projectits fundamental that you would arrive at those milestone designations by communicating with your team to determine what the milestones are and then communicate outward to your stakeholders. All interested parties should know when youve hit a key milestone.
16. D. As a result of finishing the scope document and requirements documents, you probably already know whos going to be on the project team. What you dont have a good feel for, at least yet, is the tasks that have to be done. A white board and sticky note session with your project team would be a good starting point in directing you to a network diagram that ( hopefully) everyone can live with.
17. B. As an experienced DBA, he probably has the ability to give you a fairly good estimate of what its going to take to build the database in MySQL. Much of the design work in databases is done before the DBA hits the UI ( user interface) to actually create the tables so you can be reasonably sure of the estimate of work. However, that being said, you cannot stipulate for positive the duration of the task.
18. A. Heres the wrinkle with such a proposal: The developers are smart enough to understand that the amount of time required to write the new programs will be diminished by adopting this new software development methodology; however, how long will it take them to fully envelop the new principles of this methodology? In other words, if youre used to doing a thing a certain wayin fact youve been doing it that way for a long timeand then you learn a new, faster way, how long does it take you to integrate the new method into your skill set? As a project manager, you have to somehow figure out the delta in the two (the difference between the improvement in coding speed versus the time required to adopt the new methodology). If theres a significant difference, then its probably worth your while to adopt the new technique.
19. C. The critical path is the series of consecutive activities that represent the longest necessary path through the network diagram. You use up 5 days with Task A, then 7 days with B, 10 days with C, and a final 5 days with Task E, for a total of 27 days. Even though Task D cannot fire off before Task A is completed, A-D-E only uses 13 days.
20. C. Tasks A, B, D, and G represent the longest dependent path through the network diagram, so the critical path requires 41 days.