Course Title

Advanced Software Project Planning and Management

Credit Units:5
Course Level: PG

Course Code: CSE604

By. Dr.Madhulika 1
 In the past ten years, typical goals in the
software process improvement of several
companies are to achieve a 2x, 3x, or 10x
increase in productivity, quality, time to
market, or some combination of all three,
where x corresponds to how well the
company does now

The funny thing is that many of these

organizations have no idea what x is, in
objective terms

By. Dr.Madhulika 2
By. Dr.Madhulika 3
By. Dr.Madhulika 4
By. Dr.Madhulika 5
By. Dr.Madhulika 6
By. Dr.Madhulika 7
Old way

By. Dr.Madhulika 8
Old ways

By. Dr.Madhulika 9
By. Dr.Madhulika 10
By. Dr.Madhulika 11
By. Dr.Madhulika 12
By. Dr.Madhulika 13
By. Dr.Madhulika 14
By. Dr.Madhulika 15
By. Dr.Madhulika 16
“The most significant way
to improve affordability and return on
investment is usually to produce a product that
achieves the design goals with the minimum
amount of human-generated source material.”

Reuse, object-oriented technology, automatic

code production, and higher order
programming languages are all focused on
achieving a given system with fewer lines of
human-specified source directives.

By. Dr.Madhulika 17
By. Dr.Madhulika 18
By. Dr.Madhulika 19
By. Dr.Madhulika 20
 Improving Software Economics
Reducing Software Product Size – Commercial Components

APPROACH ADVANTAGES DISADVANTAGES

Frequent upgrades
Commercial Predictable license costs
Broadly used, mature technology
Up-front license fees
Recurring maintenance fees
components Available now Dependency on vendor
Run-time efficiency sacrifices
Dedicated support organization Functionality constraints
Hardware/software independence Integration not always trivial
Rich in functionality No control over upgrades and maintenance
Unnecessary features that consume extra resources
Often inadequate reliability and stability
Multiple-vendor incompatibility

Custom Complete change freedom

Smaller, often simpler implementations
Expensive, unpredictable development
Unpredictable availability date

development Often better performance

Control of development and
Undefined maintenance model
Often immature and fragile
enhancement Single-platform dependency
Drain on expert resources

21/112
PRINCIPLES

"Software Project Management" Walker Ro 22/112

yce
"Software Project Management" Walker Ro 23/112
yce
By. Dr.Madhulika 24
Key practices that improve overall software quality:
 Focusing on driving requirements and critical use cases early in the life cycle,
focusing on requirements completeness and traceability late in the life cycle, and
focusing throughout the life cycle on a balance between requirements evolution,
design evolution, and plan evolution
 Using metrics and indicators to measure the progress and quality of an architecture
as it evolves from a high-level prototype into a fully compliant product
 Providing integrated life-cycle environments that support early and continuous
configuration control, change management, rigorous design methods, document
automation, and regression test automation
 Using visual modeling and higher level language that support architectural control,
abstraction, reliable programming, reuse, and self-documentation
 Early and continuous insight into performance issues through demonstration-based
evaluations

By. Dr.Madhulika 25
Key practices that improve overall software quality:
 Focusing on driving requirements and critical use cases early in the life cycle,
focusing on requirements completeness and traceability late in the life cycle, and
focusing throughout the life cycle on a balance between requirements evolution,
design evolution, and plan evolution
 Using metrics and indicators to measure the progress and quality of an architecture
as it evolves from a high-level prototype into a fully compliant product
 Providing integrated life-cycle environments that support early and continuous
configuration control, change management, rigorous design methods, document
automation, and regression test automation
 Using visual modeling and higher level language that support architectural control,
abstraction, reliable programming, reuse, and self-documentation
 Early and continuous insight into performance issues through demonstration-based
evaluations

"Software Project Management" Walker Ro 26/112

yce
 The Principles of Conventional Software
Engineering
Make quality
Put techniques before tools
Use different languages for different phases

Get it right before you make it faster

Evaluate design alternatives

Take responsibility Give products to customers early Inspect code

Use an appropriate process model

Minimize intellectual distance When a bridge collapses we ask, “what did

the engineers do wrong?” Even when
software fails, we rarely ask this.
The fact is that in any engineering discipline,
the best methods can be used to
produce awful designs, and the most
antiquated methods to produce elegant
design.
27/112
The Principles of Modern Software
Management

