Software Project Management - Module-I

Introduction to software project management

Project Management is the discipline of defining and achieving targets while optimizing
the use of resources (time, money, people, materials, energy, space, etc) over the course of a project
(a set of activities of finite duration).
Why is Software project management important?
• Large amounts of money are spent on ICT(Information and communications technology)
e.g. UK government in 2003-4 spent £2.3 billions on contracts for ICT and only £1.4
billions on road building
• Project often fail – Standish Group claim only a third of ICT projects are successful.
82%were late and 43% exceeded their budget.
• Poor project management a major factor in these failures
• 1 billion = 100 crore
Software Development Life Cycle:
The software development life-cycle is a methodology that also forms the frameworkfor
planning and controlling the creation, testing, and delivery of an information system.
The software development life-cycle concept acts as the foundation for multiple different
development and delivery methodologies, such as the Hardware development life-cycle and
Software development life-cycle. While Hardware development life-cycles deal specifically with
hardware and Software development life-cycles deal specifically with software, a Systems
development life-cycle differs from each in that it can deal with any combination of hardware
and software, as a system can be composed of hardware only, software only, or a combination of
both.

Four Project Dimensions

o People
o Process
o Product
o Technology

The 5 Variables of Project Control

1. Time - amount of time required to complete the project.
2. Cost - calculated from the time variable
3. Quality - The amount of time put into individual tasks determines the overallquality of
the project.
4. Scope - Requirements specified for the end result.
5. Risk - Potential points of failure.

Trade – off triangle:

The triangle illustrates the relationship between three primary
forces in a project. Time is the available time to deliver the project,
cost represents the amount of money or resources availableand quality
represents the fit-to-purpose that the project must achieve to be a
success.
The normal situation is that one of these factors is fixed and the other two will vary in inverse
proportion to each other. For example time is often fixed and the quality of the end product will
depend on the cost or resources available. Similarly if you are working to a fixed level of quality
then the cost of the project will largely be dependent upon the time available (if you have longer
you can do it with fewer people).

1.2 Project definition

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
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!
• Jobs- Very Little Uncertainty
• Task is well defined and there is little uncertainty.
• Software Process Management vs Software Project Management
Projects
• Projects seem to come somewhere between these two extremes. There are usually well-
defined hoped-for outcomes but there are risks and uncertainties about achieving those
outcomes.
• A software project can be defined as a planned activity that describes how we are going
to carry out a task before we start.
• It is a planned activity about developing a software before u actually design and
implementit.
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 engineeringpoint of view is the safe landing
of the robot, not the discovery of signs of life.
Writing an Operating System

Characteristics of projects
A task is more ‗project-like‘ if it is:
• Non-routine tasks are involved
• Planning is required
• Aiming at a specific target
• Carried out for a customer
• Carried out by a temporary work group
• Involving several specialisms
• Made up of several different phases
• Constrained by time and resources
• Large and/or complex
Are software projects really different from other projects? Not really …but
• Invisibility: Software project management can be seen as the process of making invisible
to visible
• Complexity: software products contain more complexity than other engineered artefacts.
• Conformity: Software developers have to conform to the requirements of human clients.
• Flexibility: Easy to change is strength, but

1.3 Contract management and Technical Project management

Contract management versus technical project management
Projects can be:
• In-house: clients and developers are employed by the same organization
• Out-sourced: clients and developers employed by different organizations
• ‗Project manager‘ could be:
– a ‗contract manager‘ in the client organization
– a technical project manager in the supplier/services organization
• Representing – liaising with clients, users, developers and other stakeholders

1.4 Activities covered by project management

A software project is not only concerned with the actual writing of software. Usually there
are three successive processes that bring a new system into being.

Feasibility study
 Is project technically feasible and worthwhile from a business point of
view?(recommendation of the feasibility study might be not to carry out the
proposed project)
Planning
Only done if project is feasible - evolving plan allows us to control the project.
Execution
Implement plan, but plan may be changed as we go along

The software development life-cycle (ISO 12207)

The software development life cycle is a technical model. It identifies the
technical constraints on the order activities are done. This does NOT imply that a ‗waterfall‘
approach is theonly way to organize projects. The technical model could be implemented as
increments or in an evolutionary manner.
ISO 12207 life-cycles are:
1. Requirements analysis
2. Architecture Design
3. Code and test
4. Installation \ Acceptance support

