Project

 Def:
 A specific plan or design
 A planned undertaking
 A large undertaking: for example, a public works scheme
 Planned activity
 The undertaking is non-routine: a job which is
repeated a number of times is not a project
Characteristics

 Non-routine tasks are involved

 Planning is required
 Specific objectives are to be met or a specified product
is to be created
 The project has a predetermined time span
 Work is carried out for someone other than yourself
Characteristics

 Work involves several specialisms

 Work is carried out in several phases
 The resources that are available for use on the project
are constrained
 The project is large or complex

E.g. Building the channel tunnel

Writing an operating system
 S/w Projects Vs other projects
 Invisibility
 When a physical artifact such as a bridge or road is being
constructed the progress being made can actually be seen.
With software, progress is not immediately visible
 Complexity
 Per dollar, pound or euro spent, software products contain
more complexity than other engineered artifacts
 Flexibility
 The ease with which software can be changed is usually seen
as one of its strengths. The software system are likely to be
subject to a high degree of change
 Conformity
 Software developers have to conform to the requirements of
human clients
What is Management?
 It involves the following activities:
Problems with Software Projects

 Problems from Manager’s point of view

 Poor estimates and plans
 Lack of quality standards and measures
 Lack of guidance about making organizational decisions
 Lack of techniques to make progress visible
 Poor role definition – who does what?
 Incorrect success criteria
Problems with Software Projects (Cont.)

 Problems from team member’s point of view

 Inadequate specification of work
 Management ignorance
 Lack of knowledge of application area
 Lack of standards
 Lack of up-to-date documentation
 Preceding activities not completed on time – including
late delivery of equipment
 Lack of communication between users and technicians
Problems with Software Projects (Cont.)

 Lack of communication leading to duplication of work

 Lack of commitment – especially when a project is tied
to one person who then moves
 Narrow scope of technical expertise
 Changing statutory requirements
 Changing software environment
 Deadline pressure
 Lack of quality control
 Remote management
 Lack of training
 Project Management
 Project management in the modern sense began in the early 1960s, although
it has its roots much further back in the latter years of the 19th century.
 The need for project management was driven by businesses that realized the
benefits of organizing work around projects and the critical need to
communicate and co-ordinate work across departments and professions.
 Here is the main definition of what project management is:
 Project management is no small task.
 Project management has a definite beginning and end. It is not a
continuous process.
 Project management uses various tools to measure accomplishments
and track project tasks. These include Work Breakdown Structures,
Gantt charts and PERT charts.
 Projects frequently need resources on an ad-hoc basis as opposed to
organizations that have only dedicated full-time positions.
 Project management reduces risk & increases the chance of success.
Project Management (Cont.)
 Project management is often summarized in a triangle. The three
most important factors are time, cost and scope, commonly called
the triple constraint. These form the vertices with quality as a central
theme.
Project Management (Cont.)

 Projects must be delivered on time.

 Projects must be within cost.
 Projects must be within scope.
 Projects must meet customer quality requirements.
Project Management (Cont.)
 More recently, this has given way to a project management diamond,
with time, cost, scope and quality the four vertices and customer
expectations as a central theme. No two customers' expectations are
the same so you must ask what their expectations are.
Overview of Project Management
 Project Management is “the application of knowledge,
skills, tools and techniques to project activities in order to
meet or exceed users’ and stakeholders’ needs and
expectations from the project”
 This definition is recommended by Project Management
Institute (PMI) standards committee.
 Project management has a framework of operations to lead
to a successful completion of the project. The framework is
built on nine knowledge functional areas. These are
required to be managed effectively to achieve success.
 Time Cost

Scope
Quality Project
Manage
ment
HR Procurement Integration

T T
Communication Risk o e
o c
l h
s n
i
q
u
e
s
 A key to successful project management is
“management of nine knowledge functional areas” namely.
 Setting Objectives of Project
 An objective is well defined if it is SMART
