MODULE-1

Introduction to Software Project Management

Topics Covered:

Introduction
Some ways of categorizing software

Why is Software Project Management projects
important?
Stakeholders, Setting Objectives

What is a Project?
Business Case

Contract management
Project Success and Failure

Activities Covered by Software Project
What is Management?
Management
Management Control

Plans
Traditional versus Modern Project

Methods and Methodologies Management Practices

Introduction:

What exactly do we mean by “Software Project Management”?

To answer this we need to look at some key ideas about the planning, monitoring &
control of software projects.

Software = Program + Operating procedures +Documentation

Projects to produce software are worthwhile only if they satisfy real needs and so we
will examine how we can identify the stakeholders in the project and their objectives. Identifying
those objectives and checking that they are met in the basis of successful project.

This, however cannot be done unless there is accurate information and how this is
provided will be explored.

What is a Project?

The dictionary definitions put a clear emphasis on the project’s being a planned activity.
Dictionary definitions:

 ‘A specific plan or design’

 ‘A planned undertaking’

 ‘A large undertaking: for example, a public works scheme’

The key characteristics that distinguish projects are as follows:

 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

 Work involves several specialism's

 Work is carried out is several phases

 The resources that are available for use on the project are constrained

 The project is large or complex

Software projects versus other types of projects:

Fred Brooks pointed out that the products of software projects have certain
characteristics that make them different.

One way of perceiving software project management is as the process of making visible that
which is invisible.

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

b. Complexity: Per dollar, pound or euro spent, software products contain more complexity
than other engineered artifacts.

c. Flexibility: The ease with which software can be changed is usually seen as one of its
strengths. This means the software systems are likely to be subject to a high degree of
change.

Activities covered by a SPM:

There are 3 successive processes that bring a new system into being:

1) Feasibility study
2) Planning
3) Project execution
Feasibility study:

Is it worth doing?

Decide proposed project is worth starting

Probable development & operational cost

Estimate the benefits\

Is project technically feasible and worth

worth-while
from a business point of view?

SMART -Rule

S - Specific

M - Measurable

A- Achievable

R - Relevant

T- Time constrained

Plan:

How do we do it?

Outline plan and detailed plan

Project Execution:

By considering the “Classic Project Life Cycle”

Do it
Classic Project Life Cycle: -

1) Requirement analysis

2) Specification

3) Design

4) Coding

5) Verification & validation

6) Implementation/installation

7) Maintenance & support

 Requirement Analysis: Finding out in details what the users require of the system that
the project is to be implemented.
 Specification: Detailed document of what the proposed system is to do (SRS).
 Design: A design that meets the specification has to be drawn up. This design activity
will be carried out in two stages.

o External or user design – Lays down what the system is to look like in terms of
menus, screens, report layouts, etc.

o Physical design – Tackles the way in which the data and software procedures are
to be structured internally.

 Coding: Refer to writing code in a procedural language like C, etc.

 Verification & validation: Whether the software is developed specially for the current
application or not, careful testing will be needed to check that the proposed system meets
its requirements.
 Implementation & installation: Some system development practitioners refer to the
whole of the project after design as implementation, while others insist that the term
 refers to the installation of the system after the software has been developed. (User
manuals are written to train new users)
 Maintenance & support: Once the system has been implemented there will be a
continuing need for the correction of any errors that may have crept into the system and
for extensions and improvements to the system. Maintenance and support activities may
be seen as a series of minor software projects.

Plans, Methods and Methodologies: -

 Plan – Some idea of work. A plan takes method.

 Method – Type of activity. It relates to type of activity.

E.g.: Converts it to real activities. Deciding what method to use to carry out
the following:

• Start and end

• Who will carry it out?

• What tools and materials will be used?

 Methodologies – Group of methods or techniques. E.g.: Object oriented design,

because methodology is made up of several component methods.

Example: Searching

Plan: Some idea to start the work. E.g.: Search is a plan

Method: Type of activity. E.g.: Binary Search

Methodology: Group of methods. E.g.: Linear search, Binary search, etc.

Note: “A plan takes method”

