PROJECT MANAGEMENT

Project Management

Project Management is the discipline (order or control) 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).

The job pattern of an IT company engaged in software development can be seen split in two
parts:

• Software Creation

• Software Project Management

A project is well-defined task, which is a collection of several operations done in order to

achieve a goal (for example, software development and delivery). A Project can be characterized
as:

• Every project may have a unique and distinct goal.

• Project is not routine activity or day-to-day operations.

• Project comes with a start time and end time.

• Project ends when its goal is achieved hence it is a temporary phase in the lifetime of an
organization.

• Project needs sufficient resources in terms of time, manpower, finance, material and
knowledge-bank.

Definition of Project Management

A simple definition of project management includes:

• Project management is no small task.

• Project management has a definite beginning and end. It's not a continuous process.

• Project management uses various tools to measure activities and track project tasks.
These include Work Breakdown Structures, Gantt charts and PERT charts.

• Projects frequently need ad-hoc resources rather than dedicated, full-time positions
common in organizations.

• Project management reduces risk and increases the chance of success.

1 B Naresh, Lecturer in Computer Science, BVRICE

 Often, a triangle, commonly called the "triple constraint", is used to summaries project
management. The three most important factors are time, cost and scope. These form the vertices
with quality as the central theme.

The triple constraint

In words, the triple constraint has four core elements:

• Projects must be within cost.

• Projects must be delivered on time.

• Projects must be within scope.

• Projects must meet customer quality requirements.

More recently, the project management triangle has given way to a project management
diamond - with cost, time, scope and quality as the four vertices and customer expectations as a
central theme.

The project management diamond

2 B Naresh, Lecturer in Computer Science, BVRICE

 No two customers have the same expectations. You must ask, explicitly, about each
customer's expectations. If you don't know what those expectations are, you have no hope of
meeting them.

Project Phases

A project goes through six phases during its lifecycle:

1. Project Definition: Defining the goals, objectives and critical success factors for the
project

2. Project Initiation: Everything 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 required to run the project

Roles of a Project Manager

Leader

A project manager must lead his team towards success. He should provide them direction
and make them understand what is expected of them. Clearly explain the roles of each member
of the team.

He must build a team comprising of individuals with different skills so that each member
contributes effectively to the best of their abilities.

Liaison

The project manager is a link between his clients, his team and his own supervisors. He
must coordinate and transfer all the relevant information from the clients to his team and report
to the upper management.

Mentor

He must be there to guide his team at every step and ensure that the team has cohesion.
He provides advice to his team wherever they need it and points them in the right direction.

3 B Naresh, Lecturer in Computer Science, BVRICE

Project Manager's Skill Set

A project manager must have a range of competencies:

• Leadership

• People management (customers, suppliers, functional managers and project team)

• Effective communication (verbal and written)

• Influencing

• Negotiation

• Conflict management

• Planning

• Contract management

• Estimating

• Problem solving

• Creative thinking

• Time management

Project managers put up with ultimate responsibility for making things happen.
Traditionally, they have carried out this role as simple implementers. To do their jobs they
needed to have the necessary administrative and technical competencies.

Barriers, Risks and Issues That Affect Project Success

Many things can go wrong in project management. Any barriers, risks and issues can
affect every phase and process of project management. Here are just some of the things that can
possibly go wrong:

• Poor communication

• Disagreement

• Misunderstandings

• Inclement weather

• Union strikes

• Personality conflicts
4 B Naresh, Lecturer in Computer Science, BVRICE
 • Poor management

• Poorly defined goals and objectives

A good project management discipline will not eliminate all risks, issues and surprises - but
it will provide standard processes and procedures to deal with them and help prevent the
following:

• Projects finishing late, exceeding budget and not meeting customer expectations

• Inconsistency between the processes and procedures used by project managers, leading to
the favoring of some project managers more than others

• Successful projects, despite a lack of planning, achieved through high stress levels,
goodwill and significant amounts of overtime

• Project management being seen as not adding value and as a waste of time and money

• Unforeseen internal and external events impacting the project

******************************************************************************

