ಬಿ.ಎಂ.ಎಸ್.

ತಂತ್ರಿ ಕ ಮತ್ತು ವ್ಯ ವ್ಸ್ಥಾ ಪನಾ ಮಹಾವಿದ್ಯಯ ಲಯ

BMS Institute of Technology and Management
(An Autonomous Institution Affiliated to VTU, Belagavi)
Avalahalli, Doddaballapur Main Road, Bengaluru – 560064

Department of Information Science and Engineering

Course Name: Software Engineering and Project Semester: V
Management
Course Code: BCS501 Faculty: Dr. Harish Kumar N
Module 5
Project management: Risk management, Managing people, Teamwork
Project planning: Software pricing. Plan-driven development, Project scheduling.

 Software project management is an essential part of software engineering.

 Projects need to be managed because professional software engineering is always subject to
organizational budget and schedule constraints.
 The project manager’s job is to ensure that the software project meets and overcomes these
constraints as well as delivering high-quality software.
 Good management cannot guarantee project success.
 However, bad management usually results in project failure: The software may be delivered late,
cost more than originally estimated, or fail to meet the expectations of customers.

The success criteria for project management obviously vary from project to project, but, for most
projects, important goals are:
■ to deliver the software to the customer at the agreed time;
■ to keep overall costs within budget;
■ to deliver software that meets the customer’s expectations;
■ to maintain a coherent and well-functioning development team.

However, software engineering is different from other types of engineering in a number of ways that
make software management particularly challenging. Some of these differences are:
1. The product is intangible A manager of a shipbuilding or a civil engineering project can see the
product being developed. If a schedule slips, the effect on the product is visible—parts of the structure
are obviously unfinished. Software is intangible. It cannot be seen or touched. Software project
managers cannot see progress by looking at the artifact that is being constructed. Rather, they rely on
others to produce evidence that they can use to review the progress of the work.

2. Large software projects are often “one-off” projects Every large software development project is
unique because every environment where software is developed is, in some ways, different from all
others. Even managers who have a large body of previous experience may find it difficult to anticipate
problems. Furthermore, rapid technological changes in computers and communications can make
experience obsolete. Lessons learned from previous projects may not be readily transferable to new
projects.
3. Software processes are variable and organization-specific The engineering process for some types
of system, such as bridges and buildings, is well understood. However, different companies use quite
different software development processes. We cannot reliably predict when a particular software
process is likely to lead to development problems. This is especially true when the software project is
part of a wider systems engineering project or when completely new software is being developed.
Some of the most important factors that affect how software projects are managed
are:

1. Company size Small companies can operate with informal management and team communications
and do not need formal policies and management structures. They have less management overhead
than larger organizations. In larger organizations, management hierarchies, formal reporting and
budgeting, and approval processes must be followed.
2. Software customers If the customer is an internal customer (as is the case for software product
development), then customer communications can be informal and there is no need to fit in with the
customer’s ways of working. If custom software is being developed for an external customer,
agreement has to be reached on more formal communication channels. If the customer is a government
agency, the software company must operate according to the agency’s policies and procedures, which
are likely to be bureaucratic.
3. Software size Small systems can be developed by a small team, which can get together in the same
room to discuss progress and other management issues. Large systems usually need multiple
development teams that may be geographically distributed and in different companies. The project
manager has to coordinate the activities of these teams and arrange for them to communicate with each
other.
4. Software type If the software being developed is a consumer product, formal records of project
management decisions are unnecessary. On the other hand, if a safety-critical system is being
developed, all project management decisions should be recorded and justified as these may affect the
safety of the system.
5. Organizational culture Some organizations have a culture that is based on supporting and
encouraging individuals, while others are group focused. Large organizations are often bureaucratic.
Some organizations have a culture of taking risks, whereas others are risk averse.
6. Software development processes Agile processes typically try to operate with “lightweight”
management. More formal processes require management monitoring to ensure that the development
team is following the defined process.

However, a number of fundamental project management activities are common to all

organizations:

