Sad Chapter 3 PDF

Chapter 3 Managing Systems Projects
CHAPTER
3 Managing
Systems Projects
Chapter 3 is the final chapter in the systems planning The chapter includes four “Case in Point” discussion
phase of the SDLC. This chapter describes project questions to help contextualize the concepts described
management and explains how to plan, schedule, in the text. The “Question of Ethics” considers the
monitor, and report on IT projects. implications of raising awareness of a project going astray
even when the project manager is reluctant to do so.
LEARNING OBJECTIVES CHAPTER CONTENTS

When you finish this chapter, you should be 3.1 Introduction
able to: 3.2 Overview of Project Management
• Explain project planning, scheduling, monitoring, 3.3 Creating a Work Breakdown Structure
and reporting Case in Point 3.1: Parallel Services
Case in Point 3.2: Sunrise Software
• Draw a project triangle that shows the 3.4 Identifying Task Patterns
relationship among project cost, scope, and time 3.5 Calculating the Critical Path
• Create a work breakdown structure, identify task 3.6 Project Monitoring and Control
patterns, and calculate a critical path 3.7 Reporting
• Explain techniques for estimating task completion 3.8 Project Management Examples
times and costs 3.9 Project Management Software
• Describe various scheduling tools, including Gantt Case in Point 3.3: Census 2010
charts and PERT/CPM charts 3.10 Risk Management
3.11 Managing for Success
• Analyze task dependencies, durations, start dates,
Case in Point 3.4: Spring Forward Products
and end dates
3.12 The Bottom Line
• Describe project management software and how it A Question of Ethics
can be of assistance 3.13 Chapter Summary
• Control and manage project changes as they Key Terms
occur Chapter Exercises
• Discuss the importance of managing project risks
• Understand why projects sometimes fail
Phase 1 Systems Planning
3.2 Overview of Project Management 71
3.1 INTRODUCTION
Many professionals manage business and personal projects every day, but do not
always give it much thought. To manage a large-scale IT project, specific tools and
techniques are needed. A project manager is also needed, someone who is responsible
for overseeing all relevant tasks. No matter which tools are used, the idea is to break
the project down into individual tasks, determine the order in which the tasks need to
be performed, and figure out how long each task will take. With this information,
Gantt charts or PERT/CPM charts can be used to schedule and manage the work.
Microsoft Project is a popular project management tool that can help create and then
monitor the project plan, report progress, and use risk management to make the
whole process easier for everyone.
3.2 OVERVIEW OF PROJECT MANAGEMENT

The management process for developing an information system or working on a con-
struction project is much the same. The only difference is the nature of the project.
Project management for IT professionals includes planning, scheduling, monitoring
and controlling, and reporting on information system development.
3.2.1 What Shapes a Project?

A successful project must be completed on time, within budget, and deliver
T
a quality product that satisfies users and meets requirements. Project manage-
S
CH
FA
ment techniques can be used throughout the SDLC. System developers can
EA
initiate a formal project as early as the preliminary investigation stage, or
P
later on, as analysis, design, and implementation activities occur. GOOD
Systems development projects tend to be dynamic and challenging. There
is always a balance between constraints, which was discussed in Chapter 2, PICK ANY TWO
and interactive elements such as project cost, scope, and time.
FIGURE 3-1 You can’t get
everything you want; you have
3.2.2 What Is a Project Triangle? to make choices.
Figure 3-1 shows a very simple example of a project triangle. For each
project, it must be decided what is most important, because the work
cannot be good and fast and cheap.
When it comes to project management, things are not quite so
simple. Decisions do not need to be all-or-nothing, but recognize
that any change in one leg of the triangle will affect the other
two legs. Figure 3-2 represents a common view of a project
triangle, where the three legs are cost, scope, and time. The
challenge is to find the optimal balance among these factors.
st
Sc
Co
op
Most successful project managers rely on personal experience,

e
communication ability, and resourcefulness. For example, if an

extremely time-critical project starts to slip, the project manager
might have to trim some features, seek approval for a budget
increase, add new personnel, or a combination of all three
actions.
On its website, Microsoft offers an interesting suggestion for Time
project managers who have a project at risk: Find the “stuck FIGURE 3-2 A typical project triangle includes
side” of the triangle. Microsoft states that in most projects, at cost, scope, and time.
72 3.3 Creating a Work Breakdown Structure
least one side of the triangle is fixed and unlikely to change. It might be a budget cast
in stone, a scope that is inflexible, or a schedule driven by factors beyond the firm’s
control. Whichever side is fixed is probably critical to the project’s success. The leg
where the problem resides must also be identified: cost, scope, or time. Microsoft sug-
gests that if the problem is in the fixed leg, work on the other two legs. For example,
if the project must not exceed the budget and it is starting to run over, adjust the
schedule, or the scope, or both. However, if the problem is not related to the fixed leg,
the adjustment might have to be in the remaining leg. So, when faced with an inflexi-
ble budget (fixed leg) and the schedule is slipping (problem leg), the project’s scope
(remaining leg) might have to be adjusted. Explaining this situation to management is
sometimes the most difficult task of all.
3.2.3 What Does a Project Manager Do?

Whether a project involves a new office building or an information system, good
leadership is essential. In a systems project, the project manager, or project leader,
usually is a senior systems analyst or an IT department manager if the project is large.
An analyst or a programmer/analyst might manage smaller projects. In addition to
the project manager, most large projects have a project coordinator. A project coordi-
nator handles administrative responsibilities for the team and negotiates with users
who might have conflicting requirements or want changes that would require addi-
tional time or expense.
Project managers typically perform four activities, or functions: planning, schedul-
ing, monitoring, and reporting:
• Project planning includes identifying all project tasks and estimating the com-
pletion time and cost of each.
• Project scheduling involves the creation of a specific timetable, usually in the
form of charts that show tasks, task dependencies, and critical tasks that might
delay the project. Scheduling also involves selecting and staffing the project
team and assigning specific tasks to team members. Project scheduling uses
Gantt charts and PERT/CPM charts, which are explained in the following
sections.
• Project monitoring requires guiding, supervising, and coordinating the project
team’s workload. The project manager must monitor the progress, evaluate the
results, and take corrective action when necessary to control the project and
stay on target.
• Project reporting includes regular progress reports to management, users, and
the project team itself. Effective reporting requires strong communication skills
and a sense of what others want and need to know about the project.
The following sections describe the project planning and scheduling steps: how to
create a work breakdown structure, identify task patterns, and calculate the project’s
critical path.
3.3 CREATING A WORK BREAKDOWN STRUCTURE

A work breakdown structure (WBS) involves breaking a project down into a series of
smaller tasks. Before creating work breakdown structures, the two primary chart
types should be understood: Gantt charts and PERT/CPM charts.
3.3 Creating a Work Breakdown Structure 73
3.3.1 Gantt Charts

Henry L. Gantt, a mechanical engineer and management consultant, developed Gantt
charts almost 100 years ago. His goal was to design a chart that could show planned
and actual progress on a project. A Gantt chart is a horizontal bar chart that repre-
sents a set of tasks. For example, the Gantt chart in Figure 3-3 displays five tasks in a
vertical array, with time shown on the horizontal axis. The position of the bar shows
the planned starting and ending time of each task, and the length of the bar indicates
its duration. On the horizontal axis, time can be shown as elapsed time from a fixed
starting point, or as actual calendar dates. A Gantt chart also can simplify a complex
project by combining several activities into a task group that contains subsidiary
tasks. This allows a complex project to be viewed as a set of integrated modules.
A Gantt chart can show task status by adding a contrasting color to the horizontal
bars. For example, a vertical red arrow marks the current date in Figure 3-3. With a
fixed reference point, it is easy to see that Task 1 is way behind schedule, Task 2 is
only about 80% done and is running behind schedule, Task 3 should have started, but
no work has been done, Task 4 actually is running ahead of schedule, and Task 5 will
begin in several weeks.
FIGURE 3-3 In this Gantt chart, notice the yellow bars that show the percentage of task completion.
Gantt charts can present an overview of the project’s status, but they do not pro-
vide enough detailed information, which is necessary when managing a complex proj-
ect. Some project managers may find that PERT/CPM charts, which are discussed in
the following section, are better tools for managing large projects.
3.3.2 PERT/CPM Charts

The Program Evaluation Review Technique (PERT) was developed by the U.S. Navy
to manage very complex projects, such as the construction of nuclear submarines. At
approximately the same time, the Critical Path Method (CPM) was developed by pri-
vate industry to meet similar project management needs. The distinction between the
two methods has disappeared over time, and today the technique is called either
PERT, CPM, or PERT/CPM. This textbook will use the term PERT chart.
PERT is a bottom-up technique because it analyzes a large, complex project as a series
of individual tasks, just as a pyramid is built from the bottom up using individual blocks.
To create a PERT chart, first identify all the project tasks and estimate how much time
each task will take to perform. Next, determine the logical order in which the tasks must
be performed. For example, some tasks