Requirements analysis
– Requirements eli-ci-tation(kindle): what does the client need?
– Analysis: converting ‗customer-facing‘ requirements into equivalents that
 developers can understand
– Requirements will cover
• Functions
• Quality
• Resource constraints i.e. costs
Requirement analysis has to face in (at least) two different directions. It needs to
communicate and elicit the requirements of the users, speaking in their language. It needs
to organize and translate those requirements into a form that developers can understand
and relate to.
Architecture Design

Software Software
Requirements Components

– Based on system requirements

– Defines components of system: hardware, software, organizational
– Software requirements will come out of this
Code and test
– Of individual components (separately coded and tested)
• Integration
– Putting the components together
• Qualification testing(the whole system)
– Testing the system (not just the software)
• Installation(meaning most like implementation) Install –Complete System
– The process of making the system operational
– Includes setting up standing data, setting system parameters, installing on
operationalhardware platforms, user training etc
• Acceptance support
– Including maintenance and enhancement

1.5 Plans, methods and methodologies

• A plan of an activity must be based on some idea of a method of work. While a method
relates to a type of activity in general, a plan takes one or more methods and converts them
into real activities by identifying:
Start and end dates
Who will carry it out
What tools and materials would be needed.
• A methodology is a set of related methods. Strictly speaking ‗methodology‘ ought to
mean the study of methods!
 Plans, methods and methodologies Methodology = a set of methods

Context

Plan
Methods
+ start and end dates for eachactivity, A way of working staffing, tools
and materials etc

Some ways of categorizing projects

Distinguishing different types of project is important as different types of task needdifferent
project approaches e.g.
• Voluntary systems (such as computer games –what game will do?) versus
compulsory systems e.g. the order processing system in an organization(recording
asale)
• Information systems(Enable staff to carry out office processes) versus
embedded systems(process control-which controls machine)
• Objective-based versus product-based
With objective-based projects, a general objective or problem is defined,
and there are several different ways in which that objective could be
reached. The project team have freedom to select what appears to be the
most appropriate approach.
With product-based projects, the product is already very strictly defined
and the development team’s job is to implement thespecification with
which they have been presented.

Stakeholders
These are people who have a stake or interest in the project Ingeneral, 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
Different stakeholders may have different objectives – need to define common project objectives
Project Leader is to recognize these different interests (good
Communicator/Negotiator)
Boehm & Ross – ‗Theory W‘ Win-Win
Setting objectives
• ‗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 Authority-most important-control-
finance-monitor-modify objectives)
– Project Board
– Project Management Board
– Steering committee
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
e.g. ‘a new payroll application will be operational by 4th April’ not ‘design and code a
new payroll application’
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 tomeet
the target
R – relevant/Resource Constrained, the objective must relevant to the true purpose of
theproject
T – time constrained: there is defined point in time by which the objective shouldbe
achieved
Goals/sub-objectives
These are steps along the way to achieving the objective
Informally, these can be defined by completing the sentence To reachobjective X, the following
must be in place
A……………
B……………
C .................... etc
Often a goal can be allocated to an individual. Individual might have the capability of achieving
goal on their own, but not the overall objective e.g.
Overall objective – user satisfaction with software product Analystgoal – accurate
requirements
Developer goal – reliable softwareMeasures of effectiveness
How do we know that the goal or objective has been achieved? By a practical test, that
can be objectively assessed.
e.g. for user satisfaction with software product:
• Repeat business – they buy further products from us
• Number of complaints – if low etc etc
• Measures of effectiveness
• Performance Measurement-
– To measure reliability – mtbf
– Mean time between failures
– Seek Predictive Measures
• Large number of errors during code, inspections needed
 Brainstorming
• Read the News article and find the Client‘s consideration /requirement before
outsourcinga project.
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
• Monitoring – checking on progress
• Controlling – taking action to remedy hold-ups
• Innovating – coming up with solutions when problems emerge

