SOFTWARE PROJECT MANAGEMENT

• Software Project Managements is an umbrella activity within Software

Engineering

• Project Management involves the Planning, Monitoring and Control of

People, Process and Events that occur as Software evolves from preliminary
concept to an operational implementation.

• Project Management begins before any technical activity and continues

throughout the Definition, Development and Support of Computer Software.

WHO DOES IT? Project Managers

Project Managers Plan, Monitor and Control the work of Team of Software
Engineers.

WHY IS IT IMPORTANT ?

Building a 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.

WHAT IS THE WORK PRODUCT ? ‘’A PROJECT PLAN’’

Project Plan defines the Process and Tasks to be conducted, the People who will do
the work and the mechanism to assessing Risks, Controlling Change and
Evaluating Quality.

Project Plan is produced as Management activities commences

THE MANAGEMENT SPECTRUM

Effective Project Management focuses on 4 P’s

People, Product , Process, Project

 • A Manager who forgets that Software Engineering is an intensely Human
endeavour will never have success in Project Management.

• Manager who fails to encourage comprehensive Stakeholders

communication early in the evolution of a Project Risk building an elegant
solution for the wrong problem

• The Manager who pays little attention to the Process runs the risk of
inserting competent technical Methods and Tools into a vacuum.

• The Manager who embarks without a solid Project Plan jeopardize the
success of the Product.

CHARACTERISCTIC OF AN EFFECTIVE PROJECT MANAGER

• PROBLEM SOLVING

• MANAGERIAL IDENTITY

• ACHIEVEMENT

• INFLUENCE AND TEAM BUILDING

PROBLEM SOLVING

• An effective Project Manager can diagnosis Technical and organizational

issues that are most relevant;

• Systemically structure a solution or properly motivate other Software

Practitioners to develop the solution;

• Apply lessons learned from past Projects to new solutions and remain
flexible enough to change directions if initial attempt s are fruitless.

MANAGERIAL IDENTITY

• A good Project Manager take full charge of the Project;

• Have the Confidence to assume Project Control (when necessary);

• Gives assurance to allow good Technical people to follow their instincts.

ACHIEVEMENTS

• To optimize Productivity of a Project Team:-

- Manager must Reward initiative and accomplishments;

- Demonstrate through his/her own actions that ‘’Controlled Risk taking’’

will not be punished

INFLUENCE AND TEAM BUILDING

• An effective Project Manager must be able to ’‘Read People’’, be able to

understand verbal and non-verbal symbols and react to the needs of the
people sending these signals

• Must remain in control in high stress situation.

THE PROJECT
In order to manage a Successful Software Project, we must understand

What can go wrong so that the problem can be avoided, John Reel defines 10
Signs that indicate an Information Systems Project is in Jeopardy:-

1. Software People don’t understand their Customers’ needs

2. The Product Scope is poorly defined

3. Changes are managed poorly

4. The chosen Technology changed

5. Business needs change or ill defined

6. Project Deadlines are unrealistic

7. Users are resistant

8. Sponsorship is lost (or never obtained)

 9. The Project Team lacks People with appropriate skills

10.Managers / Practitioners avoid best practice and Lessons learned.

AVOIDING PROBLEMS SIGNED BY JEOPARDY

Jaded Industrial Professionals often refer (half facetiously) to the 90 – 90 Rule
when discussing particularly difficult Software Projects.

The seeds that lead to the 90 – 90 rule are contained in the 10 Project Jeopardy
Signs.

90 – 90 RULE

– The first 90 % of a System absorbs 90 % of the Allocated Effort and

Time.

– The last 10 % takes the other 90 % of the Allocared Effort and Time.

John Reel Suggests a Five-part Common-sense approach to avoid Project

Problems:-

1. Start with right foot

2. Maintain Momentum

3. Track Progress

4. Make Smart Decision

5. Conduct a Post-mortems Analysis

1. START WITH RIGHT FOOT

• This is accomplished by working hard to understand the problem that is to

be solved and then setting realistic objectives and expectations for everyone
who will be invloved in the Project.
 • This is achieved by building the ‘’Right Team’’ and giving the Team the
autonomy, authority and technology needed for job

2. MAINTAIN MOMENTUM :

Many Projects get off a good start and then slowly disintegrate. To maintain
momentum:-

 The Project Team should emphasize quality in every task it performs.

 The Project Manager must provide initiatives to keep ‘’Staff

turnover’’ to an absolute minimum.

 Senior Management should do everything posssible to ‘’Stay out of

the Project Team’s way’’.

3. TRACK PROGRESS

• Progress is tracked as Work products (i.e Specification, Source code, Test

results etc) are produced and approved (using Formal technical reviews), as
part of a Quality Assurance activity.

• Additionally, Software Process and Project Measures can be collected and

used to ‘’Assess Progress Against Averages’’ developed for the Software
Development Organizations.

4. MAKE SMART DECISION

In essence, the decisions of Project Manager and the Software Team should be

‘’keep ıt sımple”. Whenever possible decide to:-

• Use ,commercial ‘Off- the -shelf Software’’ or Existing

Software components.

• Avoid Custom Interface when standard approaches are

available.

• Identify and then avoid obvious risks,

 • Allocate more time than you think is needed to complex or
risky tasks.

THE W5HH PRINCIPLE

BOEHM suggests an organizing Principle that scales down to provide simple
Project Plans for simple Projects.

W5HH (WWWWWHH) Principle is based on a series of questions that leads to a

definition of key Project Characteristics and the resulting Project Plan.

 Why is the System being Developed? - Goal