cannot start until other tasks have been
completed. In other situations, several
tasks can be performed at the same time.
Once the tasks are known, their dura-
tions, and the order in which they must be
performed, calculate the time that it will
take to complete the project. The specific
tasks that will be critical to the project’s
on-time completion can also be identified.
An example of a PERT chart, which
Microsoft calls a network diagram, is
shown in the lower screen in Figure 3-4.
Although a Gantt chart offers a valu-
able snapshot view of the project, PERT
charts are more useful for scheduling,
monitoring, and controlling the actual
work. With a PERT chart, a project
FIGURE 3-4 The top screen shows a Gantt chart with six tasks. The PERT manager can convert task start and fin-
chart in the bottom screen displays an easy-to-follow task pattern for the same ish times to actual dates by laying out
project. When the user mouses over the summary box for Task 5, the details
become visible. the entire project on a calendar. Then,
on any given day, the manager can com-
pare what should be happening with
what is taking place, and react accordingly. Also, a PERT chart displays complex task
patterns and relationships. This information is valuable to a manager who is trying to
address high priority issues. PERT and Gantt charts are not mutually exclusive tech-
niques, and project managers often use both methods.
Figure 3-4 shows both chart types. The top screen is a Gantt chart with six tasks. The
PERT chart below it shows the same project, using a separate box for each task instead
of a horizontal bar. Although they both show the task patterns and flow, the PERT chart
boxes can provide more information, such as task duration, start date, finish date, and
the names of resources assigned to the task. The PERT chart in Figure 3-4 would be too
small to view the actual details, which are shown in the expanded text box at the bottom
of the figure. How to create PERT charts is explained in a later section.
3.3.3 Identifying Tasks in a Work Breakdown Structure

A work breakdown structure must clearly identify each task and include an estimated
duration. A task, or activity, is any work that has a beginning and an end and requires
the use of company resources such as people, time, or money. Examples of tasks include
conducting interviews, designing a report, selecting software, waiting for the delivery of
equipment, or training users. Tasks are basic units of work that the project manager
plans, schedules, and monitors—so they should be relatively small and manageable.
In addition to tasks, every project has events, or milestones. An event, or milestone,
is a recognizable reference point that can be used to monitor progress. For example, an
event might be the start of user training, the conversion of system data, or the comple-
tion of interviews. A milestone such as “complete 50% of program testing” would not
be useful information unless it could be determined exactly when that event will occur.
Figure 3-5 shows tasks and events that might be involved in the creation, distribu-
tion, and tabulation of a questionnaire. Notice that the beginning and end of each
task are marked by a recognizable event. It would be virtually impossible to manage a
project as one large task. Instead, the project is broken down into smaller tasks,
creating a WBS. The first step in creating a WBS is to list all the tasks.
FIGURE 3-5 Using a questionnaire requires a series of tasks and events to track the progress.
The illustration shows the relationship between the tasks and the events, or milestones that mark the
beginning and end of each task.
LISTING THE TASKS: While this step sounds simple, it can be challenging because the
tasks might be embedded in a document, such as the one shown in the first version of
Figure 3-6. One trick is to start by highlighting the individual tasks, as shown in the
second version. Adding bullets makes the tasks stand out more clearly, as shown in the
third version. The next step is to number the tasks and create
a table, similar to the one shown in Figure 3-7, with columns
for task number, description, duration, and predecessor tasks, First version
which must be completed before another task can start. First, reserve the meeting room. Then order
the marketing materials and brief the
managers. After the briefings, send out
ESTIMATING TASK DURATION: Task duration can be customer emails and burn sample DVDs.
hours, days, or weeks—depending on the project. Because the When the emails are sent and the DVDs are
following example uses days, the units of measurement are ready, load the new software. When the
marketing materials have arrived and the
called person-days. A person-day represents the work that one
software is ready, do a dress rehearsal.
person can complete in one day. This approach, however, can
present some problems. For example, if it will take one person Second version
20 days to perform a particular task, it might not be true that
First, reserve the meeting room. Then order
two people could complete the same task in 10 days or that the marketing materials and brief the
10 people could perform the task in two days. Some tasks can managers. After the briefings, send out
be divided evenly so it is possible to use different combinations customer emails and burn sample DVDs.
When the emails are sent and the DVDs are
of time and people—up to a point—but not all. In most systems ready, load the new software. When the
analysis tasks, time and people are not interchangeable. If one marketing materials have arrived and the
analyst needs two hours to interview a user, two analysts also software is ready, do a dress rehearsal.
will need two hours to do the same interview.
Third version
Project managers often use a weighted formula for estimat-
ing the duration of each task. The project manager first makes • First, reserve the meeting room.
three time estimates for each task: an optimistic, or best-case • Then order the marketing materials and brief
the managers.
estimate (B), a probable-case estimate (P), and a pessimistic, or
• After the briefings, send out customer emails
worst-case estimate (W). The manager then assigns a weight, and burn sample DVDs.
which is an importance value, to each estimate. The weight can • When the emails are sent and the DVDs are
vary, but a common approach is to use a ratio of B = 1, P = 4, ready, load the new software.
and W = 1. The expected task duration is calculated as • When the marketing materials have arrived
follows: and the software is ready, do a dress rehearsal.
FIGURE 3-6 The three versions show how to

(B + 4P + W) transform a task statement into a list of specific
6 tasks for a work breakdown structure.
Task Description Duration Predecessor

No. (Days) Tasks
1 Reserve the meeting room
2 Order the marketing materials
3 Brief the managers
4 Send out customer emails
5 Burn sample DVDs
6 Load the new software
7 Do a dress rehearsal
FIGURE 3-7 In this table, columns have been added for task number, description,
duration, and predecessor tasks, which must be completed before another task can start.
For example, a project manager might estimate that a file-conversion task could be
completed in as few as 20 days or could take as many as 34 days, but most likely will
require 24 days. Using the formula, the expected task duration is 25 days, calculated
as follows:
(20 + (4*24) + 34)
= 25
6
CASE In POInT 3.1: PARALLEL SERVICES
The project management team at Parallel Services is having a debate about how to define
tasks in the work breakdown structure (WBS). Ann, the project manager, wants to break
tasks down into the smallest possible units. For example, she objected to a broad task
statement called Develop a training schedule. Instead, she suggested three subtasks:
(1) Determine availability of training room, (2) Determine availability of attendees, and
(3) Select specific dates and training times.
Karen, another project team member, disagrees. She feels that the broader task state-
ment is better because it allows more flexibility and will produce the same result. Karen
says that if you break tasks into pieces that are too small, you risk over-managing the work
and spending more time on monitoring than actually performing the tasks. As a member of
the team, would you tend to agree more with Ann or Karen? What are the pros and cons
of each approach?
3.3.4 Factors Affecting Duration

When developing duration estimates, project managers consider four factors:
1. Project size
2. Human resources
3. Experience with similar projects
4. Constraints
PROJECT SIzE: As described in Chapter 1, information systems have various charac-

teristics that affect their complexity and cost. In addition to considering those factors,
a project manager must estimate the time required to complete each project phase.
To develop accurate estimates, a project manager must identify all project tasks, from
initial fact-finding to system implementation. Regardless of the systems development
methodology used, the project manager must determine how much time will be needed
to perform each task. In developing an estimate, the project manager must allow time
for meetings, project reviews, training, and any other factors (e.g., scheduled vacations
or unscheduled medical leave) that could affect the productivity of the development
team.
HUMAN RESOURCES: Companies must invest heavily in cutting-edge technology

to remain competitive in a connected world. In many areas, skilled IT professionals
are in great demand, and firms must work hard to attract and retain the talent they
need. A project manager must assemble and guide a development team that has the
skill and experience to handle the project. If necessary, additional systems analysts or
programmers must be hired or trained, and this must be accomplished within a spe-
cific time frame. After a project gets under way, the project manager must deal with
turnover, job vacancies, and escalating salaries in the technology sector—all of which
can affect whether the project can be completed on time and within budget. The proj-
ect manager also has to accommodate official holidays, family emergencies, and other
events that may affect the schedule.
EXPERIENCE WITH SIMILAR PROJECTS: A project manager can develop time and
cost estimates based on the resources used for similar, previously developed informa-
tion systems. The experience method works best for small- or medium-sized projects
where the two systems are similar in size, basic content, and operating environment.
In large systems with more variables, the estimates are less reliable.
CONSTRAINTS: Chapter 2 explained that constraints are defined during the pre-
liminary investigation. A constraint is a condition, restriction, or requirement that
the system must satisfy. For example, a constraint might involve maximums for one
or more resources, such as time, dollars, or people. A project manager must define
system requirements that can be achieved realistically within the required constraints.
In the absence of constraints, the project manager simply calculates the resources
needed. However, if constraints are present, the project manager must adjust other
resources or change the scope of the project. This approach is similar to the what-if
analysis described in Chapter 12.
CASE In POInT 3.2: SUNRISE SOFTWARE
A lively discussion is under way at Sunrise Software, where you are a project manager.The
main question is whether the person-days concept has limitations. In other words, if a task will
require 100 person-days, does it matter whether two people in 50 days, five people in 20 days,
10 people in 10 days, or some other combination that adds up to 100 performs the work?
Programmers Paula and Ethan seem to think it does not matter. On the other hand,
Hector, a systems analyst, says it is ridiculous to think that any combination would work. To
support his point, he offers this extreme example: Could 100 people accomplish a task esti-
mated at 100 person-days in one day?
Is Hector correct? If so, what are the limits in the “people versus days” equation? Taking
the concept a step further, is there an optimum number of people to be assigned to a task?
If so, how would that number be determined? You need to offer some guidance at the next
project team meeting. What will you say?
78 3.4 Identifying Task Patterns
3.3.5 Displaying the Work Breakdown Structure

