Project Management
CIS 486
Fall 2005
Week 2 Lecture
Dr. David Gadish
© 2004-05, David Gadish, Ph.D.
1
Week 1 Review
 My background
 Course outline
 Teaching philosophy, expectations
 Course structure
 Student survey
 Student introduction
© 2004-05, David Gadish, Ph.D.
2
Week 1 Review
 Information Technology in the Digital
Economy (Ch-1)
 The Harvard Case Studies
– Team selection and assignment of cases
© 2004-05, David Gadish, Ph.D.
3
Week 2 Overview
 Student Introductions
 The Project Management and Information
Technology Context (Ch-2)
 The Project Management Process Groups
(Ch-3)
© 2004-05, David Gadish, Ph.D.
4
Student Introductions
 Your name
 What you do?
 How do you currently use technology?
 What do you want to do?
 Technology impacts on your future plans?
© 2004-05, David Gadish, Ph.D.
5
The Project Management and
Information Technology
Context
Chapter 2
6
Learning Objectives
 Understand the systems view of project
management and how it applies to information
technology projects
 Analyze a formal organization using the
structural, human resources, political, and
symbolic organizational frames
 Explain the differences among functional, matrix,
and project organizational structures
 Explain why stakeholder management and top
management commitment are critical for a
project’s success
© 2004-05, David Gadish, Ph.D.
7
Learning Objectives
 Understand the concept, development,
implementation, and close-out phases of the
project life cycle
 Distinguish between project development
and product development
 Discuss the unique attributes and diverse
nature of information technology projects
 List the skills and attributes of a good
project manager in general and in the
information technology field
© 2004-05, David Gadish, Ph.D.
8
Projects Cannot Be Run
in Isolation
 Projects must operate in a broad
organizational environment
 Project managers need to take a holistic or
systems view of a project and understand
how it is situated within the larger
organization
© 2004-05, David Gadish, Ph.D.
9
A Systems View of Project
Management
 A systems approach emerged in the 1950s
to describe a more analytical approach to
management and problem solving
 Three parts include:
– Systems philosophy: View things as systems,
interacting components working within an
environment to fulfill some purpose
– Systems analysis: problem-solving approach
– Systems management: Address business,
technological, and organizational issues
before making changes to systems
© 2004-05, David Gadish, Ph.D.
10
Three Sphere Model for Systems
Management
© 2004-05, David Gadish, Ph.D.
11
Understanding Organizations
Structural frame:
Focuses on roles and
responsibilities,
coordination and control.
Organizational charts help
define this frame.
Human resources frame:
Focuses on providing
harmony between needs of
the organization and needs
of people.
Political frame:
Assumes organizations
are coalitions composed
of varied individuals and
interest groups. Conflict
and power are key issues.
Symbolic frame: Focuses
on symbols and meanings
related to events. Culture
is important.
© 2004-05, David Gadish, Ph.D.
12
What Went Wrong?
 Many enterprise resource planning (ERP)
projects fail due to organizational issues.
 For example, Sobey’s Canadian grocery store chain
abandoned its two-year, $90 million ERP system due to
organizational problems.
 Sobey’s ERP system shut down for five days and
employees were scrambling to stock potentially empty
shelves in several stores for weeks.
 The system failure cost Sobey’s more than $90 million
and caused shareholders to take an 82-cent after-tax hit
per share.*
© 2004-05, David Gadish, Ph.D.
13
Many Organizations Focus on the
Structural Frame
 Most people understand what organizational
charts are
 Many new managers try to change
organizational structure when other changes
are needed
 3 basic organizational structures
– functional
– project
– matrix
© 2004-05, David Gadish, Ph.D.
14
Basic Organizational Structures
© 2004-05, David Gadish, Ph.D.
15
Organizational Structure Influences
on Projects
The organizational structure influences the project manager’s authority.
© 2004-05, David Gadish, Ph.D.
16
Recognize the Importance of
Project Stakeholders
 Project stakeholders are the people involved in or
affected by project activities
 Project managers must take time to:
– Identify
– Understand
– Manage
relationships with all project stakeholders
 Using the four frames of organizations can help
meet stakeholder needs and expectations
 Senior executives are very important stakeholders
© 2004-05, David Gadish, Ph.D.
17
What Helps Projects Succeed?
 The following items help IT projects succeed, in
order of importance:
–
–
–
–
–
–
–
–
–
Executive support
User involvement
Experienced project manager
Clear business objectives
Minimized scope
Standard software infrastructure
Firm basic requirements
Formal methodology
Reliable estimates
© 2004-05, David Gadish, Ph.D.
18
Need for Top Management
Commitment
 Top management can help project
managers:
– Secure adequate resources
– Get approval for unique project needs in a
timely manner
– Receive cooperation from people throughout
the organization
– Learn how to be better leaders
© 2004-05, David Gadish, Ph.D.
19
Need for Organizational Commitment to
Information Technology (IT)
 If the organization has a negative attitude
toward IT, it will be difficult for an IT
project to succeed
 Having a Chief Information Officer (CIO)
at a high level in the organization helps IT
projects
 Assigning non-IT people to IT projects also
