Managing people in Software

Environment
Unit – 5
Part - 1
 Introduction
We are going to examine some of the problems that Amanda and Brigette could meet when dealing with
members of their teams. Where possible, we want to base any advice on the findings of writers on
organizational behaviour (OB). We will pay special attention where the sources refer to software
development environments. Some of these human considerations affect staff as individuals.

Others arise from the need for people involved in ICT system development and implementation to work in
cooperation with others.

There will be four main concerns in the current chapter: staff selection, staff development, staff
motivation and the continued well-being of staff during the course of a project. The issues raised in
this chapter have impacts at all stages of project planning and execution but in particular at the following
points (see also Figure 11.1).

● Some objectives can address health and safety during the project (Step 1).
● Although project leaders might have little control over organizational structure, they need to be aware of
its implications (Step 2).
● The scope and nature of activities can be set in a way that will enhance staff motivation (Step 4).
● Many risks to project success relate to staffing (Step 6).
● The qualities of individual members of staff should be taken into account when allocating staff to
activities (Step 7).
 Understanding Behaviors
People with practical experience of projects invariably identify the handling of people as an important
aspect of project management. People like Amanda and Brigette would want to know whether the effective
and sensitive management of staff comes only from experience or whether expert advice can help. Such
advice may be more convincing if it is based on evidence that has been gathered through some kind of
research.

This research into individual and group behaviour in software and ICT development environments needs to
adopt social science research methods. This type of research requires a different mindset to that usually
needed by software developers. Although the development of systems is usually based on user
requirements that can be interpreted in more than one way, the end result is a system that works in a
perfectly consistent way. The developers who produce such systems will inevitably have a tendency to see
things in terms of deterministic systems where once a sequence of inputs is known, the outputs can be
forecast with some certainty.

Such systems are perceived as being governed by mechanistic laws, just as there are in the physical
sciences such as chemistry. This mindset tends to favour experimentation as the means of establishing the
relationships between inputs and outputs and is sometimes referred to as a positivist approach. Attempts
have been made to extend this model to social systems. However, because social systems, including
business organizations, are so complex, it is not possible to predict their outcomes with any certainty. What
can be done is to detect statistical relationships within such systems that can be expressed as generalized
models or theories.

The discipline of organizational behaviour has evolved theories that try to explain people’s behaviour.
These theories are often structured as ‘If A is the situation then B is likely to result’. Attempts are made to
observe behaviour where variables for A and B are measured and a statistical relationship between the two
variables sought. Unlike physical science it is rarely, if ever, that it can be said that B must always follow A.
An interpretivist school of thought can be contrasted with the positivist one, particularly in relation to the
extension of the quantitative and experimental methods from the physical sciences to people and
organizations.

Interpretivists point out that many concepts are not objective but are inter-subjective ones created by
human beings. For example, later in this chapter we will examine whether there are particular personal
characteristics that are associated with successful software developers. Some studies have found personal
characteristics that seem to be strongly associated with ‘software engineers’ while other studies have found
none. One question here would be how ‘software engineer’ is defined. Would someone who customizes
and instals off-the-shelf packaged software count as a ‘software engineer’? Would the description
‘software engineer’ cover the role of the ICT business analyst? Furthermore, how would you define
‘successful’? Is it someone who can write lots of code very quickly? Or someone who knows where to find
the right existing software to do a job? One way of resolving such questions would be to look closely at
specific ICT environments and observe the different types of role that people undertake and the tasks and
skills associated with such roles. The typical way of doing this is an in-depth study of a small number
(perhaps only one) of instances of a particular type of organization which produces a description of how
things are done in that context.

The two viewpoints labelled positivist and interpretivist can both be valid and useful. In the types of
research that underpin the material in the current chapter on individuals in work environments the
quantitative (or ‘positivist’) type predominates. In the following chapter on working in teams the research
drawn upon tends to be more qualitative and based on case studies in the interpretivist tradition.
 Organizational Behavior: A Background