"Software Project Management" Walker Ro 28/112

yce
 Object Oriented (Analysis->??)
• Purpose analysis activity in software life-
cycle
• Functional requirements Create a model
Independent of
implementation constraints.

By. Dr.Madhulika 29
By. Dr.Madhulika 30
 OOA
Problem RATHER
how a solution is
defined

• OO ANALYSIS—
• Finding + describing of objects or
concepts
Problem
domain

*Concepts in a Library information system  Book + Catalog

By. Dr.Madhulika 31
 OOD Implementation
constraints

applies

Developer

Object Oriented Analysis

By. Dr.Madhulika 32
 Constraints-
• Hardware
• Software platforms
• Performance requirements
• Persistent storage and
• Transaction
• Usability of the system
• limitations imposed by budgets and time.

By. Dr.Madhulika 33
• Concepts in the analysis model which is
technology independent

Mapped
Results in
a MODEL
• Implements classes and interfaces of
solution
domain
• solution domain, i.e., a detailed description
of how the system is to be built on concrete
technologies.
By. Dr.Madhulika 34
• Technical approach
Analyzing + Designing

Meant for
• Application
• System,
• business
applicable for
• Object-oriented programming,
Software is complex

36
•
Designing software for large applications is a very complex task. It could
arguably be said that there is no limit to how complex software design could get. The
reason for this is that we generally design software to model some real-world
phenomenon.
• Stages of normal software development
• Analysis,
• Design, and
• Implementation
• Phases in Object-Oriented Software
Development
• object-oriented analysis.
*

40
41
*

42
43
Break down algorithm
into smaller ones
Break down into use
case model

44
45
46
Benefits

47
48
49
50
51
 Software Management Process Framework

• Life-Cycle Phases

Engineering and Production Stages

Inception Phase

Elaboration Phase

Construction Phase

Transition Phase
• Artifacts of the Process

The Artifact Sets

Management Artifacts

Engineering Artifacts

Pragmatic Artifacts

"Software Project Management" Walker Ro 52/112

yce
Unified Process
Components Relation in 3 components
 Unified Process
• Unified Process is based on the enlargement
and refinement of a system through multiple
iterations, with cyclic feedback and
adaptation.
• The system is developed incrementally over
time, iteration by iteration, and thus this
approach is also known as iterative and
incremental software development.
 Unified Process: Phases and Major
Milestones
• Inception

• The primary goal of the Inception phase is to establish the case for the
viability of the proposed system.
• The tasks that a project team performs during Inception include the
following:
• Defining the scope of the system (that is, what's in and what's out)
• Outlining a candidate architecture, which is made up of initial versions
of six different models
• Identifying critical risks and determining when and how the project will
address them
• Starting to make the business case that the project is worth doing, based
on initial estimates of cost, effort, schedule, and product quality
Elaboration

• The primary goal of the Elaboration phase is to establish the ability to build the
new system given the financial constraints, schedule constraints, and other
kinds of constraints that the development project faces.
• The tasks that a project team performs during Elaboration include the following:
• Capturing a healthy majority of the remaining functional requirements
• Expanding the candidate architecture into a full architectural baseline, which is
an internal release of the system focused on describing the architecture
• Addressing significant risks on an ongoing basis
• Finalizing the business case for the project and preparing a project plan that
contains sufficient detail to guide the next phase of the project (Construction)
• Construction
• The primary goal of the Construction phase is to build a system
capable of operating successfully in beta customer environments.
• During Construction, the project team performs tasks that involve
building the system iteratively and incrementally (see "Iterations
and Increments" later in this chapter), making sure that the
viability of the system is always evident in executable form.
• The major milestone associated with the Construction phase is
called Initial Operational Capability. The project has reached this
milestone if a set of beta customers has a more or less fully
operational system in their hands.
• Transition
• The primary goal of the Transition phase is to
roll out the fully functional system to
customers.
• During Transition, the project team focuses on
correcting defects and modifying the system to
correct previously unidentified problems.
• The major milestone associated with the
Transition phase is called Product Release.
61
62
By. Dr.Madhulika 63
64
 UA
• The Unified Approach (UA) is a methodology
for software development that is proposed by
the author Ali Bahrami (1999).
• Methodologies based on
Rambaugh
Booch

Jacobson

65
• Use case represents a typical interaction
between a user and a computer system to
capture the users’ goals and needs.
Use case

{Goals and Needs}

interaction

User

66
• Use case is captured by talking to typical users and discussing
the various ways they might want to use the system. The use
cases are entered into all other activities of the UA.

67
68
 Unified approach->Software
development
The *processes are:
1. Use-case driven development
2. Object-oriented analysis
3. Object-oriented design
4. Incremental development and prototyping
5. Continuous testing

69
 Unified process
• The life of a software system can be
represented as a series of cycles. A cycle ends
with the release of a version of the system to
customers.
P4 P1 System

P3 P2
70
 • A phase is simply the span of time between
two major milestones.

t
• Mile Stone 1----------------------------Milestone 2
t-> where managers make
important decisions about
whether to
proceed with development
and,
If Yes what's required
concerning
1)project scope2) budget, and
3)schedule.
71
Unified Process Phases
Goals Mile stones