1. Project planning Project managers are responsible for planning, estimating, and scheduling project
development and assigning people to tasks. They supervise the work to ensure that it is carried out to
the required standards, and they monitor progress to check that the development is on time and within
budget.
2. Risk management Project managers have to assess the risks that may affect a project, monitor these
risks, and take action when problems arise.
3. People management Project managers are responsible for managing a team of people. They have to
choose people for their team and establish ways of working that lead to effective team performance.
4. 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. They have to be able to
communicate at a range of levels, from detailed technical information to management summaries. They
have to write concise, coherent documents that abstract critical information from detailed project
reports. They must be able to present this information during progress reviews.
5. 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. It usually includes cost and schedule estimates and justifies why the project contract
should be awarded to a particular organization or team. Proposal writing is a critical task as the survival
of many software companies depends on having enough proposals accepted and contracts awarded.
Risk management
 Risk management is one of the most important jobs for a project manager.
 Risks may threaten the project, the software that is being developed, or the organization.
 Risk management involves anticipating risks that might affect the project schedule or the
quality of the software being developed, and then taking action to avoid these risks

Risks can be categorized according to type of risk

1. Project risks affect the project schedule or resources. An example of a project risk is the loss of
an experienced system architect. Finding a replacement architect with appropriate skills and experience
may take a long time; consequently, it will take longer to develop the software design than originally
planned.
2. Product risks affect the quality or performance of the software being developed. An example
of a product risk is the failure of a purchased component to perform as expected. This may affect the
overall performance of the system so that it is slower than expected.
3. Business risks affect the organization developing or procuring the software. For example, a
competitor introducing a new product is a business risk. The introduction of a competitive product may
mean that the assumptions made about sales of existing software products may be unduly optimistic.

An outline of the process of risk management is presented. It involves several stages:

1. Risk identification You should identify possible project, product, and business risks.
2. Risk analysis You should assess the likelihood and consequences of these risks.
3. Risk planning You should make plans to address the risk, either by avoiding it or by minimizing its
effects on the project.
4. Risk monitoring You should regularly assess the risk and your plans for risk mitigation and revise
these plans when you learn more about the risk.
Risk identification
Risk identification is the first stage of the risk management process.
It is concerned with identifying the risks that could pose a major threat to the software engineering
process, the software being developed, or the development organization.
Risk identification may be a team process in which a team gets together to brainstorm possible risks.
Alternatively, project managers may identify risks based on their experience of what went wrong on
previous projects.
As a starting point for risk identification, a checklist of different types of risk may be used.

Six types of risk may be included in a risk checklist:

1. Estimation risks arise from the management estimates of the resources required to build the system.
2. Organizational risks arise from the organizational environment where the software is being
developed.
3. People risks are associated with the people in the development team.
4. Requirements risks come from changes to the customer requirements and the process of managing
the requirements change.
5. Technology risks come from the software or hardware technologies that are used to develop the
system.
6. Tools risks come from the software tools and other support software used to develop the system.
Risk analysis
During the risk analysis process, you have to consider each identified risk and make a judgment about
the probability and seriousness of that risk. There is no easy way to do so. You have to rely on your
judgment and experience of previous projects and the problems that arose in them. It is not possible to
make precise, numeric assessment of the probability and seriousness of each risk. Rather, you should
assign the risk to one of a number of bands:
1. The probability of the risk might be assessed as insignificant, low, moderate, high, or very high.
2. The effects of the risk might be assessed as catastrophic (threaten the survival of the project), serious
(would cause major delays), tolerable (delays are within allowed contingency), or insignificant.
Risk planning
The risk planning process develops strategies to manage the key risks that threaten the project. For
each risk, you have to think of actions that you might take to minimize the disruption to the project if
the problem identified in the risk occurs.
You should also think about the information that you need to collect while monitoring the project so
that emerging problems can be detected before they become serious.
In risk planning, you have to ask “what-if” questions that consider both individual risks, combinations
of risks, and external factors that affect these risks.

1. What if several engineers are ill at the same time?