The roots of studies in OB can be traced back to work done in the late 19th and early 20th centuries by
Frederick Taylor. Taylor attempted to analyse the most productive way of doing manual tasks. The workers
were then trained to do the work in this way.

Taylor had three basic objectives:

● to select the best people for the job;
● to instruct them in the best methods;
● to give incentives in the form of higher wages to the best workers.

‘Taylorism’ is often represented as crude and mechanistic. However, a concern for identifying best practice
is valid. In the more mundane world of software development, the growth of both structured and agile
methods is an example of an emphasis on best practice. Both Amanda and Brigette will be concerned that
tasks are carried out in the proper way. More contentious is Taylor’s emphasis on the exclusively financial
basis of staff motivation, although Amanda and Brigette will find many colleagues who hold Taylor’s view
on the importance of ‘performance-related pay’. Unfortunately, Amanda and Brigette are likely to have
very little control over the financial rewards of their staff. However, they should be encouraged by findings
that motivation rests not just on such rewards.

During the 1920s, OB researchers discovered, while carrying out a now famous set of tests on the
conditions under which staff worked best, that not only did a group of workers for whom conditions were
improved increase their work-rates, but also a control group for whom conditions were unchanged. Simply
showing a concern for what workers did increased productivity. This illustrated how the state of mind of
workers influenced their productivity.
 The cash-oriented, or instrumental, view of work of some managers can thus be contrasted with a more
rounded vision of people in their place of work. The two attitudes were labelled Theory X and Theory Y by
Donald McGregor.

Theory X holds that:

● the average human has an innate dislike of work;
● there is a need therefore for coercion, direction and control;
● people tend to avoid responsibility.

Theory Y, on the other hand, holds that:

● work is as natural as rest or play;
● external control and coercion are not the only ways of bringing about effort directed towards an
organization’s ends;
● commitment to objectives is a function of the rewards associated with their achievement;
● the average human can learn to accept and further seek responsibility;
● the capacity to exercise imagination and other creative qualities is widely distributed.
 Selecting the Right Person for the Job
Taylor stressed the need for the right person for the job. Many factors, such as the use of software tools and
methodologies, affect programming productivity. However, one of the biggest differences in software
development performance is between individuals. As early as 1968 a comparison of experienced
professional programmers working on the same programming task found a ratio, in one case, of 1:25
between the shortest and longest time to code the program and, more significantly perhaps, of 1:28 for the
time taken to debug it. Amanda and Brigette would therefore be rightly concerned to get the best possible
people working for them.

What sort of characteristics should they be looking for? Is an experienced programmer better than a new
graduate with a first-class mathematics degree? It is dangerous to generalize but, looking at behavioural
characteristics, the American researcher Cheney found that the most important influence on programmer
productivity seemed to be experience. This is not surprising as the impact of experience is the most
important factor in software productivity in Boehm’s COCOMO models – see Chapter 5. Cheney found
that mathematical aptitude had quite a weak influence in comparison.

Amanda and Brigette will want staff who can communicate well with each other and with users.
Unfortunately, the American researchers Couger and Zawacki found that information systems (IS)
professionals seemed to have much weaker ‘social needs’ than people in other professions. They quote
Gerald Weinberg: ‘If asked, most programmers probably say they prefer to work alone where they wouldn’t
be disturbed by other people.’ We see many who are attracted to writing software, and are good at it, but
do not make good managers later in their careers.
 The recruitment process
It must be stressed that often project leaders have little choice about the people who will make up their team
– they have to make do with the ‘materials that are to hand’. Recruitment is often an organizational
responsibility:
the person recruited might, over a period of time, work in many different parts of the organization.

Meredith Belbin usefully distinguishes between eligible and suitable candidates. Eligible candidates have a
curriculum vitae (CV) which shows, for example, the ‘right’ number of years in some previous post and the
‘right’ paper qualifications. Suitable candidates can actually do the job well. A mistake is to select an eligible
candidate who is not in fact suitable. Suitable candidates who are not officially eligible can, on the other hand,
be ideal candidates as once in post they are more likely to remain loyal. Belbin suggests we should try to assess
actual skills rather than past experience and provide training to make good minor gaps in expertise. It seems to
us to show that policies that avoid discrimination on the grounds of race, gender, age or irrelevant disabilities
can be not just socially responsible but also a shrewd recruitment policy.