After the task durations are entered, the work breakdown structure will look like
Figure 3-8. Task groups can be used to manage a complex project with many tasks, just as
with a Gantt chart, to simplify the list. Note that the WBS shown in Figure 3-8 is still

No. (Days) Tasks
1 Reserve the meeting room 1
2 Order the marketing materials 9
3 Brief the managers 2
4 Send out customer emails 3
5 Burn sample DVDs 3
6 Load the new software 2
7 Do a dress rehearsal 1
FIGURE 3-8 Task durations have been added, and the WBS is complete except for
predecessor task information. The predecessor tasks will determine task patterns and
sequence of performance.
incomplete: It does not show fields such as Start Date, End Date, Task Name, Duration,
and Predecessors—fields that can be key for project managers. With Microsoft Project,
the WBS (including some of these missing fields) might resemble Figure 3-9.
FIGURE 3-9 This Microsoft Project screen displays the same WBS, including task number, task name,
duration, and predecessor tasks.
3.4 IDENTIFYING TASK PATTERNS

Tasks in a work breakdown structure must be arranged in a logical sequence called a
task pattern. This section explains how to understand and create graphical models of
these patterns.
3.4.1 Task Patterns

In any project, large or small, tasks depend on each other and must be performed in a
sequence, not unlike the commands in a software program. Task patterns can involve
dependent tasks, multiple successor tasks, and multiple predecessor tasks. In larger
3.4 Identifying Task Patterns 79
projects, these patterns can be very complex, and an analyst must study TASK BOX FORMAT
the logical flow carefully.
Task Name
3.4.2 Using Task Boxes to Create a Model
In a PERT/CPM chart, project tasks are shown as rectangular boxes,
arranged in the sequence in which they must be performed. Each Start Day/Date Task ID
rectangular box, called a task box, has five sections, as shown in Finish Day/Date Task Duration
Figure 3-10. Each section of the task box contains important inf-
ormation about the task, including the Task Name, Task ID, Task FIGURE 3-10 Each section of the task
Duration, Start Day/Date, and Finish Day/Date. box contains important information
about the task, including the Task Name,
TASK NAME: The task name should be brief and descriptive, but it Task ID, Task Duration, Start Day/Date,
and Finish Day/Date.
does not have to be unique in the project. For example, a task named
Conduct Interviews might occur in several phases of the project.
TASK ID: The task ID can be a number or code that provides unique
identification.
TASK DURATION: The duration is the amount of time it will take to complete a
task, which is not necessarily the same as the elapsed time. For example, a task that
takes eight hours of effort to complete would be done in one day by a person dedi-
cated 100%, but if the person assigned this task is only working 50% on this project,
the task would take two days elapsed time to complete. All tasks must use the same
time units, which can be hours, days, weeks, or months, depending on the project. An
actual project starts on a specific date, but can also be measured from a point in time,
such as Day 1.
START DAY/DATE: The start day/date is the time that a task is scheduled to begin.
For example, suppose that a simple project has two tasks: Task 1 and Task 2. Also
suppose that Task 2 cannot begin until Task 1 is finished. An analogy might be that a
program cannot run until the computer is turned on. If Task 1 begins on Day 1 and
has duration of three days, it will finish on Day 3. Because Task 2 cannot begin until
Task 1 is completed, the start time for Task 2 is Day 4, which is the day after Task 1
is finished.
FINISH DAY/DATE: The finish day/date is the time that a task

is scheduled for completion. To calculate the finish day or date,
add the duration to the start day or date. When doing this, be
very careful not to add too many days. For example, if a task
starts on Day 10 and has duration of 5 days, then the finish
would be on Day 14—not Day 15.
3.4.3 Task Patterns

A project is based on a pattern of tasks. In a large project the
overall pattern would be quite complex, but it can be broken
down into three basic patterns: dependent tasks, multiple suc-
cessor tasks, and multiple predecessor tasks.
FIGURE 3-11 In a relay race, each runner is
dependent on the preceding runner and cannot
DEPENDENT TASKS: When tasks must be completed one start until the earlier finishes.
after another, like the relay race shown in Figure 3-11, they William Perugini/Shutterstock.com
80 3.4 Identifying Task Patterns
EXAMPLE OF A DEPENDENT TASK are called dependent tasks because one de-
pends on the other. For example, Figure 3-12
Prepare Outline Create Document shows that Task 2 depends on Task 1, because
Task 2 cannot start until Task 1 is completed.
Start: Day 1 ID: 1 Start: Day 6 ID: 2 In this example, the finish time of Task 1, Day
Finish: Day 5 Dur: 5 Finish: Day 14 Dur: 9 5, controls the start date of Task 2, which is
Day 6.
FIGURE 3-12 This example of a dependent task shows that the
finish time of Task 1, Day 5 controls the start date of Task 2, which is MULTIPLE SUCCESSOR TASKS: When
Day 6. several tasks can start at the same time, each
is called a concurrent task. Often, two or
more concurrent tasks depend on a single
prior task, which is called a predecessor
task. In this situation, each concurrent task
is called a successor task. In the example
EXAMPLE OF MULTIPLE SUCCESSOR TASKS shown in Figure 3-13, successor Tasks 2
and 3 both can begin as soon as Task 1 is
finished. Notice that the finish time for Task
Arrange
IdentifyInterviews
Needs
1 determines the start time for both Tasks
2 and 3. In other words, the earliest that
Start: Day 31 2
ID: 3 Task 1 can finish is Day 30, so Day 31 is the
Develop Plan
earliest that Tasks 2 and 3 can start.
60
Finish: Day 35 30
Dur: 5
Start: Day 1 ID: 1 MULTIPLE PREDECESSOR TASKS: Suppose

Finish: Day 30 Dur: 30 that a task requires two or more prior tasks to
Design Survey
be completed before it can start. Figure 3-14
shows that example because Task 3 cannot
Start: Day 31 ID: 3 begin until Tasks 1 and 2 are both completed.
Finish: Day 40 Dur: 10 Since the two tasks might not finish at the
same time, the longest (latest) predecessor
FIGURE 3-13 This example of multiple successor tasks shows that the task becomes the controlling factor. Notice
finish time for Task 1 determines the start time for both Tasks 2 and 3. that the start for Task 3 is Day 16, not Day
6. Why is this so? Because Task 3 depends on
two predecessor tasks, Tasks 1 and 2, Task
3 cannot begin until the later of those tasks
is complete. Therefore, the start time for a
EXAMPLE OF MULTIPLE PREDECESSOR TASKS successor task must be the latest (largest)
finish time for any of its preceding tasks.
Obtain Authorization In the example shown, Task 1 ends on Day
15, while Task 2 ends on Day 5, so Task 1
Start: Day 1 ID: 1 controls the start time for Task 3.
Conduct Interviews
Finish: Day 15 Dur: 15
3.4.4 Identifying Task Patterns
Start: Day 16 ID: 3 Task patterns are identified by looking care-
Create Job Description
Finish: Day 45 Dur: 30 fully at the wording of the task statement.
Words like then, when, or and are action
Start: Day 1 ID: 2
words that signal a sequence of events. Here
Finish: Day 5 Dur: 5 are three simple examples:
FIGURE 3-14 This example of multiple predecessor tasks shows • Do Task 1, then do Task 2 describes
that the start time for a successor task must be the latest (largest) dependent tasks that must be completed
finish time for any of its preceding tasks. In the example shown, Task 1 one after the other.
ends of Day 15, while Task 2 ends on Day 5, so Task 1 controls the
start time for Task 3.
3.5 Calculating the Critical Path 81
• When Task 2 is finished, start two tasks: Task 3 and Task 4 describes multiple
successor tasks that can both start as soon as Task 2 is finished.
• When Tasks 5 and 6 are done, start Task 7 indicates that Task 7 is a multiple
predecessor task because it cannot start until two or more previous tasks all are
completed.
3.4.5 Working with Complex Task Patterns