Project Organization

 What this is?

 A guideline written by an experienced software
development executive, relaying a step-by-step approach for
creating an effective software project organization.
 The guideline describes how to create a work and
reporting structure for all the software-related groups in a
project in order to implement the project successfully and
efficiently-without too many layers involved in decisions, but
facilitating clear responsibility definition, accountability and
oversight.
Project Organization (Cont.)

 Why it’s useful

 It is a key component of good project management because it
calls for
 (1) identifying all necessary roles to perform project tasks,
 (2) defining the responsibilities that accompany each role,
 (3) defining the authority of and between each role.
 It forces consideration of every task that must be done and
who will do it.
 Progress transparency is made easier so that schedules can
be tracked.
 Work product transparency is made easier so that quality
can be monitored.
Project Organization (Cont.)
 How to use it
 Use this guideline to first help identify places where your
current software project organizations might be operating
with less than desired efficiency, ownership, and results.
 Follow the key steps provided in the guideline to define a
software project organization for an upcoming project, or
to tweak the organization of a mid-stream project that
could benefit:
 Define the software project roles necessary for this project.
 Define the responsibilities for each role.
 Define the authority for each role.
 Define the organizational hierarchy that matches the roles and
authority.
Project Organization (cont.)
 For a new project, translate the decisions you make into
whatever project deliverables your company or team uses such
as team roles lists or team responsibility matrices, and
communication plans.
 Make sure any changes in responsibilities, communication
channels, or decision-making authority are communicated
throughout the affected team(s), including cross-functional
members who work with software, and their managers.
 Document for your projects any decisions you make through
this process about what constitutes an optimal software
project organization for this and other types of projects in
your company. The process above should result in new
insights into what kinds of reporting relationships and
responsibility assignments greatly help all your teams!
 Project Management Life Cycle

 A project goes through six phases during its life:

1. Project Definition: Defining the goals, objectives and
critical success factors for the project.
2. Project Initiation: Everything that is needed to set-up the
project before work can start.
3. Project Planning: Detailed plans of how the work will be
carried out including time, cost and resource estimates.
4. Project Execution: Doing the work to deliver the product,
service or desired outcome.
5. Project Monitoring & Control: Ensuring that a project stays
on track and taking corrective action to ensure it does.
6. Project Closure: Formal acceptance of the deliverables and
disbanding of all the elements that were required to run the
project.
Note: critical factor required for ensuring the success of a Project.
Project Management Life Cycle (Cont’d)
Project Definition & Project Initiation
Project Planning
Project Execution,
Project Monitoring
& Control
Project Closure
 Planning a Software Project

Step Activities within step

0 Select project
1 Identify project scope and objectives
1.1 Identify objectives & measures of effectiveness in meeting them
1.2 Establish a project authority
1.3 Identify all stakeholders in the project and their interests
1.4 Modify objectives in the light of stakeholder analysis
1.5 Establish methods of communications with all parties
Planning a Software Project
Step Activities within step
2 Identify project infrastructure

2.1 Establish relationship between project and strategic planning

2.2 Identify installation standards and procedures

2.3 Identify project team organization

3 Analyze project characteristics

3.1 Distinguish the project as either objective or product driven

3.2 Analyse other project characteristics

3.3 Identify high level project risks

Step Activities within step
3.4 Take into account user requirements concerning implementation
3.5 select general lifecycle approach

3.6 Review overall resource estimates

4 Identify project products and activities

4.1 Identify and describe project products (or deliverables)

4.2 Document generic product flow

4.3 Recognize product instances

4.4 Produce ideal activity network

4.5 Modify ideal to take into account need for stages & checkpoints
Step Activities within step
5 Estimates effort for each activity

5.1 Carry out bottom-up estimates

5.2 Revise plan to create controllable activities

6 Identify activity risks

6.1 Identify and quantify activity based risks

6.2 Plan risk reduction & contingency measures where appropriate