72
• Inception:-“Establish the case for the viability
of the proposed system”.
• Task: define scope, critical risk, project is
worth doing or not
• Goals: Stakeholder agree on scope

73
Elaboration (Mile stone)

The primary goal is to establish the ability to build the new system given the
financial constraints,
schedule constraints

The tasks that a project team performs during Elaboration include the following:
Capturing remaining functional requirements
Expanding the candidate architecture into a full architectural baseline, which is
an internal release of the system focused on describing the architecture
Addressing significant risks on an ongoing basis

74
Construction phase :

The business case has received a green light,

and the project team has an initial project plan
that describes how the Construction phase will
proceed.

Release

75
• Construction
• The primary goal of the Construction phase is
to build a system capable of operating
successfully in beta customer environments.
• During Construction, the project team
performs tasks that involve building the
system iteratively and incrementally (see
"Iterations and Increments" later in this
chapter), making sure that the viability of the
system is always evident in executable form.
76
• The major milestone associated with the
Construction phase is called Initial
Operational Capability. The project has
reached this milestone if a set of beta
customers has a more or less fully operational
system in their hands.

77
• Transition
• The primary goal of the Transition phase is to
roll out the fully functional system to
customers.
• During Transition, the project team focuses on
correcting defects and modifying the
system to correct previously unidentified
problems.
• The major milestone associated with the
Transition phase is called Product Release.
78
79
 Object
• The term object was first formally utilized in
the Simula language to simulate some aspect
of reality.
• An object is an entity.
• –It knows things (has attributes)
• –It does things (provides services or has
methods)
80
 Attributes
Name Properties->
Language Objects(Data)
Teaching
interest

Research
interest

81
 How to Methods  behaviour
Research

How to
speak?

How to
teach?

82
83
?

84
Object Oriented Design
 UML

Software System

86
• Model: abstract view of subsystem from
system
• View: shows some aspects of system
• Notations: graphical rules for depicting views
System Notations:
Blue prints
Electricals wiring
Fuel system

Flight simulator Model 87

Diagram is view System • Programmers
• End User • Software Management
• Functionality

Implementation
Logical View
View

Use Case View

Deployment
Process View
View

• System integrators
• Performance • System engineer
• Scalability • System topology
• Throughputs • Delivery , installation

88
89
90
 Need
• Developed to help system and software
developers
• Specifying,
• Visualizing,
• Constructing, an documenting the *artifacts of
software systems,
->>>for business modeling and other non-
software systems.
Produced during development of software

91
 Course Objectives:
• To provide students with a clear understanding of the unique
risks, issues, and critical success factors associated with
technology projects
• To introduce students to the role and function of project
management

By. Dr.Madhulika 92
 Course Learning Outcomes
• Course Learning Outcomes:
• Basic concepts of Project management.
• Explain planning and project estimation.
• Analyze project estimation and evaluation.
• Evaluate resource allocation and activity
planning.
• Assess people and quality standards.

By. Dr.Madhulika 93
 Module-I
• Introduction to Software Project Management:
• Definition of a Software Project (SP), SP Vs. other
types of projects activities covered by SPM,
categorizing SPs, project as a system, management
control, requirement specification, information and
control in organization, Objectives, issues, and
problems relating to software projects, role of the
software project manager

By. Dr.Madhulika 94
 Text Books
