STAFFING IN SOFTWARE PROJECTS

1. Chapter 11,
Project Management
STAFFING IN SOFTWARE PROJECTS

2. Outline
 Concepts and terminology
 Purpose of Software Project Management Plans
 Structure of a Project Management Plan
 Project responsibilities
 Team structures
 Project planning
 Work breakdown structure
 Communication Management
 Dependencies
 Schedule
 Project Management Tools

3. Laws of Project Management
 Projects progress quickly until they are 90% complete.
Then they remain at 90% complete forever.
 When things are going well, something will go wrong.
When things just can’t get worse, they will. When things
appear to be going better, you have overlooked something.
 If project content is allowed to change freely, the rate of
change will exceed the rate of progress.
 Project teams detest progress reporting because it
manifests their lack of progress.

4. How it should go
Requirements
Analysis
Implementation
Design
System Testing
Delivery and Installation

5. How it often goes
Requirements
Analysis
D
E
L
A
Y
Vaporware

6. Software Project Management Plan
 Software Project:
 All technical and managerial activities required to deliver
the deliverables to the client.
 A software project has a specific duration, consumes
resources and produces work products.
 Management categories to complete a software project:
 Tasks, Activities, Functions
 Software Project Management Plan:
 The controlling document for a software project.
 Specifies the technical and managerial approaches to
develop the software product.
 Companion document to requirements analysis document:
Changes in either may imply changes in the other
document.
 SPMP may be part of project agreement.

7. Project Agreement
 Document written for a client that defines:
 the scope, duration, cost and deliverables for the project.
 the exact items, quantities, delivery dates, delivery location.
 Can be a contract, a statement of work, a business plan, or a
project charter.
 Client: Individual or organization that specifies the
requirements and accepts the project deliverables.
 Deliverables (= Work Products that will be delivered to the
client):
 Documents
 Demonstrations of function
 Demonstration of nonfunctional requirements
 Demonstrations of subsystems

8. Project Agreement vs Problem Statement
Manager Project Team
Client
(Sponsor)
Problem
Statement
Project
Agreement
Software Project
Management Plan

9. Project Management Activities
(continued on next slide)
Initiation
Project kickoff
Team formation Communication
infrastructure setup
Problem statement
definition
Initial milestones
planning
Initial top-level
design

10. Installation
Steady state
Termination
Client acceptance test Postmortem
Project agreement
Project replanning
Status monitoring Risk management
Project kickoff

11. Project: Functions, Activities and Tasks
p:Project
f1:Function
f2:Function
a1:Activity a2:Activity a3:Activity
a2.1:Activity a2.2:Activity a2.3:Activity
t1:Task t2:Task t3:Task t4:Task

12. Functions
 Activity or set of activities that span the duration of the project
p:Project
f1:Function
f2:Function
a1:Activity a2:Activity a3:Activity
a2.1:Activity a2.2:Activity a2.3:Activity
t1:Task t2:Task t3:Task t4:Task

13. Functions
 Examples:
 Project management
 Configuration Management
 Documentation
 Quality Control (Verification and validation)
 Training
 Question: Is system integration a project function?
 Mapping of terms: Project Functions in the IEEE 1058
standard are called Integral processes in the IEEE 1074
standard. We call them cross-development processes

14. Tasks
• Smallest unit
of work subject
to management
• Small enough for
adequate planning
and tracking
• Large enough
to avoid micro
management
p:Project
f1:Function
f2:Function
a1:Activity a2:Activity
a2.1:Activity a2.2:Activity
t1:Task t2:Task t3:Task

15. Tasks
 Smallest unit of management accountability
 Atomic unit of planning and tracking
 Finite duration, need resources, produce tangible result (documents,
code)
 Specification of a task: Work package
 Name, description of work to be done
 Preconditions for starting, duration, required resources
 Work product to be produced, acceptance criteria for it
 Risk involved
 Completion criteria
 Includes the acceptance criteria for the work products
(deliverables) produced by the task.