Project planning is an important responsibility of the project manager. During project planning, the
project manager needs to perform a few well-defi ned activities that have been outlined below. Note
that we have given a very brief description of these activities in this chapter. We will discuss these
activities in more detail in subsequent chapters. Several best practices have been proposed for software
project planning activities.
While PRINCE2 is used extensively in the UK and Europe, similar software project management best
practices have been put forward in the USA by the Project Management Institute’s ‘PMBOK’
which refers to their publication ‘A Guide to the Project Management Body of Knowledge.’
● Estimation The following project attributes are estimated.
● Cost How much is it going to cost to complete the project?
● Duration How long is it going to take to complete the project?
● Effort How much effort would be necessary for completing the project?
The effectiveness of all activities such as scheduling and staffi ng, which are planned at a later stage,
depends on the accuracy with which the above three project parameters have been estimated.
● Scheduling Based on estimations of effort and duration, the schedules for manpower and other
resources are developed.
● Staffing Staff organization and staffing plans are made.
● Risk Management This activity includes risk identification, analysis, and abatement planning.
● Miscellaneous Plans This includes making several other plans such as quality assurance plan,
configuration management plan, etc.
Project monitoring and control activities are undertaken after the initiation of development activities.
The aim of project monitoring and control activities is to ensure that the software development
proceeds as planned. While carrying out project monitoring and control activities, a project manager
may sometimes find it necessary to change the plan to cope with specifi c situations and make the plan
more accurate as more project data becomes available.

Management Control
Management, in general, involves setting objectives for a system and then monitoring the performance
of the system. In Figure 1.5 the ‘real world’ is shown as being rather formless. Especially in the case
of large undertakings, there will be a lot going on about which management should be aware. This
will involve the local managers in data collection. Bare details, such as ‘location X has processed 2000
documents’, will not be very useful to higher management: data processing will be needed to transform
this raw data into useful information. This might be in such forms as ‘percentage of records processed’,
‘average documents processed per day per person’ and ‘estimated completion date’. It can be seen
that a project plan is dynamic and will need constant adjustment during the execution of the project.
Courses and books on project management (such as this one) often focus considerable attention on
project planning. While this is to be expected, with nearly all projects much more time is spent actually
doing the project rather than planning it. A good plan provides a foundation for a good project, but is

nothing without intelligent execution. The

original plan will not be set in stone but will be modifi ed to take account of changing circumstances.

1.15 Traditional versus Modern Project Management Practices

Over the last two decades, the basic approach taken by the software industry to develop software has
undergone a radical change. Hardly any software is being developed from scratch any more. Software
development projects are increasingly being based on either tailoring some existing product or reusing
certain pre-built libraries. In either case, two important goals of recent life cycle models are
maximization of code reuse and compression of project durations. Other goals include facilitating and
accommodating client feedbacks and customer participation in project development work, and
incremental delivery of the product with evolving functionalities. Change requests from customers are
encouraged, rather than circumvented. Clients on the other hand, are demanding further reductions in
product delivery times and costs. These recent developments have changed project management
practices in many signifi cant ways. In the following section, we will discuss some important
differences between modern project management practices and traditional practices.
● Planning Incremental Delivery Few decades ago, projects were much simpler and therefore more
predictable than the present day projects. In those days, projects were planned with suffi cient detail,
much before the actual project execution started. After the project initiation, monitoring and control
activities were carried out to ensure that the project execution proceeded as per plan. Now, projects
are required to be completed over a much shorter duration, and rapid application development and
deployment are considered key strategies. The traditional long-term planning has given way to
adaptive short-term planning. Instead of making a long-term project completion plan, the project
manager now plans all incremental deliveries with evolving functionalities. This type of project
management is Software Project Management often called extreme project management. Extreme
project management is a highly fl exible approach to project management that concentrates on the
human side of project management (e.g., managing project stakeholders), rather than formal and
complex planning and monitoring techniques.
● Quality Management Of late, customer awareness about product quality has increased signifi cantly.
Tasks associated with quality management have become an important responsibility of the project
manager. The key responsibilities of a project manager now include assessment of project progress
and tracking the quality of all intermediate artifacts.
● Change Management Earlier, when the requirements were signed off by the customer, any changes
to the requirements were rarely entertained. Customer suggestions are now actively being solicited
and incorporated throughout the development process. To facilitate customer feedback, incremental
delivery models are popularly being used. Product development is being carried out through a series
of product versions implementing increasingly greater functionalities. Also customer feedback is
solicited on each version for incorporation. This has made it necessary for an organization to keep
track of the various versions and revisions through which the product develops. Another reason for the
increased importance of keeping track of the versions and revisions is the following. Application
development through customization has become a popular business model. Therefore, existence of a
large number of versions of a product and the need to support these by a development organization has
become common. In this context, the project manager plays a key role in product base lining and
version control. This has made change management a crucial responsibility of the project manager.
Change management is also known as configuration management.