encourages more commitment
© 2004-05, David Gadish, Ph.D.
20
Need for Organizational
Standards
 Standards and guidelines help project
managers be more effective
 Senior management can encourage
– the use of standard forms and software for
project management
– the development and use of guidelines for
writing project plans or providing status
information
– the creation of a project management office or
center of excellence
© 2004-05, David Gadish, Ph.D.
21
Project Phases and the Project
Life Cycle
 A project life cycle is a collection of project
phases
 Project phases vary by project or industry,
but some general phases include
–
–
–
–
concept
development
implementation
support
© 2004-05, David Gadish, Ph.D.
22
Phases of the Project Life Cycle
© 2004-05, David Gadish, Ph.D.
23
Product Life Cycles
 Products also have life cycles
 The Systems Development Life Cycle (SDLC) is a
framework for describing the phases involved in
developing and maintaining information systems
 Systems development projects can follow
– predictive models: the scope of the project can be
clearly articulated and the schedule and cost can be
predicted
– adaptive models: projects are mission driven and
component based, using time-based cycles to meet
target dates
© 2004-05, David Gadish, Ph.D.
24
Predictive Life Cycle Models
 The waterfall model has well-defined, linear
stages of systems development and support
 The spiral model shows that software is developed
using an iterative or spiral approach rather than a
linear approach
 The incremental release model provides for
progressive development of operational software
 The prototyping model is used for developing
prototypes to clarify user requirements
 The RAD model is used to produce systems
quickly without sacrificing quality
© 2004-05, David Gadish, Ph.D.
25
Adaptive Life Cycle Models
 Extreme Programming (XP): Developers program
in pairs and must write the tests for their own code.
XP teams include developers, managers, and users
 Scrum: Repetitions of iterative development are
referred to as sprints, which normally last thirty
days. Teams often meet every day for a short
meeting, called a scrum, to decide what to
accomplish that day. Works best for objectoriented technology projects and requires strong
leadership to coordinate the work
© 2004-05, David Gadish, Ph.D.
26
Distinguishing Project Life
Cycles and Product Life Cycles
 The project life cycle applies to all projects,
regardless of the products being produced
 Product life cycle models vary considerably
based on the nature of the product
 Most large IT systems are developed as a
series of projects
 Project management is done in all of the
product life cycle phases
© 2004-05, David Gadish, Ph.D.
27
Why Have Project Phases and
Management Reviews?
 A project should successfully pass through
each of the project phases in order to
continue on to the next
 Management reviews (also called phase
exits or kill points) should occur after each
phase to evaluate the project’s progress,
likely success, and continued compatibility
with organizational goals
© 2004-05, David Gadish, Ph.D.
28
The Context of IT Projects
 IT projects can be very diverse in terms of
size, complexity, products produced,
application area, and resource requirements
 IT project team members often have diverse
backgrounds and skill sets
 IT projects use diverse technologies that
change rapidly.
– Even within one technology area, people must
be highly specialized
© 2004-05, David Gadish, Ph.D.
29
Fifteen Project Management Job
Functions
 Define scope of project
 Identify stakeholders,





decision-makers, and
escalation procedures
Develop detailed task list
(work breakdown structures)
Estimate time requirements
Develop initial project
management flow chart
Identify required resources
and budget
Evaluate project
requirements








Identify and evaluate risks
Prepare contingency plan
Identify interdependencies
Identify and track critical
milestones
Participate in project phase
review
Secure needed resources
Manage the change control
process
Report project status
© 2004-05, David Gadish, Ph.D.
30
Suggested Skills for Project
Managers
 Project managers need a wide variety of
skills
 Comfortable with change
 Understand the organizations they work in
and with
 Be able to lead teams to accomplish
project goals
© 2004-05, David Gadish, Ph.D.
31
Suggested Skills for Project
Managers
 Project managers need both “hard” and
“soft” skills.
 Hard skills include product knowledge and
knowing how to use various project
management tools and techniques
 Soft skills include being able to work with
various types of people
© 2004-05, David Gadish, Ph.D.
32
Suggested Skills for a Project Manager
 Communication skills: listening,
persuading
 Organizational skills: planning, goalsetting, analyzing
 Team Building skills: empathy,
motivation
© 2004-05, David Gadish, Ph.D.
33
Suggested Skills for a Project Manager
 Leadership skills: set examples, be
energetic, have vision (big picture),
delegate, be positive
 Coping skills: flexibility, creativity,
patience, persistence
 Technological skills: experience,
project knowledge
© 2004-05, David Gadish, Ph.D.
34
Most Significant Characteristics of Effective
and Ineffective Project Managers
Effective Project Managers
Ineffective Project Managers
 Lead by example
 Set bad examples
 Are visionaries
 Are not self-assured
 Are technically competent
 Lack technical expertise
 Are decisive
 Are poor communicators
 Are good communicators
 Are poor motivators
 Are good motivators
 Stand up to upper management
when necessary
 Support team members
 Encourage new ideas
© 2004-05, David Gadish, Ph.D.
35
The Project Management
Process Groups: A Case
Study
Chapter 3
36
Learning Objectives
 Describe the five project management