When several task patterns combine, the facts must be studied very carefully to
understand the logic and sequence. A project schedule will not be accurate if the
underlying task pattern is incorrect. For example, consider the following three fact
statements and the task patterns they represent. Examples of the task patterns are
shown in Figure 3-15, Figure 3-16, and Figure 3-17.
6
1 2
1 2 4
FIGURE 3-15 Dependent tasks. FIGURE 3-16 Dependent tasks and multiple successor tasks.
3 7
6
1 2 8
FIGURE 3-17 Dependent tasks, multiple successor tasks, and multiple predecessor tasks.
DEPENDENT TASKS: Perform Task 1. When Task 1 is complete, perform Task 2.
DEPENDENT TASKS AND MULTIPLE SUCCESSOR TASKS: Perform Task 1. When

Task 1 is complete, perform Task 2. When Task 2 is finished, start two tasks: Task 3 and
Task 4. When Task 3 is complete, start two more tasks: Task 5 and Task 6.
DEPENDENT TASKS, MULTIPLE SUCCESSOR TASKS, AND MULTIPLE

PREDECESSOR TASKS: Perform Task 1. When Task 1 is complete, perform
Task 2. When Task 2 is finished, start two Tasks: Task 3 and Task 4. When Task 3
is complete, start two more tasks: Task 5 and Task 6. When Tasks 5 and 6 are done,
start Task 7. Then, when Tasks 4 and 7 are finished, perform Task 8.
3.5 CALCULATING THE CRITICAL PATH

Task patterns determine the order in which the tasks are performed. Once the task
sequence has been defined, a project manager can schedule the tasks and calculate the
critical path.
82 3.5 Calculating the Critical Path
3.5.1 Critical Path

A critical path is a series of tasks that, if delayed, would affect the completion date of
the overall project. If any task on the critical path falls behind schedule, the entire
project will be delayed. For example, suppose that Joan and Jim are invited to some-
one’s home for dinner. Joan arrives on time, but Jim arrives 30 minutes late. Jim’s
arrival is part of the critical path because the host does not want to start without him,
so the meal will be served 30 minutes later than originally planned.
Project managers always must be aware of the critical path, so they can respond
quickly to keep the project on track. Microsoft Project and other project management
software can highlight the series of tasks that form the critical path.
3.5.2 Calculating the Critical Path

Figure 3-18 shows a training project with five tasks. Notice that the analyst has
arranged the tasks and entered task names, IDs, and durations. The task patterns
should be reviewed first. In this example, Task 1 is followed by Task 2, which is a
dependent task. Task 2 has two successor tasks: Task 3 and Task 4. Tasks 3 and 4 are
predecessor tasks for Task 5.
The next step is to determine start and finish dates, which will determine the criti-
cal path for the project. The following explanation outlines a step-by-step process.
The result is shown in Figure 3-19.
Plan Training
ID: 3
Dur: 5
Obtain Authorization Hire Analyst Announce Training
ID: 1 ID: 2 ID: 5

Dur: 10 Dur: 30 Arrange Logistics Dur: 30
ID: 4
Dur: 25
FIGURE 3-18 Example of a PERT/CPM chart with five tasks. Task 2 is a dependent task that has multiple successor tasks. Task 5 has
multiple predecessor tasks. In this figure, the analyst has arranged the tasks and entered task names, IDs, and durations.
Plan Training
Start: Day 41 ID: 3

Obtain Authorization Hire Analyst Announce Training
Start: Day 1 ID: 1 Start: Day 11 ID: 2 Start: Day 66 ID: 5

Finish: Day 10 Dur: 10 Finish: Day 40 Dur: 30 Arrange Logistics Finish: Day 95 Dur: 30
Start: Day 41 ID: 4

CRITICAL PATH:1-2-4-5 Finish: Day 65 Dur: 25
FIGURE 3-19 Now the analyst has entered the start and finish times, using the rules explained in this section. Notice that the
overall project has duration of 95 days.
3.6 Project Monitoring and Control 83
• Task 1 starts on Day 1 and has duration of 10 days, so the finish date is Day 10.
• Task 2, which is dependent on Task 1, can start on Day 11—the day after
Task 1 ends. With duration of 30 days, Task 2 will end on Day 40.
• Tasks 3 and 4 are multiple successor tasks that can start after Task 2 is done.
Task 2 ends on Day 40, so Tasks 3 and 4 both can start on Day 41. Task 3 has
duration of 5 days, and will end on Day 45. Task 4 has duration of 25 days,
and will not end until Day 65.
• Task 5 depends on Tasks 3 and 4, which are multiple predecessors. Because
Task 5 depends on both tasks, it cannot start until the later of the two tasks is
complete. In this example, Task 3 ends earlier, but Task 4 will not be completed
until Day 65, so Task 5 cannot start until Day 66.
Recall that the critical path is a series of tasks that, if delayed, would affect
the final completion date of the overall project. In this example, Tasks 1 and 2
are the first tasks on the critical path. Now look at Task 5, which cannot start
until both Tasks 3 and 4 are done. In this case, Task 4 is the controlling factor
because Task 4 finishes on Day 65, which is 20 days later than Task 3, which is
completed on Day 45. Therefore, the start date for Task 5 is determined by the
finish date for Task 4.
In contrast, Task 3 has slack time, and could be delayed up to 20 days without
affecting Task 5. Slack time is the amount of time that the task could be late without
pushing back the completion date of the entire project. Tasks 1, 2, 4, and 5 represent
the critical path, which is highlighted with red arrows in Figure 3-19.
3.6 PROJECT MONITORING AND CONTROL

Regardless of whether the project was planned and scheduled with project manage-
ment software or in some other manner, the project manager must keep track of the
tasks and progress of team members, compare actual progress with the project plan,
verify the completion of project milestones, and set standards and ensure that they are
followed.
3.6.1 Monitoring and Control Techniques

To help ensure that quality standards are met, many project managers institute struc-
tured walk-throughs. A structured walk-through is a review of a project team mem-
ber’s work by other members of the team. Generally, systems analysts review the
work of other systems analysts, and programmers review the work of other program-
mers, as a form of peer review. Structured walk-throughs take place throughout the
SDLC and are called design reviews, code reviews, or testing reviews, depending on
the phase in which they occur.
3.6.2 Maintaining a Schedule

Maintaining a project schedule can be challenging, and most projects run into at least
some problems or delays. By monitoring and controlling the work, the project man-
ager tries to anticipate problems, avoid them or minimize their impact, identify poten-
tial solutions, and select the best way to solve the problem.
The better the original plan, the easier it will be to control the project. If clear,
verifiable milestones exist, it will be simple to determine if and when those targets are
84 3.7 Reporting
achieved. If enough milestones and frequent checkpoints exist, problems will be

detected rapidly. A project that is planned and scheduled with PERT/CPM or in a
WBS with Gantt chart can be tracked and controlled using these same techniques. As
work continues, the project manager revises the plan to record actual times for
completed tasks and revises times for tasks that are not yet finished.
Project managers spend most of their time tracking the tasks along the critical
path because delays in those tasks have the greatest potential to delay or jeopardize
the project. Other tasks cannot be ignored, however. For example, suppose that a task
not on the critical path takes too long and depletes the allotted slack time. At that
point, the task actually becomes part of the critical path, and any further delay will
push back the overall project.
3.7 REPORTING
Members of the project team regularly report their progress to the project manager,
who in turn reports to management and users. The project manager collects, verifies,
organizes, and evaluates the information he or she receives from the team. Then the
manager decides which information needs to be passed along, prepares a summary
that can be understood easily, adds comments and explanations if needed, and sub-
mits it to management and users.
3.7.1 Project Status Meetings

Project managers, like the one shown in Figure 3-20, schedule regular meetings to
update the team and discuss project status, issues, problems, and opportunities.
Although meetings can be time consuming, most project managers believe they are
FIGURE 3-20 Project managers schedule regular meetings to update the project team and discuss
project status, issues, problems, and opportunities
Hero Images/Getty Images
3.8 Project Management Examples 85
worth the effort. The sessions give team members an opportunity to share informa-
tion, discuss common problems, and explain new techniques. The meetings also give
the project manager an opportunity to seek input and conduct brainstorming
sessions.
3.7.2 Project Status Reports

A project manager must report regularly to his or her immediate supervisor, upper
management, and users. Although a progress report might be given verbally to an
immediate supervisor, reports to management and users usually are written. Gantt
charts often are included in progress reports to show project status graphically.
Deciding how to handle potential problems can be difficult. At what point should
management be informed about the possibility of cost overruns, schedule delays, or
technical problems? At one extreme is the overly cautious project manager who alerts
management to every potential snag and slight delay. The danger here is that the man-
ager loses credibility over a period of time, and management might ignore potentially
serious situations. At the other extreme is the project manager who tries to handle all
situations single-handedly and does not alert management until a problem is serious.
By the time management learns of the problem, little time might remain in which to
react or devise a solution.
A project manager’s best course of action lies somewhere between the two
extremes, but is probably closer to the first. If the consequences are unclear, the ana-
lyst should err on the side of caution and warn management about the possibility of a
problem.
When the situation is reported, explain what is being done to handle and monitor
the problem. If the situation is beyond the analyst’s control, suggest possible actions
that management can take to resolve the situation. Most managers recognize that
problems do occur on most projects; it is better to alert management sooner rather
than later.
3.8 PROJECT MANAGEMENT EXAMPLES

