UNIT TITLE: SOFTWARE PROJECT MANAGEMENT

Chapter 1 - Software project management concept

1.1 Introduction

Project management involves the planning, monitoring, and control of the people, process, and events
that occur as software evolves from a preliminary concept to full operational deployment

Who does it?

Software engineer

 Plan, monitor, and control the technical tasks

Project manager

 Plan, monitor, and control the work of a team of software engineers

Senior manager

 Coordinate the interface between the business and software professionals.

1.2 The need for software project management

Building computer software is a complex undertaking, particularly if it involves many people working
over a relatively long time. That’s why software projects need to be managed.

1.3 Management spectrum

Effective software project management focuses on the four P’s:

1. People
2. Product
3. Process, and
4. Project

The manager who forgets that software engineering work is a people-intensive activity will never have
success in project management.

 People must be organized to perform software work effectively.

A manager who fails to encourage comprehensive stakeholder communication early in the evolution of a
product risks building an elegant solution for the wrong problem.

 Communication with the customer and other stakeholders must occur so that product scope and
requirements are understood.
The manager who pays little attention to the process runs the risk of inserting competent technical
methods and tools into a vacuum.

 A process that is appropriate for the people and the product should be selected ahead of time.

The manager who embarks without a solid project plan jeopardizes the success of the project.

 The project must be planned by estimating effort, cost and calendar time to accomplish work
tasks

Explaining the 4 P’s in more details

1. People

In a study published by the IEEE [Cur88], the engineering vice presidents of three major technology
companies were asked what was the most important contributor to a successful software project and

They answered in the following way:

VP 1: I guess if you had to pick one thing out that is most important in our environment, I’d say
it’s not the tools that we use, but the people.

VP 2: The most important ingredient that was successful on this project was having smart people
. . . The most
important thing you do for a project is selecting the staff. . . . The success of the software
development organization is very, very much associated with the ability to recruit good people.

VP 3: The only rule I have in management is to ensure I have good people—real good people—
and that I grow good people—and that I provide an environment in which good people can
produce.

This is a compelling testimonial on the importance of people in the software engineering process.

 The stakeholders

The software process (and every software project) is populated by stakeholders who can be categorized
into one of five categories:

1. Senior managers

The senior managers define the business issues that often have a significant influence on the project.
 2. Project (technical) managers

Project managers who are also called technical managers must plan, motivate, organize, and control the
practitioners who do software work.

3. Practitioners

The practitioners deliver the technical skills that are necessary to engineer a product or application.

4. Customers

Customers specify the requirements for the software to be engineered and other stakeholders who have
interest in the outcome.

5. End users

End users interact with the software once it is released for production use

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

1.4 Team leaders

Project management is a people-intensive activity, and for this reason, competent practitioners often
make poor team leaders. They simply don’t have the right mix of people skills.

In an excellent book of technical leadership, Jerry Weinberg [Wei86] suggests an MOI model of
leadership:

 Motivation - The ability to encourage technical people to produce to their best ability
 Organization - The ability to mold existing processes (or invent new ones) 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

Characteristics that define an effective project manager

These are the characteristics we look for when choosing someone to lead a software project

 Problem solving ability

 Managerial identity
 Achievement
 Influence and team building

1.5 Selecting staff

 ↔ One of the most important project management tasks is team selection.
↔ Budget limitations may constrain the number of expensive experienced engineers available to
work on the project.

The decision on who to appoint to a project is usually made using three types of information:

1. Information provided by candidates about their background and experience (their résumé
or CV).
This is usually the most reliable evidence that you have available to judge whether candidates
are likely to be suitable.
2. Information gained by interviewing candidates.
Interviews can give you a good impression of whether a candidate is a good communicator and
whether he or she has good social skills. However, tests have shown that interviewers are liable
to accept or reject candidates on the basis of rapid subjective judgements. Consequently,
interviews are not a reliable method for making judgements of technical capabilities.
3. Recommendations from people who have worked with the candidates.
This can be effective when you know the people making the recommendation. Otherwise, the
recommendations cannot be trusted and, it is of little use in making decisions about staff.

1.5.1 Factors governing staff selection

Factor Explanation

Application domain experience ↔ For a project to develop a successful system, the developers must
understand the application domain.
↔ It is essential that some members of a development team have some
domain experience.

Platform experience This may be significant if low-level programming is involved.

Otherwise, this is not usually a critical attribute.

Programming language This is normally only significant for short-duration projects where there is
experience not enough time to learn a new language.

Problem solving ability This is very important for software engineers who constantly have to solve
technical problems.

However, it is almost impossible to judge without knowing the work of the

potential team member.

Educational background ↔ This may provide an indicator of what the candidate knows and his
or her ability to learn.
 ↔ This factor becomes increasingly irrelevant as engineers gain