2. What if an economic downturn leads to budget cuts of 20% for the project?
3. What if the performance of open-source software is inadequate and the only expert on that open-
source software leaves?
4. What if the company that supplies and maintains software components goes out of business?
5. What if the customer fails to deliver the revised requirements as predicted?
These strategies fall into three categories:
1. Avoidance strategies Following these strategies means that the probability that the risk will arise is
reduced. An example of a risk avoidance strategy is the strategy for dealing with defective components
shown in Figure 22.5.
2. Minimization strategies Following these strategies means that the impact of the risk is reduced. An
example of a risk minimization strategy is the strategy for staff illness shown in Figure 22.5.
3. Contingency plans Following these strategies means that you are prepared for the worst and have a
strategy in place to deal with it.

Risk monitoring
 Risk monitoring is the process of checking that your assumptions about the product, process, and
business risks have not changed.
 You should regularly assess each of the identified risks to decide whether or not that risk is
becoming more or less probable.
 You should also think about whether or not the effects of the risk have changed. To do this, you
have to look at other factors, such as the number of requirements change requests, which give
you clues about the risk probability and its effects.
 These factors are obviously dependent on the types of risk. You should monitor risks regularly
at all stages in a project.
 At every management review, you should consider and discuss each of the key risks separately.
 You should decide if the risk is more or less likely to arise and if the seriousness and
consequences of the risk have changed.
Managing people
 The people working in a software organization are its greatest assets.
 It is expensive to recruit and retain good people, and it is up to software managers to ensure that
the engineers working on a project are as productive as possible.
 In successful companies and economies, this productivity is achieved when people are respected
by the organization and are assigned responsibilities that reflect their skills and experience.
 It is important that software project managers understand the technical issues that influence the
work of software development.

There are four critical factors that influence the relationship between a manager and the people
that he or she manages:
1. Consistency All the people in a project team should be treated in a comparable way. No one expects
all rewards to be identical, but people should not feel that their contribution to the organization is
undervalued.
2. Respect Different people have different skills, and managers should respect these differences. All
members of the team should be given an opportunity to make a contribution. In some cases, of course,
you will find that people simply don’t fit into a team and they cannot continue, but it is important not
to jump to conclusions about them at an early stage in the project.
3. Inclusion People contribute effectively when they feel that others listen to them and take account
of their proposals. It is important to develop a working environment where all views, even those of the
least experienced staff, are considered.
4. Honesty As a manager, you should always be honest about what is going well and what is going
badly in the team. You should also be honest about your level of technical knowledge and be willing
to defer to staff with more knowledge when necessary. If you try to cover up ignorance or problems,
you will eventually be found out and will lose the respect of the group.
Motivating people
As a project manager, you need to motivate the people who work with you so that they will contribute
to the best of their abilities. In practice, motivation means organizing work and its environment to
encourage people to work as effectively as possible. If people are not motivated, they will be less
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 People working in software
development organizations are not usually hungry, thirsty, or physically threatened by their
environment.
Therefore, making sure that peoples’ social, esteem, and self-realization needs are satisfied is most
important from a management point of view.
1. To satisfy social needs, you need to give people time to meet their co-workers and provide places
for them to meet. Software companies such as Google provide social space in their offices for people
to get together. This is relatively easy when all of the members of a development team work in the
same place, but, increasingly, team members are not located in the same building or even the same
town or state. They may work for different organizations or from home most of the time.
2. To satisfy esteem needs, you need to show people that they are valued by the organization. Public
recognition of achievements is a simple and effective way of doing this. Obviously, people must also
feel that they are paid at a level that reflects their skills and experience.
3. Finally, to satisfy self-realization needs, you need to give people responsibility for their work,
assign them demanding (but not impossible) tasks, and provide opportunities for training and
development where people can enhance their skills. Training is an important motivating influence as
people like to gain new knowledge and learn new skills.

Teamwork
Most professional software is developed by project teams that range in size from two to several hundred
people. However, as it is impossible for everyone in a large group to work together on a single problem,
large teams are usually split into a number of smaller groups. Each group is responsible for developing
part of the overall system. The best size for a software engineering group is 4 to 6 members, and they
should never have more than 12 members. When groups are small, communication problems are
reduced. Everyone knows everyone else, and the whole group can get around a table for a meeting to
discuss the project and the software that they are developing.

