Managing People: Managing People Working As Individuals and in Groups

You might also like

Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 44

Managing people


Managing people working as
individuals and in groups

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 1


Objectives

To explain some of the issues involved in selecting
and retaining staff

To describe factors that influence individual
motivation

To discuss key issues of team working including
composition, cohesiveness and communications

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 2


Topics covered

Selecting staff

Motivating people

Managing groups

The people capability maturity model

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 3


People in the process

People are an organisation’s most important
assets.

The tasks of a manager are essentially
people-oriented. Unless there is some
understanding of people, management will
be unsuccessful.

Poor people management is an important
contributor to project failure.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 4


People management factors

Consistency
• Team members should all be treated in a comparable
way without favourites or discrimination.

Respect
• Different team members have different skills and these
differences should be respected.

Inclusion
• Involve all team members and make sure that people’s
views are considered.

Honesty
• You should always be honest about what is going well
and what is going badly in a project.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 5


Selecting staff

An important project management task is
team selection.

Information on selection comes from:
• Information provided by the candidates.
• Information gained by interviewing and talking
with candidates.
• Recommendations and comments from other
people who know or who have worked with the
candidates.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 6


Staff selection case study 1

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 7


Staff selection case study 2
The next stage is to try and find people from within the company with
the necessary skills. However, the company has expanded significantly
and has few staff available. The best that Alice can negotiate is to have
help from an alarm expert (Fred) for 2 days/week. She therefore
decides to advertise for new project staff, listing the attributes that
sheÕdlike:
1. Programming experience in C. She has decided to develop all the
assistive technology control software in C.
2. Experience in user interface design. A UI designer is essential but
there may not be a need for a full-time appointment.
3. Experience in hardware interfacing with C and using remote
development systems. All the devices used have co mplex hardware
interfaces.
4. Experience of working with hardware engineers. At times, it will be
necessary to build completely new hardware.
A sympathetic personality so that they can relate to and work with elderly people who are
providing requirements for and are testing the system.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 8


Lessons

Managers in a company may not wish to lose
people to a new project. Part-time
involvement may be inevitable.

Skills such as UI design and hardware
interfacing are in short supply.

Recent graduates may not have specific skills
but may be a way of introducing new skills.

Technical proficiency may be less important
than social skills.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 9


Staff selection factors 1

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 10


Staff selection factors 2

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 11


Motivating people

An important role of a manager is to motivate
the people working on a project.

Motivation is a complex issue but it appears
that their are different types of motivation
based on:
• Basic needs (e.g. food, sleep, etc.);
• Personal needs (e.g. respect, self-esteem);
• Social needs (e.g. to be accepted as part of a
group).

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 12


Human needs hierarchy

Self-
realisa tion needs

Esteem needs

Social needs

Safety needs

Ph ysiolo gical needs

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 13


Need satisfaction

Social
• Provide communal facilities;
• Allow informal communications.

Esteem
• Recognition of achievements;
• Appropriate rewards.

Self-realization
• Training - people want to learn more;
• Responsibility.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 14


Individual motivation

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 15


Personality types

The needs hierarchy is almost certainly an
over-simplification of motivation in practice.

Motivation should also take into account
different personality types:
• Task-oriented;
• Self-oriented;
• Interaction-oriented.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 16


Personality types

Task-oriented.
• The motivation for doing the work is the work itself;

Self-oriented.
• The work is a means to an end which is the achievement
of individual goals - e.g. to get rich, to play tennis, to
travel etc.;

Interaction-oriented
• The principal motivation is the presence and actions of
co-workers. People go to work because they like to go to
work.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 17


Motivation balance

Individual motivations are made up of elements
of each class.

The balance can change depending on personal
circumstances and external events.

However, people are not just motivated by personal
factors but also by being part of a group and culture.

People go to work because they are motivated by
the people that they work with.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 18


Managing groups

Most software engineering is a group activity
• The development schedule for most non-trivial
software projects is such that they cannot be
completed by one person working alone.

Group interaction is a key determinant of
group performance.

Flexibility in group composition is limited
• Managers must do the best they can with
available people.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 19


Factors influencing group working

Group composition.

Group cohesiveness.

Group communications.

Group organisation.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 20


Group composition

Group composed of members who share the
same motivation can be problematic
• Task-oriented - everyone wants to do their own thing;
• Self-oriented - everyone wants to be the boss;
• Interaction-oriented - too much chatting, not enough work.

An effective group has a balance of all types.

This can be difficult to achieve software engineers
are often task-oriented.

Interaction-oriented people are very important as
they can detect and defuse tensions that arise.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 21


Group composition

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 22


Group leadership

Leadership depends on respect not titular
status.

There may be both a technical and an
administrative leader.

Democratic leadership is more effective that
autocratic leadership.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 23


Group cohesiveness

In a cohesive group, members consider the
group to be more important than any individual
in it.

The advantages of a cohesive group are:
• Group quality standards can be developed;
• Group members work closely together so inhibitions
caused by ignorance are reduced;
• Team members learn from each other and get to
know each other’s work;
• Egoless programming where members strive to
improve each other’s programs can be practised.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 24


