LECTURE 4: PROJECT MANAGEMENT

4.1 Introduction
In this lecture we shall learn the basic concepts in software project management.

4.2 Specific Objectives

At the end of the lecture you should be able to:
1) Define software project management
2) Explain the basic concepts in software project management
3) Describe the Risk management process

4.3 Lecture Outline

4.3.1 Software project management

4.3.2 People
4.3.3 The Process
4.3.4 The Project
4.3.5 Risk management

4.4 Software Project Management

Software project management is concerned with activities involved in ensuring that software is
delivered on time and on schedule and in line with the requirements of the organisations
developing and procuring the software. Project management is needed because software
development is always subject to budget and schedule constraints that are set by the organisation
developing the software.

Some of the activities undertaken during project management include

 Project planning: Project managers are responsible for planning. estimating and
scheduling project development and assigning people to tasks.
 Reporting: Project managers are usually responsible for reporting on the progress of a
project to customers and to the managers of the company developing the software.
 Risk management: Project managers assess the risks that may affect a project, monitor
these risks and take action when problems arise.
 People management: Project managers have to choose people for their team and establish
ways of working that leads to effective team performance
 Proposal writing: The first stage in a software project may involve writing a proposal to
win a contract to carry out an item of work. The proposal describes the objectives of the
project and how it will be carried out.

The project success criteria includes the following aspects

 Delivering the software to the customer at the agreed time.
 Keeping overall costs within budget.
 Delivering software that meets the customer’s expectations.
The managing of software development differs from other types of management due to the
following
 The product is intangible: Software cannot be seen or touched. Software project
managers cannot see progress by simply looking at the artefact that is being constructed.
 Many software projects are 'one-off' projects: Large software projects are usually
different in some ways from previous projects. Even managers who have lots of previous
experience may find it difficult to anticipate problems.
 Software processes are variable and organization specific:We still cannot reliably predict
when a particular software process is likely to lead to development problems.

4.5 The Management Spectrum

Effective software project management focuses on the three P’s: people, problem, and process.
The order is not arbitrary. The manager who forgets that software engineering work is an
intensely human endeavor will never have success in project management. A manager who fails
to encourage comprehensive customer communication early in the evolution of a project risks
building an elegant solution for the wrong problem. Finally the manager who pays little attention
to the process runs the risk of inserting competent technical methods and tools into a vacuum.

4.5.1 People
The “people factor” is so important that the Software engineering Institute has developed a
people management capability maturity model in order to enhance the readiness of software
organizations to undertake increasingly complex applications to develop talent needed to
improve their software development capability.
The people management maturity model defines the following key practice areas for software
people career development, selection performance management, training, compensation, career
development, organization and work design and team culture development. Organization that
achieve high levels of maturity in the people management area have a higher likelihood of
implement effective software engineering practices.
The PM-CMM is a companion to the software capability maturity model which guides
organizations in the creation of a mature software process. Issues associated with people
management and structure for software projects are considered later in this lecture.

4.5.2 The Problem

Before a project can be planned, its objectives and scope should be established, alternative
solutions should be considered, technical and management constraints be identified. Without this
information, it is impossible to define accurate estimates of the cost, effective risk assessment,
realistic project task breakdown or a manageable project schedule that provides a meaningful
indication of process.
The software developer and customer must meet to define project objectives and scope. In many
cases, this activity begins as part of the system engineering process and continues as the first step
in software requirements analysis. Objectives identify the overall goals of the project without
considering how these goals will be achieved. Scope identifies the primary data, functions, and
behaviors that characterize the problem.
Once the project objectives and scope are understood, alternative solutions are considered.
Although very little details is discussed, the alternatives enables managers and practitioners to
select a “best” approach, given the project constraints imposed by delivery deadlines, budgetary
restrictions personnel availability, technical interfaces, and myriad other factors.

4.5.3 The Process

A software process provides the framework from which a comprehensive plan for software
development can be established. A small number of framework activities are applicable to all
software projects, regardless of their size or complexity. A number of different tasks, milestones,
deliverables, and quality assurance points enable the framework activities to be adapted to the
characteristics of the software project and the requirements of the project team. Finally, umbrella
activities such as software quality assurance, software configuration management, and
measurement overlay the process model. Umbrella activities are independent of any one-
framework activity and occur throughout the process.
The project manager must decide which process model is most appropriate for the project, then define a
preliminary plan based on the set of common process frame work activities. Once the preliminary plan is
established, process decomposition begins. That is, a complete plan reflecting the work tasks required to
populate the framework activities must be created.