Readings
•Bob Hughes and Mike Cotterell; Software Project
Management, third edition, Tata McGraw Hill
Publishing Company Ltd., New Delhi.
•Tom Demarco, Controlling Software Project
Management, Measurement, Prentice Hall, New
Jersey.
References:
•Tom Glib, Finzi Susannah, Principles of Software
Engineering Management, Addison Wesley, England.
•Pankaj Jalote; Software Project Management in
Practice, Pearson Education Asia.
•Watts S. Humphrey; Winning with Software? An
Executive Strategy, Pearson Education Asia.
•Philip Metzger, Managing a Programming Project,
Prentice Hall, New Jersey.
•Kishore, Swapna, “Software Requirements and
Estimation”, Tata McGraw Hill, 2001Computer
Communications and Networking Technologies –
Michael A.Gallo, William M .Hancock - Thomson
By. Dr.Madhulika 95
Publication.
By. Dr.Madhulika 96
 Outline of talk
In this introduction the main questions to be
addressed will be:

– What is software project management? Is it really

different from ‘ordinary’ project management?

– How do you know when a project has been

successful? For example, do the expectations of
the customer/client match those of the
developers?

97
 Outline of talk
In this introduction the main questions to be
addressed will be:

– What is software project management? Is it really

different from ‘ordinary’ project management?

– How do you know when a project has been

successful? For example, do the expectations of
the customer/client match those of the
developers?

98
By. Dr.Madhulika 99
• General conditions should be fulfilled for tasks to be
completed in the form of a project:
• The task
• is unique,
• is a novelty,
• is subject to constraints by timescale, funding and staff,
• has a complex technical and organizational structure,
• has clear performance targets with regard to the agreed
specification and quality,
• is implemented in teamwork, generally by cross-disciplinary
and cross-hierarchy project teams.
By. Dr.Madhulika
100
By. Dr.Madhulika 101
By. Dr.Madhulika 102
By. Dr.Madhulika 103
 What is a project?
Some dictionary definitions:
“A specific plan or design”
“A planned undertaking”
“A large undertaking e.g. a public works scheme”
Longmans dictionary

Key points above are planning and size of

task

104
By. Dr.Madhulika 105
By. Dr.Madhulika 106
By. Dr.Madhulika 107
 Jobs versus projects

‘Jobs’ – repetition of very well-defined and well understood

tasks with very little uncertainty
‘Exploration’ – e.g. finding a cure for cancer: the outcome is
very uncertain
‘Projects’ – in the middle!
108
 Characteristics of projects
A task is more ‘project-like’ if it is:
• Non-routine
• Planned
• Aiming at a specific target
• Work carried out for a customer
• Involving several specialism
• Made up of several different phases
• Constrained by time and resources
• Large and/or complex

109
 Are software projects really different from other projects?

Not really! …but…

• Invisibility
• Complexity
• Conformity
• Flexibility
make software more problematic to build
than other engineered artifacts.

110
Activities covered by project
management

111
112
Feasibility study
Is project technically feasible
and worthwhile from a
business point of view?

Planning
Only done if project is feasible
Execution
Implement plan, but plan may be changed as we go along.

113
 Examples of Software Projects
• Putting a robot vehicle on Mars to search
for signs of life.
» Relative novelty of the project
» International nature of the project
» Successful achievement of the project from
engineering point of view is the safe landing of the
robot, not the discovery of signs of life.

• Writing an Operating System

114
 Software projects Vs. other
types of project
• Invisibility:- progress is not immediately
visible as compared to other project
• (bridge construction)
• Complexity:- they are more complex.
• Conformity:- software projects have to
conform to the requirements of clients but
with other project laws are there .
• Flexibility :- biggest strength of SP.
115
 Categorizing SPs
Information systems Vs Embedded systems

• In Information systems, the system interfaces

with the organization.
• Example:- Stock control system.
• In Embedded systems, system interfaces with
a machine.
• Example:- it can control the air conditioning
equipment in a building.
• It is also known as Process control systems,
Real time systems or Industrial systems.
116
• Objectives Vs Products
– the aim of a project may be to produce a product or to meet
certain objectives.

– Example: services given to customer is objective driven

– the aim of a project may be to produce a product

By. Dr.Madhulika 117

 Project as a System
• A system can be considered as a set of
elements joined together for a common
objective.
• All the systems are parts of larger systems.

By. Dr.Madhulika 118

 Project as a
Management Control
• Management can be seen as the process of
setting objectives for a system and then
monitoring the system
Management can be seento see
as the what
process of its true
performance is.
setting objectives for a system and then
monitoring the system to see what its true
performance is.

By. Dr.Madhulika 119