THE MANAGEMENT SPECTRUM or 4 P`s of Software System

Effective software project management focuses on the four P’s: people, product, process,
and project. The manager who forgets that soft-ware engineering work is an extremely human
effort will never have success in project management.

The effective software project management focuses on four P's.

The People

The Product

The Process

The Project

The People

The following categories of people are involved in the software process.

• Senior Managers

• Project Managers

• Practitioners

• Customers

5 B Naresh, Lecturer in Computer Science, BVRICE

 • End Users

Senior Managers define the business issue.

Project Managers plan, motivate, Organize and control the practitioners who do the
Software work.

Practitioners deliver the technical skills that are necessary to engineer a product
or application.

Customer specifies the requirements for the software to be developed.

End Users interact with the software once it is released.

The Product

• Before a software project is planned, the product objectives and scope should be
established technical and management constraints should be identified.

• Without this information it is impossible to define a reasonable cost, amount of

risk involved, the project schedule etc.

Scope can be defined by

• Context.

How does this product fit into business processes?

What systems will the product interact with?

• Objectives. What data objects are required as i/p or o/p

• Function.

What function does the software system perform on i/p to produce o/p What level of
performance is required

The Process

Here the important thing is to select an appropriate process model to develop the
software. There are different process models available.

They are

• Water fall model,

• Iterative water fall model,
• Prototyping model,

6 B Naresh, Lecturer in Computer Science, BVRICE

 • Evolutionary model,

• RAD(Rapid Application Development) model,

• Spiral model.

In practice we may use any one of the above models or a combination of

the above models.

The Project

In order to manage a successful software project, we must understand what can go

wrong (so that problems can be Avoided)and how to do it right. A project is a series of
steps where we need to make accurate decision so as to make a successful project.

• Projects get into risk when …

– Software people don’t understand their customer’s needs.

– The product scope is poorly defined.

– Changes are managed poorly.

– The chosen technology changes.

– Deadlines are unrealistic.

– Users are resistant.

– Sponsorship is lost.

– The project team lacks people with appropriate skills.

– Managers [and practitioners] avoid best practices and lessons learned.

******************************************************************************

The W5HH Principle in Project Management

Barry Bohem suggested an approach that addresses project objectives, milestones and
schedules, responsibilities, management and technical approaches and required resources. This is
called W5HH principle. The questions that are answered in this principle are:

1. Why is the system being developed?

2. What will be done?

3. When will it be done?

7 B Naresh, Lecturer in Computer Science, BVRICE

 4. Who is responsible for a function?

5. Where they are organizationally located?

6. How will the job be done technically and managerially?

7. How much of each resource is needed?

WHY IS THE SYSTEM BEING DEVELOPED?

It enables the parties to assess the validity of business reasons for the software work. It
justifies the expenditure of people, time, and money.

Stated in another way, does the business purpose justify the expenditure of people, time,
and money?

WHAT WILL BE DONE?

It specifies the task set required for the project.

WHEN WILL IT BE DONE?

It helps to determine the project schedule. It helps in determining when tasks are
conducted and when milestones are reached.

WHO IS RESPONSIBLE FOR A FUNCTION?

It helps to accomplish the role and responsibilities of each member of the software team.

WHERE THEY ARE ORGANIZATIONALLY LOCATED?

The software team does not contain all the roles and responsibilities. The customers,
users and stakeholders also have responsibilities.

HOW WILL THE JOB BE DONE TECHNICALLY AND MANAGERIALLY?

The management and technical strategy of project is defined once the scope of the
product is established.

HOW MUCH OF EACH RESOURCE IS NEEDED?

It helps in deriving estimates based on the answers to the above questions.

******************************************************************************

8 B Naresh, Lecturer in Computer Science, BVRICE

 Software estimation
In order to successful software project & proper execution of task, the Estimation
Techniques plays vital role in software development life cycle.

The technique which is used to calculate the time required to accomplish a particular task
is called Estimation Techniques.

To estimate a task different effective Software Estimation Techniques can be used to

get the better estimation.

What is Estimation?

“Estimation is the process of finding an estimate, or approximation, which is a value

that is usable for some purpose even if input data may be incomplete, uncertain, or unstable.”

The Estimate is prediction or a rough idea to determine how much effort would take to
complete a defined task. Here the effort could be time or cost.

A rough idea how long a task would take to complete. An estimate is especially an
approximate computation of the probable cost of a piece of work.

The calculation of test estimation techniques is based on:

• Past Data/Past experience

• Available documents/Knowledge
• Assumptions
• Calculated risks
Before starting one common question arises in the testers mind is that “Why do we
estimate?” The answer to this question is pretty simple, it is to avoid the exceeding timescales
and overshooting budgets for testing activities we estimate the task.

Few points need to be considered before estimating testing activities:

• Check if all requirements are finalize or not.

• If it not then how frequently they are going to be changed.
• All responsibilities and dependencies are clear.
• Check if required infrastructure is ready for testing or not.
• Check if before estimating task is all assumptions and risks are documented.

******************************************************************************

9 B Naresh, Lecturer in Computer Science, BVRICE

Empirical estimation models

COCOMO - An Empirical Estimation Model for Effort

Introduction:

The structure of empirical estimation models is a formula, derived from data collected
from past software projects that uses software size to estimate effort. Size, itself, is an estimate,
described as either lines of code (LOC) or function points (FP).

No estimation model is appropriate for all development environments, development

processes, or application types. Models must be customized (values in the formula must be
altered) so that results from the model agree with the data from the particular environment.

The typical formula of estimation models is:

Where;

E represents effort, in person months,

S is the size of the software development, in LOC or FP, and,

a, b, and c are values derived from data.

The relationship seen between development effort and software size is generally:

This graph demonstrates that the amount of effort accelerates as size increases, i.e., the
value c in the typical formula above is greater than 1.

10 B Naresh, Lecturer in Computer Science, BVRICE

COCOMO:

When Barry Boehm wrote 'Software Engineering Economics', published in 1981, he

introduced an empirical effort estimation model (COCOMO - COnstructive COst MOdel) that is
still referenced by the software engineering community.

The original COCOMO model was a set of models; 3 development modes (organic, semi-
detached, and embedded) and 3 levels (basic, intermediate, and advanced).

COCOMO model levels:

Basic - predicted software size (lines of code) was used to estimate development effort.

Intermediate - predicted software size (lines of code), plus a set of 15 subjectively assessed 'cost
drivers' was used to estimate development effort.

Advanced - on top of the intermediate model, the advanced model allows phase-based cost
driver adjustments and some adjustments at the module, component, and system level.

COCOMO development modes:

Organic - small relatively small, simple software projects in which small teams with good
application experience work to a set of flexible requirements.

Embedded - the software project has tight software, hardware and operational constraints.

Semi-detached - an intermediate (in size and complexity) software project in which teams with
mixed experience levels must meet a mix of rigid and less than rigid requirements.

COCOMO model:

The general formula of the basic COCOMO model is:

Where:

E represents effort in person-months,

S is the size of the software development in KLOC and,

a and b are values dependent on the development mode,

11 B Naresh, Lecturer in Computer Science, BVRICE

 The intermediate and advanced COCOMO models incorporate 15 'cost drivers'. These
'drivers' multiply the effort derived for the basic COCOMO model. The importance of each
driver is assessed and the corresponding value multiplied into the COCOMO equation, which
becomes:

12 B Naresh, Lecturer in Computer Science, BVRICE

 As an example of how the intermediate COCOMO model works, the following is a
calculation of the estimated effort for a semi-detached project of 56 KLOC. The cost drivers are
set as follows:

******************************************************************************

13 B Naresh, Lecturer in Computer Science, BVRICE

 Project Planning

The effective management of a software project greatly depends on careful planning the
progress of the project. The plan prepared at the start of a project is considered an initial plan and it
should be used as the driver for the entire project. The initial plan should be the best possible plan given
by the available information. It evolves as the project progresses and more information becomes
available.

The project plan

The project plan sets out the resources available to the project, the work breakdown and a schedule for
carrying out the work. Most project plans includes the following sections:

1. Introduction. This summarizes the objectives of the project and sets out the budget, time and
other constraints.

2. Work breakdown. This sets out the breakdown of the project into activities and identifies the
milestones and deliverables associated with each activity.

3. Hardware and software resource requirements. This specifies the hardware and the support
software allocated to development activities.

4. Project organization. This defines the development team, its members and the roles in the
team.

5. Project schedule. Project schedule shows the dependencies between activities, the estimated
time required to complete activities and the allocation of people to activities.

6. Risk analysis. This describes the possible project risks and the strategies to manage them.

7. Monitoring and reporting mechanisms. This defines the management reports that should be
produced, when these should be produced and the project monitoring mechanisms used.

******************************************************************************

14 B Naresh, Lecturer in Computer Science, BVRICE

 Risk Management
What Is Software Risk And Software Risk Management?

Risk is an expectation of loss, a potential problem that may or may not occur in the
future. It is generally caused due to lack of information, control or time.

A possibility of suffering from loss in software development process is called a software

risk.

Loss can be anything, increase in production cost, development of poor quality software,
not being able to complete the project on time. Software risk exists because the future is
uncertain and there are many known and unknown things that cannot be incorporated in the
project plan.

A software risk can be of two types

(1) Internal risks that are within the control of the project manager and

(2) External risks that are beyond the control of project manager.

A project manager has to deal with risks arising from three possible cases:

1. Known knowns are software risks that are actually facts known to the team as well as to
the entire project.

For example not having enough number of developers can delay the project
delivery. Such risks are described and included in the Project Management Plan.

2. Known unknowns are risks that the project team is aware of but it is unknown that such
risk exists in the project or not.

For example if the communication with the client is not of good level then it is not
possible to capture the requirement properly. This is a fact known to the project team
however whether the client has communicated all the information properly or not is
unknown to the project.

3. Unknown Unknowns are those kind of risks about which the organization has no idea.
Such risks are generally related to technology such as working with technologies or tools
that you have no idea about because your client wants you to work that way suddenly
exposes you to absolutely unknown unknown risks.

15 B Naresh, Lecturer in Computer Science, BVRICE

Risk Management comprises of following processes:

1. Software Risk Identification

2. Software Risk Analysis

3. Software Risk Planning

4. Software Risk Monitoring

These Processes are defined below.

Software Risk Identification

In this phase of Risk management you have to define processes that are important for risk
identification. All the details of the risk such as unique Id, date on which it was identified,
description and so on should be clearly mentioned.

Software Risk Analysis

Software Risk analysis is a very important aspect of risk management. In this phase the
risk is identified and then categorized.

After the categorization of risk, the level, likelihood (percentage) and impact of the risk is
analyzed.

Likelihood is defined in percentage after examining what are the chances of risk to occur
due to various technical conditions. These technical conditions can be:

1. Complexity of the technology

2. Technical knowledge possessed by the testing team

3. Conflicts within the team

4. Teams being distributed over a large geographical area

5. Usage of poor quality testing tools

With impact we mean the consequence of a risk in case it happens. It is important to

know about the impact because it is necessary to know how a business can get affected:

1. What will be the loss to the customer

2. How would the business suffer

3. Loss of reputation or harm to society

4. Monetary losses

16 B Naresh, Lecturer in Computer Science, BVRICE

 5. Legal actions against the company

6. Cancellation of business license

Level of risk is identified with the help of:

Qualitative Risk Analysis: Here you define risk as:

• High

• Low

• Medium

Quantitative Risk Analysis: can be used for software risk analysis but is considered
inappropriate because risk level is defined in % which does not give a very clear picture.

Software Risk Planning

Software risk planning is all about:

1. Defining preventive measure that would lower down the likelihood or probability of
various risks.

2. Define measures that would reduce the impact in case a risk happens.

3. Constant monitoring of processes to identify risks as early as possible.

Software Risk Monitoring

Software risk monitoring is integrated into project activities and regular checks are conducted
on top risks. Software risk monitoring comprises of:

• Tracking of risk plans for any major changes in actual plan, attribute, etc.

• Preparation of status reports for project management.

• Review risks and risks whose impact or likelihood has reached the lowest possible level
should be closed.

• Regularly search for new risks

17 B Naresh, Lecturer in Computer Science, BVRICE