16. Task Sizes
 Finding the appropriate task
size is problematic
 Todo lists from previous
projects
 During initial planning a
task is necessarily large
 You may not know how to
decompose the problem into
tasks at first
 Each software development
activity identifies more tasks
and modifies existing ones
 Tasks must be decomposed
into sizes that allow
monitoring
 Work package usually
corresponds to well defined
work assignment for one
worker for a week or a
month.
 Depends on nature of work
and how well task is
understood.

17. Examples of Tasks
 Unit test class “Foo”
 Test subsystem “Bla”
 Write user manual
 Write meeting minutes and post them
 Write a memo on NT vs Unix
 Schedule the code review
 Develop the project plan
 Related tasks are grouped into hierarchical sets of functions and
activities.
 Action item

18. Action Item
 Definition: A task assigned to a person that has to be done
within a week or less
 Action items
 Appear on the agenda in the Status Section (See lecture on
communication)
 Cover: What?, Who?, When?
 Example of action items:
 Florian unit tests class “Foo” by next week
 Marcus develops a project plan before the next meeting
 Bob posts the next agenda for the Simulation team meeting before
Sep 10, 12noon.
 The VIP team develops the project plan by Sep 18

19. Activities
• Major unit of work
with precise dates
• Culminates in project
milestone.
• Consists of smaller
activities or tasks
p:Project
f1:Function
f2:Function
a1:Activity a2:Activity
a2.1:Activity a2.2:Activity
t1:Task t2:Task t3:Task

20. Activities
 Major unit of work
 Culminates in major project
milestone:
 Internal checkpoint should
not be externally visible
 Scheduled event used to
measure progress
 Milestone often produces
baseline:
 formally reviewed work product
 under change control (change
requires formal procedures)
 Activities may be grouped
into larger activities:
 Establishes hierarchical
structure for project (phase,
step, ...)
 Allows separation of
concerns
 Precedence relations often
exist among activities (PERT
Chart)

21. Examples of Activities
 Major Activities:
 Planning
 Requirements Elicitation
 Requirements Analysis
 System Design
 Object Design
 Implementation
 System Testing
 Delivery
 Activities during
requirements analysis:
 Refine scenarios
 Define Use Case model
 Define object model
 Define dynamic model
 Design User Interface

22. Structure of a Software Project Management Plan
Front Matter
1. Introduction
2. Project Organization
3. Managerial Process
4. Technical Process
5. Work Elements, Schedule, Budget
Optional Inclusions

23. SPMP Part 0: Front Matter
 Title Page
 Revision sheet (update history)
 Preface: Scope and purpose
 Tables of contents, figures, tables

24. SPMP Part 1: Introduction
1.1 Project Overview
 Executive summary: description of project, product summary
1.2 Project Deliverables
 All items to be delivered, including delivery dates and location
1.3 Evolution of the SPMP
 Plans for anticipated and unanticipated change
1.4 Reference Materials
 Complete list of materials referenced in SPMP
1.5 Definitions and Acronyms

25. SPMP Part 2: Project Organization
2.1 Process Model
 Relationships among project elements
2.2 Organizational Structure
 Internal management, organization chart
2.3 Organizational Interfaces
 Relations with other entities
2.4 Project Responsibilities
 Major functions and activities; nature of each; who’s in charge

26. Process Model
 Shows relationships among
 Functions, activities, tasks
 Milestones
 Baselines
 Reviews
 Work breakdown structure
 Project deliverables
 Sign-offs
 Visualization of process
model
 Project Management Aids
 MS Project (Microsoft)
 MAC Project (Claris)
 EasyTrak (Planning Control
International)

27. Example of an Organization Chart
Client Management Consultants
Cross-functional Teams
Logbook
Maintenance
Vehicle
Travel
VIP
Development Teams
Infrastructure Team
Architecture
HCI
Web Master
Documentation
Configuration Mgt

28. Project Roles
 Planner
 Analyst
 Designer
 Programmer
 Tester
 Maintainer
 Trainer
 Document Editor
 Web Master
 Configuration Manager
 Group leader
 Liaison
 Minute Taker
 Project Manager