experience across a
range of projects.

Communication ability Project staff must be able to communicate orally and in writing with other
engineers, managers and customers

Adaptability ↔ Adaptability may be judged by looking at the experience that

candidates have had.
↔ This is an important attribute, as it indicates an ability to learn.

Attitude ↔ Project staff should have a positive attitude toward their work and
should be willing to learn new skills.
↔ This is an important attribute but often very difficult to assess.

Personality ↔ This is an important attribute but difficult to assess.

↔ Candidates must be reasonably compatible with other team
members.

1.6 Motivating people

↔ One of the roles of project managers is to motivate the people who work for them.
↔ Motivation means organising the work and the working environment so that people are
stimulated to work as effectively as possible.
↔ 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 organisation.

Maslow (Maslow 1954) suggests that people are motivated by satisfying their needs and that needs
are arranged in a series of levels
 ↔ The lower levels of this hierarchy represent fundamental needs

Example: food, sleep, air, water, security, sex etc

 Social needs - concerned with the need to feel part of a social grouping.
 Esteem needs - are the need to feel respected by others,
 Self-realisation needs - are concerned with personal development.
↔ Human priorities are to satisfy lower-level needs such as hunger before the more abstract,
higher-level needs.
↔ People working in software development organisations are not usually hungry or thirsty and
generally do not feel physically threatened by their environment.

Therefore, ensuring the satisfaction of social, esteem and self-realisation needs is most significant from a
management point of view.
Chapter-2 Software project estimation

2.1 Objectives

The objective of this chapter is to introduce techniques for estimating the cost and effort required for
software production.

Estimation involves answering the following questions:

 How much effort is required to complete each activity?

 How much calendar time is needed to complete each activity?
 What is the total cost of each activity?

The initial cost estimate may be used to establish a budget for the project or to set a price for the
software for a customer.

There are three parameters involved in computing the total cost of a software development project:

 Hardware and software costs including maintenance

 Travel and training costs
 Effort costs (the costs of paying software engineers).

2.2 Software pricing

If the project cost has been computed as part of a project bid to a customer, a decision then has to be
made about the price quoted to the customer.

Classically, Price = Cost + Profit

Software pricing must take into account broader organisational, economic, political and business
considerations

2.3 Factors affecting software pricing

Factor Description

Market opportunity A development organisation may quote a low price because it wishes to move into a
new segment of the software market. Accepting a low profit on one project may give
the organisation the opportunity to make a greater profit later. The experience gained
may also help it develop new products.

Cost estimate If an organisation is unsure of its cost estimate, it may increase its price by some
uncertainty contingency over and above its normal profit.
Contractual terms A customer may be willing to allow the developer to retain ownership of the source
code and reuse it in other projects. The price charged may then be less than if the
software source code is handed over to the customer.

Requirements volatility If the requirements are likely to change, an organisation may lower its price to win a
contract. After the contract is awarded, high prices can be charged for changes to the
requirements.

Financial health Developers in financial difficulty may lower their price to gain a contract. It is better to
make a smaller than normal profit or break even than to go out of business.

2.3 Software productivity

Estimating the productivity of software engineers

You may need these productivity estimates to:

 Help define the project cost or schedule,

 Inform investment decisions
 Assess whether process or technology improvements are effective.

2.4 Productivity metrics

There are two metrics to estimate the productivity:

1. Size-related metrics

 Uses number of lines of code (LOC) produced as productivity metric.

 LOC metric applies only to the programming process.

 LOC is language dependent.

 Difficult to estimate in early stages of development.

 It is not efficient since one language requires more lines than another to implement the same
functionality

2. Function-related metrics

 Uses function-point count

 A function point is not a single characteristic but is computed by combining several different
measurements or estimates.
You compute the total number of function points in a program by measuring or estimating the following
program features:

 External inputs and outputs;

 User interactions;
 External interfaces;
 Files used by the system.

Lines of code and function point metrics can be used together to provide the productivity estimates

Code size = AVC x Number of function points

AVC = The average number of lines of code, in a particular language required to implement a function
point or (LOC/FP)

2.4 Factors affecting software engineering productivity

Factor Description

Application domain Knowledge of the application domain is essential for experience effective
experience software development. Engineers who already understand a domain are likely to
be the most productive.

Process quality The development process used can have a significant effect on productivity.

project size The larger a project, the more time required for team communications. Less time
is available for development so individual productivity is reduced.

Technology support Good support technology such as CASE tools and configuration management
systems can improve productivity.

Working environment A quiet working environment with private work areas contributes to improved
productivity.

2.5 Estimation techniques

Most common estimation models:

 Expert Judgment
 Analogy
 Parkinson’s Law
 Price to win
 Top-down
  Bottom- up