Some ways of categorizing software projects

It is important to distinguish between the main types of software project because what is
appropriate in one context might not be so in another. For example, SSADM, the Structured
Systems Analysis and Design Method, is suitable for developing information systems but not
necessarily other types of system.

Embedded systems are also called real-time or industrial systems.

• Information systems versus embedded systems

A distinction may be made between information systems and embedded systems. Very
crudely, the difference is that in the former case the system interfaces with the organization,
whereas in the latter case the system interfaces with a machine! A stock control system would be
an information system that controls when the organization reorders stock. An embedded, or
process control, system might control the air conditioning equipment in a building. Some
systems may have elements of both so that the stock control system might also control an
automated warehouse.

Exercise- Would an operating system on a computer be an information system or an embedded

system?
Service level agreements are becoming increasingly important as organizations contract out
functions to external service suppliers.

• Objectives versus products

Projects may be distinguished by whether their aim is to produce a product or to meet certain
objectives.

A project might be to create a product the details of which have been specified by the client. The
client has the responsibility for justifying the product.

On the other hand, the project might be required to meet certain objectives. There might be
several ways of achieving these objectives in contrast to the constraints of the product-driven
project. One example of this is where a new information system is implemented to improve some
service to users inside or outside an organization. The subject of an agreement would be the level
of service rather than the characteristics of a particular information system.

Many software projects have two stages. The first stage is an objectives-driven project, which
results in a recommended course of action and may even specify a new software application to
meet identified requirements. The next stage is a project actually to create the software product.

The Project as a system: -

A project is concerned with creating a new system and/or transforming an old one and is
itself a system.

a) Systems, subsystems and environments – A simple definition of the term system is ‘a

set of interrelated parts’. A system will normally be part of a larger system and will itself
comprise subsystems.
Outside the system there will be the system’s environment. This will be made up
of things that can affect the system but over which the system has no direct control.

b) Open versus closed systems – Open systems are those that interact with the
environment. Nearly all systems are open. One reason that engineered systems and the
projects to construct them often fail is that the technical staff involved do not appreciate
the extent to which systems are open and are liable to be affected by outside changes.

c) Sub-optimization – This is where a subsystem is working at its optimum but is having

detrimental effect on the overall system. An example of this might be where software
developers deliver to the users a system that is very efficient in its use of machine
resources, but is also very difficult to modify.

d) Sociotechnical systems – Software projects belong to this category of systems. Any

software project required both technological organization and also the organization of
people. Software project managers therefore need to have both technical competence and
the ability to interact persuasively with other people.
What is management?

The management 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 holds-ups
• Innovating – coming up with new solutions
• Representing – liaising with users etc

Problems with the software projects: -

• Poor estimates and plans

• Lack of quality standards and measures
• Lack of guidance about making oraganizational decisions
• Lack of techniques to make progress visibile
• Poor role definitin – who does what?
• Incorrect succes criteria

The above list looks at the project from the manager’s point of view. What about the staff
who make up the members of the project team? Below is a list of the problmes identified by a
number of students on a degree course in Computing and Information Systems who had just
completed a year’s placement:

• Inadequate specification of work

• Management ignorance of IT
• Lack of knowledge of application area
• Lack of standards
• Lack of up-to-date documention
• Proceding activities not completed on time
 • Lack of communication between users and technicians
• 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
• Chaning software environment
• Deadling pressure
• Lack of quality control
• Remote management
• Lack of training

Management Control: -

Management, in general can be seen as the process of setting objectives for a system and
then monitoring the system to see what its true performance is.

Project Control Cycle

What is meant by management control?
 Management control describes the means by which the actions of individuals or groups
within an organization are constrained to perform certain actions while avoiding other actions in
an effort to achieve organizational goals.
Management, in general, can be seen as the process of setting objectives for a system and
then monitoring the system to see what its true performance is. In Figure 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. As an example, take an IT project that is to
replace locally held paper-based records with a centrally-organized database. It might be that
staff in a large number of offices that are geographically dispersed need training and then need to
use the new IT system to set up the back-log of manual records on the new database. It might be
that the system cannot be properly operational until the last record has been transferred. It might
also be the case that the new system will be successful only if new transactions can be processed
within certain time cycles. The managers of the project ought to be asking questions about such
things as how effective training has been, how many records have still to be transferred to the
new database and transfer rates. 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'.