By. Dr.Madhulika 120
 Project as Requirement
Specification
• Functional Requirements

• Quality Requirements

• Resource Requirements

By. Dr.Madhulika 121

By. Dr.Madhulika 122
Non-functional requirements define system
behaviour, features, and general characteristics
that affect the user experience. How well non-
functional requirements are defined and
executed determines how easy the system is to
use, and is used to judge system performance.
Non-functional requirements are
product properties and focus on
user expectations. There are more examples below, but for now,
think about a functional requirement that the
system loads a webpage after someone clicks
on a button. There should be a related non-
functional requirement specifying how fast the
webpage must load. Without it, the user
experience and perception of quality are at risk
if they are forced to wait too long, even though
the functional requirement is fully met.
By. Dr.Madhulika 123
By. Dr.Madhulika 124
By. Dr.Madhulika 125
• Specify not the functionality of the system, but the quality
with which it delivers that functionality
• Quantify wherever possible
• Requirements serve as contracts: should be testable/falsifiable
• Can be more critical than functional requirements •
Can work around missing functionality
• Low-quality system may be unusable

By. Dr.Madhulika 126

 Project as Information and Control in
Organization

• Information related to project travels from

one department to another or one module to
another.
• Coding (department)  testing (team)
• s Information and Control in
Organization

By. Dr.Madhulika 127

By. Dr.Madhulika 128
By. Dr.Madhulika 129
Management control

130
 Management control
Data – the raw details
e.g. ‘6,000 documents processed at location X’

Information – the data is processed to produce

something that is meaningful and useful
e.g. ‘productivity is 100 documents a day’

Comparison with objectives/goals

e.g. we will not meet target of processing all documents
by 31st March

continued….. 131
By. Dr.Madhulika 132
 Stakeholders
These are people who have a stake or interest in
the project
In general, they could be users/clients or
developers/implementers

They could be:

• Within the project team
• Outside the project team, but within the same
organization
• Outside both the project team and the
organization
133
• According to the Project Management Institute, project
stakeholders are defined as:
• “Individuals and organizations who are actively involved in the
project, or whose interests may be positively or negatively
affected as a result of project execution or successful project
completion.”
• In other words, your project’s stakeholders are the people or
groups who have something to gain (or lose) from your
project’s outcome

By. Dr.Madhulika 134

By. Dr.Madhulika 135
• Internal stakeholders
• These stakeholders are coming from within the house!!!
Internal stakeholders are people or groups within the
business, such as team members, managers, executives, and
so on.
• External stakeholders
• External stakeholders are — as you can probably guess —
people or groups outside the business.
• This includes customers, users, suppliers, and investors.

By. Dr.Madhulika 136

 (highly technologically-advanced) matrix
above, stakeholders who fall into the top-right
quadrant (powerful + interested) are the ones
you should be giving extra attention to,
because they’re the ones who can have the
most impact on your project

By. Dr.Madhulika 137

analysis

By. Dr.Madhulika 138

By. Dr.Madhulika 139
 What is management?
This involves the following activities:
• Planning – deciding what is to be done
• Organizing – making arrangements
• Staffing – selecting the right people for the
job
• Directing – giving instructions

continued…
140
 What is management?
(continued)
• Monitoring – checking on progress
• Controlling – taking action to remedy hold-ups
• Innovating – coming up with solutions when
problems emerge
• Representing – liaising with clients, users,
developers and other stakeholders

141
 Setting objectives
• Answering the question ‘What do we have
to do to have a success?’

• Need for a project authority

– Sets the project scope
– Allocates/approves costs

• Could be one person - or a group

– Project Board
– Project Management Board
– Steering committee

142
 Objectives
Informally, the objective of a project can be defined
by completing the statement:

The project will be regarded as a success

if………………………………..

Rather like post-conditions for the project

Focus on what will be put in place, rather than how

activities will be carried out

143
 Objectives should be SMART
S– specific, that is, concrete and well-defined

M– measurable, that is, satisfaction of the

objective can be objectively judged

A– achievable, that is, it is within the power of the

individual or group concerned to meet the target

R– relevant, the objective must relevant to the

true purpose of the project

T– time constrained: there is defined point in time

by which the objective should be achieved
144
 Goals/sub-objectives
These are steps along the way to achieving the
objective. Informally, these can be defined by
completing the sentence…

Objective X will be achieved