1. Expert’s judgement

 One or more experts in both software development and the application domain use their
experience to predict software costs.

 Process iterates until an agreed estimate is reached.

Advantages:

It is relatively cheap estimation method. It can be accurate if experts have direct experience of similar
systems.

Disadvantages:

It is very inaccurate if there are no experts!

2. Estimation by analogy
 Uses the past project estimation history
 The cost of a project is computed by comparing the estimation to a similar project in the
same application domain

Advantages:

May be accurate if project data are available and people/tools are the same

Disadvantages:

Impossible if no comparable project has been undertaken. Needs systematically maintained cost
database.

3. Parkinson’s Law

Parkinson’s Law states that work expands to fill the time available. The project costs whatever resources
are available

4. Price to win
 The project costs whatever the customer has to spend on it

Advantages: You get the contract

Disadvantages: The probability that the customer gets the system he or she wants is small. Costs do not
accurately reflect the work required.
 How do you know what customer has?
 Only a good strategy if you are willing to take a serious loss to get a first customer.
Chapter-3

Risk analysis and management

3.1 Introduction

Risk is the project management area that is forward-looking, during which the team tries to identify
potential trouble spots that could jeopardize the success of the project.

3.2 Characteristics of risk

 Uncertainty: - The risk may or may not happen; that is, there are no 100 percent probable risks
 Loss: - If the risk becomes a reality, unwanted consequences or losses will occur

3.3 Risk management strategies

1. Reactive Risk Management

 Project team reacts to risks when they occur
 More commonly, the software team does nothing about risks until something goes wrong.
 Then, the team involved into action in an attempt to correct the problem rapidly. This is often
called a fire fighting mode.

When this fails, “crisis management” takes over and the project is in real jeopardy.

2. Proactive Risk Management

 A proactive strategy begins long before technical work is initiated.
 Potential risks are identified, their probability and impact are assessed, and they are ranked
by importance.
 Then, the software team establishes a plan for managing risk.

The primary objective is to avoid risk, but because not all risks can be avoided, the team works to
develop a contingency plan that will enable it to respond in a controlled and effective manner.

3.4 Categories of risks and their effects

1. Project risks

 Threaten the project plan

 If project risks become real, it is likely that the project schedule will slip and the costs will
increase.
 Project risks identify potential budgetary, schedule, personnel (staffing and organization),
resource, stakeholder, and requirements problems and their impact on a software project. Project
complexity, size, were also defined as project (and estimation) risk factors.
2. Technical risks

 Threaten the quality and timeliness of the software to be produced.

 If a technical risk becomes a reality, implementation may become difficult or impossible.
 Technical risks identify potential design, implementation, interface, verification, and
maintenance problems.
 Technical obsolescence and “leading-edge” technology are also risk factors.
 Technical risks occur because the problem is harder to solve than you thought it would be.

3. Business risks

Candidates for the top five business risks:

1. Building an excellent product or system that no one really wants (market risk)
2. Building a product that no longer fits into the overall business strategy for the company
(strategic risk)
3. Building a product that the sales force doesn’t understand how to sell (sales risk)
4. Losing the support of senior management due to a change in focus or a change in people
(management risk)
5. Losing budgetary or personnel commitment (budget risks)

Other categories of risks

 Known risks

Known risks are those that can be uncovered after careful evaluation of the project plan.

Example:

Unrealistic delivery date, lack of documented requirements or software scope, poor development
environment

 Predictable risks

Predictable risks are extrapolated from past project experience

Example:

Staff turnover, poor communication with the customer,

 Unpredictable risks

They can and do occur, but they are extremely difficult to identify in advance.
3.5 Risk identification

↔ Risk identification is a systematic attempt to specify threats to the project plan (estimates,
schedule, resource…)
↔ By identifying known and predictable risks, the project manager takes a first step toward
avoiding them when possible and controlling them when necessary.

3.5.1 Method for identifying risks

One method for identifying risks is to create a risk item checklist.

The checklist can be used for risk identification and focuses on some subset of known and predictable
risks in the following generic subcategories:

 Product size—risks associated with the overall size of the software to be built or modified.
 Business impact—risks associated with constraints imposed by management or the marketplace
 Stakeholder characteristics—risks associated with the sophistication of the stakeholders and the
developer’s ability to communicate with stakeholders in a timely manner.
 Process definition—risks associated with the degree to which the software process has been
defined and is followed by the development organization.
 Development environment—risks associated with the availability and quality of the tools to be
used to build the product.
 Technology to be built—risks associated with the complexity of the system to be built and the
“newness” of the technology that is packaged by the system.
 Staff size and experience—risks associated with the overall technical and project experience of
the software engineers who will do the work.

Questions relevant to each of the topics can be answered for each software project. The answers to these
questions allow you to estimate the impact of risk.