Step wise : an overview of project planning

Planning is the most difficult process in project management This chapter describes a framework
of basic steps in project planning. Many different techniques can be used but this chapter tells the
overview of the steps and activities in each step of project planning .
A major step in project planning is to plan in outline first and then in more detail.

Following are the major steps in project planning

 Steps in Project Planning

Step 0 : Select project

Step 1 : Identify project scope and objectives Step 2 : Identify project infrastructure
Step 3 : Analyze project characteristics
Step 4 : Identify project products and activities Step 5: Estimate effort for each activity.
Step 6 : Identify activity risks. Step 7 : Allocate resources Step 8 Review / Publicize pl\an
Step 9 & 10 : Execute plan / lower level of planning

Each step of project planning has different activities to perform. Following the description of ach
step with its activities
Step 0 : Select project
This is called step 0 because in a way of project planning , it is out side the main project planning
process. Feasibility study suggests us that the project is worthwhile or not.

Step 1 : Identify project scope and objectives

The activities in this step ensure that all parties to the project agree on the objectives and
are committed to the success of the project.

Step 1.1 : Identify objectives and practical measures of the effectiveness in meeting those
objectives
Step 1.2 : Establish project authority
Step 1.3 : Stakeholders analysis – Identify all stakeholders in the project and theirinterest.
Step 1.4 : Modify objectives in the light of stakeholder anaylsis.
Step 1.5 : Establish method of communication

Step 2 : Identify project infrastructure

Projects are rarely carried out in a vacuum. There is usually some kind of infrastructure into
which the project must fit. Where the project manager are new to the organization , they
must find out the precise nature of this infrastructure.
Step 2.1: Identify relationship between the project and strategic planning
Step 2.2 : Identify installation standards and procedures.
Step 2.3 : Identify project team organization.

Step 3 : Analyze project characteristics.

 The general purpose of this part of planning operation is to ensure that the appropriate
methods are used for the project.
Step 3.1 : Distinguish the project as either objective- product driven
Step 3.2 : Analyze other project characteristics ( including quality –based ones)
Step 3.3 : Identify high level project risks
Step 3.3 : Take into account user requirement concerning implementation.
Step 3.4 : Select development methodology and life cycle approach.
Step 3.5 : Review overall resources estimates

1.6 Stepwise Planning(step 4- step 5 )

Step 4 Identify project products and activities

• 4.1 Identify and describe project products - ‘what do
we have to produce?’

14

Products

• The result of an activity

• Could be (among other things)
– physical thing (‘installed pc’),
– a document (‘logical data structure’)
– a person (‘trained user’)
– a new version of an old product (‘updated software’)
• The following are NOT normally products:
– activities (e.g. ‘training’)

-I
 Step 4 continued
• 4.2 document
generic product
flows

Step 4.3 Recognize product instances

• The PBS and PFD will probably have identified generic

products e.g. ‘software modules’
• It might be possible to identify specific instances
e.g. ‘module A’, ‘module B’ …
• But in many cases this will have to be left to later, more
detailed, planning

4.4. Produce ideal activity network

• Identify the activities needed to create each product in the

PFD
• More than one activity might be needed to create a single
product
• Hint: Identify activities by verb + noun but avoid
‘produce…’ (too vague)
• Draw up activity network
 An ‘ideal’ activity

Step 5:Estimate effort for each activity

• 5.1 Carry out bottom-up estimates
– distinguish carefully between effort and
elapsed time
• 5.2. Revise plan to create controllable activities
– break up very long activities into a series ofsmaller ones
– bundle up very short activities (create check lists?)

Step 6: Identify activity risks

• [Link] and quantify risks for activities
– damage if risk occurs (measure in time lost or money)
– likelihood if risk occurring
• 6.2. Plan risk reduction and contingency measures
– risk reduction: activity to stop risk occurring
– contingency: action if risk does occur
• 6.3 Adjust overall plans and estimates to take account ofrisks
– e.g. add new activities which reduce risks associated with otheractivities e.g. training, pilot
trials, information gathering