These examples can be used to practice the
skills described in this chapter. The examples No. (Days) Tasks
also illustrate the use of project management
1 Develop Plan 1 -
software to help manage and display tasks.
2 Assign Tasks 4 1
3 Obtain Hardware 17 1
3.8.1 PERT/CPM Examples
4 Programming 70 2
Figure 3-21 shows a work breakdown struc-
5 Install Hardware 10 3
ture with 11 tasks. The example is more com-
plex than previous ones, but the same 6 Program Test 30 4
guidelines apply. Notice that each task has an 7 Write User Manual 25 5
ID, a description, duration, and a reference to 8 Convert Files 20 5
predecessor tasks, if any, which must be com- 9 System Test 25 6
pleted before the task can begin. Also notice 10 User Training 20 7, 8
that dependent tasks can have one predecessor
11 User Test 25 9,10
task, or several. A PERT/CPM chart can be
constructed from this task list in a two-step FIGURE 3-21 Example of a work breakdown structure listing 11 tasks,
process: together with their descriptions, durations, and predecessor tasks.
86 3.8 Project Management Examples
STEP 1: DISPLAY THE TASKS AND TASK PATTERNS: In the first step, as shown in
Figure 3-22, identify the tasks, determine task dependencies, and enter the task name,
ID, and duration. Notice that this example includes dependent tasks, multiple succes-
sor tasks, and multiple predecessor tasks.
TRANSFORMING A TASK LIST: STEP 1
Assign Tasks Programming Program Test System Test
ID: 2 ID: 4 Start: Day 76 ID: 6 ID: 9

Dur: 4 Dur: 70 Dur: 30 Dur: 25
Develop Plan User Test
ID: 1 Write User Manual ID: 11

Dur: 1 Dur: 25
ID: 7
Dur: 25
Obtain Hardware Install Hardware User Training
ID: 3 ID: 5 ID: 10

Dur: 17 Dur: 10 Convert Files Dur: 20
ID: 8
Dur: 20
FIGURE 3-22 To transform a task list into a PERT/CPM chart, you first enter the task name, ID, duration, and predecessors for each
task. Notice that this example includes dependent tasks, tasks with multiple successors, and tasks with multiple predecessors.
STEP 2: ENTER START AND FINISH TIMES: In the second step, as shown Figure 3-23,
enter the start and finish times by applying the guidelines in this section. For example,
Task 1 has a one-day duration, so the start and finish times for Task 1 are entered
as Day 1.Then enter Day 2 as the start time for successor Tasks 2 and 3. Continuing
from left to right, add the task duration for each task to its start time to determine its
finish time.
Assign Tasks Programming Program Test System Test
Start: Day 2 ID: 2 Start: Day 6 ID: 4 Start: Day 76 ID: 6 Start: Day 106 ID: 9
Finish: Day 5 Dur: 4 Finish: Day 75 Dur: 70 Finish: Day 105 Dur: 30 Finish: Day 130 Dur: 25
Develop Plan User Test
Start: Day 1 ID: 1 Write User Manual Start: Day 131 ID: 11
Finish: Day 1 Dur: 1 Finish: Day 155 Dur: 25
Start: Day 29 ID: 7
Obtain Hardware Install Hardware User Training
Start: Day 2 ID: 3 Start: Day 19 ID: 5 Start: Day 54 ID: 10

Finish: Day 18 Dur: 17 Finish: Day 28 Dur: 10 Convert Files Finish: Day 73 Dur: 20
Start: Day 29 ID: 8

FIGURE 3-23 To complete the PERT/CPM chart, you apply the guidelines explained in this section. For example, Task 1 has a one-day
duration, so you enter the start and finish for Task 1 as Day 1. Then you enter Day 2 as the start for successor Tasks 2 and 3.
3.9 Project Management Software 87
There are three important rules to must keep in mind during this process:
1. If a successor task has more than one predecessor task, use the latest finish time
of the predecessor tasks to determine the start time for the successor task.
2. If a predecessor task has more than one successor task, use the predecessor
task’s finish time to determine the start time for all successor tasks.
3. Continuing from left to right, add the task duration for each task to its start
time to determine and enter its finish time. Again, be very careful not to add
too many days. For example, if a task starts on Day 10 and has duration of five
days, then the finish would be Day 14—not Day 15.
When all the start and finish times have been entered, it is determined that the
project will be completed on Day 155. Also, note that Tasks 1, 2, 4, 6, 9, and 11 rep-
resent the critical path shown by the red arrows.
3.9 PROJECT MANAGEMENT SOFTWARE

Project managers use software applications to help plan, schedule, monitor, and
report on a project. Most programs offer features such as PERT/CPM, Gantt charts,
resource scheduling, project calendars, and cost tracking. As shown in Figure 3-24,
Microsoft Project is a full-featured program
that holds the dominant share of the market.
It is available as a software product for
Windows and as an online service as part of
Microsoft’s Office 365.
Irrespective of which project manage-
ment tool used, a step-by-step process is
followed to develop a WBS, work with
task patterns, and analyze the critical path.
The main difference is that the software
does most of the work automatically,
which enables much more effective
management.
The following sections explain how
Microsoft Project could be used to handle FIGURE 3-24 Microsoft Project.
Source: Microsoft Corporation
the sample task summary for a prelimi-
nary investigation shown in Figure 3-25.
This example illustrates that project management is dynamic and challenging.
One significant advantage of integrated project management software is that it
allows the project manager to adjust schedules, estimates, and resource assign-
ments rapidly to response to real-world events.
WORK BREAKDOWN STRUCTURE: Creating a work breakdown structure using

Microsoft Project is much the same as creating it manually. The tasks, durations, and
task patterns must still be identified. This information might have to be developed, or
a task summary like the one in Figure 3-25 might be used. The goal is to document
all tasks, dependencies, dates, and total project duration. The first step is to create a
Gantt chart showing the necessary information. As the information for each task is
entered into Microsoft Project, the duration and the predecessor tasks, if any, should
also be noted.
88 3.9 Project Management Software
Please study the following task summary:
• First, we need to spend one day studying potential problems or opportunities.

• Then, we will define the project scope and constraints. That will take two days.
• Next, we will analyze the organization charts. That will take one day.
• After we analyze the charts, four fact-finding tasks can start at once:
❍ Observe operations (two days)
❍ Conduct a user survey (three days)
❍ Conduct interviews (two days)
❍ Review documentation (one day)
• When all four fact-finding tasks are finished, we will spend one day evaluating feasibilty.
• Then we will spend one day presenting the results and recommendations to management.
FIGURE 3-25 A sample task summary for a preliminary investigation.
GANTT CHART: As tasks are entered, the program automatically performs the cal-
culations, detects the task patterns, and creates a Gantt chart. The chart consists of
horizontal bars, connected with arrows that indicate task dependencies. If a typical
workweek is selected, tasks will not be scheduled on Saturdays and Sundays. How-
ever, for a mission-critical project, a 24/7 calendar might be created. Whatever is
specified, the program will handle the tasks accordingly. Microsoft Project offers nu-
merous choices of display settings, formats, and calculation methods.
NETWORK DIAGRAM: After the Gantt chart is completed, the data can be viewed
in the form of a Microsoft Project network diagram, which is similar to a PERT
chart. When the Network Diagram option is selected, the project tasks, dependencies,
and a start and finish date for each task are shown. A network diagram displays the
same information as the Gantt chart, including task dependencies, but use task boxes
to include much more detail. Using Microsoft Project, each task can be assigned to
one or more people, budgets can be assigned targets, progress reports produced, and
schedules and deadlines readjusted as necessary.
CALENDAR VIEW: Calendar view is a good way to manage day-to-day activity.

This view shows the tasks, similar to a PERT chart, as an overlay on the actual calen-
dar. Because the critical path is highlighted in red, it is easy for a project manager to
determine priorities at any point in time.
Suppose the project manager wants to view the preliminary investigation in Figure
3-25 as a Gantt chart, a PERT chart, and a day-to-day calendar. All three views are
shown in Figure 3-26. Each view shows the tasks, the timing, the dependencies, and
the critical path. Notice that of the four tasks scheduled for September 25, only the
user survey is on the critical path, therefore that should be the project manager’s pri-
mary concern.
In addition to Microsoft Project, there are a number of other project management
tools available. For example, GanttProject is a free open source Java-based project
management tool that is available on multiple platforms (Windows, Mac OS X, and
Linux). It can produce Gantt charts, PERT/CPM charts, calculate the critical path
automatically, and read/write Microsoft Project files. Figure 3-27 shows GanttProject
displaying a Gantt chart for the same information shown by Microsoft Project in
Figure 3-26.
3.9 Project Management Software 89
Gantt Chart View
PERT Chart View
Calendar View
FIGURE 3-26 Notice how each view displays the project and highlights the critical path. If you were the
project manager on September 25, your primary concern should be conducting the user survey.
FIGURE 3-27 GanttProject is a free open source Java-based program. The