3.5.2 Risk components and drivers

 Performance risk—the degree of uncertainty that the product will meet its requirements and be
fit for its intended use.
 Cost risk—the degree of uncertainty that the project budget will be maintained.
 Support risk—the degree of uncertainty that the resultant software will be easy to correct, adapt,
and enhance.
  Schedule risk—the degree of uncertainty that the project schedule will be maintained and that
the product will be delivered on time

3.6 Risk projection

Risk projection is also called risk estimation; it attempts to rate each risk in two ways

(1) The likelihood or probability that the risk is real and

(2) The consequences or impact of the problems associated with the risk, if it occurs.

The project planner, along with other managers and technical staff, performs four risk projection
activities:

 Establish a scale that reflects the supposed likelihood of a risk

 Describe the consequences of the risk,
 Estimate the impact of the risk on the project and the product,
 Note the overall accuracy of the risk projection so that there will be no
misunderstanding

The intent of these steps is to consider risks in a manner that leads to prioritization.

By prioritizing risks, the team can allocate resources where they will have the most impact.

3.6.1 Developing a risk table

A risk table provides you with a simple technique for risk projection.
Procedure to build risk table

 Listing all risks in first column

This can be accomplished with the help of the risk item checklists

 Each risk is categorized in the second column

 The probability of occurrence of each risk is entered in the next column of the table.

This can be estimated by team members.

 Impact of each risk is assessed. Each risk component is assessed using the
characterization and an impact category like catastrophic, critical, marginal and
negligible are determined.

Once table is completed, manger will give order of prioritization to the risk. Therefore, the table is
sorted by probability and by impact.

 High-probability, high-impact risks get into the top of the table, and low-probability risks
drop to the bottom. (First order prioritization).
 The project manager studies the resultant sorted table and defines a cutoff line.
 The cutoff line implies that only risks that lie above the line will be given further
attention.
 Risks that fall below the line are considered as second-order prioritization.
 Risk impact and probability have a distinct influence on management concern.
 Risk factor that has a high impact but a very low probability of occurrence management
will give little attention or some time no attention.
 But if risk factor that has high impact and high probability of occurrence then
management will give high attention.
 All risks that lie above the cutoff line must be managed and specify in last column of the
table under RMMM column.

3.6.3 Risk Mitigation, Monitoring, and Management (RMMM)

Risk analysis goal

↔ The goal of risk analysis is to assist the project team in developing a strategy for dealing with
risk.
↔ An effective strategy must consider three issues:
 Risk avoidance or mitigation
 Risk monitoring
  Risk management and contingency planning
↔ Proactive approach to risk, avoidance is always the best strategy.
↔ This is achieved by developing a plan for risk mitigation.

For example, assume that high staff turnover is noted as a project risk.

↔ To mitigate this risk, project management must develop a strategy for reducing turnover.

Steps:

1. Meet with current staff to determine causes for turnover (e.g., low pay, competitive job market).
2. Mitigate those causes that are under our control before the project starts.
3. Organize project teams so that information about each development activity is widely dispersed.
4. Define documentation standards and establish mechanisms to be sure that documents are
developed in a timely manner.
5. Conduct peer reviews of all work
6. Assign a backup staff member for every critical technologist.

As the project proceeds, risk monitoring activities commence.

 The project manager monitors factors that may provide an indication of whether the risk is
becoming more or less likely.

 In the case of high staff turnover, the following factors can be monitored:

o General attitude of team members based on project pressures.

o Potential problems with compensation and benefits.

o The availability of jobs within the company and outside it.

 Risk management and contingency planning assumes that mitigation efforts have failed and
that the risk has become a reality.

 The project is well underway and a number of people announce that they will be leaving. If
the mitigation strategy has been followed, backup is available, information is documented,
and knowledge has been dispersed across the team.

 In addition, the project manager may temporarily refocus resources (and readjust the project
schedule) to those functions that are fully staffed, enabling newcomers who must be added to
the team to “get up to speed.”
  Those individuals who are leaving are asked to stop all work and spend their last weeks in
“knowledge transfer mode.”

 This might include video-based knowledge capture, the development of “commentary

documents,” and/or meeting with other team members who will remain on the project.

 RMMM steps incur additional project cost. For example, spending the time to "backup"
every critical technologist costs money.

3.6.4 The RMMM plan

↔ The RMMM plan documents all work performed as part of risk analysis and are used by the
project manager as part of the overall project plan.
↔ Some software teams do not develop a formal RMMM document. Rather, each risk is
documented individually using a risk information sheet (RIS).
↔ RIS is maintained using a database system, so that creation and information entry, priority
ordering, searches, and other analysis may be accomplished easily.
↔ Once RMMM has been documented and the project has begun, risk mitigation and monitoring
steps commence.