29. Project Roles
 Management roles
 Organization and execution of the project within constraints.
Examples: project manager, team leader.
 Development roles
 Specification, design and construction of subsystems. Examples:
Analyst, system architect, implementor.
 Cross functional roles
 Coordination of more than one team. Example: API Engineer,
configuration manager, tester
 Consultant roles
 Support in areas where the project participants lack expertise.
Examples: End user, client, application domain specialist ( problem
domain), technical consultant (solution domain).
 Promoter roles
 Promote change through an organization.

30. Promoter Roles
 Promoters are self appointed individuals who identify
themselves with the outcome of the project.
 They are member of the corporate organization and may not
necessarily be directly involved with the project. Instead, they
are interfaces to the rest of the corporate organization.
 Because of the power, knowledge of technology, or familiarity
with the project’s processes, they are able to promote and push
specific changes through the organization.

31. Power Promoter
 Also called executive champion
 Pushes the change through the existing organizational hierarchy.
 not necessarily at the top of the organization, but must have
protection from top level management, otherwise project
opponents might be able to prevent the success of the project.
 Tasks:
 constantly identify difficulties, resolve issues, and
communicate with the project members, especially with the
developers.
 Example at project level: Project Manager.
 Example at corporate level: Chief Executive Officer (CEO).

32. Knowledge Promoter
 Also called the technologist,
 Promotes change arising in the application domain or the solution
domain. Usually associated with the power promoter.
 Tasks: Acquire information iteratively, understand the benefits
and limitations of new technologies, and argue its adoption with
the other developers.
 Example at project level: System architect.
 Reports to project manager
 Does not have any direct subordinate in the reporting hierarchy
 Has final say over all technical decisions in the system.
 Example at corporate level: Chief Technical Officer (CTO).

33. Process Promoter
 The process promoter has intimate knowledge of the projects
processes and procedures.
 The process promoter is in constant interaction with the power
promoter to get consensus on the overall goals.
 Tasks: Bridge between the power and knowledge promoters,
who often do not speak or understand the same language.
 Example at project level: Development lead. Responsible for