In a cohesive group, members think of the group as more important than the individuals who
are group members. Members of a well-led, cohesive group are loyal to the group. They identify with
group goals and other group members. They attempt to protect the group, as an entity, from outside
interference. This makes the group robust and able to cope with problems and unexpected situations.
The benefits of creating a cohesive group are:
1. The group can establish its own quality standards because these standards are established by
consensus, they are more likely to be observed than external standards imposed on the group.
2. Individuals learn from and support each other Group members learn by working together.
Inhibitions caused by ignorance are minimized as mutual learning is encouraged.
3. Knowledge is shared Continuity can be maintained if a group member leaves. Others in the group
can take over critical tasks and ensure that the project is not unduly disrupted.
4. Refactoring and continual improvement is encouraged Group members work collectively to
deliver high-quality results and fix problems, irrespective of the individuals who originally created the
design or program.

Given a stable organizational and project environment, the three factors that have the biggest effect
on team working are:
1. 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.
2. The way the group is organized A group should be organized so that individuals can contribute to
the best of their abilities and tasks can be completed as expected.
3. Technical and managerial communications Good communication between group members, and
between the software engineering team and other project stakeholders, is essential.

Group organization
The way a group is organized affects the group’s decisions, the ways information is exchanged, and
the interactions between the development group and external project stakeholders. Important
organizational questions for project managers include the following:
1. Should the project manager be the technical leader of the group? The technical leader or system
architect is responsible for the critical technical decisions made during software development.
Sometimes the project manager has the skill and experience to take on this role. However, for large
projects, it is best to separate technical and managerial roles. The project manager should appoint a
senior engineer to be the project architect, who will take responsibility for technical leadership.
2. Who will be involved in making critical technical decisions, and how will these decisions be made?
Will decisions be made by the system architect or the project manager or by reaching consensus among
a wider range of team members?
3. How will interactions with external stakeholders and senior company management be handled? In
many cases, the project manager will be responsible for these interactions, assisted by the system
architect if there is one. However, an alternative organizational model is to create a dedicated role
concerned with external liaison and appoint someone with appropriate interaction skills to that role.
4. How can groups integrate people who are not co-located? It is now common for groups to include
members from different organizations and for people to work from home as well as in a shared office.
This change has to be considered in group decision-making processes.
5. How can knowledge be shared across the group? Group organization affects information sharing as
certain methods of organization are better for sharing than others. However, you should avoid too much
information sharing as people become overloaded and excessive information distracts them from their
work.

Group communications

It is absolutely essential that group members communicate effectively and efficiently with each other
and with other project stakeholders. Group members must exchange information on the status of their
work, the design decisions that have been made, and changes to previous design decisions. They
have to resolve problems that arise with other stakeholders and inform these stakeholders of changes
to the system, the group, and delivery plans. Good communication also helps strengthen group
cohesiveness.
Group members come to understand the motivations, strengths, and weaknesses of other people in the
group.
The effectiveness and efficiency of communications are influenced by:
1. Group size As a group gets bigger, it gets harder for members to communicate effectively.
The number of one-way communication links is n * (n − 1), where n is the group size, so, with a group
of eight members, there are 56 possible communication pathways. This means that it is quite possible
that some people will rarely communicate with each other. Status differences between group members
mean that communications are often one-way. Managers and experienced engineers tend to dominate
communications with less experienced staff, who may be reluctant to start a conversation or make
critical remarks.
2. Group structure People in informally structured groups communicate more effectively than people
in groups with a formal, hierarchical structure. In hierarchical groups, communications tend to flow up
and down the hierarchy. People at the same level may not talk to each other. This is a particular problem
in a large project with several development groups. If people working on different subsystems only
communicate through their managers, then there are more likely to be delays and misunderstandings.
3. Group composition People with the same personality types (discussed in Section 22.2) may clash,
and, as a result, communications can be inhibited. Communication is also usually better in mixed-sex
groups than in single-sex groups (Marshall and Heslin 1975). Women are often more interaction-
oriented than men and may act as interaction controllers and facilitators for the group.
4. The physical work environment The organization of the workplace is a major factor in facilitating
or inhibiting communications. While some companies use standard open-plan offices for their staff,
others invest in providing a workspace that includes a mixture of private and group working areas.
This allows for both collaborative activities and individual development that require a high level of
concentration.
5. The available communication channels There are many different forms of communication—
face to face, email messages, formal documents, telephone, and technologies such as social networking
and wikis. As project teams become increasingly distributed, with team members working remotely,
you need to make use of interaction technologies, such as conferencing systems, to facilitate group
communications.