A general approach might be the following.

● Create a job specification Advice is often needed as there could be legal implications in an official document.
However, formally or informally, the requirements of the job, including the types of task to be carried out,
should be documented and agreed.
● Create a job holder profile The job specification is used to construct a profile of the person needed to carry
out the job. The qualities, qualifications, education and experience required would be listed.
● Obtain applicants Typically, an advertisement would be placed, either within the organization or outside in
the trade or local press. The job holder profile would be examined carefully to identify the medium most likely
to reach the largest number of potential applicants at least cost. For example, if a specialist is needed it would
make sense to advertise in the relevant specialist journal. The other principle is to give enough information in
the advertisement to allow an element of self-elimination. By giving the salary, location, job scope and any
essential qualifications, the applicants will be limited to the more realistic candidates.
● Examine CVs These should be read carefully and compared to the job holder profile – nothing is more
annoying for all concerned than when people have CVs which indicate clearly that they are not eligible for
the job and yet are called for interview.
● Interviews, etc. Selection techniques include aptitude tests, personality tests and the examination of
samples of previous work. Any method must test specific qualities detailed in the job holder profile.

Interviews are the most commonly used method. It is better if there is more than one interview session with
an applicant and within each session there should not be more than two interviewers as a greater number
reduces the possibility of follow-up questions and discussion. Some formal scoring system for the qualities
being judged should be devised and interviewers should then individually decide scores which are then
compared. An interview might be of a technical nature where the practical expertise of the candidate is
assessed, or of a more general nature. In the latter case, a major part of the interview could be evaluating
and confirming statements in the CV – for example, time gaps in the education and employment history
would be investigated, and the precise nature of previous jobs would need to be explored.

Other procedures References will need to be taken up where necessary, and a medical examination might
be needed.
 Instruction in the Best Methods
This is the second concern that we have taken from Taylor. When new members of the team are recruited,
the team leader will need to plan their induction into the team very carefully. Where a project is already
well under way, this might not be easy. However, the effort should be made – it should pay off as the new
recruit will become a fully effective member of the team more quickly.

The team leader should be aware of the need to assess continually the training needs of their team
members. Just as you formulate a user requirement before considering a new system, and a job holder
profile before recruiting a member of staff, so a training needs profile ought to be drawn up for each staff
member when considering specific courses. Some training might be provided by commercial training
companies. Where money is tight, alternative sources of training should be considered but training should
not be abandoned. It could just be a team member finding out about a new software tool and then
demonstrating it to colleagues.

Of course, the nice thing about external courses is talking to colleagues from other organizations – but
attending meetings of your local branch of a computer-related professional association, such as the British
Computer Society (BCS) in the United Kingdom, can serve the same purpose. The methods learnt need, of
course, to be actually applied. Reviews and inspections help to ensure this
 Motivation
The third of Taylor’s concerns was that of motivating people to work. We are going to look at some models
of motivation.
• The Taylorist model
Taylor’s viewpoint is reflected in the use of piece-rates in manufacturing industries and sales bonuses
amongst sales forces. Piece-rates can cause difficulties if a new system will change work practices. If new
technology improves productivity, adjusting piece-rates to reflect this will be a sensitive issue. Usually,
radical changes in work practices have to be preceded by a move from piece-rates to day-rates. As will be
seen later, the tendency towards dispersed or ‘virtual projects’ where staff work on their own premises at
some distance from the sponsoring organization’s site has seen a movement away from payment based on
time worked. Even where work practices are stable and output can be easily related to reward, people paid
by the amount they produce will not automatically maximize their output in order to maximize their
income. The amount of output will often by constrained by ‘group norms’: informal, even unspoken,
agreements among colleagues about the amount to be produced. Rewards based on piece-rates need to
relate directly to work produced. Where a computer application is being developed, it is difficult to isolate
and quantify work done by an individual, as system development and support is usually a team effort. As
one member of staff in a study of software support work said: ‘This support department does well because
we’re a team, not because we’re all individuals. I think it’s the only way the support team can work
successfully.’

