Fundamentals of Software Project

Management

INTRODUCTION
Software project management is the process of planning,
organising, staffing , monitoring, controlling and leading a
software project.
Every software project must have a manager who leads the
development team and is the interface with the initiators (synonym :
one who start the project), suppliers and senior management. The
project manager :
Produces the software project management plan (SPMP).
Defines the organisational roles and allocates staff to them.
Controls the project by informing staff of their part in the
plan .
Leads the project by making the major decisions and by
motivating staff to perform well ;
Monitors the project by measuring progress.
Reports progress to initiates and senior managers.

INTRODUCTION (Contd.)
Figure 1 shows the control and monitoring loop required in every
software project.
Standards and user requirements are the primary input to both the
planning and production processes.
Plans are made for project management, configuration management,
verification and validation and quality assurance.
These plans control production. Reports, such as progress reports,
timesheets, work package completion reports, quality assurance reports
and test reports provide feedback to the planning process. Plans may
be updated to take account of these reports.
The project manager is the driving force in the management control
loop. The following sections defines the skills, roles and responsibilities
of the project manager and discuss project management activities.

The Skills of a Project Manager

The evolution of development projects has changed the skills

required of project managers.
Not long ago the emphasis was placed on technical skills and
project managers were hired by the experience and proficiency in
the technical area the project was involved in.
In the last years the nature of development projects has changed
considerably, projects are not just one-dimensional approaches
focused on a single solution.
So, different types of skills are required by Project Manager:
Managerial Skills
Technical
Problem Solving
Negotiation
Conceptual
Interpersonal Skills
Leadership
Communication
Behavioral

Managerial Skills
Project teams involve more and more non-technical staff, and
behavioral skills became equally important as technical skills.
In this new time, to be an effective project manager, may require
having an understanding of general management rather than being a
technical expert.
Projects are becoming more complex that it is simply no longer
possible for the project manager to remain a technical expert in all
aspects of the project.
Project managers need to spend more of their time planning,
organizing, directing and controlling progress rather than providing
technical direction.
Project management is both a science and an art; it's a science
because it requires the use of quantitative analysis such as charts,
graphs, financial data ; and an art because it deals with qualitative
analysis such as negotiating , conflict resolution, political,
interpersonal and organizational factors.

Managerial Skills : Technical

Skills
The project manager must have skills to use management techniques,

procedures and tools.

He/She must know how to interpret a budget report, know how to read a
statistical analysis of a project baseline data, and understand the
correct application of the different management methodologies.
In addition to the above the project manager is expected to have skills in the
effective use of information and communication technology to help his/her
be more effective in work.
Technical skills are related to working with processes and tools.
They refer to using specialized knowledge and experience related to project
management and the specific methodologies of the project for implementing
project activities.
These skills are necessary to communicate effectively with the project team ,
to assess risks, and to make trade-offs between cost, schedule, time and
quality issues.

Managerial Skills:Technical Skills

(Contd.)
Since project managers do not do the actual work of the project, they do not
need the same technical skill level as the people performing the work.
This is not to say that the project manager doesn't need a level of
technical expertise, the more expertise the project manager has in the
technical area of the project , the greater identify potential problems and
increases the ability of the project manager to integrate all aspects of the
project.
The project manager must maintain a general perspective and not let
his/her technical competence lead to micro-managing or do the project
work.
He / She must concentrate on managing the project, letting the project team
members perform the technical work and limit his/her technical involvement
to
evaluating
the
work
of
the
team.

Managerial Skills: Problem Solving

Skills

All projects are prone to encounter problems, problems that were not identified
in the risk or scope of the project and that will need to be managed accordingly.
Problem solving requires a good definition of the problem that is detected early
enough to allow time to respond.
In many cases the original problem is a symptom or a larger problem.
Problem solving skills make use of different techniques, and by using
these techniques we can start to tackle problems which might otherwise seem
huge, overwhelming and excessively complex. down into manageable parts,
identifying root causes of problems, analyzing strengths, weaknesses,
opportunities & threats, must be mastered in order to solve problems.
Additionally the project manager needs synthesis and analysis thinking skills.
A project manager must be able to synthesize information-collecting and arrange
disparate information into a meaningful whole.
A project manager must be able to see patterns in information and derive
meaning from distinct pieces of data.
Analysis is the skill of breaking a whole into component parts, much like
decomposing work into a WBS.

Managerial Skills: Negotiation Skills

Project managers spend a large portion of their time negotiating for

resources, equipment or other support, and if they do not have strong
negotiating skills, their chances of being successful project managers are
greatly reduced.
A large part of negotiation takes place within the organization to get the
resources the project needs, resources that are being requested by other
project managers.
Negotiation is the process of obtaining mutually acceptable agreements
with individuals or groups.
Depending on the projects structure and the level of authorization the
project managers has to negotiate on behalf of the organization.
Negotiation usually include making trade-offs when stakeholders request
changes or modifications to the project and its resources, negotiation also
includes dealing with vendors or consultants who are bidding for a specific
good or service, this area may require the assistance of specialized staff such as
representatives from legal or the procurement department.

Managerial Skills: Negotiation Skills

(Contd.)
Negotiation skills also come handy when
dealing with project beneficiaries and building
agreements that will benefit both the project
and the beneficiaries.
Beneficiaries have in many instances other
priorities and participating in
the project
activities may not be a main priority.
The project manager must be able to find the
best
approach
to
develop
common
understanding and align the interest of the
beneficiaries with those of the project.

Managerial Skills:
Conceptual Conceptual
skills is the ability to coordinate
and integrate all
Skills
the projects efforts, it requires for the project manager to see
the project as a whole and not just the sum of its parts, ability
to understand how all the parts make a whole and how they all
relate and depend on one another, and the ability to anticipate
how a change on one part of the project will affect the entire
project.
The bigger and more complex is the project, the larger is the
need for this type of skill.
This skill helps the project manager keep a clear vision of the
ultimate goal of the project and understand its relationships
and dependencies with the project's environment.
Conceptual skills refer to the ability to see the big picture.
Project managers with good conceptual skills are well aware
of how various elements of the project environment or
ecosystem interrelate and influence one another.
Conceptual skills are necessary to appropriately deal with
project politics and to acquire adequate support from top

Interpersonal Skills
It is better that the project manager be a generalist rather
than an expert.
The reason is that experts tend to be very narrow in their
views.
A generalist on the other hand, is far more open to views
and suggestions of this team members.
The results of projects led by a generalist tend to give
much better deliverables than a comparable project led by
an expert.
Every organization has a unique culture and individual
divisions within an organization often have their own
personalities.
Understanding of these culture is very important.

Interpersonal Skills

Interpersonal skills require understanding people, their attitudes, and

human dynamics.
They represent the ability of a project manager to work effectively as a
project team leader and to build cooperative effort with the project
members and all other groups with which the project team interacts.
They are most critical for and how effective performance in a project
environment.
Major interpersonal skills include : communication, team building,
leadersh ip, coaching, motivating, decision making, delegating, training,
directing, influencing, negotiating, and supporti ng
The project manager must be sensible to the cultural differences when
dealing with diverse people and their opinions, values, and attitudes.
The good interpersonal abilities build trust and confidence between
members of the project team and help create good relations and good
working environment. The important interpersonal abilities required to
handle projects are leadership, communication, behavior and negotiation.

Interpersonal Skills: Leadership

Skills
Leadership skills are essential for project managers
because project managers must influence the
behavior of others.
Project managers require leadership skills for the
simple reason that they accomplish their work
through people who have faces and names.
Leadership is the predominant contributor to the
success of the project manager.
In small projects, good leadership can succeed even
in a climate of otherwise unskilled management.
This skill gives the project manager the ability to
articulate a clear vision and provide direction.

Interpersonal Skills: Communication

Skills

Good communications skills include verbal and non verbal

communications that enables a project manager to convey
project
information in a way that it is received and
understood by al project stakeholders.
The first essential skill is the ability to communicate.
This skill is important in any endeavor but is absolutely
crucial in project management.
It has been estimated that project managers spend 90 percent
of their time just communicating: with the project team, the
customer,
functional managers, and upper management.
Communication is only successful when both the sender and
the receiver understand the same information as a result of
the communication.
By successfully getting our message across, we convey our
thoughts and ideas effectively.
When not successful, the thoughts and ideas that our send
do not necessarily reflect our own, causing a communications

Interpersonal Skills: Behavioral

Skills
Behavioral skills are the skills that give the project manager the ability to
work with people, and the ability to motivate people involved in the
project.
Behavioral skills are also known as people skills and these skills are needed
in development projects due to the large and varied number of people the
project interfaces with.
Behavioral or people skills, it's the ability to build cooperation between
the project team, other project stakeholder, and the
project
organization.
These skills involve communication, team building, leadership,
influencing, under standing perceptions and attitudes, which help improve
the morale of individuals and groups.
An element of communication skill is having good listening skills that
make a project manager an active listener which makes the communication
skills more effective.

The Roles of a Project Manager

One of the mistakes development organizations make is
appointing project manager only for he depth of his/her
technical skills.
Project Manager must have a good understanding of the
technical aspects of the project, the principal areas of
competence that are required from every project managers
are in the management competence areas and these
include communicating, planning, negotiating, coaching.
He/ She is the one whose job is to make sure the project
gets done, and is the principal contact person for the
donor, beneficiaries and the key stakeholders.
As responsible for the project he/she needs to make key
decisions regarding the management of the resources
available to the project; in order to do that, the
organization's senior management needs to appoint the
project manager and give the sole responsibility and

The Roles of a Project Manager

: Integrator

A key responsibility of the project manager is to ensure the

proper integration of the project management processes
and coordinate the process phases trough the project
management cycle, to ensures that all areas of the project
come together to deliver the project to a successful
conclusion.
This is the main role of the project manager The role of
integrator involves three specific areas of responsibility :
Developing the project management plans, which
involves the development of all project planning
documents into a consistent, coherent project plan
document
Implementing the project plan, which involves the
execution of the project plan and ensuring all activities
are performed by all the people involved
Monitor and control the plan, which involves measuring

The Roles of a Project Manager

: Communicator

Communication is providing relevant, timely information to the right people

