Chapter 24

 Project Management Concepts

Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is
prohibited without the express written permission of the author.

All copyright information MUST appear if these slides are posted on a website for student
use.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 1
 Project Manager Positions

 Project Administrator /
Coordinator
 Assistant Project Manager
 Project Manager / Program
Manager
 Executive Program Manager

2
Software Project
Management
Management

Project
Management

Software
Project
Management

3
 Software Teams
How to lead?
How to organize?
How to collaborate?

How to motivate? How to create good ideas?

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 4
 The Four P’s
 People — the most important element of a
successful project
 Product — the software to be built
 Process — the set of framework activities and
software engineering tasks to get the job done
 Project — all work required to make the
product a reality

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 5
 The Process
 Once a process framework has been
established
 Consider project characteristics
 Determine the degree of rigor required

 Define a task set for each software

engineering activity

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 6
Task
 A task describes the smallest amount of
work tracked by management
 Typically 3-10 working days effort
 Tasks descriptions
 Role
 Work product

 Start date

 Planned duration

 Required resources.

7
 Role
 A role defines a set responsibilities (“to-dos”)
 Examples
 Role: Tester
 Write tests
 Report failures
 Check if bug fixes address a specific failure
 Role: System architect
 Ensure consistency in design decisions and define subsystem
interfaces
 Formulate system integration strategy
 Role: Liaison
 Facilitate communication between two teams.

8
Work Products
 A work product is a visible outcome of a task
 Examples
 A document
 A review of a document
 A presentation
 A piece of code
 A test report
 Work products delivered to the customer are
called deliverables

9
Scope of Complexity
 amount of effort
 number of groups and organizations to be
coordinated
 diversity in skills or expertise needed

Usually the MORE COMPLEX, the more

time and resources required

10
Challenges of Modern Environments

 rapidly changing technology

 rising costs
 increased competition
 frequent resource shortages
 many opposing interest groups

11
 Information System (IS)
Project Features
 technological explosion
 286; 386; 486; Pentium; ?
 CASE tools; C++; GUI;
 highly volatile & expanding market
 CAD/CAM; EDI; laptops; Internet
 uncertainty
 is what requester wants feasible?
 how long will it take to program?
 will there be any bugs?
 many people involved
 user group; systems designers; programmers; end users;

12
IS Project Environment
 Risky
 Standish Group reports:
• >30% cancelled
• About 40% lack designed functionality
• Only 13% rated successful by sponsors
 Examples

• Bank of America project

• American Airlines subsidiary travel
reservation
13
 Summary
 All projects are complex
 IS projects even more so
 Get diverse people to work together: Time,
Cost, Functionality.
 Work is organized in terms of tasks
assigned to roles and producing work
products.
 Critical Success Factors: Top management
support, Clearly stated objectives, End user
involvement
14
Tracking
 Cost, effort, schedule
 Planned vs. Actual
 How to handle when things go
off plan?

15
 Project Organization
 A project organization defines the relationships
among resources, in particular the participants, in
a project

 A project organization should define

 Who decides (decision structure)
 Who reports their status to whom (reporting structure)
 Who communicates with whom (communication
structure)

16
Reporting vs. Communication
 Reporting supports project management in tracking
project status
 What work has been completed?
 What work is behind schedule?
 What issues threaten project progress?
 Reporting along the hierarchy is not sufficient when
two teams need to communicate
 A communication structure is needed
 A participant from each team is responsible for
facilitating communication between both teams
 Such participants are called liaison

17
 Hierarchical Project Organization

Chief Executive

First Level Manager

(“Front-Line Manager”)

A B Project Members

A wants to talk to B: Information Flow

A wants to make sure B does a certain change: Controlflow

18
 Peer-To-Peer Communication
Project
Leader
Subsystem Teams

A B Team
Members

A wants to talk to B: Simple Information Flow

A wants to make sure B does a certain change: Simple Controlflow

19
 Organizational Structures

 Functional
 Engineering, Marketing, Design, etc
 Project
 Project A, Project B

20
 Functional Organization

Pros Cons
– Clear definition of authority – Can lack customer orientation
– Eliminates duplication – Create longer decisions cycles
– Encourages specialization – Conflicts across functional areas
– Clear career paths – Project leaders have little power

21
 Project Organization

Pros Cons
– Unity of command – Duplication of facilities
– Effective inter-project – Career path

communication
22
Planning
 Determine requirements
 Determine resources
 Select lifecycle model
 Determine product features
strategy

23
 Planning
 How much will it cost?
 How long will it take?
 How many people will it
take?
 What might go wrong?

24
Make-or-buy Analysis
 Make-or-buy analysis (build vs.
buy)
 Determining whether a particular
product or service should be made
or performed inside the organization
or purchased from someone else.
Often involves financial analysis
 Experts

25
 Make-or Buy Example
 Assume you can lease an item you
need for a project for $150/day. To
purchase the item, the investment cost
is $1,000, and the daily cost would be
another $50/day.
 How long will it take for the lease cost
to be the same as the purchase cost?
 If you need the item for 12 days, should
you lease it or purchase it?

26
 Make-or Buy Solution
 Set up an equation so the “make” is equal to the “buy”
 In this example, use the following equation. Let d be the number of days
to use the item.
$150d = $1,000 + $50d
 Solve for d as follows:
 Subtract $50d from the right side of the equation to get
$100d = $1,000
 Divide both sides of the equation by $100
d = 10 days
 The lease cost is the same as the purchase cost at 10 days
 If you need the item for > 12 days, then purchase it

27
MS Project Tool: Gantt Chart

28
Responsibility Assignment Matrix
(RAM)
 A resource planning tool
 Who does What
 Who: can be individual, team or
department
 Can have totals/summary at end of
row or column
 ex: total Contributors on a task

29
RAM Example
Another RAM Example
 Skills Matrix
 Another resource planning tool
 Resources on one axis, skills on other
 Skills can high level or very specific
 Cells can be X’s or numeric (ex: level, # yrs.)