In this kind of environment, a reward system that makes excessive distinctions between co-workers could
damage morale and productivity. Organizations sometimes get around this problem by giving bonuses to
project team members at the end of a successful project, especially if staff have ‘volunteered’ considerable
unpaid overtime to get the project completed.
Maslow’s hierarchy of needs

The motivation of individuals varies. Money is a strong motivator when you are broke. However, as the
basic need for cash is satisfied, other motivators are likely to emerge. Abraham Maslow, an American
psychologist, suggested a hierarchy of needs. As a lower level of needs is satisfied then gradually a higher
level of needs emerges. If these are then satisfied then another level will emerge. Basic needs include food,
shelter and personal safety. The highest-level need, according to Maslow, is the need for ‘self-
actualization’, the feeling that you are completely fulfilling your potential.

In practice, people are likely to be motivated by different things at different stages of their life. For
example, salary increases, while always welcome, probably have less impact on the more mature employee
who is already relatively well paid than on a lowly paid trainee. Older team-members might place more
value on qualities of the job, such as being given autonomy, which show respect for their judgement and
sense of responsibility.

Some individual differences in motivation relate simply to personality differences. Some staff have
‘growth needs’ – they are interested in their work and want to develop their work roles – while others
simply see the job as a way of earning a living.
• Herzberg’s two-factor theory

Some things about a job can make you dissatisfied. If the causes of this dissatisfaction are removed, this
does not necessarily make the job more exciting. Research into job satisfaction by Herzberg and his
associates found two sets of factors about a job:

● hygiene or maintenance factors, which can make you dissatisfied if they are not right, for example the
level of pay or the working conditions;

● motivators, which make you feel that the job is worthwhile, like a sense of achievement or the challenge
of the work itself. Brigette, at Brightmouth College, might be in an environment where it is difficult
to compete with the high level of maintenance factors that can be provided by a large organization like
IOE, but the smaller organization with its closer contact with the users might be able to provide better
motivators.
• The expectancy theory of motivation

Amanda and Brigette need to be aware of how the day-to-day ups and downs of system development affect
motivation. A model of motivation developed by Vroom and his colleagues illustrates this. It identifies
three influences on motivation:

● expectancy: the belief that working harder will lead to a better performance;
● instrumentality: the belief that better performance will be rewarded;
● perceived value: of the resulting reward.

Motivation will be high when all three factors are high. A zero level for any one of the factors can remove
motivation. Imagine trying to get a software package supplied by a third party to work. You realize that
you will never get it to work because of a bug, and you give up. No matter how hard you work you will not
be able to succeed (zero expectancy).

You are working on a package for a user and, although you think you can get it to work, you discover that
the user has started employing an alternative package and no longer needs this one. You will probably feel
you are wasting your time and give up (zero instrumentality).

Given that the users really do want the package, your reward might simply be the warm feeling of helping
your colleagues and their gratitude. If in fact, when the users employ the package, all they do is complain
and hold you responsible for shortcomings, then you might avoid getting involved if they later ask for help
implementing a different package (low perceived value of reward).
The Oldham–Hackman Job Characteristics
Model
Managers should group together the elements of tasks to be carried out so that they form meaningful and
satisfying assignments. Oldham and Hackman suggest that the satisfaction that a job gives is based on five
factors. The first three factors make the job ‘meaningful’ to the person who is doing it:

● skill variety: the number of different skills that the job holder has the opportunity to exercise;
● task identity: the degree to which your work and its results are identifiable as belonging to you;
● task significance: the degree to which your job has an influence on others.

The other two factors are:

● autonomy: the discretion you have about the way that you do the job;
● feedback: the information you get back about the results of your work.