The answer to this question enables all parties to asses the validity of
business reasons for the Software work. (To justify the expenditure of
People, Time, and Money for the Business purpose)

 What will be done? -Outcome

The answer establishes the task set that will be required for the project

 When will it be done? -Schedule

The answer helps the Project Team to establish a Project Schedule by

identifying when Project Tasks are to be conducted and when Milestones
are to be reached.

 Who is responsible for a function? -Stakeholders

The answer helps to define the roles and responsibilities of each member
within the Project team.

 Where are they organizationally located? -Organization

Not all roles and responsibilities reside within the Project team itself. Users,
Customers and other stakeholders may have responsibilities as well.

 How will the job be done technically and Managerially? -Technology

 Once Product Scope is established a Management and Technical strategy
for Project must be defined.

 How much of each resource is needed? -Resources

The answer is derived by developing estimates based on answers of the

above questions

Software Project Planning

Objective: To provide a framework that enables the manager to make reasonable
estimates of

Resources, Cost and Schedule

Project Resources
This is the task of software planning is estimation of resources required to accomplish the software
development effort. The main resources are the hardware and software tools, reusable
software components and people The hardware/software tools make up the development
environment, the foundation or base of the pyramid which provides the necessary
infrastructure to support the development effort. The middle layer in the pyramid is the
reusable software components layer. It constitutes the software building blocks that can reduce the
development costs and speed up the delivery. The top most part of the pyramid is the main resource, the people.
1. People/Human Resources

 Scope and skills required

 Organizational position and specialty must both be considered
 Estimate of development effort (this isessential to determine the number
of people required for the project)

2.Reusable Software Resources

 Off-the-shelf components
 Full experience components
 Partial experience components
 New components
3.Environmental Resources (SEE)

Compilers, Editors, Design tools, Configuration management tools,

Management tracking tools, Problem Reporting And Corrective Action
(PRACA)tools, Documentation tools, Hardware resources, Network support

Project Resources characteristics

Each resource can be specified by the following characteristics

1. Description of the resource

2. A statement of availability

3. Time when the resource will be required

4. Duration of time that resource will be applied

Software Project Estimation

Categories of estimation techniques

 Delay estimates until late in the project
 Base estimates on similar projects
 Use simple decomposition technique.
 Use one or more empirical models.
Empirical Estimation Models

An estimation model for computer software uses empirically derived formulas to

predict effort as afunction of LOC or FP. A typical estimation model which is
derived on the data collected from the past projects, can be written as

E = A + B * (ev)C

Where, A, B, and C are empirically derived constants, E is the effort in persons-

months and ev is the estimation variable ( either in LOC or FP )

Risk Management

When considering risk management and the concept of risk in the development of
software it may be useful first of all to examine what software management is.
Primarily risk and risk management can be assessed by considering the following
definitions:

Risk,
“A chance or possibility of danger, loss, injury or other adverse consequences.”A
definition from Oxford Dictionary.

Software Risks, as per the Quotations [Boehm 93] Failure to obtain all or even any,
of the anticipated benefits. Costs of implementation vastly exceed planned levels.
Time for implementation that is much greater than expected. Technical
performance of resulting systems turns out to be significantly below estimate.
Incompatibility of the system with the selected hardware and software.”

Risk is defined as a Possibility of loss & the degree of probability of such loss. It
implies that there is a possibility that something negative may happen.
Possibility of a negative or undesirable outcome, so a risk could negatively
affect customer, user, or stakeholder satisfaction.

Risk concerns future happenings.

Risk involves change, such as changes of mind, opinion, action or places

Risk involves choice, and the uncertainty that choice itself entails

Risk management is the area that tries to ensure that the impact of risk on cost,
quality and schedule is minimal.

Characteristics of Risks
Uncertainty-May or may not happen
Loss-Unwanted consequences

Risk Management Process

Software risk management is an emerging discipline whose objectives are to
identify, address and eliminate software risk items before rework.” [IEEE 89]

Process involving
 Identification of risk
 Assess its probability of occurrence
 Estimate its impact
 Establish a contingency plan should the problem actually occur

Types of Risks
1.Project Risks-threaten the project plan. Examples include
 Budgetary
 Schedule
 Personnel
 Resource
 Customer
2.Technical Risks-threaten the quality & timeliness of the product
 Design
  Implementation
 Interfacing
 Verification
 Maintenance
3.Business Risks-threaten the viability of the software
 Market
 Strategic
 Management
 Budget

Risk Projection

Risk protection, is also called as risk estimation. It attempts to rate each risk in
two ways the likelihood or probability that the risk is real and the consequences of
the problems associated with the risk, if it occurs. There are four risk estimation
activities:

1.establish a scale that reflects the perceived likelihood of a risk

2.delineate the consequences of the risks

3.estimate the impact of the risk on the project and the product

4.note the overall accuracy of the risk projection so that there will be
no misunderstandings.

Developing a risk table is an important activity of the project planner. This table
provides a simpletechnique for risk projection. The sample risk table is given
below. It has information like list of risks,category of risks, probability of its
occurrence and its impact.

Risk Components
Impact of the risk drivers on the risk components:
1.Negligible
2.Marginal
3.Critical
4.Catastrophic

Example of a risk table

RMMM -Risk Mitigation, Monitoring& Management

1. Develop a plan for risk mitigation

-For example: high staff turnover is noted as a project risk r1.

2. As the project proceeds monitor the risk factors

3. Risk management and contingency planning

-When mitigation efforts have failed and that the risk hasbecome reality