the administrative aspects of a project, including planning,
milestones definition, budgeting and communication
infrastructure.
 Example at corporate level: Chief Information Officer (CIO

34. Project Management: Hierarchical Project
Organization
Chief Executive
First Level Manager
(“Front-Line Manager”)
Project Members
Basis of organization:
Complicated information and control flow
across hierarchical boundaries
A B
A wants to talk to B: Complicated Information Flow
A wants to make sure B does a certain change: Complicated Controlflow
Information Flow
Control Flow

35. Example of Hierchical Organization:
Chief Programmer Team
Chief Programmer
Librarian Administration Tester
Junior Programmer
Assistant
Chief Programmer
Senior Programmer

36. Another Project Organization:
Egoless Programming Team (Weinberg)
Analyst
Designer Librarian
Tester Programmer

37. Project-Based Project Organization
Project
Leader
Coaches
Team
Members
Basis of organization:
Nonlinear information flow across dynamically formed units
Subsystem Team Subsystem Team Subsystem Team
A B
A wants to talk to B: Communication Flow
A wants to make sure B does a certain change: Decision Flow

38. Associations in organizational structures
 Reporting association:
 Used for reporting status information
 Decision association
 Used for propagating decisions
 Communication association
 Used for exchanging information needed for decisions (e.g.,
requirements, design models, issues).

39. Observations on Management Structures
 Hierarchical structures
 “Reports”, “Decides” and “Communicates-With” all mapped on the
same association
 Do not work well with iterative and incremental software
development process
 Manager is not necessarily always right
 Project-based structures
 “Reports”, “Decides” and “Communicates-With”are different
associations
 Cut down on bureaucracy reduces development time
 Decisions are expected to be made at each level
 Hard to manage

40. Hierarchical Structure
 Projects with high degree of certainty, stability, uniformity and
repetition.
 Requires little communication
 Role definitions are clear
 When?
 The more people on the project, the more need for a formal
structure
 Customer might insist that the test team be independent from the
design team
 Project manager insists on a previously successful structure

41. Project-Based Structure
 Project with degree of uncertainty
 Open communication needed among members
 Roles are defined on project basis
 When?
 Requirements change during development
 New technology develops during project

42. Assigning Responsibilities To People
“To Do” List for the Project
• Item 1
• Item 2
• Item 3
• Item 4
• Item 5
• Item 6
• Item 7
• Item 8
• Item 9
Item 1
Item 2
Item 9
Role 1
Item 4
Item 5
Item 7
Role 2
Item 3
Item 6
Item 8
Role 3
Person A
Role 1
Role 2
Person B
Role 3
Team A

43. Possible Mappings of ToDos to People
 One-to-One
 Ideal but often not worth to be called a project
 Many-to-Few
 Each project member assumes several roles ("hats")
 Danger of overcommittment
 Need for load balancing
 Many-to-"Too-Many"
 Some people don't have significant roles
 Bystanders
 Loosing touch with project

44. Team Formation
 Top level Design
 “Rough” Subsystem Decomposition (before requirements analysis)
 Done during Predevelopment phase
 Team Formation done after Top Level Design
 Heuristics:
 One team for each subsystem
 One cross-functional task per team
 5-7 members per team
 Be prepared to iterate the team formation after system design
when the subsystem decomposition is baselined

45. Project Roles: Coach
 Listen to gripes from individual teams
 Review weekly team reports
 Attend weekly project meetings
 Schedule and prepare meetings with client
 Insist that guidelines are followed
 Assign presentations (in-class project meetings, client review,
client acceptance test)
 Resolve conflicts if they cannot be resolved otherwise

46. Project Role: Group leader
 Responsible for intra-group communication (Meeting
Management: Primary Facilitator)
 Run the weekly project meeting
 Post agenda before meeting
 Define and keep track of action items (who, what, when)
 Measure progress (Enforce milestones)
 Deliver work packages for the tasks to the project management
 Present problems and status of team to project manager
 The group leader has to be rotated among members of the team.

47. Group Leader: Create an Agenda
Action Items
(Check Previous
Meeting)
Issues
(Check Previous
Meeting & BBoards)
 Purpose of Meeting
 Desired Outcome
 Information Sharing
 Information Processing
 Meeting Critique

48. Project Role: Liaison
 Responsible for inter-group communication
 Make available public definitions of subsystem developed by the
team to the architecture teams (ensure consistency, etc)
 Coordinate tasks spanning more than one group with other teams
 Responsible for team negotiations
 Examples: API Engineer, Configuration manager

49. Project Role: Planner
 Plans and tracks the activities of an individual team and has
the following responsibilities.
 Define project plan for team:
 PERT chart, resource table and GANTT chart showing work
packages
 Enter project plan into project management tool
 Make project plan available to management
 Report team status to project manager
No explicit planner in PAID. Responsibilities assumed by
coaches

50. Project Role: Document Editor
 Collect, proofread and distribute team documentation
 Submit team documentation to architecture team
 Collect agendas
 Take minutes at meetings

51. Web Master
 Maintain team home page
 Keep track of meeting history
 Keep track of design rationale

52. Date
9/9/96
Agenda Minutes Action Items Issues
Agenda Minutes Action Items Issues
9/16/96 Agenda Minutes Action Items Issues
Web Master:
 Publish Meeting Information on Team Homepage
 Must contain Agenda, minutes, action items and issues
 Possibilities:
 One HTML document per meeting, with anchors (maintained by one
role)
 Separate HTML documents for Agenda, Minutes, etc (maintained by
several roles)
http://cascade1.se.cs.cmu.edu/
15-413/homePagesTeams/UserInterface/www/index.htm

53. SPMP Part 3: Managerial Processes
3.1 Management Objectives and Priorities
 Philosophy, goals and priorities
3.2 Assumptions, Dependencies, Constraints
 External factors
3.3 Risk Management
 Identifying, assessing, tracking, contingencies for risks
3.4 Monitoring and Controlling Mechanisms
 Reporting mechanisms and formats, information flows, reviews
3.5 Staffing Plan
 Needed skills (what?, how much?, when?)

54. Examples of Assumptions
 There are enough cycles on the development machines
 Security will not be addressed
 There are no bugs in Together-J, the CASE Tool recommended
for the project
 A demonstration of the Starnetwork system will be given by the
client

55. Examples of Dependencies
 The database team depends on the EPC database provided by
DaimlerChrysler
 The automatic code generation facility in the CASE tool
depends on JDK. The current release of Together-J supports
only JDK 1.1.6

56. Examples of Constraints
 The length of the project is 3 months. limited amount of time to
build the system
 The project consists of beginners. It will take time to learn how
to use the tools
 Not every project member is always up-to-date with respect to
the project status
 The use of UML and a CASE tool is required
 Any new code must be written in Java
 The system must use Java JDK 1.1.6

57. Risk Management
 Risk: Members in key roles
drop the course.
 Contingency: Roles are
assigned to somebody else.
Functionality of the system is
renegotiated with the client.
 Risk: The project is falling
behind schedule.
 Contingency: Extra project
meetings are scheduled.
 Risk: One subsystem does
not provide the
functionality needed by
another subsystem.
 Contingency: ?
 Risk: Ibutton runs only
under JDK 1.2
 Contingency: ?

58. SPMP Part 4: Technical Process
4.1 Methods, Tools and Techniques
 Computing system, development method, team structure, etc.
 Standards, guidelines, policies.
4.2 Software Documentation
 Documentation plan, including milestones, reviews and baselines.
4.3 Project Support Functions
 Plans for functions (quality assurance, configuration management).

59. SPMP Part 5: Work Elements
5.1 Work Packages (Work breakdown structure)
 Project decomposed into tasks; definitions of tasks
5.2 Dependencies
 Precedence relations among functions, activities and tasks
5.3 Resource Requirements
 Estimates for resources such as personnel, computer time, special
hardware, support software.
5.4 Budget and Resource Allocation
 Connect costs to functions, activities and tasks.
5.5 Schedule
 Deadlines, accounting for dependencies, required milestones

60. Creating Work Packages
 Work Breakdown Structure (WBS) (Section 5.1)
 Break up project into activities (phases, steps) and tasks.
 The work breakdown structure does not show the interdependence
of the tasks
 The identification of the work breakdown structure is an
instance of object identification and associating these objects

61. WBS Schedule
Cost
(Time, $$)
Source: Software Engineering
Economics, Barry W. Boehm
p. 47, Prentice Hall, N.J., 1981
WBS Trade-offs
 Work breakdown structure influences cost and schedule
 Thresholds for establishing WBS in terms of percentage of total
effort:
 Small project (7 person-month): at least 7% or 0.5 PM
 Medium project (300 person-month): at least 1% or 3 PMs
 Large project (7000 person-month): at least 0.2 % or 15 PMs
 Determination of work breakdown structure is incremental and
iterative

62. Dependencies and Schedule
(SPMP Section 5.2 + 5.5)
 An important temporal relation: “must be preceded by”
 Dependency graphs show dependencies of the tasks
(hierarchical and temporal)
 Activity Graph:
 Nodes of the graph are the project milestones
 Lines linking the nodes represent the tasks involved
 Schedule Chart (MS-Project):
 Nodes are tasks and milestones
 Lines represent temporal dependencies
 Estimate the duration of each task
 Label dependency graph with the estimates

63. Project Management Tools for Work Packages
 Visualization Aids for Project Presentation
 Graphs (Schedule), Trees (WBS)
 Tables (Resources)
 Task Timeline
 Gantt Charts: Shows project activities and tasks in parallel. Enables
the project manager to understand which tasks can be performed
concurrently.
 Schedule Chart (PERT Chart)
 Cornerstone in many project management tools
 Graphically shows dependencies of tasks and milestones
 PERT: Program Evaluation and Review Technique
– A PERT chart assumes normal distribution of tasks durations
– Useful for Critical Path Analysis
 CPM: Critical Path Method

64. Project: Building a House
 Activity 1: Landscaping the lot
 Task 1.1: Clearing and grubbing
 Task 1.2: Seeding the Turf
 Task 1.3: Planting shrubs and trees
 Activity 2: Building the House
 Activity 2.1 : Site preparation
 Activity 2.2: Building the exterior
 Activity 2.3: Finishing the interior
 Activity 2.1 : Site preparation
 Task 2.1.1: Surveying
 Task 2.1.2: Obtaining permits
 Task 2.1.3: Excavating
 Task 2.1.4: Obtaining materials

65. Activity 2: Building a House, ctd
 Activity 2.2: Building the exterior
 Task 2.2.1: Foundation
 Task 2.2.2: Outside Walls
 Task 2.2.3: Exterior
plumbing
 Task 2.2.4: Exterior
electrical work
 Task 2.2.5: Exterior siding
 Task 2.2.6: Exterior painting
 Task 2.2.7: Doors and
Fixtures
 Task 2.2.8: Roof
 Activity 2.3 : Finishing the Interior
 Task 2.3.1: Interior
plumbing
 Task 2.3.2: Interior electrical
work
 Task 2.3.3: Wallboard
 Task 2.3.4: Interior painting
 Task 2.3.5: Floor covering
 Task 2.3.6: Doors and
fixtures

66. Activity Graph for Activity “Building a House”
1.1
1.2
1.4
1.3
2.1
2.2
3.1
3.2
3.3
3.4
2.3
2.4
2.5
2.6
2.8
2.7
3.5
3.6
2.6
Install Exterior Plumbing Install Interior Plumbing
Build Outside Wall
Lay Foundation
Buy Materials
Excavation
Surveying
Build Outside Wall
STAR T
Install Exterior Electrical
Install Exterior Siding
Paint Exterior
Install Exterior Doors Install Roo¼ ng
Install Interior Electrical
Install Wallboard
Install Flooring Paint Interior
Install Interior Doors
FINISH

67. PERT Chart Example for "Building a House"
Start Time
Slack Time
MS Project PERTcy
Chart with Duration of
Activities (Pfleeger 2.3)
Duration
Building a House:
START
8/27/94
0
0
Request
Permits
8/27/94
15
0
Survey
ing
8/27/94
3
12
Excava
tion
9/17/94
10
0
Legend
8/29/94
0
0
Buy
Material
10/1/94
10
0
Lay
Founda
tion
10/15/94
15
0
Build
Outside
Wall
11/5/94
20
0
Install
Exterior
Plumbing
12/3/94
10
12
Install
Interior
Plumbing
12/3/94
12
0
Install
Exterior
Electrical
12/17/94
10
12
Install
Interior
Electrical
12/21/94
15
0
Install
Exterior
Siding
12/31/94
8
12
Install
Wallboard
1/11/95
9
0
Paint
Exterior
1/12/95
5
12
Install
Roofing
1/19/95
9
12
Install
Flooring
1/22/95
18
0
Paint
Interior
1/22/95
11
0
Install
Interior
Doors
2/8/95
7
0
Install
Exterior
Doors
1/19/95
6
15
FINISH
2/16/95
0
0

68. Slack Time and Critical Path
 Slack Time
 Available Time - Estimated (“Real”) Time for a task or activity
 Or: Latest Start Time - Earliest Start Time
 Critical Path
 The path in a project plan for which the slack time at each task is
zero.
The critical path has no margin for error when performing the
tasks (activities) along its route.

69. How do you become a good project planner?
 Establish a project plan
 Start with the plan based on your experience with the last project(s)
 Keep track of activities and their duration
 Determine difference between planned and actual performance
 Make sure to do a post-mortem
 Lessons learned
 Ask developers for feedback
 Write a document about what could have been improved

70. Writing the SPMP
 Example full SPMPs
 OWL project
 http://cascade1.se.cs.cmu.edu/15-413/courseDocs/spmpF96.html
 JAMES project
 http://cascade1.se.cs.cmu.edu/JAMES/J_courseDocs/SPMP/SPMP1.
0.html

71. Project Management Heuristics
 Make sure to be able to revise or dump a project plan
 Complex system development is a nonlinear activity
 If project goals are unclear and complex use team-based project
management. In this case
 Avoid GANTT charts and PERT charts for projects with changing
requirements
 Don’t look too far into the future
 Avoid micro management of details
 Don’t be surprise if current project management tools don’t
work:
 They were designed for projects with clear goals and fixed
organizational structures

72. Project Management Summary
 Get agreement among customers, managers and teams
 Problem statement
 Software project management plan
 Project agreement
 Make sure agreement allows for iteration
 Organization Structures
 SPMP
 Project planning
 Start with work breakdown structure (WBS)
 Identify dependencies and structure: Tasks, activities, functions
 Tools and Techniques
 GANTT, Dependency graph, Schedule, Critical Path Analysis
 Be careful with tools in projects with a lot of change

73. Hackman & Oldham’s Job
Characteristics Model
Core Dimensions Psychological States Outcomes
Skill Variety
Task Identity
Task Signif.
Autonomy
Feedback
Meaningfulness
of Work
Responsibility
for outcomes
Knowledge of
Results
High intrinsic
motivation
High job per-
ormance
High job satis-
faction
Low absentee
ism & turnover

74. Moderating Variables for the
Job Characteristics Model
• Growth need strength
– job is a vehicle for personal growth, sense of
achievement, avenue for feeling success
• Knowledge and skills
• Satisfaction with extrinsic aspects of
work

75. Motivating Potential Score
MPS =
Skill Variety +Task Identity+Task Significance
3
X
Autonomy
X
Feedback

76. Implementing Concepts for the
Job Characteristics Model
• Combine tasks: Effects skill variety, task
identity, & task significance
• Group tasks into natural work units:
Effects task significance and task identity
• Give workers contact with customers:
Effects skill variety, autonomy, feedback
• Vertically load jobs: Effects autonomy
• Open feedback channels: Effects
feedback

77. Designing Jobs for Teams
• Team has to be an identifiable group,
doing a specified piece of work, and be
self-managing
• Key behaviors: Ask for ideas, give
suggestions,. listen to others, share
information, help others
• Manager’s role: Make alterations needed
for effective group performance, consult

78. Goals That Motivate
• Specific Goals
• Difficult Goals
• Goal Acceptance
• Goal Feedback

79. Why Goals Motivate
• Mobilize energy in relation to goal
• Focus attention towards goals attainment
• Encourages setting of action plans or
strategies for goal attainment
• Encourages persistence until goal is
attained

80. Enhancing Goal Acceptance
• Participation
• Rewards
• Supportiveness

81. Incentives for Individuals
• For Executives
– Compensation tied to achieving strategic
goals
• For Lower Level Employees
– Tied to performance: bonuses, commissions,
piecework

82. Incentives for Groups
• Team incentives
• Profit sharing
• Gain sharing
• Stock options

83. Where Pay Fails to Motivate
• Bonuses or merit pay is too small
• Non-existent link between pay and
performance
• Performance appraisal is done poorly
• Effect of unions
• Adaptation problems

84. Effective Reward Systems
• Set high goals for performance
• Develop accurate ways to measure
performance
• Train supervisors in performance
appraisal
• Link pay to performance
• Make increases noticeable and
meaningful

85. Backwards & Forwards
• Summing up: Examined how Hackman’s
& Oldhams Job characteristics Model
can be used to redesign jobs to engage
motivation; studied how and why goals
setting works & looked at ways to use pay
as a motivator
• Next time we begin our study of groups in
the organization looking at how they
function and the role of cohesiveness