Oldham and Hackman also noted that both the job holders’ personal growth needs and their working
environment influenced their perception of the job. Some writers have pointed out that if people are happy
with their work for other reasons, they are likely to rate it higher on the Oldham–Hackman dimensions
anyway. Thus it might be that cause and effect are reversed.
In practical terms, activities should be designed so that, where possible, staff follow the progress of a
particular product and feel personally associated with it.
Methods of improving motivation
To improve motivation the manager might therefore do the following.

● Set specific goals These goals need to be demanding and yet acceptable to staff. Involving staff in the
setting of goals helps to gain acceptance for them.

● Provide feedback Not only do goals have to be set but staff need regular feedback about how they are
progressing.

● Consider job design Jobs can be altered to make them more interesting and give staff more feeling of
responsibility.
Two measures are often used to enhance job design – job enlargement and job enrichment.

● Job enlargement The person doing the job carries out a wider variety of activities. It is the opposite of
increasing specialization. For example, a software developer in a maintenance group might be given
responsibility for specifying minor amendments as well as carrying out the actual code changes. Couger
and Zawacki found that programmer/analysts had higher job satisfaction than programmers. Job
enrichment The job holder carries out tasks that are normally done at a managerial or supervisory level.
With programmers in a maintenance team, they might be given authority to accept requests for changes
that involve less than five days’ work without the need for their manager’s approval. A comprehensive
survey of research into the motivation of software developers can be found in paper published by Sarah
Beecham and colleagues in 2008.
 Stress
Projects are about overcoming obstacles and achieving objectives. Almost by definition, both the project manager and team
members will be under pressure. An American project manager is quoted as saying: ‘Once a project gets rolling, you should
expect members to be putting in at least 60 hours a week. . . . The project leader must expect to put in as many hours as
possible. . . .’

Some pressure is actually healthy. Boredom can make many jobs soul-destroying. Beyond a certain level of pressure,
however, the quality of work decreases and health can be affected. There is good evidence that productivity and the quality of
output go down when more than about 40 hours a week are worked. As long ago as 1960 it was found in a US study that
people under 45 years of age who worked more than 48 hours a week had twice the risk of death from coronary heart disease.

Many software developers are expected to work overtime on projects for no additional payment. In these cases, a fall in
productivity is more than compensated for by the fact that the work is effectively free to the employer. Clearly, it is sometimes
necessary to put in extra effort to overcome some temporary obstacle or to deal with an emergency, but if overtime working
becomes a way of life then there will be longer-term problems. Good project management can reduce the reliance on overtime
by the more realistic assessment of effort and elapsed time needed, based on careful recording and analysis of the performance
of previous projects. Good planning and control will also help to reduce ‘unexpected’ problems generating unnecessary crises.

Stress can be caused by role ambiguity when staff do not have a clear idea of the objectives that their work is supposed to be
fulfilling, what is expected of them by others and the precise scope of their responsibilities. The project manager could clearly
be at fault in these instances.

Role conflict can also heighten stress. This is where the person is torn between the demands of two different roles. The parent
of young children might be torn between the need to look after a sick child and the need to attend an important meeting to win
new business.

Some managers claim to be successful through the use of essentially bullying tactics to push projects through. They need to
create crises in order to justify the use of such tactics. This, however, is the antithesis of professional project management
which aims at a rational, orderly and careful approach to the creation of complex products.
 Health and Safety
As far as the project manager is concerned, safety objectives, where appropriate, should be
treated like any other project objectives, such as the level of reliability of the completed
application or the overall cost of the project. The management of safety should therefore be
embedded in the general management of the project. Responsibility for safety must be clearly
defined at all levels. Some points that will need to be considered include:

● top management must be committed to the safety policy;

● the delegation of responsibilities for safety must be clear;
● job descriptions should include definitions of duties related to safety;
● those to whom responsibilities are delegated must understand the responsibilities and agree
to them;
● deployment of a safety officer and the support of experts in particular technical areas;
● consultation on safety;
● an adequate budgeting for safety costs.