Gantt chart shown here represents the same information shown by Microsoft
Project in Figure 3-26.
Courtesy of GanttProject Team
90 3.9 Project Management Software
Gantter is a free cloud-based project management tool. It runs in a browser win-

dow, so there is no software to install to use it. Figure 3-28 shows Gantter displaying
a Gantt chart with the same information shown by GanttProject in Figure 3-27 and
by Microsoft Project in Figure 3-26.
Apptivo and smartsheet are other examples of web-based project management
tools offering similar capabilities, but on a paid subscription model.
The websites for all of these tools have more information about their capabilities,
including demos, trial versions (where applicable), and training material.
FIGURE 3-28 Gantter is a free cloud-based project management tool. The Gantt chart shown here represents
the same information shown by GanttProject in Figure 3-27 and by Microsoft Project in Figure 3-26.
Source: Courtesy of InQuest Technologies, Inc.
CASE In POInT 3.3: CENSUS 2010
Just before the 2010 census, the U.S. Commerce Department canceled a plan to acquire
500,000 handheld computers they had ordered to tabulate data. According to Commerce
Secretary Carlos Gutierrez, costs had skyrocketed. He blamed the problem on “a lack of
effective communications with one of our major suppliers.”
Apparently, there was plenty of blame to go around. Secretary Gutierrez noted that the
Census Bureau had submitted numerous technical changes to the vendor, Harris
Corporation. This greatly increased the cost and the complexity of the devices. Gutierrez
stated, “The Census Bureau was unaccustomed to working with an outside vendor on such
a large contract.” He also pointed out that the vendor had submitted an initial estimate of
$36 million to operate a help desk to assist census-takers, but that figure had jumped to
$217 million. “It was a bad estimate. I can’t think of a better way to say it. Harris gave us the
number. We accepted it. It was totally underestimated.”
What can be learned from the failure of this project, and could it have been prevented?
Suppose you were asked to head up a similar project. What would you do to prevent a sim-
ilar outcome?
3.10 Risk Management 91
3.10 RISK MANAGEMENT

Every IT project involves risks that systems analysts and project managers must
address. A risk is an event that could affect the project negatively. Risk management is
the process of identifying, analyzing, anticipating, and monitoring risks to minimize
their impact on the project.
3.10.1 Steps in Risk Management

The first step in risk management is to develop a specific plan. Although project man-
agement experts differ with regard to the number of steps or phases, a basic list
would include the following tasks:
• Develop a risk management plan. A risk management plan includes a review of
the project’s scope, stakeholders, budget, schedule, and any other internal or
external factors that might affect the project. The plan should define project
roles and responsibilities, risk management methods and procedures, categories
of risks, and contingency plans.
• Identify the risks. Risk identification lists each risk and assesses the likelihood
that it could affect the project. The details would depend on the specific proj-
ect, but most lists would include a means of identification, and a brief descrip-
tion of the risk, what might cause it to occur, who would be responsible for
responding, and the potential impact of the risk.
• Analyze the risks. This typically is a two-step process: Qualitative risk analysis
and quantitative risk analysis. Qualitative risk analysis evaluates each risk by
estimating the probability that it will occur and the degree of impact. Project
managers can use a formula to weigh risk and impact values, or they can dis-
play the results in a two-axis grid. For example, a Microsoft Excel XY chart
can be used to display the matrix, as shown in Figure 3-29. In the chart, notice
High impact High impact

Low probability High probability
Medium impact
Medium probability
Low impact
High probability
Low impact
Low probability
FIGURE 3-29 You can use a Microsoft Excel XY Chart type to display a risk matrix that
shows risk probability and potential impact.
92 3.10 Risk Management
the various combinations of risk and impact ratings for the five sample values.
This tool can help a project manager focus on the most critical areas, where
risk probability and potential impact are high.
The purpose of quantitative risk analysis is to understand the actual impact in
terms of dollars, time, project scope, or quality. Quantitative risk analysis can involve
a modeling process called what-if analysis, which allows a project manager to vary
one or more element(s) in a model to measure the effect on other elements. This topic
is discussed in more detail in Chapter 12.
• Create a risk response plan. A risk response plan is a proactive effort to antici-
pate a risk and describe an action plan to deal with it. An effective risk
response plan can reduce the overall impact by triggering timely and appropri-
ate action.
• Monitor risks. This activity is ongoing throughout the risk management pro-
cess. It is important to conduct a continuous tracking process that can identify
new risks, notice changes in existing risks, and update any other areas of the
risk management plan.
3.10.2 Risk Management Software

Most project management software includes powerful features that allow a project
manager to assign specific dates as constraints, align task dependencies, note exter-
nal factors that might affect a task, track progress, and display tasks that are behind
schedule.
For example, the enterprise edition of Microsoft Project has a built-in risk man-
agement capability that can be used for large, corporate-wide projects. Microsoft
claims that the software can link risks with specific tasks and projects, specify
probability and impact, assign ownership, and track progress to manage projects
more efficiently. Microsoft’s risk management model includes the following
factors:
• Probability, which represents the likelihood that the risk will happen, expressed
as a percentage
• Impact, which indicates the degree of adverse effect should the risk occur, on a
scale of 1 to 10
• Cost, which indicates the potential financial impact of the risk
• Category, which specifies the risk type
• Description, which specifies the nature of the risk
• Mitigation plan, which identifies plans to control or limit the risk
• Contingency plan, which specifies actions to be taken if the risk occurs
• Trigger, which identifies a condition that would initiate the contingency
plan
Armed with this information, the IT team can quantify the project’s risks, just as
they use financial analysis tools to quantify costs and benefits.
In addition to Microsoft, other vendors offer risk management software. Some are
add-on packages that integrate with Microsoft Project to extend its capabilities.
Others are stand-alone applications that provide similar functionality to the core
Microsoft Project program.
3.11 Managing for Success 93
3.11 MANAGING FOR SUCCESS

To be successful, an information system must satisfy business requirements, stay
within budget, be completed on time, and—most important of all—be managed effec-
tively. When a project develops problems, the reasons typically involve business, bud-
get, or schedule issues, as explained in the following sections. In addition to planning
and managing the project, a project manager must be able to recognize these prob-
lems and deal with them effectively.
3.11.1 Business Issues

The major objective of every system is to provide a solution to a business problem or
opportunity. If the system does not do this, then it is a failure—regardless of positive
reaction from users, acceptable budget performance, or timely delivery. When the
information system does not meet business requirements, causes can include unidenti-
fied or unclear requirements, inadequately defined scope, imprecise targets, shortcuts
or sloppy work during systems analysis, poor design choices, insufficient testing or
inadequate testing procedures, and lack of change control procedures. Systems also
fail because of changes in the organization’s culture, funding, or objectives. A system
that falls short of business needs also produces problems for users and reduces
employee morale and productivity.
As explained in Chapter 2, projects without clear scope definitions are risky
because they tend to expand gradually, without specific authorization, in a process
called project creep. However, even when a project is clearly described, it must be
managed constantly.
3.11.2 Budget Issues

Cost overruns typically result from one or more of the following:
• Unrealistic estimates that are too optimistic or based on incomplete
information
• Failure to develop an accurate forecast that considers all costs over the life of
the project
• Poor monitoring of progress and slow response to early warning signs of
problems
• Schedule delays due to factors that were not foreseen
• Human resource issues, including turnover, inadequate training, and
motivation
3.11.3 Schedule Issues

Problems with timetables and project milestones can indicate a failure to recognize
task dependencies, confusion between effort and progress, poor monitoring and con-
trol methods, personality conflicts among team members, or turnover of project per-
sonnel. The failure of an IT project also can be caused by poor project management
techniques.
If the project manager fails to plan, staff, organize, supervise, communicate, moti-
vate, evaluate, direct, and control properly, then the project is certain to fail. Even
when factors outside his or her control contribute to the failure, the project manager
is responsible for recognizing the early warning signs and handling them effectively.
94 3.12 The Bottom Line
CASE In POInT 3.4: SPRING FORWARD PRODUCTS
After three years with the company, you recently were asked to manage several IT projects.
You are confident that you have the technical skills you need, but you are concerned about
morale at the company. There has been some downsizing, and many employees are worried
about the future.
As a longtime fan of the Dilbert cartoon strip, you know that maintaining morale can
be a real challenge. Your current project involves a team of a dozen people, several of
whom remind you of Dilbert and his coworkers. What are some techniques that you
might use to motivate the team and inspire its members? What are some things you might
not want to do?
3.12 THE BOTTOM LINE