4.6 Managing the Team

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.

4.6.1 The Players

The software process is populated by players who can be categorized into one of five
constituencies.

 Senior managers: define the business issues that often have significant influence on the
project.
 Project (technical) managers: plan, motivate, organize, and control the practitioners who
do software work.
 Practitioners: deliver the technical skills that, are necessary to engineer a product or
application.
 Customers: specify the requirements for the software to be engineered.
 End users: interact with the software once it is released for productions use.

To be effective, the project team must be organized in a way that maximizes each person’s skills
and abilities. That’s the job of the team leader.

4.6.2 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.
4.6.3 Motivation
This is the ability to encourage people to produce to their best ability.It is an important role for a
manager to motivate the people working on a project. It means organizing the work and the
working environment to encourage people to work effectively. If people are not motivated, they
will not be interested in the work they are doing. They will work slowly, be more likely to make
mistakes and will not contribute to the broader goals of the team or the organization. Motivation
is a complex issue but it appears that their are different types of motivation based on individuals
needs.
 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).

In software development groups, basic physiological and safety needs are not an issue.
 Social needs (e.g. Provide communal facilities; Allow informal communications e.g.
via social networking)
 Esteem needs (e.g. Recognition of achievements; Appropriate rewards.)
 Self-actualization (e.g.Training - people want to learn more; Responsibility)

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

Motivation should also take into account different 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.

Individual motivations are made up of elements of each class. The balance between the classes
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.

4.6.4 Teamwork
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. A good
group is cohesive and has a team spirit. The people involved are motivated by the success of the
group as well as by their own personal goals. Group interaction is a key determinant of group
performance.
Regardless of the team organization, the objective for every project manager is to help create a team that
exhibits cohesiveness. In their book, peopleware, DeMarco and Lister discuss a “ jelled team” - as a
group of people so strongly knit that the whole is greater than the sum of the parts. Once a team begins to
jell, the probability of success goes way up. They don’t need to be managed in the traditional way, and
they certainly don’t need to be motivated because they have momentum. They share a common goal and a
common culture.
In a cohesive group, members consider the group to be more important than any individual in it.The
advantages of a cohesive group include:
 Group quality standards can be developed by the group members.
 Team members learn from each other and get to know each other’s work; Inhibitions caused
by ignorance are reduced.
  Knowledge is shared. Continuity can be maintained if a group member leaves.
 The group members work collectively to deliver high quality results and fix problems,
irrespective of the individuals who originally created the design or program

4.6.4.1 Team effectiveness

The team effectiveness is affected by the following issues:
 The people in the group: You need a mix of people in a project group as software
development involves diverse activities such as negotiating with clients, programming,
testing and documentation.
 The group organization: A group should be organized so that individuals can contribute
to the best of their abilities and tasks can be completed as expected.
 Technical and managerial communications: Good communications between group
members, and between the software engineering team and other project stakeholders, is
essential.

4.6.4.2 Team selection

A manager or team leader’s job is to create a cohesive group and organize their group so that
they can work together effectively. This involves creating a group with the right balance of
technical skills and personalities, and organizing that group so that the members work together
effectively.

4.6.4.3 Team Composition

The team should be composed of members who share the same motivation. However this can be
problematic. 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.

4.6.4.3 Team organisation

The way that a group is organized affects the decisions that are made by that group, the ways that
information is exchanged and the interactions between the development group and external
project stakeholders. Small software engineering groups are usually organised informally
without a rigid structure. For larger projects, there may be a hierarchical structure where different
groups are responsible for different sub-projects. Agile development is based around an informal
group on the principle that formal structure inhibits information exchange. For informal group
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.
Instead, 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.
The key questions to be considered in team organisation include:
 Should the project manager be the technical leader of the group?
 Who will be involved in making critical technical decisions, and how will these be made?
 How will interactions with external stakeholders and senior company management be
handled?
 How can groups integrate people who are not co-located?
4.6.4.4 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.
 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

4.6.5 Effective project manager

The following are characteristics that define an effective project manager

 Organization The ability to mold existing processes that will enable the initial concept to