6.3 Adjust plans and estimates to take account of risks

Step Activities within step
7 Allocate resources

7.1 Identify and allocate resources

7.2 Revise plans and estimates to account of resource

constraints

8 Review plan

8.1 Review quality aspects of project plan

8.2 Document plans and obtain agreement

9 Execute plan

10 Lower levels of planning

Project Manager

 The role of the project manager is one of great

responsibility. It is the project manager's job to direct,
supervise and control the project from beginning to
end. Project managers should not carryout project
work, managing the project is enough. Here are some
of the activities that must be undertaken:
Project Manager (Cont.)

1. The project manager must define the project, reduce it to a set of

manageable tasks, obtain appropriate resources and build a team
to perform the work.
2. The project manager must set the final goal for the project and
motivate his/her team to complete the project on time.
3. The project manager must inform all stakeholders of progress on
a regular basis.
4. The project manager must assess and monitor risks to the project
and minimize them.
5. No project ever goes exactly as planned, so project managers
must learn to adapt and manage change.
Project Manager (Cont.)
 A project manager must have a range of skills including:
Activities Covered By SPM

Feasibility study

Plan

Project execution
Project Communication
Project Documentation
 Risk Management

 A Project Risk is a potential problem that would be

opposing to a project’s success
 The major components of risk are the probability
that something undesirable might happen and the
resulting consequences should the undesired event
occur
 For Ex: the project might overrun the schedule,
resulting in delayed delivery of the product; exceed its
budget; which would result in a cost overrun or deliver
an unsuitable product; which would result in a
customer and user dissatisfaction
Risk Management
 Project risk is characterized by the following:
Uncertainty is involved (0<Probability<1)
A loss is associated with it (life, money, property, reputation
and so forth)
It is manageable – in the sense that human action can be
applied to change its form and degree
 Risk exposure is the product of probability and
potential loss
 A problem is a risk that has materialized. The problem
arises when the undesired event has occurred and a
potential loss is now real
Risk Management

 For the purpose of identifying and managing risks that

may cause a project to overrun its time-scale or budget,
it is convenient to identify three types of risk:
 Those caused by the inherent difficulties of estimation
 Those due to assumptions made during the planning
process
 Those of unforeseen (or at least unplanned) events
occurring
 Risk Management Vs Project Management

 There is basic difference between risk management

and traditional project management
 The goal of traditional project management is to
control pervasive (spread throughout) risks by using
systematic procedures
 In contrast, risk management is concerned with
identifying and managing the unique aspects of a
specific project that might prevent delivery of a
suitable product, on time and within budget
Managing Risk

 The objective of risk management is to avoid or

minimize the adverse effects of unforeseen events
 There are number of models for risk management, but
most are similar, in that they identify two main
components –
risk identification and
risk management
Question for the Project Manager

 Establish the context What are we trying to achieve?

 Identify the risks What might happen?
 Analyze the risks What might that mean for the
project’s key criteria?
 Evaluate the risks What are the most important things?
 Treat the risks What are we going to do about them?
 Monitor and review How do we keep them under
control?
 Communicate and consult Who should be involved in the
process?
 Risk Framework

Actors

Structure Technology

Tasks
Risk Framework
 Boehm’s Risk Engineering Task Breakdown
Risk
Engineering

Risk Risk
Analysis Management

Risk Risk Risk

Identification Estimation Evaluation

Risk Risk Risk Risk Risk

Planning Control Monitoring Directing Staffing
Software risk management steps
 Risk Management
Characteristics
Risk Components and Drivers
Software Risk Categories
Project Risks
Threaten to Project Plan
 Technical Risks
Threaten for quality and timeliness of the software to be produced
Business Risks
Risk Identification

 Risk identification consists of listing all of the risks

that can adversely affect the successful execution of
the project
 Five common and interrelated areas of risk for