Project management is a challenging task. Project managers must be alert, technically
competent, and highly resourceful. They also must be good communicators with
strong human resource skills. Project managers can be proud when they handle a suc-
cessful project that helps the company achieve its business objectives.
Unfortunately, projects can and do get derailed for a wide variety of reasons.
When problems occur, the project manager’s ability to handle the situation becomes
the critical factor. When a project manager first recognizes that a project is in trouble,
what options are available? Alternatives can include trimming the project require-
ments, adding to the project resources, delaying the project deadline, and improving
management controls and procedures. Sometimes, when a project experiences delays
or cost overruns, the system still can be delivered on time and within budget if several
less critical requirements are trimmed. The system can be delivered to satisfy the most
necessary requirements, and additional features can be added later as a part of a
maintenance or enhancement project.
If a project is in trouble because of a lack of resources or organizational support,
management might be willing to give the project more commitment and higher prior-
ity. For example, management might agree to add more people to a project that is
behind schedule. Adding staff, however, will reduce the project’s completion time only
if the additional people can be integrated effectively into the development team. If
team members lack experience with certain aspects of the required technology, tempo-
rary help might be obtained from IT consultants or part-time staff. Adding staff can
mean training and orienting the new people, however. In some situations, adding
more people to a project actually might increase the time necessary to complete the
project because of a principle called Brooks’ Law. Frederick Brooks, Jr., an IBM engi-
neer, observed that adding manpower to a late software project only makes it later.
Brooks reached this conclusion when he saw that new workers on a project first had
to be educated and instructed by existing employees whose own productivity was
reduced accordingly.
3.13 Chapter Summary 95
A QUESTIOn OF ETHICS
iStockphoto.com/faberfoto_it
“Better blow the whistle,” says Roy, your friend and project teammate at Final Four
Industries. “The project is out of control, and you know it!” “Maybe so,” you respond, “But
that’s not my call—I’m not the project manager.” What you do not say is that Stephanie,
the project manager, feels like her career is on the line and she is reluctant to bring bad
news to management at this time. She honestly believes that the project can catch up, and
says that a bad report on a major project could result in bad publicity for the firm and
frighten potential customers.
To be fair, the next management progress report is scheduled in three weeks. It is pos-
sible that the team could catch up, but you doubt it. You wonder if there is an ethical ques-
tion here: Even though the report is not due yet, should a significant problem be reported
to management as soon as possible? You are concerned about the issue, and you decide to
discuss it with Stephanie. What will you say to her?
3.13 CHAPTER SUMMARY

Project management is the process of planning, scheduling, monitoring, and reporting
on the development of an information system. Planning includes identifying all
project tasks and estimating the completion time and cost of each. Project scheduling
involves the creation of a specific timetable, usually in the form of charts that show
tasks, task dependencies, and critical tasks that might delay the project. Project
monitoring requires guiding, supervising, and coordinating the project team’s
workload. The project manager must monitor the progress, evaluate the results, and
take corrective action when necessary to control the project and stay on target.
Project reporting includes regular progress reports to management, users, and the
project team itself. Effective reporting requires strong communication skills and a
sense of what others want and need to know about the project. A successful project
must be completed on time, within budget, and deliver a quality product that satisfies
users and meets requirements.
A project triangle shows three legs: project cost, scope, and time. A project man-
ager must find the best balance among these elements because a change in any leg of
the triangle will affect the other two legs. Project management techniques can be used
throughout the SDLC.
Planning, scheduling, monitoring and reporting all take place within a larger proj-
ect development framework, which includes three key steps: creating a work break-
down structure, identifying task patterns, and calculating the critical path. A work
breakdown structure must clearly identify each task and include an estimated dura-
tion. A task, or activity, is any work that has a beginning and an end and requires the
use of company resources such as people, time, or money. Time and cost estimates for
tasks usually are made in person-days. A person-day represents the work that one
person can accomplish in one day. Estimating the time for project activities is more
difficult with larger systems. Project managers must consider the project size and
scope, IT resources, prior experience with similar projects or systems, and applicable
constraints. In addition to tasks, every project has events, or milestones. An event, or
milestone, is a recognizable reference point that can be used to monitor progress.
Task patterns establish the sequence of work in a project. Task patterns involve
dependent tasks, multiple successor tasks, and multiple predecessor tasks. In larger
projects, these patterns can be very complex.
96 3.13 Chapter Summary
A critical path is a series of tasks that, if delayed, would affect the completion date
of the overall project. If any task on the critical path falls behind schedule, the entire
project will be delayed. Tasks on the critical path cannot have slack time. To identify
the critical path, calculate the start and finish date for each task, which will determine
the critical path for the project.
In project scheduling, the project manager develops a specific time for each task,
based on available resources and whether or not the task is dependent on other pre-
decessor tasks. The manager can use graphical tools such as Gantt charts and PERT
charts to assist in the scheduling process.
A Gantt chart is a horizontal bar chart that represents the project schedule with
time on the horizontal axis and tasks arranged vertically. It shows individual tasks
and task groups, which include several tasks. In a Gantt chart, the length of the bar
indicates the duration of the tasks. A Gantt chart can display progress, but does not
show task dependency details or resource assignment unless the chart was created
with a project management program that supports dependency linking and the entry
of other information.
A PERT/CPM chart shows the project as a network diagram with tasks connected
by arrows. Using a prescribed calculation method, the project manager uses a PERT
chart to determine the overall duration of the project and provide specific informa-
tion for each task, including the task IDs, their durations, start and finish times, and
the order in which they must be performed. With this information, the manager can
determine the critical path, which is the sequence of tasks that have no slack time and
must be performed on schedule in order to meet the overall project deadline.
Most project managers use software applications such as Microsoft Project to
plan, schedule, and monitor projects. Project managers are responsible for risk man-
agement, which is the process of identifying, analyzing, anticipating, and monitoring
risks to minimize their impact on the project.
In the end, project management involves the same skills as any other management.
The project manager must be perceptive, analytical, well organized, and a good com-
municator. If the project manager senses that the project is off-track, he or she must
take immediate steps to diagnose and solve the problem. If the project manager fails
to plan, staff, organize, supervise, communicate, motivate, evaluate, direct, and con-
trol properly, then the project is certain to fail. Even when factors outside his or her
control contribute to the failure, the project manager is responsible for recognizing
the early warning signs and handling them effectively.
Key Terms 97
Key Terms
activity Any work that has a beginning and an end, and requires the use of company resources includ-
ing people, time, and/or money. Examples include conducting a series of interviews, designing a
report, selecting software, waiting for the delivery of equipment, and training users. See also task.
best-case estimate The most optimistic outcome.
bottom-up technique A method for analyzing a large, complex project as a series of individual tasks,
called project tasks.
Brooks’ Law Frederick Brooks, an IBM engineer, observed that adding more manpower to a late soft-
ware project only makes it later.
code review See structured walk-through.
concurrent task A task that can be completed at the same time as (in parallel with) another task.
critical path A series of events and activities with no slack time. If any activity along the critical path
falls behind schedule, the entire project schedule is similarly delayed. As the name implies, a critical
path includes all activities that are vital to the project schedule.
Critical Path Method (CPM) Shows a project as a network diagram. The activities are shown as vectors, and
the events are displayed graphically as nodes. Although CPM developed separately from the Program
Evaluation Review Technique (PERT), the two methods are essentially identical. See also PERT/CPM.
dependent task A task is said to be dependent when it has to be completed in a serial sequence.
design review See structured walk-through.
duration The amount of time it will take to complete a task.
event A reference point that marks a major occurrence. Used to monitor progress and manage a project.
See also milestone.
finish day/date The day or date when a task is scheduled to be finished.
Gantt chart A horizontal bar chart that illustrates a schedule. Developed many years ago by Henry L.
Gantt as a production control technique. Still are in common use today.
milestone A reference point that marks a major occurrence. Used to monitor progress and manage a
project. See also event.
network diagram A PERT chart also is referred to as a network diagram.
open source Software that is supported by a large group of users and developers. The source code is
made freely available.
person-day The amount of work that one person can complete in one day.
PERT/CPM The Program Evaluation Review Technique (PERT) was developed by the U.S. Navy to
manage very complex projects, such as the construction of nuclear submarines. At approximately the
same time, the Critical Path Method (CPM) was developed by private industry to meet similar project
management needs. The important distinctions between the two methods have disappeared over time,
and today the technique is called either PERT, CPM, or PERT/CPM.
predecessor task A single prior task upon which two or more concurrent tasks depend.
probable-case estimate The most likely outcome is called a probable-case estimate.
Program Evaluation Review Technique (PERT) See PERT/CPM.
project coordinator The person who handles administrative responsibilities for the development team
and negotiates with users who might have conflicting requirements or want changes that would
require additional time or expense.
project leader The person charged with leading a project from a technical perspective.
project management The process of planning, scheduling, monitoring, controlling, and reporting upon
the development of an information system.
project manager The person charged with managing a project from an administrative perspective.
98 Key Terms
project monitoring Guiding, supervising, and coordinating the project team’s workload.
project planning Identifying project tasks and estimating completion time and costs.
project reporting Providing regular progress reports to management, users, and the project team itself.
project scheduling The creation of a specific timetable to facilitate completion of a project. Also
involves selecting and staffing the project team and assigning specific tasks to team members.
project triangle The three major components of a project: cost, scope, and time. A project manager tries
to find the optimal balance among these factors.
qualitative risk analysis Evaluating risk by estimating the probability that it will occur and the degree
of impact.
quantitative risk analysis Evaluating risk in terms of the actual impact in terms of dollars, time, project
scope, or quality.
risk An event that could affect the project negatively.
risk identification Listing each risk and assessing the likelihood that it could affect a project.
risk management The process of identifying, evaluating, tracking, and controlling risks to minimize
their impact.
risk management plan Includes a review of the project’s scope, stakeholders, budget, schedule, and any
other internal or external factors that might affect the project. The plan should define project roles and
responsibilities, risk management methods and procedures, categories of risks, and contingency plans.
risk response plan A proactive effort to anticipate a risk and describe an action plan to deal with it. An
effective risk response plan can reduce the overall impact by triggering a timely and appropriate action.
slack time The amount of time by which an event can be late without delaying the project. The dif-
ference between latest completion time (LCT) and earliest completion time (ECT).
start day/date The day or date when a task is scheduled to begin.
structured walk-through A review of a project team member’s work by other members of the team.
Generally, systems analysts review the work of other systems analysts, and programmers review the
work of other programmers, as a form of peer review. Should take place throughout the SDLC and
are called requirements reviews, design reviews, code reviews, or testing reviews, depending on the
phase in which they occur.
successor task Each of the concurrent tasks of a predecessor task.
task Any work that has a beginning and an end, and requires the use of company resources including
people, time, and/or money. Examples include conducting a series of interviews, designing a report,
selecting software, waiting for the delivery of equipment, and training users. See also activity.
task box A component of a PERT/CPM chart that contains important scheduling and duration informa-
tion about a task. Each task in a project is represented by its own task box in the PERT/CPM chart.
task group A task that represents several activities.
task ID A number or code that uniquely identifies a task.
task name A brief descriptive name for a task, which does not have to be unique in the project. For
example, a task named Conduct Interviews might appear in several phases of the project.
task pattern A logical sequence of tasks in a work breakdown structure. Can involve sequential tasks,
multiple successor tasks, and multiple predecessor tasks.
testing review See structured walk-through.
weight An important multiplier that managers factor into estimates so they can be analyzed.
work breakdown structure (WBS) A project broken down into a series of smaller tasks. See also Gantt
chart; PERT/CPM chart.
worst-case estimate The most pessimistic outcome.
Chapter Exercises 99
Chapter Exercises
Questions
1. Write the script for a one-minute explanation of basic project management concepts.
2. What is a task? What is an event? What is a milestone?
3. What specific information do you need to create a work breakdown structure?
4. What are the three main task patterns? Provide an example of each.
5. Explain the differences between a Gantt chart and a PERT/CPM chart.
6. What formula can a project manager use to estimate task duration? Provide an example.
7. What is a common problem in calculating start and finish times? Provide an example.
8. Why is the critical path important? Why would a task be on the critical path?
9. Why is it important to deliver effective project reports and communications?
10. What is risk management, and why is it important? Provide an example.
Discussion Topics
1. In Poor Richard’s Almanac, Benjamin Franklin penned the familiar lines: “For the want of a nail the
shoe was lost, for the want of a shoe the horse was lost, for the want of a horse the rider was lost, for
the want of a rider the battle was lost, for the want of a battle the kingdom was lost—and all for the
want of a horseshoe nail.” Looking at the outcome in hindsight, could project management concepts
have avoided the loss of the kingdom? How?
2. Microsoft Project is powerful, but quite expensive. As a manager, how would you justify the purchase
of this software?
3. Suppose you want to manage a small project, but you do not have access to project management soft-
ware. Could you use a spreadsheet or database program instead? How?
4. Some managers believe that they have “seat of the pants” intuition and do not need project manage-
ment tools. Does that make sense to you? Why or why not?
5. Consider a scenario where a task is dependent on another task being started but not necessarily com-
pleted. For example, a project may depend on a task being started and 25% being completed before
the group could start their portion of the project. Do you think this situation occurs frequently in
systems analysis projects? Why or why not?
Projects
1. Think of all the tasks that you perform when you purchase a car. Include any research, decisions, or fi-
nancial issues that relate to the purchase. Create a work breakdown structure that shows all the tasks,
their estimated duration, and any predecessor tasks.
2. Perform an Internet research to learn more about project risk management, and write a summary of
the results. Be sure to search for the classic book titled Waltzing with Bears: Managing Risk on
Software Projects, by Tom Demarco and Timothy Lister.
3. Go to the websites for project management tools (besides Microsoft Project), such as Apptivo (www.
apptivo.com), GanttProject (www.ganttproject.biz), Gantter (www.gantter.com), and smartsheet
(www.smartsheet.com/product-tour/gantt-charts). Explore each program’s features and describe what
you like and do not like.
4. Describe three personal experiences where project management would have helped you avoid a prob-
lem or take advantage of an opportunity. Be specific.
5. Many of today’s projects involve team members scattered across different time zones and in differ-
ent physical locations. Moreover, the projects may have adopted an agile methodology, which reduces
cycle time dramatically. Write a brief report that summarizes some of the key differences a manager
would face managing this type of project, as opposed to a traditional project.