IF the following goals are all achieved
A……………
B……………
C…………… etc

145
 Goals/sub-objectives
Often a goal can be allocated to an individual.
Individual may have the capability of achieving goal,
but not the objective on their own e.g.

Objective – user satisfaction with software product

Analyst goal – accurate requirements

Developer goal – software that is reliable

146
 Challenges in Software
Project management

By. Dr.Madhulika 147

• Globalization causing high competition.
• Older legacy systems and infrastructure issues.
• Adoption rates and time to market pressures.
• SaaS offerings taking over.
• Internal sourcing or outsourcing.
• Sufficient software requiring specific expertise.
• Integration and interface issues.
• Multiple software bug testing & resolution iterations.
• Multiple and complex user level requirements.
• Difficulty attracting and retaining applicable talent.
• ROI (return on investment).
• Evolving revenue recognition requirements/reporting for software
companies
By. Dr.Madhulika 148
• Competition can be local or international and
impact software companies in terms of pricing
structures, customer reach, customer
retention, service level agreements and a host
of other factors.

By. Dr.Madhulika 149

• Often businesses have invested significant financial and human resources
implementing, enhancing, maintaining and patching older legacy systems
and infrastructures. As a result, there may be great reluctance to replace
them, even if these systems no longer meet their needs, creating a
scenario where it is an uphill battle for innovative software companies to
get their foot in the door, even though they have a top-notch solution that
businesses can greatly benefit from.

By. Dr.Madhulika 150

• As a general rule, the more complex the
system, project implementation, and the
larger the organization, the more likely direct
system related project implementation
experience will be required.

By. Dr.Madhulika 151

• With increasing frequency, older legacy
systems and large ERP systems are being
replaced with Saas offerings, enabling small,
mid-siz and large businesses to access the
same or better features and capabilities
without outlaying large amounts of valuable
capital.

By. Dr.Madhulika 152

• Businesses require system users at multiple levels, some may be basic
users, some may be power users, administrators and some may be strictly
IT users. When it comes to systems implementations project managers in
the software industry need to be versed in all the different types of users
with specific systems, and the types of user access rights and permissions
for each. This can range from complex to extremely complicated
depending on the system.

By. Dr.Madhulika 153

• Software vendors can no longer develop standalone solutions.
There is an increasing need for third-party integration, making
it more complex for project managers as they are under
pressure to increase their knowledge and experience with
other software that may interface with the one they are
implementing. To some degree, it can be as if they are
implementing multiple systems within one project.

By. Dr.Madhulika 154

• STEPWISE PROJECT PLANNING:
Introduction, selecting a project; identifying
project scope and objectives; identifying
project infrastructure,analyzing project
characteristics; identifying project products
and activities; estimate efforts each activity;
identifying activity risk; allocate resources;
review/ publicize plan

By. Dr.Madhulika 155

By. Dr.Madhulika 156
 Introduction
• Describes a framework of basic steps in
project planning.
• It includes only the planning stages of a
project and not monitoring and control.
• Major principle of project planning is to
plan in outline first and then in more detail
as the time to carry out an activity
approaches.