software projects are schedule, cost, requirements,
quality and operational risks
Risk Identification

 Application factors
 Staff factors
 Project factors
 Project methods
 Hardware / software factors
 Changeover factors
 Supplier factors
 Environment factors
 Health and safety factors
Risk Identification

1) Schedule Risks
2) Cost Risks
3) Requirement Risks
4) Quality Risks
5) Operational Risks
1. Schedule Risks
 Techniques for identifying schedule risks include
algorithmic scheduling models, critical path methods and
PERT analysis
 Probabilistic techniques such as PERT and Monte Carlo
simulation can provide ranges of probabilities for achieving
various project milestones based on probabilistic values for
the duration of the individual project tasks and the
sequencing dependencies among those tasks
 The schedule network is a source for identifying potential
risk
 Nodes or junction points with a high degree of fan-in and
those with a high degree of fan-out are potential high-risk
areas
2. Cost Risks

 Budgets are usually determined using effort (people x

time) as the primary cost factor
 The nonlinear increase in cost with decreasing
schedule may result in a very high risk that the project
cannot be completed within budget
 Other factors that influence cost and schedule risks
are as follows:
 Creeping requirements
 Project requirements slowly increase without a corresponding
increase in the budget (or the schedule)
 Schedule compression
 Brought about by pressures from marketing, upper
management and the customer, which results in a nonlinear
increase in software costs
 Unreasonable budgets
 Budget estimates based on the price necessary to satisfy the
market, upper management and/or the customer rather than
to satisfy the technical requirements
3. Requirements Risks

 Incorrect requirements
 Requirements that do not correctly state user needs and
customer expectations
 Incomplete requirements
 Requirements that do not state desired product features or
particular aspects of desired product features
 Inconsistent requirements
 Requirements that conflict with other requirements in the
same specification
 Unclear requirements
 Requirements that have more than one semantic
interpretation
 Unverifiable requirements
 Requirements for which no finite process exists to verify
that the product meets the requirements
 Untraceable requirements
 Requirements for which there is no audit trail from
requirements to tested code and back
 Volatile requirements
 Requirements that are constantly changed; continual
addition of new requirements
4. Quality Risks
 Many risk factors for software projects result from the
delivery of unexpectedly poor software quality such as:
 Unreliable
 Unusable
 Un maintainable
 Non portable
 Non expandable
 Unreliable
 The software does not perform its intended functions under
specified conditions for stated periods of time
 Unusable
 Unreasonable effort is required to use the software or to train
software users
 Un maintainable
 Extraordinary effort is required to locate and fix errors in the
software or to upgrade it for future use
 Non portable
 Extreme difficulty is encountered in converting the software for use
in a different operating environment
 Non expandable
 Software capability or performance cannot be increased by
enhancing current functions or adding new functions/data
5. Operational Risks

 Risk that a project may produce a system that does not

satisfy operational needs
 That is it does not posses the
 functional,
 performance, or
 quality attributes
the customers and users want and need.
 Risk Item Check-list
Method for identifying risks in the project is create “ Risk Item Check List”
Risk Analysis

 Risk assessment is the overall process of risk analysis

and risk evaluation. Its purpose is to develop agreed
priorities for the identified risks.
 Risk analysis
is the systematic use of available information to
determine how often specified events may occur and
the magnitude of their consequences.
 Risk evaluation
is the process of comparing the estimated
risk against given risk criteria to determine the
significance of the risk.
 The Risk Assessment process:
 determines the consequences of each risk, should it
arise;
 assesses the likelihood of those consequences occurring;
 data obtained by surveying experienced software
project;
 converts the consequence and likelihood ratings to an
initial priority for the risk; and
 develops agreed risk priorities and inherent risk
levels.
Quantitative Risk

 Hazard (or threat): a set of conditions that can lead to

an undesirable event
 accident, loss, law breaking
 Risk: the possibility of loss. A function of three things