about the project.
Communication is used to inform and educate the project stakeholders about
the project objectives, risks, assumptions and constraints .
The communication or informational role is the most critical role for the
success of the project, the organization functional managers, project staff,
donors and key stakeholders need to make critical decision about the project,
and the information they receive must be relevant, on time and accurate.
Project managers in the role of communicators take three functions:
to gather information from project staff and other people involved with the
project;
distribute the information to stakeholders, which includes the donor,
beneficiaries , and the organizations functional managers;
transmit the information to the external environment, such as the general
public to gain support to the project.

The Roles of a Project Manager

: Leader

A project manager is above all a leader ; the team needs

direction for the life of the project and the project manager is
responsible for leading the team to achieve the vision that the
project has created, a project manager does this by facilitating,
coordinating and motivating the team to achieve the project
goals, this is a central role of the project manager and her
ability to influence, inspire, direct, communicate will determine
her effectiveness as a project manager.
Leading is a central role ; it involves working with and through
others to achieve the objectives of the project.
It is through the project manager's ability to lead - which
includes the ability to facilitate, coordinate, and motivate - that
will determine the effectiveness of the project manager.
The focus on this role is to ensure the project team and the
project stakeholders have a clear vision of the objectives the
project aims to achieve.

The Roles of a Project Manager

: Facilitator

In this role the project manager acts an individual who enables

the project team to work more effectively ; helps them
collaborate and achieve synergy.
The project manager is not responsible to do all the tasks of
the project, that is the responsibility of the project team, the
project manager role is to create the right conditions that
enable the project team to carry their duties.
The project manager also contributes by providing the
framework to facilitate the interactions among the different
groups so that they are able to function effectively.
The project manager encourages full participation from the
project
team . promotes mutual understanding with the
beneficiaries and cultivates shared responsibility among all
project stakeholders.
The facilitator role is mostly used when dealing with
beneficiaries , since the project manager doesn't have any

The Responsibilities of Project

Manager
Responsibility is an agreement between two or more
people for the intention of achieving a desired result.
The project manager must be sure that the assigned
responsibility is clearly stated and the expected results
are mutually understood and accepted by all stakeholders.
Accountability comes as a result of the assigned
responsibility.
When an organization assigns responsibility to a person to
manage a project, the organization must hold that person
accountable for achieving the desired result or provide
consequences for poor performance, such as a negative
employee performance rating, reassignment, probation,
or termination.
The accountability must be consistent with the
responsibility assigned.

The Responsibilities of Project

Manager (Contd.)
Projects vary in duration, scope, and complexity.
On a large or complex project, the Project
Manager may elect to appoint one or more
Assistant Project Managers.
The Project Manager may delegate single or
multiple responsibilities , including budget
responsibility to an Assistant Project Manager.
The Project Manager may direct the Assistant
Project Manager to control different processes of
the project; this may include controlling budgets,
and monitoring progress.

The Responsibilities of Project

Manager (Contd.)
The project manager is responsible
for three areas of the project:
responsibility to the donor to provide
timely and accurate information
responsibility to beneficiaries for
delivering the project outcomes
responsibility to organization for
managing the project and follow policies
and uphold its values .

The Responsibilities of Project

Manager (Contd.)
In general terms the project manager
responsibilities in the project are:
planning
organizing
directing
controlling the project.

The Responsibilities of Project

Manager (Contd.): Planning
Planning responsibility involves defining what the
project will accomplish, when it will be completed, how
it will be implemented and monitored and who will do
it.
The project manager is responsible for creating the
project plans and defining the ,goals, objectives,
activities and resources needed.
The project plans are the blueprints under which
the entire project will be implemented and will
serve as a map to guide the project
team,
beneficiaries, donors and management.
The project manager is also responsible for updating
the plans as new changes or modifications are
approved, he/she is responsible for communicating all

The Responsibilities of Project

Manager (Contd.):Organizing
The responsibility of the project manager is to
establish a structure that will maximize the efficiency
(doing the things right) and effectiveness (doing the
right things) of the project.
The project manager, once the plans have been
approved and distributed, has the responsibility to
build and staff the project organization that will be
capable to carry out the plans.
The focus is on coordination, and control of activities
and the flow of information within the project.
In this responsibility the project manager distributes
and delegates authority to project staff.
The project manager must have the ability to
determine the type of project organization that will fit

The Responsibilities of Project

Manager (Contd.):Directing
Once the plans are made and the
organization has , been determined and the
project staffed, the responsibility of the
project manager is to direct, lead and
motivate the members
of the project to
perform in a unified, consistent and manner.
By directing, the project manager assumes
the responsibility that the project team will
follow his/her vision of the project and all
instructions, mandates and work orders.

The Responsibilities of Project

Manager (Contd.): Controlling
Controlling is a responsibility to ensure the
actions of the project team contribute toward
the project goals;
the project manager must establish standards
for performance,
measure performance and compare it with the
established standards;
detect variations from the standards and make
the necessary corrections.

This responsibility
project is on track.

ensures

that the

PROJECT INTERFACES

Project managers must identify the people or groups the project

deals with , both within the parent organization and outside. A
project may have interfaces to :
initiators
end users
suppliers
subcontractors
the prime contractor
other subsystem developers
When defining external project interfaces, the project manager
should :
ensure that a single, named point of contact exists both
within the project team and each external group ;
channel all communications between the project and
external groups through as few people as possible ;
ensure that no person in the project has the liaise (to form)
with more than seven external groups

Project Interfaces
Stakeholder analysis
Stakeholders can be individuals, groups, a community or
an institution.
Stakeholders are:
people affected by the impact of an activity
people who can influence the impact of an activity.
Stakeholder groups are made up of people who share a
common interest, such as an NGO, church leaders and the
community.
However, such groups often contain many sub-groups.
Seeing the community as one stakeholder group can be
meaning less because some people may have very
different interests from others in the same community.
These sub-groups may be affected by the project in
different ways, and some subsgroups may have a lot more
influence on the impact of the project than others.

Project Interfaces
Stakeholder analysis (Contd.)
government ministries are different stakeholder
groups, if they have different, and even conflicting,
opinions about a development proposal.
Government at national, state and local levels may
also have very different interests.
Stakeholders include :
User Groups people who use the resources or
services in an area
Interest Groups people who have an interest in,
an opinion about, or who can affect the use of,
a resource or service
Beneficiaries of the project
Decision Makers
Those Often Excluded from the decision-making

Project Interfaces
Stakeholder analysis (Contd.)

Stakeholders can be divided into two main types :

Primary Stakeholders who benefit from, or are adversely
affected by , an activity.
This term describes people whose well-being may
be dependent on a resource or service or area (e.g., a
forest) that the project addresses .
Usually they live in the area or very near the resources.
They often have few options when faced with change, so
they have difficulty adapting.
Primary stakeholders are usually accessible.
They are the reason why a project is carried out - the
end users.

Project Interfaces
Stakeholder analysis (Contd.)

Secondary Stakeholders include all other people and

institutions with an interest in the resources or area being
considered .
They are the means by which project objectives can be
met, rather than an end in themselves.
If stakeholders are not identified at the project
planning stage, the project is at risk of failure.
This is because the project cannot take into account
the needs and aims of those who will come into
contact with it.

Project Interfaces
Stakeholder analysis: Advantages (Contd.)

Stakeholder analysis is a useful tool for identifying

stakeholders and describing the nature of their stake, roles and
interests. Stakeholder analysis helps to :
improve the project's understanding of the needs of those
affected by a problem
reveal how little we know as outsiders, which encourages
those who do know to participate
identify potential winners and losers as a result of the
project
reduce, or hopefully remove, potential negative project
impacts
identify those who have the rights, interests, resources,
skills and abilities
to take part in, or influence the course of, the project
identify who should be encouraged to take part .in the
project planning and implementation

Project Interfaces
Stakeholder analysis: Risks (Contd.)
It is important to be aware that there
are risks in doing a stakeholder
analysis :
The analysis is only as good as the
information used. Sometimes it is
difficult
to
get
the
necessary
information, and many assumptions will
have to be made.
Tables
can
oversimplify
complex
situations .

Project Interfaces
Stakeholder analysis: Methods (Contd.)
There are a number of ways of doing stakeholder analysis. The
method provided below is just one approach.
The approach taken will vary depending on the type of project that
is being proposed.
The method given below is quite general and can be adapted to
whatever type of project is being proposed
Ideally, stakeholder analysis should be carried out with
representatives of as many stakeholder groups as possible.
It might not always be practical to do so if the stakeholders are
widely spread.
However, if there is a danger that important stakeholders might be
excluded, more time and resources should be invested in doing the
stakeholder analysis to make sure they are included.

NEEDS IDENTIFICATION

Accurate requirements are an essential part of the formula for

software project success.
According to survey projects are cancelled due to following major
reasons
Some software projects are canceled before they are
completed
Many projects runs out of cost than original estimate
Small number of projects are completed on time and within
budget.
When the causes of these failures were identified, the survey
found the following top three reasons why projects are damaged.
Lack of user input
Incomplete requirements and specifications
Changing requirements and specifications
This basic problem is poor requirement share.
If it isn't clear what we are supposed to build, how can we
estimate the cost of building it ?
How can we create a project, plan , assign resources, design
system components, or create work orders ?

NEEDS IDENTIFICATION: Need of

Requirements

We use requirements for a variety of purposes, including :

Project scoping
Cost estimating
Budgeting
Project scheduling
Software design
Software testing
Documentation and training manual
Individuals throughout an organization have a fixed interest in
producing solid requirements.
Many project teams treat requirements as a statement of
purpose for the application and express them in very general
terms, such as : "The system should have the ability to create
problem labels for outside warning." But is this a solid
requirement ?

NEEDS IDENTIFICATION: Classifying and

Documenting Requirements

Requirements are not requirements unless they are written

down.
In other words, neither hallway conversations nor "mental
notes" constitute requirements.
We typically capture requirements in three separate documents
:
Stakeholder Needs
Software Features
Software Requirements Specification
Generally, in any organization, we associate some attributes
(e.g., priority, status etc.) with each requirement to help with
decision making, scheduling, and so on.
The information contained in one requirement document should
be referenceable in the others. For example, the information
recorded in the software features document should support and
be traceable to one or more items listed in the stakeholder
needs document.

NEEDS IDENTIFICATION:Classifying and Documenting

Requirements : Documenting Stakeholder Needs