Madhulika(Assistant Professor,ASET
10/21/2024 157
CSE,Amity University
 Step wise planning
activities

Madhulika(Assistant Professor,ASET
10/21/2024 158
CSE,Amity University
 Step 0: Select project
• It is outside the main project planning process.
• Some process must decide to initiate a project
from the proposed projects.
• A feasibility study can be helpful.
• Evaluation of the Merits of the project could
be a part of strategic planning.
• Explaination Step 0 Word document

Madhulika(Assistant Professor,ASET
10/21/2024 159
CSE,Amity University
Step 0

By. Dr.Madhulika 160

Step 1:Identify project scope and
activities
• Identify objectives and measures of effectiveness in
meeting them
• Establish a project authority
• Identify stakeholders
• Modify objectives in the light of stakeholders analysis
• Establish methods of communications with all parties
• Refer Word file for Explaination

Madhulika(Assistant Professor,ASET
10/21/2024 161
CSE,Amity University
Step 1

By. Dr.Madhulika 162

 Step 1 establish project scope and
objectives
• 1.1 Identify objectives and measures of effectiveness
– ‘how do we know if we have succeeded?’

• 1.2 Establish a project authority

– ‘who is the boss?’

• 1.3 Identify all stakeholders in the project and their

interests
– ‘who will be affected/involved in the project?’

163
 Step 1 continued
• 1.4 Modify objectives in the light of
stakeholder analysis
– ‘do we need to do things to win over
stakeholders?’

• 1.5 Establish methods of communication

with all parties
– ‘how do we keep in contact?’

164
 Step 1 continued
• 1.4 Modify objectives in the light of
stakeholder analysis
– ‘do we need to do things to win over
stakeholders?’

• 1.5 Establish methods of communication

with all parties
– ‘how do we keep in contact?’

165
By. Dr.Madhulika 166
By. Dr.Madhulika 167
Step 2: Identify project infrastructure

• Identify relationship between the

project and strategic planning
• Identify installation standards and
procedures
• Identify project team organization

Madhulika(Assistant Professor,ASET
10/21/2024 168
CSE,Amity University
 Step 2 Establish project infrastructure

• 2.1 Establish link between project and any

strategic plan
– ‘why did they want the project?’

• 2.2 Identify installation standards and

procedures.
– ‘what standards do we have to follow?’

• 2.3. Identify project team organization

– ‘where do I fit in?’

169
By. Dr.Madhulika 170
Strategic planning focuses on a business's
future by understanding operational priorities
and resource availability, setting out clear
objectives for desired business results, and
developing an action plan on how to achieve
them

By. Dr.Madhulika 171

By. Dr.Madhulika 172
Step 3: Analyse project Characteristics
• Distinguish the project as either objective or product
driven
• Analyze other project characteristics
• Identify high-level project risks
• Take into account user requirements concerning
implementation
• Select development method and general life-cycle
approach
• Review overall resource estimates(an estimate based
on FP might be used)

Madhulika(Assistant Professor,ASET
10/21/2024 173
CSE,Amity University
By. Dr.Madhulika 174
By. Dr.Madhulika 175
By. Dr.Madhulika 176
Step 4:Identify project products and
activities
• Identify and describe project products
(including quality criteria)
• Document generic product flows
• Recognize product instances
• Produce real activity network
• Modify ideal to take into account need for
stages and checkpoints

Madhulika(Assistant Professor,ASET
10/21/2024 177
CSE,Amity University
By. Dr.Madhulika 178
By. Dr.Madhulika 179
By. Dr.Madhulika 180
By. Dr.Madhulika 181
 Step 5: Estimate effort for each
activity
• Carry out bottom-up estimates
• Revise plan to create controllable activities

Madhulika(Assistant Professor,ASET
10/21/2024 182
CSE,Amity University
By. Dr.Madhulika 183
 Step 6:Identify activity risks

• Identify and quantify activity-based risks

• Plan risk reduction and contingency measures
where appropriate
• Adjust plans and estimates to take account of
risks.

Madhulika(Assistant Professor,ASET
10/21/2024 184
CSE,Amity University
By. Dr.Madhulika 185
 Step 7: Allocate resources

• IiIdentify and allocate resources

• Revise plans and estimates to take account of
resource constraints

Madhulika(Assistant Professor,ASET
10/21/2024 186
CSE,Amity University
By. Dr.Madhulika 187
 Step 8:Review/Publicize plan

• Review quality aspects of project plan

• Document plans and obtain agreement

Madhulika(Assistant Professor,ASET
10/21/2024 188
CSE,Amity University
 Step 9 and 10: Execute plan/lower
level of planning

• This may require the reiteration of the

planning process at a lower level

Madhulika(Assistant Professor,ASET
10/21/2024 189
CSE,Amity University
 0.Select project

2.Identify project
1.Identify project
infrastructure
Scope & objective

3.Analyse project
characteristics
Fig:- An
4.Identify the products
Overview
and activities
Review Of
step-wise
planning
5.Estimate effort for
Lower each activity For
Level Each
detail 6.Identify activity activity
risks
10.Lower level
planning 7.Allocate resources

9.Execute plan 8.Review/

10/21/2024
publicizeProfessor,ASET
Madhulika(Assistant plan 190
CSE,Amity University
 Key points in lecture
• Projects are non-routine - thus uncertain
• The particular problems of projects e.g. lack of
visibility
• Clear objectives are essential which can be
objectively assessed
• Stuff happens. Not usually possible to keep precisely
plan – need for control
• Communicate, communicate, communicate!

191
“WE” 2021, ASPM, M.Tech 1sem

By. Dr.Madhulika 192

ASPM LAB

By. Dr.Madhulika 193