(Leveson, 1991):
 the likelihood of a hazard occurring (h)
 the likelihood that the hazard will lead to an accident (a)
 the worst possible potential loss associated with that
accident (l)
r = P(h) * P(a) * l
 Risk management seeks to tackle at least one of the
three elements of risk by:
 reducing the likelihood of the hazard occurring
 reducing the likelihood of the hazard leading to
accident or loss
 reducing the amount of the loss
r = P(h) * P(a) * l
Risk management tackles one or more of these
 Risk estimation
consists of assessing the likelihood and impact of
each hazard
 Risk evaluation
consists of drawing up contingency plans
and where appropriate adding these to the project’s
task structure. With small projects, risk planning is
likely to be the responsibility of the project manager
but medium or large projects will benefit from the
appointment of a full-time risk manager.
 Risk control
concerns the main functions of the risk manager
in minimizing and reacting to problems throughout
the project. This function will include aspects of
quality control in addition to dealing with problems as
they occur.
 Risk monitoring
must be ongoing activity, as the importance and
likelihood of particular risks can change as the project
proceeds.
 Risk resolution
success criteria in terms of the process
goals, the results that we expect to achieve by using the
process. We can view the risk resolution process from
two perspectives: external and internal.
 The external view specifies the process controls,
inputs, outputs, and mechanisms.
 The internal view specifies the process activities that
transform inputs to outputs using the mechanisms.
 Reducing the risks (Risk Handling)

 Risk Avoidance: Find alternative processes.

 Ex: be protected from the risk of overrunning the schedule by
increasing duration estimates or reducing functionality
 Risk Acceptance: Accept the risk and face it.
 Ex: Prioritize risk and ignore less damaging risks
 Risk Transference: Assign responsibility to others.
 Ex: Contracting out (Outsourcing) or taking out insurance
 Risk Mitigation: Find the ways to make risks less likely
to eventuate or reduce the impact.
 The project risk management process
Establish the context
- Objectives
- Stakeholders
- Criteria
- Define key elements

Identify the risks

Communicate and Consult

- What can happen?
Monitor and Review

- How can it happen?

Analyze the risks

- Review controls
- Likelihoods
- Consequences
- Level of risks
Evaluate the risks
- Evaluate risks
- Rank risks

Treat the risks

- Identify options
- Select the best responses
- Develop risk treatment plan
- Implement
Qualitative or Quantitative Risk Analysis Template

 Remember there are positive and negative risks

Risk Probability of Occurrence Magnitude of Impact Risk

Event Response
Medium High Low Mediu High Low Type of
m Action
Risk and the control loop

Enter Leave
Important Aspects of Project
The 4 P’s
 People — the most important element of a
successful project
 Product — the software to be built
 Process — the set of framework activities and
software engineering tasks to get the
job done
 Project — all work required to make the
product a reality

80
People…
For successful project people are important aspects in
project.
They could be
1.Project Manager
2.Stakeholders
3.Customers
4.End users
5.Testers
6.Practitioners

81
 Product Scope…
Context: How does the software to be built fit into a larger system,
product, or business context and what constraints are imposed as a
result of the context.
Information Objectives : What customer-visible data objects are
produced as output from the software? What data objects are
required for input?
Function and Performance: what function does the software
perform to transform input data into output? Are any special
performance characteristics to be addressed?
Software project scope must be understandable at the
management and technical levels.

82
Problem…
Sometimes called partitioning or problem elaboration.
(Problem explanation)
Once scope is defined
1.It is decomposed into constituent functions.
2.It is decomposed into user-visible objects.
3.It is decomposed into a set of problem classes.
Decomposition process continues until all functions or
problem classes have been defined.

83
Process…
Software
Engineer

uses

Produces
Process Product

Once a process framework has been established

1. Consider project characteristics
2. Determine the degree of requirements.
3. Define the task set for each software engineering activity
Task set includes:
Software engineering tasks
Work products
Quality assurance points
84
Software risk management steps