Several different proposals could be modelled in this way before one was chosen for
implementation.

Having implemented the decision, the situation needs to be kept under review by
collecting and processing further progress details. For instance, the next time that progress is
reported, a branch to which staffs have been transferred might still be behind in transferring
details. This might be because the reason why the branch has got behind in transferring details is
because the manual records are incomplete and another department, for whom the project has a
low priority, has to be involved in providing the missing information. In this case, transferring
extra staff to do data input will not have accelerated data transfer.
Objectives

Project objectives should to have a successful software project, the manager and the
project team members be clearly defined. Must know what will constitute success. This will
make them concentrate on what is essential to project success.

There might be more than one set of users of a system and there might be different
groups of staff who are involved its development. There is a need for well defined objectives that
are accepted by all these people. Where there is more than one user group, then a project
authority needs to be identified. Such a project authority has overall authority over what the
project is to achieve.

This authority is often held by a project steering committee, which has overall
responsibility for setting, monitoring and modifying objectives. The project manager still has
responsibility for running the project on a day to day basis, but has to report to the steering
committee at regular intervals. Only the steering committee can authorize changes to the project
objectives and resources.

Measures of effectiveness

Effective objectives are concrete and well defined. Vague aspirations such as 'to improve
customer relations' are unsatisfactory. Objectives should be such that it is obvious to all whether
the project has been successful or not. Ideally there should be measures of effectiveness, which
tell us how successful the project has been. For example, 'to reduce customer complaints by 50%'
would be more satisfactory as an objective than 'to improve customer relations'.

Sub-objectives and goals

In order to keep things manageable, objectives might need to be broken down into sub-
objectives. Here we say that in order to achieve A we must achieve B, C and D first. These sub-
objectives are also known as goals, steps on the way to achieving an objective, just as goals
scored in a football match are steps towards the objective of winning the match.
Stakeholders: -

There are people who have a stake or interest in the project. It is important that they be
identified as early as possible, because you need to set up adequate communication channels
with then right from the start.

The project leader also has to be aware that not everybody who is involved with a project
has the same motivation and objectives. The end users might, for instance, be concerned about
the ease of use of the system while their managers might be interested in the staff savings the
new system will allow.

Stake holders might be internal to the project team, external to the project team but in the
same organization or totally external to the organization.

• Internal to the project team – This means that they will be under the direct managerial
control of the project leader.
• External to the project team but within the same organization – For example, the
project leader might need the assistance of the information management group in order to
add some additional data types to a database or the assistance of the users to carry out
systems testing. Here the commitment of the people involved has to be negotiated.
• External to both the project team and the organization – External stakeholders might
be customers (or users) who will benefit from the system that the project implements or
contractors who will carry out work for the project. One feature of the relationship with
these people is that is likely to be based on a legally binding contract.

Different types of stakesholders might have different objectives and one of the jobs of the
successful project leader is to recognize these different interests and to be able to reconcile
them. It should therefore come as no surprise tht the project leader needs to be a good
communicator and negotiator.

Boehm and Ross proposed a ‘Theory W’ of software project management where the
manager concentrates on creating situations where all parties involved in a project benefit form it
and therefore have an inerest in its success. (The ‘W’ stands for Everyone a Winner).
Requirements Specification:

Very often, especially in the case of product-driven projects, the objectives of the project
are carefully defined in terms of functional requirements, quality requirements and resource
requirements.

• Functional requirements: These define what the system that will be the end product of
the project is to do. Systems analysis and design methods, such as SADT and Information
Engineering are designed primarily to provide functional requirements.
• Quality requirements: There will be other attributes of the system to be implemented
that do not relate so much to what the system is to do but how it is to do it. These are still
things that the user will be able to experience. They include, for example, response time,
the ease of using the system and its reliability.
• Resource requirements: A record of how much the organization is willing to spend on
the system. There will usually be a trade-off between this and the time it takes to
implement the system. In general it costs disproportionately more to implement a system
by an earlier date than a later one.