Whatever needs and requirements we formulate

at the beginning of our project, it expand as our
project gain.
If we are using an iterative development
approach, we should compute our requirements
after each iteration, and if we make changes
one document, we should update the others as
well to maintain consistency.
Stakeholder needs, which are part of the
problem domain, describe what stakeholders
require for successful project.

NEEDS IDENTIFICATION:Classifying and Documenting

Requirements : Documenting Stakeholder Needs

Needs describe what the application should do to help in

lower the cost of a business process , increase revenue or
meet regulatory or other obligations .
Documenting stakeholder needs involves identifying,
understanding and representing different viewpoints.
The first step is to identify all stakeholders.
Users represent a class of stakeholders , but by no
means do they represent the interests of the whole
organization.
Other classes of stakeholders may come from finance
and accounting, procurement, and IT, as well as from
other departments or organizations that directly or
indirectly support or benefit from the project .
We can draw needs from stakeholders using various
techniques , including one-on-on meetings,

NEEDS IDENTIFICATION:Classifying and Documenting

Requirements: Documenting Software Features

After we have defined stakeholder needs, we must translate

them into a set of distinct system features.
There is difference between needs and features : Needs do
not indicate a particular solution ; they simply describe the
business need.
For example, if a stakeholder says, "We need to stream line
the help-desk application support process because we can't
keep up with the calls", that person is expressing a need that
the development team can translate into a feature .
However , if the stakeholder says, "We need a Web -enabled
system so that customers can enter their own support
requests", the stakeholder has already translated the need
into a feature.

NEEDS IDENTIFICATION:Classifying and Documenting

Requirements: Documenting Software Features
(Contd.)
A feature is a service that the system provides to
fulfill one or more stakeholder needs.
It is important for the development team to
understand the distinction between needs and
features and to record them in separate documents .
We should separate needs from features ; the reason
behind it is that needs are part of the problem
domain, and features are part of the solution domain.
Also, by separating needs from features, we can find a
common set of features that will meet multiple
needs .

NEEDS IDENTIFICATION:Classifying
and Documenting Requirements:
Documenting Software
Requirements
After we analyze
and generalize needs and features,
we should move into the solution domain by
analyzing and capturing the system requirements.
Now we have enough understanding to define a
requirement as : a software capability that must be
met or possessed by a system or a system component
to satisfy a contract, standard, or desired feature.
Requirements must satisfy one or more of the
following criteria
Contract obligations

Standards
Desired needs and features

NEEDS IDENTIFICATION:Classifying
and Documenting Requirements:
Documenting Software
(Contd.)
We canRequirements
classify the requirements
into two
categories :
Functional requirements
present a complete description of how the
system will function from the user's
perspective. They should allow both business
stakeholders and technical people to walk
through the system and see every aspect of
how it should work - before it is built.
Non -functional requirements
dictate properties and impose constraints on
the project or system. They specify attributes
of the system , rather than what the system

Qualities of SRSD

Following are some qualities that should characterize the

descriptions
in
our Software Requirements Specification
Document :
Lack of ambiguity. The software development team will
be unable to produce a product that satisfies users' needs
if one or more requirements can be interpreted in
multiple ways.
Completeness. In the beginning of our project, we should
not expect to know all the system requirements in detail;
the development team should not waste time trying to
specify things that are bound to evolve . As the project
proceeds , however, we should keep our Software
Requirements Specification document up to date ; as we
gain more knowledge about the system , the specification
document should grow more complete .
Consistency. We cannot build a system that satisfies all
requirements if two requirements conflict or if the
requirements do not reflect changes that were made to

Qualities of SRSD (Contd.)

Traceability. The team should track the source of each

requirement whether it evolved from a more abstract
requirement , or a specific meeting with a target user .
No design information. As long as requirements address
external behaviors, as viewed by users or by other
interfacing systems, then they are still requirements,
regardless of their level of detail. However, if a requirement
attempts to specify particular subcomponents or
their algorithms, it is no longer a requirement; it
has become design information .

Capturing functional
requirements
To document functional
requirements we must capture
three categories of information :
Use cases
Functional capabilities
Business rules
Use cases define a step-by-step sequence of actions
between the user system.
Organizations are rapidly adopting use cases as a means to
communicate requirements because they.
Show how the system will work from the users' perspective
Force us to think about the end-job : What is the user trying
to accomplish by using the system ?
Require us to define how the system should work, step-bystep.
Provide an excellent basis for building test cases and helping
to ensure that these are built before the code is written.
Provide a common requirements "language" that's easy
for stakeholders, users, analysts, architects, programmers,

Capturing functional requirements

(Contd.)
when we communicate via uses cases, we don't
leave it up to the developers to determine the
application's external behavior.
These include a use case diagram, primary and
assisting actors, triggering
events, use case
descriptions,
preconditions,
post conditions,
alternative flows, error and exception conditions,
risks
and issues, functional capabilities, and
business rules.
It should be noted that use cases do not result in
requirements until we define functional capabilities
and any business rules that apply to the use case.

Capturing functional requirements

(Contd.)
Functional capabilities define what
specific action the system should
take in a given situation.
We can relate functional capabilities
directly to a specific use case or define
them globally for the entire system.
Business rules state the condition
under which a use case is applicable
and the rule to be applied.

Capturing non-functional requirements

Non-functional requirements are attributes that either
the system or the environment must have.
Such requirements are not always in the front of
stakeholders' minds , and often we must make a special
effort to draw them out.
To make it easier to capture non-functional
requirements, we organize them into five
categories :
Usability
Reliability
Performance
Supportability
Security

Capturing non-functional
requirements (Contd.)
Usability describes the ease with which
the system can be learned or used. A
typical usability requirement might
state :
The system should allow novice users to
install and operate it with little or no training.
The end user shall be able to place an order
within thirty seconds .
The end user shall be able to access any
page within four seconds.

Capturing non-functional
requirements (Contd.)
Reliability describes the degree to which
the system must work for users.
Specifications for reliability typically refer
to availability, mean time between failures,
mean time to repair, accuracy, and
maximum acceptable bugs. For example :
The system shall meet the terms of a Service
Level Agreement.
The mean time to failure shall be at least four
months.

Capturing non-functional
requirements (Contd.)
Performance specifications typically
refer to response time, transaction
through put , and capacity. For
example :
All Web pages must download within three
seconds during an average load, and five
seconds during a peak load .
While executing a search, the system
must be able to display 200 search results
per page.

Capturing non-functional
requirements (Contd.)
Supportability refers to the softwares ability
to be easily modified or maintained to
accommodate typical usage or change
scenarios. Here are some examples of
supportability requirements :
The system shall allow users to create new
workflows without the need for additional
programming.
The system shall allow the system administrator
to create and populate tax tables for the
upcoming tax year.

Capturing non-functional
requirements (Contd.)

Security refers to the ability to prevent and/or forbid

access to the system by unauthorized parti Some
examples of security requirements are :
User authentication shall be via the corporate Single
Signon system .
Only authorized payroll administrators shall be
permitted to access employee pay information .

Requirements Analysis Process : Requirements

Elicitation, Analysis and Specification

Requirements Analysis is a process of understanding

customer needs and expectations from a proposed system
or application and is a well-defined stage in the Software
Development Life Cycle model.
Requirements are a description of how a system should
behave or a description of system properties or attributes.
It can
alternatively be
a statement
of 'what' an
application is expected to do.
Given the multiple levels of interaction between users,
business processes and devices in global corporations,
there are simultaneous and complex requirements from a
single application, from various levels within an
organization and outside it as well.
The Software Requirements Analysis Process covers the
complex task of eliciting and
documenting
the

Requirements Analysis Process : Requirements

Elicitation, Analysis and Specification
A dedicated and specialized Requirements Analyst is
best equipped to handle the job .
The Requirements Analysis function may also fall
under the scope of Project Manager, Program
Manager or Business Analyst , depending on the
organizational hierarchy.
Software Requirements Analysis and Documentation
Processes are critical to software project success.
Requirements Engineering is an emerging field
which deals with the systematic handling
of
requirements.

Requirements Analysis Process: Requirements

Elicitation, Analysis and Specification: Importance of
Requirements Analysis
Surveys reveal that inadequate attention to Software
Requirements Analysis at the beginning of a project is the
most common cause for critically vulnerable projects that
often do not deliver even on the basic tasks for which they
were designed .
There are instances of corporations that have spent huge
amounts on software projects where the end application
eventually does not perform the tasks it was intended for.
Software companies are now investing time and resources
into effective and streamlined Software Requirements
Analysis Processes as a prerequisite to
successful projects that align with the client's business
goals and meet the project's requirement specifications .

Requirements Analysis Process: Requirements

Elicitation, Analysis and Specification: Footfalls in the
Requirements Analysis Process

Fix system boundaries

This initial step helps in identifying how the new
application integrates with the business processes,
how it fits into the larger picture and what its
scope an limitations will be.

Identify the customer

By defining in concrete terms who the intended user is,

the Requirements Analysis knows in advance where he
has to look for answers. The Requirements Elicitation
Process should focus on the wish-list of this defined
group to arrive at a valid requirements list.

Requirements Analysis Process: Requirements Elicitation,

Analysis and Specification: Requirements elicitation

Information is gathered from the multiple

stakeholders identified.
The Requirements Analyst draws out from
each of these groups what their requirements
from the application
are and what they
expect the application to accomplish.
The level of detail of the requirements list is
based on the number and size of user groups ,
the degree of complexity of business
processes and the size of the application

Requirements Analysis Process: Requirements

Elicitation, Analysis and Specification: Requirements
elicitation

Problems faced in Requirements Elicitation.

Ambiguous understanding of processes
Inconsistency within a single process by multiple
users
Insufficient input from stakeholders
Conflicting stakeholder interests
Changes in requirements after project has begun
Tools used in Requirements Elicitation.
Prototypes
Transition process diagrams
Use cases
User Interfaces

Requirements Analysis Process: Requirements Elicitation,

Analysis and Specification: Requirements Analysis
Process

Once all stakeholder requirements have

been gathered, a structured analysis of these
can be done after modeling the
requirements.
Some of the Software Requirements Analysis
techniques used are requirements animation,
automated
reasoning,
knowledge-based
critiquing, consistency checking, analogical
and case-based reasoning .