be translated into a final product.
 Ideas or innovation The ability to encourage people to create and feel creative even
when they must work within bounds established for a particular software product or
application.
 Problem solving An effective software project manager can diagnose technical and
organizational issues to develop a solution and remain flexible enough to change
direction if initial attempts at problem solution are fruitless.
 Managerial identity A good project manager must take charge of the project. He must
have the
 confidence to assume control when necessary and the assurance to allow good technical
people to follow their instincts.
 Achievement To optimize the productivity of a project team, a manager must reward
initiative and accomplishment, and demonstrate through his own actions that controlled
risk taking will not be punished.
 Influence and Team Building An effective project manager must be able to read people;
she must be able to understand verbal and nonverbal signals and react to the needs of the
people sending these signals.
 Control The manager must remain under control in high stress situations.

4.7 Project Risk Management

Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a
project. A risk is a probability that some adverse circumstance will occur. This will have the following
effect
 Project risks affect schedule or resources
 Product risks affect the quality or performance of the software being developed
 Business risks affect the organisation developing or procuring the software

4.7.1 The risk management process

The risk management process involves the following activities
Risk identification:
In the risk identification step, the team systematically enumerates as many project risks as possible to
make them explicit before they become problems. There are several ways to look at the kinds of software
project risks. A checklist of common risks may be used to identify risks in a project
 Technology risks.
 People risks.
 Organisational risks.
 Requirements risks.
 Estimation risks.

Risk analysis
After risks have been identified the next step is risk analysis. Through risk analysis, we transform the
risks that were identified into decision-making information. Each risk is considered and a judgment made
about the likelihood and consequences of these risks. The probability may be very low, low, moderate,
high or very high. Risk consequences might be catastrophic, serious, tolerable or insignificant.
Determining the probability and the magnitude of the risk can be difficult and can seem to be arbitrarily
chosen. One means of determining the risk probability is for each team member to estimate each of these
values individually. Then, the input of individual team members is collected in a round robin fashion and
reported to the group. The team then sorts the risk list so that the high probability, high impact risks
percolate to the top of the table and the low-probability, low impact risks drop to the bottom.

Risk planning
During planning each risk is considered and a strategy developed to manage that risk. The strategies
include
 Avoidance strategies: The probability that the risk will arise is reduced;
 Minimisation strategies: The impact of the risk on the project or product will be reduced;
 Contingency plans: If the risk arises, contingency plans are plans to deal with that risk;

Risk monitoring
During monitoring we assess each identified risks regularly to decide whether or not it is becoming less or
more probable. Also assess whether the effects of the risk have changed. Each key risk should be
discussed at management progress meetings. It is essential that the team regularly monitor the progress of
the product and the resolution of the risk items, taking corrective action when necessary. This monitoring
can be done as part of the team project management activities or through explicit risk management
activities.
 4. 8 Activities
1) Read on capability maturity models
2) Read Maslow’s Hierarchy of need
3) Identify examples
communication ofmost
have the risk in eachfor
value of practitioners.
the following categories
a) Technology risks.
b) People risks.
c) Organisational risks.
d) Requirements risks.
e) Estimation risks.

4. 9 Self Test Questions

1) Differentiate between the terms: task, milestone, activity and deliverable
2) What do we look for when we select someone to lead a software project ?
3) Define the three p’s in project management
4) Define the term risk mitigation and risk prioritization

4. 10 Summary
 Software project management is concerned with activities involved in ensuring
that software is delivered on time and on schedule and in line with the
requirements of the organisations developing and procuring the software
 There P’s have a substantial influence on software project management people, problem
and process.
 People must be organized into effective teams, motivated to do high quality software
work, and coordinated to achieve effective communication.
 The problem must be communicated from customer to developer, partitioned into its
constituent arts, and positioned for work by the software team.
 The process must be adapted to the people and the problem. A common process
framework is selected, an appropriate software engineering paradigm is applied, and a
set of work tasks is chosen to get the job done.
 Risk management involves identifying and assessing project risks to establish the
probability that they will occur and the consequences for the project if that risk does
arise. You should make plans to avoid, manage or deal with likely risks if or when they
arise.

4. References
Extracted from
 Ian Sommerville (2011) Software Engineering (11th Edition) Addison Wesley
 Kharagpur Software Engineering Online Notes