Sad Chapter 3 PDF

Uploaded by

Copyright:

Available Formats

Sad Chapter 3 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sad Chapter 3 PDF

Uploaded by

Copyright:

Available Formats

Chapter 3 Managing Systems Projects

LEARNING OBJECTIVES CHAPTER CONTENTS

3.2 Overview of Project Management 71

3.2 OVERVIEW OF PROJECT MANAGEMENT

3.2.1 What Shapes a Project?

Most successful project managers rely on personal experience,

communication ability, and resourcefulness. For example, if an

3.2.3 What Does a Project Manager Do?

3.3 CREATING A WORK BREAKDOWN STRUCTURE

3.3 Creating a Work Breakdown Structure 73

3.3.1 Gantt Charts

3.3.2 PERT/CPM Charts

be performed. For example, some tasks

3.3.3 Identifying Tasks in a Work Breakdown Structure

3.3 Creating a Work Breakdown Structure 75

FIGURE 3-6 The three versions show how to

Task Description Duration Predecessor

CASE In POInT 3.1: PARALLEL SERVICES

3.3.4 Factors Affecting Duration

PROJECT SIzE: As described in Chapter 1, information systems have various charac-

3.3 Creating a Work Breakdown Structure 77

HUMAN RESOURCES: Companies must invest heavily in cutting-edge technology

CASE In POInT 3.2: SUNRISE SOFTWARE

3.3.5 Displaying the Work Breakdown Structure

Task Description Duration Predecessor

3.4 IDENTIFYING TASK PATTERNS

3.4.1 Task Patterns

3.4 Identifying Task Patterns 79

FINISH DAY/DATE: The finish day/date is the time that a task

3.4.3 Task Patterns

Start: Day 1 ID: 1 MULTIPLE PREDECESSOR TASKS: Suppose

3.5 Calculating the Critical Path 81

3.4.5 Working with Complex Task Patterns

DEPENDENT TASKS: Perform Task 1. When Task 1 is complete, perform Task 2.

DEPENDENT TASKS AND MULTIPLE SUCCESSOR TASKS: Perform Task 1. When

DEPENDENT TASKS, MULTIPLE SUCCESSOR TASKS, AND MULTIPLE

3.5 CALCULATING THE CRITICAL PATH

3.5.1 Critical Path

3.5.2 Calculating the Critical Path

ID: 1 ID: 2 ID: 5

Start: Day 41 ID: 3

Start: Day 1 ID: 1 Start: Day 11 ID: 2 Start: Day 66 ID: 5

Start: Day 41 ID: 4

3.6 Project Monitoring and Control 83

3.6 PROJECT MONITORING AND CONTROL

3.6.1 Monitoring and Control Techniques

3.6.2 Maintaining a Schedule

achieved. If enough milestones and frequent checkpoints exist, problems will be

3.7.1 Project Status Meetings

3.8 Project Management Examples 85

3.7.2 Project Status Reports

3.8 PROJECT MANAGEMENT EXAMPLES

TRANSFORMING A TASK LIST: STEP 1

Assign Tasks Programming Program Test System Test

ID: 2 ID: 4 Start: Day 76 ID: 6 ID: 9

Develop Plan User Test

ID: 1 Write User Manual ID: 11

ID: 3 ID: 5 ID: 10

Assign Tasks Programming Program Test System Test