Requirements Analysis Process: Requirements Elicitation,

Analysis and Specification: Requirements Specification
Requirements Specification. Requirements , once
elicited, modeled and analyzed should be documented in
clear, unambiguous terms.
A written requirements document is critical so that its
circulation is possible among all stakeholders
Requirements Specification is vital and serves as a:
Base for validating the stated requirements and
resolving stakeholder conflicts, if any
Contract between the client and development team
Basis for systems design for the development team
Bench-mark for project managers for planning
project development lifecycle and goals
Source for formulating test plans for QA and testing
teams
Resource for requirements management and

Requirements Analysis Process: Requirements Elicitation,

Analysis and Specification: Requirements Specification
The challenge of a well-written requirements specification
is to clearly communicate to both these groups and all
the sub-groups within. Requirements Specifications may
be documented separately as:
User Requirements wriitten in clear, precise language
with plain text and use cases, for the benefit of the
customer and end-user
System Requirements expressed as a programming or
mathematical model, addressing the Application
Development Team and QA and Testing Team.
Requirements Specification serves as a starting point for
software , hardware and database design.
It describes the function (Functional and Non-Functional
specifications) of the system, performance of the system
and the operational and user-interface constraints that

Requirements Analysis Process: Requirements Elicitation,

Analysis and Specification: Requirements Management

Requirements
Management
is
the
comprehensive process that includes all aspects
of
software
requirements
analysis
and
additionally ensures verification, validation and
traceability of requirements.
Effective requirements management practices
guarantee that all system requirements are
stated unambiguously, that omissions and errors
are corrected and that evolving specifications
can be incorporated later in the project lifecycle .

VIS ION AND SCOPE

DOCUMENT
The document that covers the business requirement is
called the vision and scope document.
This document covers the vision of the project, which
is in the long run what the project will accomplish.
The scope part of the document will clearly spell out
what would be taken up.
There are four sections to this document and each one
of them is important. These sections are :
Business Requirements
Vision of the solution
Scope and limitations
Business context.

VIS ION AND SCOPE DOCUMENT:

Benefits of Creating Vision and Scope
Document (Contd.)

Earning Credibility
By creating vision and scope document , the customer can
see that we are adding value by capturing his requirements.
He can also see a tangible product at the end of the
requirement capture exercise
Ensuring project success
It is essential for all parties concerned that the project is
completed successfully.
Preparing vision and scope document has significant
contribution in ensuring success of a project.
Ensuring project viability
Many times project fail because the client was not clear in
his mind about the project.
Putting down the requirement from the business
perspective would force the client to think about why he is
doing the project.

VIS ION AND SCOPE DOCUMENT: Sections

Under Vision and Scope Document (Contd.)

Business Requirements
Background, Business Opportunity, and Customer Needs
Business Objectives and Success Criteria
Business Risks
Vision of the Solution
Vision Statement
Major Features
Assumptions and Dependencies
Scope and Limitations
Scope of Initial and Subsequent Releases
Limitations and Exclusions
Business Context
Stakeholder Profiles
Project Priorities

PROJECT MANAGEMENT
CYCLE
The Project Management Life Cycle has four

phases: Initiation, Planning, Execution and

Closure.
Each project life cycle phase is described as
follows, along with the stasks needed to complete
it.
During Project Initiation phase, we :
Develop a Business Case
Undertake a Feasibility Study
Establish the Project Charter
Appoint the Project Team
Set up the Project Office
Perform Phase Review

PROJECT MANAGEMENT CYCLE

(Contd.)
Develop a Business Case

A Business Case justifies the start-up of a project.

It includes a description of the business problem or opportunity,
the costs and benefits of each alternative solution, and the
recommended solution for approval.
A Business Case document is used whenever the expenditure on a
project has to be justified.
Completing a Business Case document is usually the first step
in the Project Life Cycle.
Once the Business Case document has been completed, it is
presented to a Sponsor for approval.
The Business Case is referred to frequently during the project , to
determine whether it is currently on track.
At the end of the project, success is measured against the ability
to meet the objectives defined in the Business Case.

PROJECT MANAGEMENT CYCLE

(Contd.)
Undertake a Feasibility Study
A Project Feasibility Study is an exercise that involves
documenting each of the potential solutions to a particular
business problem or opportunity.
Feasibility Studies can be undertaken by any type of
business, project or team and they are a critical part of the
Project Life Cycle.
The purpose of a Feasibility Study is to identify the likelihood
of one or more solutions meeting the stated business
requirements.
During the Feasibility Study, a variety of 'assessment:
methods are undertaken.
The outcome of the Feasibility Study is a confirmed solution
for implementation.

PROJECT MANAGEMENT CYCLE

(Contd.)

Establish the Project Charter

The Project Charter describes the project
vision,
objectives, scope and deliverables, as well as the
Stakeholders, roles and responsibilities.
The Project Charter is also known as a "Terms of
Reference" or "Project Definition Report" .
Every time we start a new project, we should complete a
Project Charter document.
The Project Charter defines the vision and boundaries for
the project, as well as the high level roadmap.
In addition, the Project Charter also defines the scope of
the project, within which the deliverables are produced.
With a well defined Project Charter, the Project Manager
has a clear project roadmap for success.

PROJECT MANAGEMENT CYCLE

(Contd.)
Appoint the Project Team
A Project Job Description defines the objectives and
responsibilities of a particular role on a project.
Completing a Job Description document ensures the
skills, experience and qualifications needed to fulfill the
role are clearly defined.
A Job Description may also be referred to as a "Position
Description".
A Project Job Description should be completed every
time a new role is identified.
The Project Job Description should clearly state the
objectives and responsibilities of the role and where it
fits within the organizational structure.

PROJECT MANAGEMENT CYCLE

(Contd.)
Set up the Project Office
The Project Office document lists everything
we need to do, to set up a Project
Management Office.
A Project Management Office is the physical
premises within which project staff (e.g. the
Project Manage r and support staff) reside.
The Project Office also contains the
communications infrastructure and
technologies required to support the project.

PROJECT MANAGEMENT CYCLE

(Contd.)

Perform Phase Review

A Project Review is an assessment of the status of a
project, at a particular point in time.
The first time in the project life cycle that a project review
is undertaken is at the end of the first project phase, called
"Initiation".
During this project review, a decision is made as to
whether or not the team has met the objectives and is
approved to proceed to the next project phase, being
the "Planning" phase.
Performing a project management review at the end of
each phase is critical to the success of the project, because
it allows the Project Sponsor to control the progress of the
project and make sure that it passes through each Project
Phase smoothly.
As soon as the project team believes they have completed
a particular project phase, a prcject review should be

PROJECT MANAGEMENT CYCLE

(Contd.)

During Project Planning phase, we :

Create a Project Plan
Create a Resource Plan
Create a Financial Plan
Create a Quality Plan
Create a Risk Plan
Create an Acceptance Plan
Create a Communications Plan
Create a Procurement Plan
Contract the Suppliers
Define the Tender Process
Issue a Statement of Work
Issue a Request for Information
Issue a Request for Proposal
Create Supplier Contract
Perform Phase Review

PROJECT MANAGEMENT CYCLE:

Planning (Contd.)
Create a Project Plan
A Project Plan sets out the phases , activities and tasks needed to deliver a
project .
The time frames required to deliver the project, along with the resources
and milestones are also mentioned in the Project Plan.
Using this Project Plan Document, we can quickly and easily create a
comprehensive Project Management Plan for our project, as it already lists
the commonly used tasks needed to complete projects from start to
finish.
A Project Plan Document is filled in every time we wish to embark on a new
project .
A summarized Project Plan is usually created early in the life cycle, with a
detailed Project Plan being created later the planning phase.
Every day, the Project Manager will review actual progress against that
stated in the Project Plan, to ensure they are still on track .
The Project Plan is therefore the most critical tool a Manager can have to
successfully deliver projects.

PROJECT MANAGEMENT CYCLE:

Planning(Contd.)
Create a Resource Plan
A Resource Plan summarizes the level of resources
needed to complete a project .
A properly documented Resource Plan will
specify
the
exact
quantities
of
labor ,
equipment and materials needed to complete our
project.
The Resource Planning document also helps us gain
approval from our Sponsor, ensuring their buy in.
Anyone
responsible
for Project Resource
Management
will
need
to
create
a
comprehensive Resource Plan , to ensure that all of
the resources needed to complete the project are
identified.

PROJECT MANAGEMENT CYCLE:

Planning (Contd.)

Create a Financial Plan

A Financial Plan identifies the Project Finance (i.e., money)
needed to meet specific objectives.
The Financial Plan defines all of the various types of
expenses that a project will incur (labor, equipment,
materials and
administration
costs) along with an
estimation of the value of each expense.
The Financial Plan also summarizes the total expense to be
incurred across the project and this total expense becomes
the project budget.
As part of the Financial Planning exercise , a schedule is
provided which states the amount of money needed
during each stage of the project.
Whenever we need to ask for money, we need a sound
Financial Plan showing how it will be consumed.
Using this Financial Plan document, we can create a
detailed Financial Plan for our project.

PROJECT MANAGEMENT CYCLE:

Planning (Contd.)

Create a Quality Plan

A Quality Plan helps us schedule all of the tasks needed
to make sure that our project meets the needs of our
customer.
It comprises two parts : the Quality Assurance Plan
lists the independent reviews needed and the Quality
Control
Plan
lists the internal reviews needed to meet our quality
targets.
By using
Quality Assurance and Quality Control
techniques, we can create a comprehensive Quality
Management Plan for our project.
Creating a Quality Plan is essential if we want to provide
the customer with confidence that we will produce a
solution that meets their needs.
The Quality Plan states everything we're going to do, to

PROJECT MANAGEMENT CYCLE:

Planning (Contd.)

Create a Risk Plan

A Risk plan helps us to foresee risks, identify action to
prevent them from occurring and reduce their impact
should they eventuate.
The Risk Management Plan is created as part of the Risk
Planning process.
It lists of all foreseeable risks, their ranking and priority, the
preventative and contingent actions, along with a process
for tracking them.
This Risk Plan document will help us perform these steps
quickly and easily.
A Risk Plan should be used anytime that risks need to be
carefully managed. For instance, during the start up of a
project a Risk Plan is created to identify and manage the
risk involved with the project delivery.
The Risk Plan is referred to frequently throughout the
project, to ensure that all risks are mitigated as quickly as