Information and control in organizations: -

With small projects, the project leaders are likely to be working very closely with the
other team members and might even be carrying out many non-managerial tasks themselves.
Therefore they should have a pretty good idea of what is going on.

Larger projects are likely to have a hierarchical management structure shown in the
figure. Project team members will each have a group leader who allocates them work and to
whom they report progress.

Management Information flows up the

organizational structure and conrol flows
down
Levels of decision making and information:

Each decidion made in a project environement should be based on adequate information of

the correct sort. The type of information needed depends on the level of decision making.
Decisions can be grouped at three levels:

• Strategic – It is essentially about deciding objectives.

• Tactical –It is needed to ensure that the objectives will be fulfilled.
• Operational – Relate to the day-to-day work of implementing the project.

Differences in types of information:

Below table gives some idea of the difference in the kind of information needed. There is
a kind of continuum of most of the qualiteis suggested and what is needed for tactical decision
makding comes somewhere in the middle.

Effectiveness is concerned with doing the right thing. Efficiency is carrying out a task
making the best possible used of the resources.

Types of information required for making decisions

Measurement:

The leader of a small project will have direct contact with many aspects of the project.
With larger projects, project leaders would have to depend on the information being supplied to
them. This information shout not be vague and ideally should be quantitative. This ties in with
our need for unambiguous measures of effectiveness.

Software development deals largely with intangibles and does not easily lend itself to
quantitative measures, but attempts are increasingly being made to introduce measurement into
the software process.

Software measurements can be divided into performance measures and predictive

measures.

• Performance measures: These measure the characteristics of a system that has been
delivered. They are important when we are trying to specify unambiguously the quality
requirements of a proposed system.
• Predictive measures: The trouble with performance measures is that you need to have a
system actually up and running before you can take measurements. As a project leader,
what you want to be able to do is to get some idea of the likely characteristics of the final
system during its development. Predicative measures are taken during development and
indicate what the performance of the final system is likely to be.
Project Management Life Cycle:

Phases/Activities of Project management life cycle:

1. Project Initiation

• Different characteristics of s/w to be developed are thoroughly understood

• Aspects which are considered are:
• The scope of the project
• Project constraint,
• Cost that would be incurred
• Benefit that would be incurred

It consists of 7 questions; Answering to these will reveal the key

characteristics of the project

 Why is the software being built?

 What will be done?

 When will be done?

 Who is responsible for a function?

 Where they are organizationally located?

 How will the job be done technically & managerially?

 How much of each resource is needed?

2. Project Planning

• A project charter is created

• Project manager creates following documents:

• Project plan

• Resource plan

• Financial plan
 • Quality Plan

• Risk Plan

3. Project Execution

• Tasks are executed as per project plan

• Monitoring & control process are executed to ensure tasks are executing as per plan

4. Project closure
• It involves the completing the release of all the deliverables to the customer along
with necessary documentation.
• All project resources are released
• Supply agreements with vendors are terminated
• Pending payments are completed

Traditional versus Modern Project Management Practices:-

Planning Incremental Delivery:

• Traditional Practice- Long-term planning

• Modern practice- Incremental delivery (Extreme Project Management Approach)

Quality Management:

• Assessment of project progress & tracking the quality at every phase

Change management:

• Configuration/version management

• (Ex: Local VCS [RCS,IBM Rational clear case, Apache Subversion],Distributed VCS
[Git, Mercurial, Bazaar, Darcs])

Risk Management:

• Risk- Negative situation which affects the project success

• Ex: Technology, personnel & customer

• Risk identification, Risk Assessment, Risk Prioritization, Risk reduction

• Ex: Delphi Technique, Brain storming, SWAT Analysis , Root Cause Analysis,
Interviewing

Scope Management:

• Modern practice- Encourages change requests

• Change request is interdependent on Scope, Schedule & project cost

• There shouldn’t be any “scope creep and Gold Plating”