Team spirit

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 25


Developing cohesiveness

Cohesiveness is influenced by factors such as the
organisational culture and the personalities in the
group.

Cohesiveness can be encouraged through
• Social events;
• Developing a group identity and territory;
• Explicit team-building activities.

Openness with information is a simple way of
ensuring all group members feel part of the group.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 26


Group loyalties

Group members tend to be loyal to cohesive
groups.

'Groupthink' is preservation of group
irrespective of technical or organizational
considerations.

Management should act positively to avoid
groupthink by forcing external involvement
with each group.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 27


Group communications

Good communications are essential for
effective group working.

Information must be exchanged on the
status of work, design decisions and
changes to previous decisions.

Good communications also strengthens
group cohesion as it promotes
understanding.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 28


Group communications

Group size
• The larger the group, the harder it is for people to
communicate with other group members.

Group structure
• Communication is better in informally structured groups than
in hierarchically structured groups.

Group composition
• Communication is better when there are different personality
types in a group and when groups are mixed rather than
single sex.

The physical work environment
• Good workplace organisation can help encourage
communications.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 29


Group organisation

Small software engineering groups are
usually organised informally without a rigid
structure.

For large projects, there may be a
hierarchical structure where different groups
are responsible for different sub-projects.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 30


Informal groups

The group acts as a whole and comes to a
consensus on decisions affecting the system.

The group leader serves as the external interface of
the group but does not allocate specific work items.

Rather, work is discussed by the group as a whole
and tasks are allocated according to ability and
experience.

This approach is successful for groups where all
members are experienced and competent.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 31


Extreme programming groups

Extreme programming groups are variants of
an informal, democratic organisation.

In extreme programming groups, some
‘management’ decisions are devolved to
group members.

Programmers work in pairs and take a
collective responsibility for code that is
developed.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 32


Chief programmer teams

Consist of a kernel of specialists helped by others
added to the project as required.

The motivation behind their development is the wide
difference in ability in different programmers.

Chief programmer teams provide a supporting
environment for very able programmers to be
responsible for most of the system development.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 33


Problems

This chief programmer approach, in different forms,
has been successful in some settings.

However, it suffers from a number of problems
• Talented designers and programmers are hard to find.
Without exceptional people in these roles, the approach
will fail;
• Other group members may resent the chief programmer
taking the credit for success so may deliberately
undermine his/her role;
• There is a high project risk as the project will fail if both
the chief and deputy programmer are unavailable.
• The organisational structures and grades in a company
may be unable to accommodate this type of group.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 34


Working environments

The physical workplace provision has an important
effect on individual productivity and satisfaction
• Comfort;
• Privacy;
• Facilities.

Health and safety considerations must be taken
into account
• Lighting;
• Heating;
• Furniture.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 35


Environmental factors

Privacy - each engineer requires an area for
uninterrupted work.

Outside awareness - people prefer to work in

natural light.

Personalization - individuals adopt different
working practices and like to organize their
environment in different ways.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 36


Workspace organisation

Workspaces should provide private spaces
where people can work without interruption
• Providing individual offices for staff has been
shown to increase productivity.

However, teams working together also
require spaces where formal and informal
meetings can be held.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 37


Office layout

Meeting
room

Office Office Windo w


Comm unal
area
Office Office

Office Office
Shared
documenta tion
Office Office

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 38


The People Capability Maturity Model


Intended as a framework for managing the
development of people involved in software
development.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 39


P-CMM Objectives

To improve organisational capability by
improving workforce capability.

To ensure that software development
capability is not reliant on a small number of
individuals.

To align the motivation of individuals with
that of the organisation.

To help retain people with critical knowledge
and skills.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 40


P-CMM levels

Five stage model
• Initial. Ad-hoc people management
• Repeatable. Policies developed for capability
improvement
• Defined. Standardised people management across the
organisation
• Managed. Quantitative goals for people management in
place
• Optimizing. Continuous focus on improving individual
competence and workforce motivation

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 41


The people capability model Optimizing
Continuously improve methods Continuous workforce innovation
for developing personal and Coaching
organisational competence Personal competency development

Mana ged
Quantitatively manage Organisational per formance alignment
organisational g row th in Organisational competency management
workforce capabilities and
establish competency-based Team-based practices
teams Team building
Mentoring

Defined
Identify primary
competencies and Participatory culture
align workforce Competency-based practices
activities with them
Career development
Competency development
Workforce planning
Knowledge and skills analysis

Repea ta ble
Instill basic
discipline into Compensation
workforce Training
activities Performance management
Staffing
Communication
Work environment

Initial

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 42


Key points

Staff selection factors include education,
domain experience, adaptability and
personality.

People are motivated by interaction,
recognition and personal development.

Software development groups should be
small and cohesive. Leaders should be
competent and should have administrative
and technical support.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 43


Key points

Group communications are affected by
status, group size, group organisation and
the gender and personality composition of
the group

Working environments should include
spaces for interaction and spaces for private
working.

The People Capability Maturity Model is a
framework for improving the capabilities of
staff in an organisation.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 25 Slide 44

You might also like