Project managers usually work to tight deadlines, and, consequently, they often try to use
communication channels that don’t take up too much of their time. They may rely on meetings and
formal documents to pass on information to project staff and stakeholders and send long emails to
project staff. Unfortunately, while this may be an efficient approach to communication from a project
manager’s perspective, it is not usually very effective.

Project planning
Project planning is one of the most important jobs of a software project manager. As a manager, you have to break down
the work into parts and assign them to project team members, anticipate problems that might arise, and prepare tentative
solutions to those problems. The project plan, which is created at the start of a project and updated as the project progresses,
is used to show how the work will be done and to assess progress on the project.
Project planning takes place at three stages in a project life cycle:
1. At the proposal stage, when you are bidding for a contract to develop or provide a software system. You need a plan at
this stage to help you decide if you have the resources to complete the work and to work out the price that you should quote
to a customer.
2. During the project startup phase, when you have to plan who will work on the project, how the project will be broken
down into increments, how resources will be allocated across your company, and so on. Here, you have more information
than at the proposal stage, and you can therefore refine the initial effort estimates that you have prepared.
3. Periodically throughout the project, when you update your plan to reflect new information about the software and its
development. You learn more about the system being implemented and the capabilities of your development team. As
software requirements change, the work breakdown has to be altered and the schedule extended. This information allows
you to make more accurate estimates of how long the work will take.

Software pricing

In principle, the price of a software system developed for a customer is simply the cost of development plus profit for the
developer. In practice, however, the relationship between the project cost and the price quoted to the customer is not usually
so simple. When calculating a price, you take broader organizational, economic, political, and business considerations into
account some of the project pricing issues

Plan-driven development
Plan-driven or plan-based development is an approach to software engineering where the development process is planned
in detail. A project plan is created that records the work to be done, who will do it, the development schedule, and the work
products. Managers use the plan to support project decision making and as a way of measuring progress. Plan-driven
development is based on engineering project management techniques and can be thought of as the “traditional” way of
managing large software development projects.
The problem with plan-driven development is that early decisions have to be revised because of changes to the
environments in which the software is developed and used. Delaying planning decisions avoids unnecessary rework.
However, the arguments in favour of a plan-driven approach are that early planning allows organizational issues
(availability of staff, other projects, etc.) to be taken into account. Potential problems and dependencies are discovered
before the project starts, rather than once the project is underway.

Project plans
In a plan-driven development project, a project plan sets out the resources available to the project, the work breakdown,
and a schedule for carrying out the work. The plan should identify the approach that is taken to risk management as well
as risks to the project and the software under development.
The details of project plans vary depending on the type of project and organization but plans normally include the
following sections
1. Introduction Briefly describes the objectives of the project and sets out the constraints (e.g., budget, time) that affect
the management of the project.
2. Project organization Describes the way in which the development team is organized, the people involved, and their
roles in the team.
3. Risk analysis Describes possible project risks, the likelihood of these risks arising, and the risk reduction strategies
(discussed in Chapter 22) that are proposed.
4. Hardware and software resource requirements Specifies the hardware and support software required to carry out the
development. If hardware has to be purchased, estimates of the prices and the delivery schedule may be included.
5. Work breakdown Sets out the breakdown of the project into activities and identifies the inputs to and the outputs from
each project activity.
6. Project schedule Shows the dependencies between activities, the estimated time required to reach each milestone, and
the allocation of people to activities. The ways in which the schedule may be presented are discussed in the next section
of the chapter.
7. Monitoring and reporting mechanisms Defines the management reports that should be produced, when these should be
produced, and the project monitoring mechanisms to be used.