PROJECT MANAGEMENT CYCLE:

Planning (Contd.)
Create an Acceptance Plan
An Acceptance Plan (also known as an "Acceptance
Test Plan") is a schedule of tasks that are required to
gain the customers acceptance that what we .have
produced is satisfactory.
It is more than just a task list though.
An Acceptance Plan is in fact an agreement
between us and the customer, stating the
acceptance tasks that will be undertaken at the end
of the project to get their final approval.
The Acceptance Plan includes a list of the
deliverables, the acceptance test activities, the
criteria and standards to be met, and the plan for
their completion.

PROJECT MANAGEMENT CYCLE:

Planning (Contd.)

Create a Communications Plan

A Communication Plan (or Communications Plan) describes
how we intend to communicate the right messages to the
right people at the right time.
Within a Communication Plan, the communication goals,
stakeholders and strategies, activities and timeframes are
described.
A Communication Plan helps us keep everyone informed so
that we can communicate a consistent message to our
target audience.
Whenever we have a variety of staff, external
suppliers, customers and stakeholders to communicate
with, then we should record our communications
formally in a Communication Plan.
It is also critical to the success of projects, as it ensures that
all of the staff and stakeholders are kept properly informed
of the progress of
a project.

PROJECT MANAGEMENT CYCLE:

Planning (Contd.)

Create a Procurement Plan

A Procurement Plan defines the products and services that
we will obtain from external suppliers.
A good Procurement Plan will go one step further by
describing the process we will go through to appoint those
suppliers contractually.
Whether we are embarking on a project procurement or
organizational procurement planning exercise, the steps
will be the same.
First, define the items we need to procure.
Next, define the process for acquiring those items . And
finally, schedule the timeframes for delivery.
It is advisable to create a Procurement Plan whenever we
want to purchase item from suppliers.
Using the Procurement Plan document, we can define
the procurement requirements, identify potential suppliers,
contract those suppliers and manage them to ensure

PROJECT MANAGEMENT CYCLE:

Planning (Contd.)
Contract the Suppliers
A Tender Form is issued to a supplier during the
"Invitation to Tender" process.
Each Tender Form helps the team to collect
information about potential suppliers so that
they can appoint one or more preferred suppliers
to the business.
As each Tender Form is released to the suppliers,
the progress is tracked in the Tender Register.
To save time creating each Tender Form, a
Tender Document is used .

PROJECT MANAGEMENT CYCLE:

Planning (Contd.)
Define the Tender Process.
A Tender Process (or "Invitation to Tender" process)
is a method by which suppliers are selected for the
provision of products and services to an
organization.
The process involves creating a suite of Tender
Documents to manage the supplier selection
process.
The Tender Documents help the organization to
select the best possible supplier available, and
include documents such as the "Statement of
Work", "Request for Information" and "Request for
Proposal".

PROJECT MANAGEMENT CYCLE:

Planning (Contd.)
Issue a Statement of Work.
A Statement of Work or SOW, defines 'what it is that we
need' from an external supplier.
It is a statement of the work to be completed by a
supplier.
The Statement of Work also describes the materials and
equipment to be provided, within a defined timeframe.
This Statement of Work Document saves our time,
because all of the sections have been pre-completed for
us.
Every time we need to request work from an external
supplier, we need to issue a Statement of Work.
It helps us clarify what it is that we want from our supplier
and the timeframes in which to complete it.

PROJECT MANAGEMENT CYCLE:

Planning (Contd.)
Issue a Request for Information.
A Request for Information (or "RFI") is a document
which is issued to potential suppliers to allow them to
take part in an "Invitation to Tender" process.
It is a request for information from the supplier, to help
us decide whether or not to appoint them.
By using this Request for Information document , we can
complete the RFI process quickly and easily.
We need to issue a Request for Information whenever we
want to contract an external supplier to our business.
The document will explain to our supplier, the
information we need, to help us with our supplier
selection.

PROJECT MANAGEMENT CYCLE:

Planning (Contd.)
Issue a Request for Proposal.
A Request for Proposal (RFP) is a document that is
issued to suppliers to help them provide the
information needed to make a preferred supplier
decision.
By using this RFP Document, we can quickly create a
Request for Proposal for our business .
We need to create a Request for Proposal whenever we
want to request a proposal from external suppliers.
The Request for Proposal describes the nature of the
proposal we're seeking from them and the time frames
for delivering it.
The Request for Proposal also includes key terms and
conditions we intend to include in a supplier
agreement.

PROJECT MANAGEMENT CYCLE:

Planning (Contd.)
Create Supplier Contract.
A Supplier Contract or "Supply Contract" is an
agreement between a business and an external
supplier for the delivery of a defined set of products and
services.
A Supplier Contract is a legal agreement and is used as
the basis upon which to measure the supplier's
performance.
In addition to listing the items to be supplied, the Supply
Contract states the timeframes, responsibilities, pricing
and payment clauses needed to administer the
relationship.
A Supplier Contract should be used whenever we need
to purchase products or services from an external
supplier.
The Supply Contract defines the delivery milestones and

PROJECT MANAGEMENT CYCLE:

Planning (Contd.)
Perform Phase Review.
A Project Phase Review is completed at the end of each
project phase.
During this project management review, the reviewer
completes a Phase Review Form describing the progress of
the project to date and recommending whether or not it
should continue to the next project phase.
If approved, the next project phase can be commenced .
The project review may be conducted by the Team Manager
or an independent person to the project.
During the project management review, any risks and issues
should also be recorded.
The Project Phase Review Form is then completed,
documenting the outcome of the reyiew , for approval.

PROJECT MANAGEMENT CYCLE:

Execution (Contd.)

During Project Execution phase, we :

Build Deliverables
Monitor and Control
Perform Time Management
Perform Cost Management
Perform Quality Management
Perform Change Management
Perform Risk Management
Perform Issue Management
Perform Acceptance Management
Perform Communications Management

PROJECT MANAGEMENT CYCLE: :

Execution (Contd.)

Perform Time Management

Project Time Management is all about recording the
time spent by people on a project.
To record time spent, the team implement a Project Time
Management
Process (or "Time Process").
This time process involves recording the time spent on
tasks, using Timesheets.
The time process helps the manager know which tasks has
been worked on, when and for how long.
The best way to see if our project is on track is to record
time actually spent vs. time planned to be spent.
The time process allows us to see for every task, whether is
has been completed on time.
This time process also allows us to control time spent
by implementing a timesheet approval process.

PROJECT MANAGEMENT CYCLE: :

Execution (Contd.)
Perform Cost Management
A Cost Management process helps us control expenses
within an organization.
Using this project Cost Management process, we can
ensure that our project delivered within budget.
If we want to control the way that expenses are
incurred, then we need to implement a Cost
Management process.
It will help us to control project expenses ensuring that
only expenses which have been approved, may
take place.
Using this Cost Management process, we can also keep
our project plan up-to-date with the latest expense
information available.

PROJECT MANAGEMENT CYCLE: :

Execution (Contd.)
Perform Quality Management
A Quality Management Process is a set of procedures
that are followed to ensure that the deliverables
produced by a team are "fit for purpose".
The start of the Quality Management Process involves
setting quality targets, which are agree with the
customer.
A "Quality Assurance Process" and "Quality Control
Process are then undertaken, to measure and report the
actual quality of deliverables.
A part of the Quality Management Process, any
quality issues are identified an resolved quickly.
Whether we are producing deliverables as part of a
project or operational team, an effective quality
management and quality assurance process will be
beneficial.

PROJECT MANAGEMENT CYCLE: :

Execution (Contd.)
Perform Change Management
A Change Process, or Change Management Process, is
a set of procedures that help teams to control change
effectively.
It's not that we have to prevent change from
happening ; it's how we manage change once it occurs
that really matters.
The Change Process allows us to record change
requests, and review and approve those requests,
before implementing them.
This Change Process makes change management easy.
If we work in a team that is subject to change, then we
need a Change Process.
By implementing a Change Process, we can track
change as it occurs and control the effect it has on our

PROJECT MANAGEMENT CYCLE: :

Execution (Contd.)
Perform Risk Management
A Risk Process, or Risk Management Process, describes
the steps we need to take to identify, monitor and
control risk.
Within the Risk Process, a risk is defined as any future
event that may prevent you to meet your team goals.
A Risk Process allows you to identify each risk, quantify
the impact and take action now to prevent it from
occurring and reduce the impact should it
eventuate.
We use a Risk Process whenever your ability to meet
your objectives is at risk.
By putting in place this Risk Process, you can monitor
and control risks, removing all uncertainty.
The Risk Process involves running risk reviews to
identify and quantify risks.

PROJECT MANAGEMENT CYCLE: :

Execution (Contd.)
Perform Issue Management
An Issue Process, or Issue Management Process, is a set
of procedures that help us manage issues as they occur.
Whether we're part of a project or operational team,
issues will occur on a regular basis affecting the ability to
meet our team goals.
An Issue Process helps us record each issue and identify
the actions needed to resolve it.
As part of the Issue Process, an approval step is included
to ensure that the right actions are taken, at the right
time.
We follow an Issue Process when we encounter issues
that need to be resolved quickly.
Examples of issues that are resolved through an Issue
Process include; lack of funding, insufficient resources
and tight deadlines.

PROJECT MANAGEMENT CYCLE: :

Execution (Contd.)
Perform Procurement Management
A Procurement Management Process, or Procurement
Process, is a method by which items are purchased
from external suppliers.
The procurement management process involves
managing the ordering, receipt, review and approval
of items from suppliers.
A procurement process also specifies how the supplier
relationships will be managed, to ensure a high level
of service is received.
In essence, the procurement process helps us "get
what you have paid for".
It also helps us manage the supplier relationship,
ensuring that any issues are resolved quickly.
By implementing a Procurement Process, we can

PROJECT MANAGEMENT CYCLE: :

Execution (Contd.)
Perform Acceptance Management
An Acceptance Management Process is a series of steps
that we take to complete User Acceptance Testing.
When a project is nearly complete, one of the final step
is to perform User Acceptance Testing with the
customer.
As part of the User Acceptance Testing process, the
customer will be asked to review the project
deliverables and confirm that they are "fit for
purpose" .
By using this Use Acceptance Testing process , we can
confirm that our customer is happy and sign off the
project as complete .
Before we can close a project officially, we need to show
our Project Sponsor that we have completed User
Acceptance Testing and that our customer has signed off
the deliverables as being 100 percent complete.

PROJECT MANAGEMENT CYCLE: :

Execution (Contd.)
Perform Communications Management
A Communication Process , or Communications
Management Process, is a set of that are taken
every time formal communications are under taken
in organization .
A Communications Process is undertaken as part of
Communications Management and helps to ensure
that our stakeholders are kept regularly informed.
For example as part of the project life cycle, the
team implement a Communication Process to make
sure that the entire team is kept informed of status of
the project.
A Communication Process should be used when we wish
to communicate formally within an organization.
As part of the Communication Process, we can receive
feedback on the communications which have taken place
to date ensure that future communications are

PROJECT MANAGEMENT CYCLE:

Closure (Contd.)
During Project Closure phase, we :
Perform Project Closure
Review Project Completion

PROJECT MANAGEMENT CYCLE:

Closure (Contd.)
Perform Project Closure
A Project Closure Report describes how we intend to
close our projects .
The Project Closure Report confirms that the objectives
have been met, the deliverables have been handed
over to the customer and that project closure can
commence.
Every Project Manager needs to complete a Project
Closure Report to gain agreement from their Sponsor
that the project is ready for closure.
Once the Project Closure Report has been approved,
the Manager can proceed with the actions needed to
close the project swiftly.
A Project Closure Report should be documented any
time that a project is ready for closure.
Using this Project Closure Report, we can to document

PROJECT MANAGEMENT CYCLE:

Closure (Contd.)
Review Project Completion
A Post Implementation Review, or Post Project Review, is
performed after a project is complete.
The purpose of a Post Implementation Review is to
determine whether the project was successful and
identify any lessons learned.
A Post Implementation Review also looks at whether the
project produced the required deliverables within the
agreed timeframe.
The overall achievements are also documented in the
Post Implementation Review report.
The best time to conduct a Post Implementation Review
is between 1 and 6 months after a project has
completed.
By then, the project deliverables will have been handed
over to the customer and the benefits of the project will

SPM OBJECTIVES
The primary responsibility of the project manager is to ensure that the
end product meets the client's requirements ; therefore, the first
scheduling task of the project manager is to clarify project objectives
by translating them into quantifiable terms.
A project objective is a statement specifying the results to be achieved.
These statements form the foundation for the entire planning process .
including development of the Master Schedule.
The project objectives will be previewed frequently throughout the
project.
They will be referred to at the onset of the project.
They will be referred to at the onset of the project to identify the
project team's responsibilities.
During the project they will be reviewed to identify changes that fall
outside the original project scope.
At the project's conclusion, they will be reviewed to help the
project manager perform an objective postmortum review of the
project.

SPM OBJECTIVES(Contd.)
A well defined project objective has
several characteristics. The objective will
be:
Attainable. The objective identifies a
target which can be reasonably
achieved given the project's time and
resource constraints. If the objective is
set too high, credibility is destroyed
because the sence of shortfall greater
than the sense of accomplishment

SPM OBJECTIVES(Contd.)
Definitive. It spells out in concrete terms what is to be
achieved and to what degree. The results to be attained
are clearly defined. Only those objectives related to
project or organizational goals are included. Routine
project activities must not be mistaken for objectives.
Quantifiable. It specifies a yardstick for completion which
can be identified by all concerned, especially those
responsible for its achievement. The establishment of
measurable objective is mandatory so that performance
can be compared to a standard.
Specific Duration. It defines the time parameters within
which the task is to be achieved. This is also necessary
for evaluation of project progress.

SPM OBJECTIVES(Contd.)
Trode-off Functions

The primary objective of software project management

is to establish relation between performance, time and
budget. The following graph shows the relation.

SPM OBJECTIVES(Contd.)
Following are the trade-off functions for determining performance,
time and budget.
Performance = f (Time, Budget)
Time
= f (Budget , Performance)
Budget= f (Performance, Tim e)

SMART Principles
For setting general objectives , we should use SMART principles.
SMART objectives. are :
Specific

Measurable
Achievable
Realistic
Timely
Smart principles are strongly encouraged when setting
objectives.

SPM OBJECTIVES(Contd.)
Specific
Is it clear and well defined
Is it clear to anyone that has a basic knowledge of
the work.
Measurable
Know if the goal is obtainable and how far away
completion is.
Know when it has been achieved.
Achievable
Agreement with all the stakeholders what the goal
should be.
Is there a realistic path to achievement.
Realistic
Within the availability of resources, knowledge and
time.
Timely

MANAGEMENT SPECTRUM
Effective software project management focuses on
the three P's :people, problem, and process.
The
manager
who
forgets
that
software
engineering work is an intensely human endeavor
will never have success in project management.
A manager who fails to encourage comprehensive
customer communication early in the evolution of a
project risks building an elegant solution for the
wrong problem.
Finally, the manager who pays little attention to the
process runs the risk of inserting competent
technical methods and tools into a vacuum .

MANAGEMENT SPECTRUM:
People
The Software Engineering Institute has sponsored

a
people management maturity model to enhance the
readiness of software organizations to undertake
increasingly complex applications by helping to attract,
grow, motivate, deploy , and retain the talent needed to
improve their software development capability."
The people management maturity model defines tie
following key practice areas for software people:
recruiting, selection, performance management ;
training,
compensation,
career
development,
organization, and team and culture development.
Organizations that achieve high levels of maturity in the
people management area have a higher likelihood of
implementing effective software engineering practices.

MANAGEMENT SPECTRUM: The

Problem
Before a project can be planned, objectives and scope

should be established, alternative solutions should be

considered, and technical and management constraints
should be identified.
Without this information, it is impossible to develop
reasonable estimates of the cost, a realistic breakdown of
project tasks, or a manageable project schedule that
provides a meaningful indication of progress.
The software developer and customer must meet to
define project objectives and scope.
In many eases, this activity occurs as pare of structured
customer communication process such as joint
application design.
Joint Application Design (JAD) is an activity that occurs in
five phases : project definition, research, preparation, the
JAD meeting, and document preparation.
The intent of each phase is to develop information that

MANAGEMENT SPECTRUM: The Process

A few framework activities apply to all software
projects, regardless of their size or complexity.
A number of task sets - tasks, milestones, deliverables,
and quality assurance points - enable the framework
activities to be adapted to the characteristics of the
software project and the requirements of the project
team .
Finally, umbrella activities such as software quality
assurance,
software configuration management,
and measurement - overlay the process model.
Umbrella activities are independent of any one
framework activity and occur throughout the process.

MANAGEMENT SPECTRUM: The Process

MANAGEMENT SPECTRUM: The Process

The Software Engineering Institute (SEI) has developed a
comprehensive assessment model that is predicated on a
set of software engineering capabilities that should be
present as organizations reach different levels of process
maturity.
To determine an organization's current state of process
maturity, the Sill uses an assessment questionnaire and a
five-point grading scheme.
The grading scheme determines compliance with a
capability maturity model that defines key activities
required at different levels of process maturity.
The Sill approach provides a measure of the global
effectiveness of a company's software engineering
practices and establishes five process maturity levels
that are defined in the following manner :

MANAGEMENT SPECTRUM : The

Process
Level 1 :Initial. The software process is characterized as
adhoc, and occasionally even chaotic. Few processes are
defined, and success depends on individual effort.
Level 2 :Repeatable. Basic project management processes
are established to track cost, schedule, and functionality.
The necessary process discipline is in place to repeat earlier
successes on projects with similar applications.
Level 3 : Defined. The software process for both
management and engineering activities is documented,
standardized and integrated into an organization wide
software process. All projects use a documented and
approved version of the organization's process for
developing and maintaining software. This level includes all
characteristics defined for level 2.
Level 4 :Managed. Detailed measures of the software
process and product quality are collected. Both the
software
process and products are quantitatively

MANAGEMENT SPECTRUM : The

Process

Level 5: Optimizing.
Continuous
process
improvement is enabled by quantitative feedback
from the process and from testing innovative ideas
and
technologies.
This
level
includes
all
characteristics defined for level 4.
The five levels defined by the SEI are derived as a
consequence of evaluating responses to the SEI
assessment questionnaire that is based on the
CMM.
The results of the questionnaire are distilled to a
single numerical grade that provides an indication
of an organization's process maturity.

MANAGEMENT SPECTRUM : The

Process
The SEl has associated key process areas (KPAs) with each
of the maturity levels. The KPAs describe those software
engineering functions (for example , software project
planning and requirements management) that must be
present to satisfy good practice at a particular level.
Each KPA is described by identifying the following
characteristics :
goals : the overall objectives that the KPA must achieve
commitments : requirements (imposed on the
organization) that must be met to achieve the goals,
provide proof of intent to comply with the goals
abilities : those things that must be in place
(organizationally and technically) that will enable the
organization to meet the commitments
activities : the specific tasks that are required to achieve
the
KPA
function
methods
for
monitoring
implementation -the manner in which the activities are

Project Plan
A project plan is : "a formal, approved document used
to guide both project execution and project control.
The primary uses of the project plan are to document
planning assumptions and decisions, facilitate
communication among stakeholders, and document
approved scope, cost and schedule baselines. A
project plan may be summary or detailed. "
Also we can define it as :
"a statement of how and when a project's objectives
are to be achieved , by showing the major products.
milestones, activities and resources required on the
project."

Planning Objectives
The purpose of a project plan is to maintain control of a
project.
As a complicated process, a project always threatens to
exceed the limit of our control.
To maintain control we need help in the form of tools and
best tool is our plan.
The project plan controls the project by :
Breaking a complex process down into a number of
simpler components
Providing visibility for difficulty or ambiguous tasks in
the project
Providing a single point of reference for everyone
Enforcing inspection of the sequence and nature of
events
Providing a baseline against which execution of the
project can be compare
Anticipating likely events and providing pre-planned
means of a them.
A project plan must be as accurate, complete and as

Types of project plan

There are many types of plans used in human service
organizations.
While the essence of all plans is the same - answering
questions such as : where are we going and how are
we going to get there ?
We often give them different names depending on
what the plan is for.
For example plans can be made for :
The organization (e.g. strategic plan, service plans,
financial plan)
A project (e.g. project plan, financial plan)
A team (e.g. team work plan)
worker (e.g. individual work plan)
A client (e.g. individual service plan)

Types of project plan

(Contd.)
Some of the different types of plans and the questions
they ask and attempt to answer are given as follows.
The Organisation
Strategic Plan. Where are we? Where are we going? Why?
How will we get there?
Service Plan . Who are the clients ? What will be the
benefits to them ? How ?
Operational Plan. What do we need to do to make it all
happen and know we are on track ?
Financial Plan. Where is the money coming from ? Where
is it going to ? Will there be enough?
Evaluation Plan. How do we know we are doing a good job ?
How do we know how to improve what we are doing ?

Types of project plan

(Contd.)
The Project
Project Plan. What are we trying to
achieve ? How will we make it happen ?
Project Financial Plan. Where is the
money coming from ? Where is it going to
? Will there be enough ?
Project Evaluation Plan. How do we know
we are doing a good job ? How do we
know how to improve what we are
doing ?

Types of project plan

(Contd.)
The Team
Team Work Plan. What are we on about?
What do we need to do, when and why?

The Worker
Individual Work Plan. What am I on
about? What do I need to do, when and
why?

Types of project plan

(Contd.)
Clients

The
Individual Service Plans / Case Management.
What do I want to achieve ? How can it happen ?
A typical large organization:
In a large organisation there will be many plans,
for example, a separate strategic plan, financial
plan and operational plan.
There will be project plans, team work plans,
individual work plans.
And if the organisation is a direct service provider
there will be individual service plans or case
management plans.
Very small organizations.
A very small organisation many only require
one plan which incorporates the answers to all

Structure of a Software Project

Management Plan
Projects require a plan of what is
intended and a description of what
happens.
Following is a pro-forma that can
be used for a project plan.

Project

What is the name of the project ?

Background How did this project arise ? How was it identified ? How has
it evolved ?
Description

What is a brief description of the project ?

Values

What values underpin this project ?

Target
group &
their needs

Who will benefit ?

What are their needs ?

Aims

What are the overall aims this project is trying to achieve ?

Outcomes
hierarchy

What is the outcomes hierarchy that will lead to the

achievement of
these aims ?

Objectives

What are the specific objectives this project will achieve ?

Strategies/
steps

What are the principal strategies or steps that will be

required to make this project happen ? How will the project
work ?

Manageme
nt

Who is responsible for the management of the

project ?

Funding

What financial resources are required and where are they

coming from ?

Time frame

What is the time frame ?

SOFTWARE PROJECT
ESTIMATION
Software cost and
effort estimation will never be an exact

science.
Too many variableshuman, technical, environmental,
politicalcan affect the ultimate cost of software and
effort applied to develop it.
However, software project estimation can be transformed
from a black art to a series of systematic steps that
provide estimates with acceptable risk.
To achieve reliable cost and effort estimates, a number of
options arise:
Delay estimation until late in the project (obviously,
we can achieve 100% accurate estimates after the
project is complete!).
Base estimates on similar projects that have already
been completed.
Use relatively simple decomposition techniques to
generate project cost and effort estimates.

SOFTWARE PROJECT ESTIMATION

(Contd.)
Unfortunately, the first option, however attractive, is not
practical. Cost estimates must be provided "up front.
The second option can work reasonably well, if the
current project is quite similar to past efforts and other
project influences (e.g., the customer, business
conditions, the SEE, deadlines) are equivalent.
Unfortunately, past experience has not always been a
good indicator of future results.
The remaining options are viable approaches to software
project estimation.
Ideally, the techniques noted for each option should be
applied in tandem; each used as a cross-check for the
other.

SOFTWARE PROJECT ESTIMATION

(Contd.)
Decomposition techniques take a "divide and conquer
approach to software project estimation.
By decomposing a project into major functions and
related software engineering activities, cost and effort
estimation can be performed in a stepwise fashion.
Empirical estimation models can be used to complement
decomposition techniques and offer a potentially
valuable estimation approach in their own right.
A model is based on experience (historical data) and
takes the form
d = f (vi)
where d is one of a number of estimated values (e.g.,
effort, cost, project duration) and vi are selected
independent parameters (e.g., estimated LOC or FP).

SOFTWARE PROJECT ESTIMATION

(Contd.)
Automated
estimation
tools
implement
one
or
more
decomposition
techniques
or
empirical models.
When combined with a graphical
user interface, automated tools
provide an attractive option for
estimating.
Cost and effort estimates are derived
from these data.

SOFTWARE PROJECT ESTIMATION:DECOMPOSITION

TECHNIQUES (Contd.)

Problem decomposition, sometimes called

partitioning or problem elaboration, is an
activity that sits at the core of software
requirements analysis.
During the scoping activity no attempt is
made to fully decompose the problem.
Rather, decomposition is applied in two
major areas:
the functionality that must be delivered
the process that will be used to deliver it.

SOFTWARE PROJECT ESTIMATION

(Contd.)
Estimation uses one or both forms of
partitioning.
But before an estimate can be made, the
project planner must understand the scope of
the software to be built and generate an
estimate of its size.

SOFTWARE PROJECT ESTIMATION

(Contd.)
Software Sizing
The accuracy of a software project estimate is predicated
on a number of things:
the degree to which the planner has properly
estimated the size of the product to be built;
the ability to translate the size estimate into human
effort, calendar time (a function of the availability of
reliable software metrics from past projects);
the degree to which the project plan reflects the
abilities of the software team; and
the stability of product requirements and the
environment that supports the software engineering
effort.
In the context of project planning, size refers to a
quantifiable outcome of the software project.
If a direct approach is taken, size can be measured in

SOFTWARE PROJECT ESTIMATION

(Contd.)
Problem-Based Estimation
LOC and FP data are used in two ways
during software project estimation: (1)
as an estimation variable to "size each
element of the software and
(2) as baseline metrics collected from
past projects and used in conjunction
with estimation variables to develop
cost and effort projections.

SOFTWARE PROJECT ESTIMATION

(Contd.)
The project planner begins with a bounded statement of
software scope and from this statement attempts to
decompose software into problem functions that can
each be estimated individually.
LOC or FP (the estimation variable) is then estimated for
each function. Alternatively, the planner may choose
another component for sizing such as classes or objects,
changes, or business processes affected.
Baseline productivity metrics (e.g., LOC/pm or FP/pm) are
then applied to the appropriate estimation variable, and
cost or effort for the function is derived.
Function estimates are combined to produce an overall
estimate for the entire project.

SOFTWARE PROJECT ESTIMATION

(Contd.)
In general, LOC/pm or FP/pm averages should be
computed by project domain.
That is, projects should be grouped by team size,
application area, complexity, and other relevant
parameters.
Local domain averages should then be computed.
When a new project is estimated, it should first be
allocated to a domain, and then the appropriate
domain average for productivity should be used in
generating the estimate.
The LOC and FP estimation techniques differ in the
level of detail required for decomposition and the
target of the partitioning.
When LOC is used as the estimation variable,

SOFTWARE PROJECT ESTIMATION

(Contd.)
This decomposition approach assumes that all functions can be
decomposed into subfunctions that will resemble entries in a
historical database.
If this is not the case, then another sizing approach must be
applied.
The greater the degree of partitioning, the more likely
reasonably accurate estimates of LOC can be developed.
For FP estimates, decomposition works differently. Rather than
focusing on function, each of the information domain
characteristicsinputs, outputs, data files, inquiries, and
external interfaces.
The resultant estimates can then be used to derive a FP value
that can be tied to past data and used to generate an estimate.

SOFTWARE PROJECT ESTIMATION

(Contd.)

Regardless of the estimation variable that is used, the project

planner begins by estimating a range of values for each
function or information domain value.
Using historical data or (when all else fails) intuition, the
planner estimates an optimistic, most likely, and pessimistic
size value for each function or count for each information
domain value.
An implicit indication of the degree of uncertainty is provided
when a range of values is specified.
A three-point or expected value can then be computed. The
expected value for the estimation variable (size), S, can be
computed as a weighted average of the optimistic (sopt), most
likely (sm), and pessimistic (spess) estimates. For example,
S = (sopt + 4sm + spess)/6

(5-1)

gives heaviest credence to the most likely estimate and

follows a beta probability distribution. We assume that there is
a very small probability the actual size result will fall outside

SOFTWARE PROJECT ESTIMATION

(Contd.)
Process-Based Estimation
The most common technique for estimating a
project is to base the estimate on the process
that will be used.
That is, the process is decomposed into a
relatively small set of tasks and the effort
required to accomplish each task is estimated.
A series of software process activities must be
performed for each function.
Functions and related software process
activities may be represented as part of a
table similar to the one presented in Figure

SOFTWARE PROJECT ESTIMATION

(Contd.)
Once problem functions and process activities are
melded, the planner estimates the effort (e.g., personmonths) that will be required to accomplish each software
process activity for each software function.
Costs and effort for each function and software process
activity are computed as the last step.
If process-based estimation is performed independently of
LOC or FP estimation, we now have two or three estimates
for cost and effort that may be compared and reconciled.
If both sets of estimates show reasonable agreement,
there is good reason to believe that the estimates are
reliable.
If, on the other hand, the results of these decomposition
techniques show little agreement, further investigation
and analysis must be conducted.

EMPIRICAL ESTIMATION MODELS

An estimation model for computer software
uses empirically derived formulas to predict
effort as a function of LOC or FP.
The empirical data that support most
estimation models are derived from a
limited sample of projects.
For this reason, no estimation model is
appropriate for all classes of software and
in all development environments.

The Structure of Estimation Models

A typical estimation model is derived using
regression analysis on data collected from past
software projects.
The overall structure of such models takes the form:
E = A + B x (ev)C
where A, B, and C are empirically derived constants,
E is effort in person-months, and ev is the
estimation variable (either LOC or FP).
In addition to the relationship noted in Equation, the
majority of estimation models have some form of
project adjustment component that enables E to be
adjusted by other project characteristics (e.g.,
problem complexity, staff experience, development
environment).

The Structure of Estimation

Models(Contd.)
Among the many LOC-oriented estimation models proposed
in the literature are:
E = 5.2 x (KLOC)0.91 Walston-Felix model
E = 5.5 + 0.73 x (KLOC)1.16 Bailey-Basili model
E = 3.2 x (KLOC)1.05 Boehm simple model
E = 5.288 x (KLOC)1.047 Doty model for KLOC > 9
FP-oriented models have also been proposed. These include
E = 13.39 + 0.0545 FP Albrecht and Gaffney model
E = 60.62 x 7.728 x 10-8 FP3 Kemerer model
E = 585.7 + 15.12 FP Matson, Barnett, and Mellichamp model

The COCOMO Model

Barry Boehm introduced a hierarchy of software
estimation models bearing the name COCOMO,
for COnstructive COst MOdel.
The original COCOMO model became one of the
most widely used and discussed software cost
estimation models in the industry.
It has evolved into a more comprehensive
estimation model, called COCOMO II.
Like its predecessor, COCOMO II is actually a
hierarchy of estimation models that address the
following areas:

The COCOMO Model

Application composition model. Used during
the early stages of software engineering,
when
prototyping
of
user
interfaces,
consideration of software and system interaction,
assessment of performance, and evaluation of
technology maturity are paramount.
Early design stage model. Used once
requirements have been stabilized and basic
software architecture has been established.
Post-architecture-stage model. Used during
the construction of the software.

The COCOMO Model

Like all estimation models for software, the
COCOMO II models require sizing information.
Three different sizing options are available as
part of the model hierarchy: object points,
function points, and lines of source code.
The COCOMO II application composition model
uses object points and is illustrated in the
following paragraphs. It should be noted that
other, more sophisticated estimation models
(using FP and KLOC) are also available as part
of COCOMO II.

The COCOMO Model

Like function points, the object point is an
indirect software measure that is computed
using counts of the number of (1) screens (at the
user interface), (2) reports, and (3) components
likely to be required to build the application.
Each object instance (e.g., a screen or report) is
classified into one of three complexity levels
(i.e., simple, medium, or difficult) using criteria
suggested by Boehm.
In essence, complexity is a function of the
number and source of the client and server data
tables that are required to generate the screen
or report and the number of views or sections
presented as part of the screen or report.

The COCOMO Model

Once complexity is determined, the number of screens,
reports, and components are weighted according to Table
in next slide.
The object point count is then determined by multiplying
the original number of object instances by the weighting
factor and summing to obtain a total object point count.
When component-based development or general software
reuse is to be applied, the percent of reuse (%reuse) is
estimated and the object point count is adjusted:
NOP = (object points) x [(100 % reuse)/100]
where NOP is defined as new object points.
To derive an estimate of effort based on the computed
NOP value, a productivity rate must be derived.
Table next to next slide presents the productivity rate
PROD = NOP/person-month

The COCOMO Model

The COCOMO Model

The COCOMO Model

For different levels of developer experience
and development environment maturity.
Once the productivity rate has been
determined, an estimate of project effort
can be derived as
estimated effort = NOP/PROD
In more advanced COCOMO II models, a
variety of scale factors, cost drivers, and
adjustment procedures are required.

The Software Equation

The software equation is a dynamic multivariable

model that assumes a specific distribution of effort
over the life of a software development project.
The model has been derived from productivity
data collected for over 4000 contemporary
software projects.
Based on these data, an estimation model of the
form
E = [LOC B0.333/P]3 (1/t4)
where E = effort in person-months or person-years
t = project duration in months or years
B = special skills factor16
P = productivity parameter that reflects:

The Software Equation

Typical values might be P = 2,000 for development
of real-time embedded software; P = 10,000 for
telecommunication and systems software; P =
28,000 for business systems applications.
The productivity parameter can be derived for local
conditions using historical data collected from past
development efforts.
It is important to note that the software equation
has two independent parameters:
(1) an estimate of size (in LOC) and (2) an indication
of project duration in calendar months or years.

The Software Equation

To simplify the estimation process and use a more

common form for their estimation model, Putnam and
Myers suggest a set of equations derived from the
software equation. Minimum development time is
defined as
tmin = 8.14 (LOC/P)0.43 in months for tmin > 6 months (a)
E = 180 Bt3 in person-months for E 20 person-months
(b)
Note that t in Equation (b) is represented in years.
Using above Equations with P = 12,000 (the
recommended value for scientific software)
tmin = 8.14 (33200/12000)0.43
tmin = 12.6 calendar months
E = 180 0.28 (1.05)3
E = 58 person-months

Decision Process
Decision process is used in strategic planning,
operational management, and other areas of business.
The decision process is a framework that helps project
managers solve a variety of decision-making problems.
There are no exact methods for how decision analysis
should be structured.
The process can be different for different companies,
types of projects, and the types of decisions that must
be made.
Any decision process is based on three main rules,
which can be called 3C principle :

Decision Process
(Contd.)
Consistency
It is important to standardize the decision
process for similar kinds of problem and
opportunities
to enable consistent
decision
making over time.
Comprehensiveness
Decision
processes
should
include
a
comprehensive assessment and analysis of the
business situation. Missing
or incomplete
information can lead to incorrect . decisions.
Continuity
The value of decision process will significantly
less important if it is done only discrete
situations during the course of a project.
Decision process is a continuos process of

FOOTFALLS OF DECISION
PROCESS
Decision Making
Decision making is based mainly on
subjective expert judgment.
Experts provide their own beliefs in the
form of their answers, which can be biased.
There are many forms of biases : cultural,
organizational, motivational, cognitive and
others.
Motivational and cognitive biases are
most common in project management .

Decision Process
(Contd.)
Identifying Potential Problems and Opportunities
In some cases, it is difficult to identify the
problems and opportunities.
For example, what is causing the different
projects within the organization to go
consistently over budget in relation to the
different specific corrective actions that were
undertaken ?
In our software development example, the
project will be delayed if certain actions are
not taken.

Decision Process
(Contd.)
Assessing Business
Situation
Before attempting to make a decision,
it is important to assess the business
environment
and
define
the
constraints related to the problem.
The assessment may also include an
analysis of markets, competition ,
prices, or anything that can be related
to the problem or opportunity.
In our example, it is the availability of
an additional resource.

Decision Process
(Contd.)
Determining Success Criteria
In
our
software
development
example, it is the chance that
project will be completed on time.
Very often project managers have to
make decisions based on multiple
criteria, including project duration,
cost, scope, and other parameters.

Decision Process
(Contd.)
Identifying Uncertainties
Understanding of uncertainties is the
key to the decision process.
In our example there are uncertainties
in task duration, start and finish times.
Potentially, there could be many
different
types
of
uncertainties
including
uncertainties in cost,
resource allocation , and others.

Decision Process
Generating Alternatives
(Contd.)
First, let's identify what cannot be changed, or
project constraints for making the particular
decision process. In our software example it is
the deadline.
The project scope is a constraint as well.
However, there is the possibility of bring
in additional resources (software developers)
to accelerate the development. As result,
we have three potential project scenarios :
"Do Not Add". In this example, it means
that additional project resources will not be
added to the project team
Bring a developer from another team within
the organization

Decision Process
(Contd.)
Designing the Situation
A mathematical model helps the analysis
and estimation of future events.
During
the modeling stage, project
managers depend on heuristics or rules
of thumb make estimations and create
the model.
Under many circumstances, heuristics
lead to predictably faulty judgments or
cognitive biases.

Decision Process
(Contd.)
Creating Models
for Each Project Alternative
Project managers constantly create
mathematical models of projects, in most
this is the project schedule.
Sometimes, more elaborate models are
required.
For example, in the analysis of a
complete product lifecycle,
comprehensive will include not only
product development, but also marketing
and sales efforts.
In our example, it is possible to create
three simple, slightly different project
schedules associated with each scenario

Decision Process
(Contd.)
Quantifying the
Uncertainties
The uncertainties, identified through the
decision making process should be quantified.
One of the ways to quantify uncertainties is
defining ranges for parameters.
For example, define low (optimistic), base
(expected), and high (pessimistic) duration
estimates for each task.
Another way to define uncertainties is to list
all the potential events, which could affect the
project
schedule and
quantify their
probabilities and impact.
In our software development example, there is
a 50% chance that external consultant will

Decision Process
(Contd.)
Quantitative Analysis
The analysis should give project managers enough
data to make an informed decision . Even with most
advanced
analytical
tools
and
techniques
,
interpretation of the results of the analysis is the
subject of multiple mental traps.
Determining what is Most Important
A model of a project may include a considerable
number of variables : large numbers of tasks,
resources, risks, and other parameters .
For example, certain risks will cause failure of the
project, while others risks will have no noticeable
effect on the project.
To determine which project parameter is the
most important, project managers can use
sensitivity analysis.
In our software development example, the duration

Decision Process
(Contd.)
Quantifying Risks
Associated with the Project
Uncertainties associated with input parameters
were already quantified during modeling step.
Now it is important to analyze how the
combination of all these uncertainties could
affect the project .
A number of analytical techniques can be applied
for this analysis. In our example, quantitative
analysis shows the following probability that
project will be completed on time:
"Do Not Add" 32%
"Bring resource from another team" 95%
"Hire external contractor" 65%

Decision Process
(Contd.)
Determining the
Value of New Information
One of the useful decision analysis technique s
is to assess a value of new information.
For example, the goal is to select new
development tools for the software project
based on performance .
Tests can be done to determine performance,
but it could be costly and time consuming.
Alternatively, it is possible to select the tools
based on specifications, without specific tests.
The analytical technique helps to establish the
value of new information , which in this case
would be the testing results, and to determine
whether the money should be spent on the
test.

Decision Process
(Contd.)
Deciding on a Course of Action
In many situations, selection of
alternatives is not so trivial.
Sometimes, decisions are made using
many criteria which complicates the
selection of the most efficient alternative.
In our example it is clear that according to
our success criterion, we should select
alternative "Bring resource from another
team".

 Actual

Decision Process
(Contd.)
Project Performance Tracking

Now a decision has been made and a selected

course of action is under However, in the middle of
the project, an unforeseen event occurs that causes
selected plan to derail.
For example, because of other commitments, the
software developer cannot move to the project.
Luckily, there is a model of the selected project
alternative and the project manager can update
model, perform a new analysis and make a decision.
It is very important constantly track project
performance and analyze all potential pitfalls
opportunities.