process groups, the typical level of activity
for each, and the interactions among them
 Understand how the project management
process groups relate to the project
management knowledge areas
 Discuss how organizations develop project
management methodologies to meet their
needs
© 2004-05, David Gadish, Ph.D.
37
Learning Objectives
 Review a case study of an organization
applying the project management process
groups to manage an information
technology project
 Understand the contribution that effective
project initiation, project planning, project
execution, project control, and project
closing makes to project success
© 2004-05, David Gadish, Ph.D.
38
Project Management Process
Groups
 Project management can be viewed as a
number of interlinked processes
 The project management process groups
include
–
–
–
–
–
initiating processes
planning processes
executing processes
controlling processes
closing processes
© 2004-05, David Gadish, Ph.D.
39
Overlap of Process Groups in a
Phase
© 2004-05, David Gadish, Ph.D.
40
Relationships Among Process Groups
and Knowledge Areas
© 2004-05, David Gadish, Ph.D.
41
Relationships Among Process Groups and
Knowledge Areas
© 2004-05, David Gadish, Ph.D.
42
Developing an IT Project
Management Methodology
 Just as projects are unique, so are
approaches to project management
 Many organizations develop their own
project management methodologies,
especially for IT projects
 Blue Cross Blue Shield of Michigan used
the PMBOK as a guide in developing their
IT project management methodology
© 2004-05, David Gadish, Ph.D.
43
ITPM Methodology (Fig 3.2)
© 2004-05, David Gadish, Ph.D.
44
Case Study: JWD Consulting’s
Project Management Intranet Site
 This case study provides an example of what’s
involved in initiating, planning, executing,
controlling, and closing an IT project
 You can download templates for creating your
own project management documents from the
companion Web site for the book
 Note: This case study provides a big picture view
of managing a project. Later chapters provide
detailed information on each knowledge area.
© 2004-05, David Gadish, Ph.D.
45
Project Initiation
 Initiating a project includes recognizing and
starting a new project or project phase
 Some organizations use a pre-initiation phase,
while others include items like developing a
business case as part of initiation
 The main goal is to formally select and start off
projects
 Key outputs include:
–
–
–
–
Assigning the project manager
Identifying key stakeholders
Completing a business case
Completing a project charter and getting signatures on
it
© 2004-05, David Gadish, Ph.D.
46
Project Initiation Documents
 Business case: See pages 74-76
 Charter: See pages 77-78, also shown on
next two slides
 Note: Every organization has its own
variations of what documents are required
for project initiation.
© 2004-05, David Gadish, Ph.D.
47
Project Initiation Documents
 It’s important to identify:
– The need for projects
– Who the stakeholders are
– What the main goals are for the project
© 2004-05, David Gadish, Ph.D.
48
JWD’s Project Charter
© 2004-05, David Gadish, Ph.D.
49
JWD’s Project Charter
© 2004-05, David Gadish, Ph.D.
50
Project Planning
 The main purpose of project planning is to
guide execution
 Every knowledge area includes planning
information (see Table 3-5 on pages 79-80)
© 2004-05, David Gadish, Ph.D.
51
Project Planning
 Key outputs include:
– A team contract
– A scope statement
– A work breakdown structure (WBS)
– A project schedule, in the form of a Gantt chart
with all dependencies and resources entered
– A list of prioritized risks
 See sample documents on pages 83-90, and
refer to them later in the course
© 2004-05, David Gadish, Ph.D.
52
JWD’s Project Gantt Chart
© 2004-05, David Gadish, Ph.D.
53
JWD’s List of Prioritized Risks
© 2004-05, David Gadish, Ph.D.
54
Project Executing
 It usually takes the most time and resources
to perform project execution since the
products of the project are produced here
 The most important output of execution is
work results
 Project managers must use their leadership
skills to handle the many challenges that
occur during project execution
© 2004-05, David Gadish, Ph.D.
55
Project Controlling
 Controlling involves measuring progress
toward project objectives, monitoring
deviation from the plan, and taking
corrective actions
 Controlling affects all other process groups
and occurs during all phases of the project
life cycle
 Status and progress reports are important
outputs of controlling
© 2004-05, David Gadish, Ph.D.
56
Project Closing
 The closing process involves gaining
stakeholder and customer acceptance of the
final product and bringing the project, or
project phase, to an orderly end
 Even if projects are not completed, they
should be closed out to learn from the past
 Project archives and lessons learned are
important outputs. Most projects include a
final report and presentations
© 2004-05, David Gadish, Ph.D.
57
Post-Project Follow-up
 Many organizations have realized that it’s
important to review the results of projects a
year or so after they have been completed
 Many projects promise potential savings, so
it’s important to review the financial
estimates and help learn from the past in
preparing new estimates
© 2004-05, David Gadish, Ph.D.
58
Questions?
© 2004-05, David Gadish, Ph.D.
59
Next Week’s Agenda
 Project Integration Management (Ch 4)
 Project Scope Management (Ch 5)
© 2004-05, David Gadish, Ph.D.
60