Step 8 : Review / Publicize plan

Step 8.1 : Review quality aspects of the project plan.
Step 8.2 : Document plans and obtain agreement.

Step 9 & 10 : Execute plan / lower level of planning

 Once the project is underway, plans will need to be drawn up in greater detail for each
activity as it becomes due. Detailed and lower level of planning of the the later stages will need to
bedelayed because more information will be available nearer the start of the stage.
Project planning is an iterative process. As the time approaches for the particular activities to be
carried out they should be re-planned in more detail.

1.9 Activity Planning

1. IDENTIFY THE ACTIVITY:
Can you answer the following questions on the activity?
a. What is the activity? Can you give a brief description of what it is andwhat will
be involved?
b. Who is the activity designed for? Is it for a club, a class, the whole student
body?
c. When is the activity planned for? Do you have a target date to plan your other
deadlines around?
d. How much will the activity cost? Do you have money allotted for the activity?
Is it enough, and can you get more if needed? Will there be a fee charged for this
activity and is there a bookkeeping system to handle that account?
2. PLANNING THE ACTIVITY
Step 1: Getting the manpower—Assemble members of your committee through asking people
youknow you can depend on and who are willing to work, in addition to having ―sign
ups‖ or
―recruiting‖.
Step 2: Getting the advisor—In many aspects of activity planning and following through, it is
highly recommended that you seek an advisor, or an adult staff member who is willing to assist
you in planning and supervising the follow through of your plans.
Step 3: How should we plan the activity?
a. Brainstorm: After getting your committee and advisor together, ―brainstorm‖ over every
possible step that would be needed to plan the activity. As a guide, prior to brainstorming,
remindthe committee of the following guidelines:
1. No idea is stupid, so no criticism of any suggestion is allowed. 2. Let theideas flow freely, let
everyone complete their suggestion before moving on to the next one.
3. Keep going until every thought is exhausted.
b. Weeding out ideas: After looking at the completed list of ideas, go over each item
SEPERATELY and OBJECTIVELY to see if it is an idea that is definitely valid and essential
toyour planning. If not, eliminate it from the list.
c. Prioritize the items: After looking at the ―slimmed down‖ list, asterisk (*) or underline those
planning areas that would require MAJOR attention. Have the committee keep in mind that these
areas may be the basis for the formation of ―sub-committees‖, or related task groups to be
responsible for these MAJOR items.
d. Chronological listing of the planning list: After sorting out the ―major areas‖, have the group
list the items in ―chronological order‖, or list what should be completed from first to last.
Assigning people to handle specific tasks: After agreeing to the organization of the planning of
theactivity, asking your committee members to handle the major areas identified by the group.
e. Giving deadlines: Since every task was listed chronologically, now you can assign
DEADLINES,or target dates by which these steps should be completed. Make sure these dates are
realistic.
PRIOR TO THE ACTIVITY (Would suggest a target date of a week to 10 days prior)
a. Check up: Make sure everyone has their areas of responsibility properly covered. If
anything isnot covered, find out why then make the proper
arrangements.
b. Activity day plan
1. Diagram the facilities to be used: Get an idea of the physical area that you will be using.
2. List the major stations/areas of responsibility for the day of
the activity: Review stations then check manpower assignments to make sure these areas
arecovered.
c. Simulation/run through: If possible, actually run through the activity in the facility to be used.
For example, have the person assigned to handle registration for the activity actually practice
having the ―check in‖ table go through the simulation of collecting money and stamping hands for
a dance.
The main thing to stress here is that as a chairperson, you are to supervise or ―direct traffic‖. You
cannot physically do everything so make sure that those assigned know their duties well enough
so that you won‘t have to worry about anything except for handling emergencies.
4. DAY OF THE ACTIVITY
a. Brief run through
b. Make the proper acknowledgements: If you are emceeing the activity, take time to
properlyacknowledge your ―crew‖ for their work and efforts.
5. AFTER THE ACTIVITY
a. Send out your thank you notes/letters: This is the official acknowledgement of their efforts.
Take the time even before the activity to prepare these notes or letters so that you can get them out
immediately after the activity date.
b. Evaluation: Review and analyze your efforts and keep good records to help out the next person
who will be responsible for this activity. Remember to list very specific recommendations.