NARSEE MONJEE COLLEGE

OF COMMERCE & ECONOMICS

PRESENTS,
Software Project Management —

Copyright © PROF. GUFRAN QURESHI

9029120671 / 7021047199

SOFTWARE
PROJECT MANAGEMENT
Unit I

Ch 1: Introduction to Software Project Management: Introduction, Why is Software

Project Management
Important? What is a Project? Software Projects versus Other Types of Project,
Contract Management and
Technical Project Management, Activities Covered by Software Project Management,
Plans, Methods and
Methodologies, Some Ways of Categorizing Software Projects, Project Charter,
Stakeholders, Setting
Objectives, The Business Case, Project Success and Failure, What is Management?
Management Control,
Project Management Life Cycle, Traditional versus Modern Project Management
Practices.

Ch 2: Project Evaluation and Programme Management: Introduction, Business Case,

Project Portfolio
Management, Evaluation of Individual Projects, Cost-benefit Evaluation Techniques,
Risk Evaluation,
Programme Management, Managing the Allocation of Resources within Programmes,
Strategic Programme
Management, Creating a Programme, Aids to Programme Management, Some Reservations
about
Programme Management, Benefits Management.

Ch 3: An Overview of Project Planning : Introduction to Step Wise Project Planning,

Step 0; Select
Project, Step 1: Identify Project Scope and Objectives, Step 2: Identify Project
Infrastructure, Step 3: Analyse
Project Characteristics, Step 4: Identify Project Products and Activities, Step 5:
Estimate Effort for Each
Activity, Step 6: Identify Activity Risks, Step 7: Allocate Resources, Step 8:
Review/Publicize Plan, Steps 9
and 10: Execute Plan/Lower Levels of Planning.

Copyrig OF. GUFRAN QURESHI

Ch-1 Introduction to Software Project Management

Definition:- Software project management is an art and discipline of planning and

supervising software projects. It is a sub-

discipline of software project management in which software projects planned,

implemented, monitored and controlled.

* It is a procedure of managing, allocating and timing resources to develop

computer software that fulfills requirements.

+ Insoftware Project Management, the client and the developers need to know the
length, period and cost of the project.

Prerequisite:
There are three needs for software project management. These are:

* Time: Time management is about using the amount of time allocated to a project
wisely in order to meet scheduled
deliverables and conclude all work by or before the project completion date.

* Cost: Cost management is the process of estimating, allocating, and controlling

the costs in a project. It allows a business
to predict coming expenses in order to reduce the chances of it going over budget.
Projected costs are calculated during the
planning phase of a project and must be approved before work begins.

* Quality: A quality management process is introduced in a project towards quality

planning, quality assurance and quality control. In a project, quality
characteristics
are defined by the stakeholders. Some of the most common quality characteristics
are performance, functionality, suitability, reliability, consistency and more.

It is an essential part of the software organization to deliver a quality product,

keeping
the cost within the client’s budget and deliver the project as per schedule. There
are
various factors, both external and internal, which may impact this triple factor.
Any of
three-factor can severely affect the other two.

Quality
Copyright © PROF, GUFRAN QURESHI

Neéed / Importance of SPM

1. To control scope of project & manage change: Although the projéct deliverables
are defined at the outset of the project,
small changes in project deliverables aré common.

2. To deliver projects on time & within budget: Once return once investments (ROI)
is established it is for the project
manager to ensure that the project schedule & budget are adhered to else the
project will fail to deliver the expected
results.

3. To ensure the focus of the project team: It is the responsibility of the project
manager to ensure that the project team
focuses on the right tasks by using a clear & concise project charter & that there
are no interferences.

4. To collect user requirement from disparate sources: The project manager at the
initiation phase should collect user
requirement, project constraints and conduct a feasibility study to build a strong
business case justification.

5. To define the critical path to optimally complete the project: By using the
critical path method technique the project
manger is able to identify the critical path & thus ensure the successful
completion of the project.

6. To provide a process for estimating project resources, time and costs: Solid
project management tools & techniques
enable the project manager to correctly estimate the project resources requirement,
completion time & likely expenditure.

7. To communicate project progress, risks and changes: The stakeholders of the

project need to be kept updated on the
project progress, hurdles encountered & changes incorporated.

8. To explore project assumptions: A good project manager has to delve deeper into
user requirements, project constraints
& management expectations to understand the hidden project requirements.

9. To prepare for unexpected project issues: Howsoever, one may be prepared there
are bound to be.a few issues which
may suddenly surface. Hence, the project manager should always be prepared with an
alternate plan.

10. To document the knowledge gained from the project: The last phase of the
project involves the documentation of all
that has been learnt at each phase in the project which will provide guidance to
other project manager in other projects.

Copyright © PROF, GUFRAN QURESHI

What is a Project?

Definition: A project can be defined as a temporary endeavour undertaken to

accomplish a unique product, services or results.

Project can be sequences of task which is planned from beginning to end bounded by
time, resources, and required result.

> Aprojectis a group of tasks that need to complete to reach a clear result. A
project also defines as a set of inputs and outputs which are
required to achieve a goal. Projects can vary from simple to difficult and can be
operated by one person or a hundred.

» Projects usually described and approved by a project manager or team executive.

They go beyond their expectations and objects, and it's
up to the team to handle logistics and complete the project on time. For good
project development, some teams split the project into
specific tasks so they can manage responsibility and utilize team strengths.

Attributes:

a. Time frame: Because a project is a temporary endeavour, it must have a definite

beginning and end. Many projects begin on a specific date

and the date of completion is estimated.

b. Purpose: An IT Project can produce any number of results such as a system, a

software package, or a recommendation based on a study.

Therefore a project’s goal must be to produce something tangible and of value to

the organization.

ce. Ownership: The project must provide something of value to an individual or

group who will own the project product after it is completed.

Determining who owns this project is not always easy.

d. Resources: IT project require time, money, people, and technology. Resources

provide the means for achieving a project’s goal and also

act as a constraint, ‘

e. Roles: IT Projects require different individuals with different skills set, they
are listed below.

1. Project Manager: She/he is responsible for ensuring that all of the project
management and technica] development processes are in place

and being carried out properly.

2. Project sponsor: The project sponsor may be the client, customer, or

organizational resources manager who will act as champion for the

project.

3. Subject matter experts: The subject matter expert may be user or client who has
specific knowledge, expertise, or insight in a specific

functional area.

4, Technical Expert: Technical expert is needed to provide a technical solution to

organization problems.
Copyright © PROF. GUFRAN QURESHI
Software projects versus other types of project copyright © PROF.

Many of the techniques of general project management are applicable to software

project management, but Fred Brooks pointed out that the

products of software projects have certain characteristics that make them

different.

One way of perceiving software project management is as the process of making

visible that which is invisible.

1. Invisibility: When a physical artifact such as a bridge or road is being

constructed the progress being made can actually be seen. With
software, progress is not immediately visible.

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

3. Flexibility: The ease with which software can be changed is usually seen as one
of its strengths. However this means that where the
software system interfaces with a physical or organizational system, it is expected
that, where necessary, the software will change to
accommodate the other components rather than vice versa. This means the software
systems are likely to be subject to a high degree of
change.

4. Conformity: Software project are based on logical work, while other are based on
physical work. Software developers have to conform
to the requirements of human clients.

Project Management versus Contract Management

Project Management:
> Project management is important because it brings leadership & direction to
projects.
> Good project management ensures that the goals of project closely align with the
strategic goals of the business.
> It ensures what is being delivered, is right, and will deliver real value against
the business opportunity.
> It ensures proper expectations are set around what can be delivered, by when, and
for how much.
> It ensures the quality of whatever is being delivered, consistently hits the
mark. :
Contract Management:
The client organization will appoint a project manager to supervise the contract.
Project manager will be able to delegate many technical oriented decisions to the
contractors.
The project manager will not be concerned about estimating the effort needed to
write individual software components.
The overall project is fulfilled within budget and on time.
Supplier side-project managers are concerned with more technical management issues.

VVWVV WV

Copyright
‘opyrigh
Activities covered by Software Project Management

Definition:- Software project management is an art and discipline of planning and

supervising software projects. It is a sub-
discipline of software project management in which software projects planned,
implemented, monitored and controlled.
> A software project is not only concerned with the actual writing of software.
>» Three successive processes
Feasibility Study, Planning, Project Execution

1, Feasibility Study
> Prospective project is worth starting
> Information is gathered about the requirements of
the proposed application.
> Requirements elicitation can at least initially be
complex and difficult.
2. Planning
> A large project would not do all detailed planning right at the beginning.
> Formulate an outline plan for the whole project a detailed one for the first
stage and’
more detailed planning of the later stages.
3. Project execution
> The execution of a project often contains design and implementation sub phases.
> Design is thinking and making decisions about the precise form of the products
that the project is to create.
> Planning and design can be confused because at the most detailed level, planning
decisions are influenced by design
decisions.

mee A AMON

Project execution
‘Categories of Software Projects Copyright

I] Custom Software Projects:

> Custom software (also known as bespoke software or tailor-made software) i is

software that is specially developed for some

specific organization or other user.

As such, it can be contrasted with the use of software packages developed for the
mass market, such as commercial off-the-

shelf (COTS) software, or existing free software.

>» Custom software development is the process of designing, creating, deploying and
maintaining software for a specific set of
users, functions or organizations.

> Custom softwareis built to fit company’s specifications and business needs and is
different from traditional off-the-shelf
software which is available to a larger audience.

» The custom-made software which is available to companies is more

secured. As the custom softwareis developed only to suit particular

Ww

enterprises, it will be used only by those individuals in the company.

> The custom-made software is more sizeable than ready-made application. ayy a
The custom-made application is developed on a long-term basis. They can —

conveniently scale this softwareto meet the business requirements.

Il] Distributed Computing Projects:

» Distributed computing is a model in which components of a

software system are shared among multiple computers to improve
efficiency and performance.

» According to the narrowest of definitions, distributed computing is limited

to programs with components shared among computers within a limited
geographic area.

Copyright © PROF. GUFRAN QURESHI

Copyright © PROF. GU RE
> Distributed computing is a computing concept that, in its most general
sense, refers to multiple computer systems working on a single problem. Distr \
buted
> In distributed computing, a single problem is divided into many parts, and ER
Cllal cl A Co mpuT i ng
each partis solved by different computers. yo
> Distributed systems are inherently scalable as they work across different wba
lial
machines and scale horizontally. Distributed systems are also inherently Cl e rs
Cia
more fault tolerant than single machines. or -
ao

III] Free Software Projects

> “Free software” means software that respects users’ freedom and
community. Roughly, it means that the users have the freedom to run,
copy, distribute, study, change and improve the software. Thus, “free
software” is a matter of liberty, not price.

>» Use: Free Software can be used for any purpose and is free of restrictions
such as license expiry or geographic limitations.

> Study: Free Software and its code can be studied by anyone, without

non-disclosure agreements or similar restrictions.

> Share: Free Software can be shared and copied at virtually no cost.

I # Free Software

>
> Improve: Free Software can be modified by anyone, and these improvements can be
shared publicly.

IV] Software hosted on CodePlex

> CodePlex was Microsoft's free, open source project hosting site, which ran from
2006 through 2017.
> CodePlex.com has been archived into this read-only, lightweight website.
> In 2012, CodePlex hosted more than 28,000 projects. Microsoft had been perceived
as an opponent of open source early
in the new century, but that has changed with the company's growing embrace of the
concept. Copyright © PROF. GUFRAN QURESHI
. GUFRAN QURESHI

Project Charter (Contract)

» A project charter is the statement of scope, objectives and people who are
participating in a project. It begins the process of
defining the roles and responsibilities of those participants and outlines the
objectives and goals of the project. The charter
also identifies the main stakeholders and defines the authority of the project
manager.

» A project charter names the project manager and defines the authority of the
project manager. It gives the project manager the
power to utilize organizational resources to accomplish the project objectives.

» The project charter is not only a tool that is used for planning projects but
also a communication mechanism that acts as a
reference. A well-planned project with an effective communication plan will
definitely bring in success for the project
undertaken at hand.

Benefits:
> Helps determine project value: help you determine if it’s worthwhile to s
ae outor Bee the project. ° Nera pages Charter
» Saves time down the road: the time you take at the beginning is time you
won’tneed to spend trouble-shooting and negotiating if you’ve already
addressed these areas in the project charter.
» Gives you budget clarity: ensure that funding is available and will be
‘released on time. Settle your spending authority and budgets prior to starting
the project.
>» Helps you give clear guidelines to your team: The milestones and criteria
for measurement give invaluable guidance to your team as you begin to brief
out the project. ,
> Inspires confidence: gives the team assurance that they’re working under an
effective and well-organized project manager.

Copyright © PROF. GUFRAN QURESHI

Elements of Project Charter

Depending on company culture and on the person ahead of writing the company
charter, the points that comprise it can

vary. Typically, however, it’s composed of the following sections:

>» Project Overview — Consists of the project name, author of the charter, creation
date, project manager, project charter
purpose, and charter version, :

» Project Details — here you can add a detailed project description which includes
the mission, the general scope of the
project, the key stakeholders, and clients.

>» Project Scope — a range of companies prefer including the project scope within
the Project Details section. However, if
the project is large enough, a completely separate section helps us better
visualize the project scope. You would also
include points such as objectives, goals, deliverables, out of scope deliverables,
benefits, assumptions, risks, and
constraints.

» Project Team Organization — here you'd include a list of all team members that
would take part in implementation. You
can also include their contact details and their role in the project.

» Project Resource Planning — this can include all resources starting from staff,
non-human resources up to finances.

» Project Communication Plan — it is generally a good idea to set up a

communication plan to consistently revise changes
and assure alignment of goals and objectives. The project rarely goes the way it’s
intended; oftentimes, you'll have to
make some changes to the project charter along the way. Meaning, you should
establish a communication plan, bi-weekly
meetings, for example, to check on whether the project is going according to the
charter or not.

» Project Timeline — it’s important to have an idea on what the timeline for your
project is. Your management, or possibly
the client, will want to know whether the project ison schedule, and a timeline is
a good way to estimate that.

» Signatories — the list of signatories to the project

Copyright © PROF. GUFRAN QURESHI

. Stakeholders Copyright © PROF. GUFRAN QURESHI

> ‘A stakeholder is either an individual, grbup or organization who is impacted by

the outcome of a project. They have an
interest in the success of the prdjéct, and can be within of outside the
organization that is sponsoring the
project. Stakeholders can have a positive or negative influence on the project.

» It includes normally the members of a project team: project managers, project

sponsors, executives, customers, or users.
If a project is small in size, the number of stakeholders can be small. However, if
it is large and expanded to a large area,
one may have a huge number of stakeholders, including communities or the general
public.
Types:

> Internal Stakeholders: As the name suggests, these are the people involved in a
project from within. They include:
Sponsor, internal customer or client(internal need of organization), project team,
program or portfolio manager,
management.

>» External Stakeholders: These stakeholders are not directly involved but are
engaged from outside and are affected by the
project outcome. They include: External customer or client(contract from external
party), end user, subcontractor,
supplier, government, local communities, media. :

Q) One of the keys to a successful project is successfully managing the

relationships aes
between everyone involved - the stakeholders. There are three processes involved:

1. Identify the Project Stakeholders: This involves identifying the people, groups,
eshte
or organizations that could impact or be impacted by a decision, activity, or Peet:
outcome of the project. ue aly

2. Analyze their potential involvement with the project: This is the process that
develops appropriate management strategies to effectively engage stakeholders Seta
throughout the project.

3. Manage their engagement with the project: This is the process that
communicates and works with stakeholders to meet their needs and expectations, peel
address issues as they occur, and support stakeholder engagement.

Setting Objectives (for Projects) —

> Objectives are the project “Road Map... “ Objectives define a set of supporting
actions to ensure the broader goals are
accomplished. Objectives are your action plan or high level road map. They are
specific steps or tasks that must be
completed to reach the goal.”
> Objectives are concrete statements describing what the project is trying to
achieve. The objective should be written at a lower
Q An example of an objective statement might be to “upgrade the helpdesk telephone
system by

>
$

>

> The objective is time-bound, and should be completed by December 31.

level, so that it can be evaluated-at the conclusion of a project to see whether it

was achieved or not. Goal statements are
designed to be vague (uncertain). Objectives should not be vague. A well-worded
objective will be Specific, Measurable,
Attainable/Achievable, Realistic and Time-bound (SMART). Baia =

December 31 to achieve average client wait times of no more than two minutes”.
Measurable
Note that the objective is much more concrete and specific than the goal statement.

The objective is measurable in terms of the average client wait times the new phone
system is Accepted
trying to achieve.

We must assume that the objective is achievable and realistic. Reasonable

Time-bound

) Objectives can often be set under three headings:

1.

Performance and Quality: In more recent years the concept of total quality
management has come to the fore, with the
responsibility for quality shared by all staff from top management downwards.

Budget: The project must be completed without exceeding the authorised expenditure.
Financial sources are not always
inexhaustible and a project might be abandoned altogether if funds run out before
completion.

Time to Completion: Actual progress has to match or beat planned progress. All
significant stages of the project must take
place no later than their specified dates, to result in total completion on or
before the planned finish date.
Copyright © PROF. GUFRAN QURESHI

The Business Case

Definition: The business case is a process to critically examine the opportunities,

alternatives, project stages and financial
investment in order to make a recommendation for the best course of action that
will create business value,

Steps for Developing the Business Case:

Step 1: Confirm the opportunity ;

Describe the situation and the business opportunity that your proposal will impact.
This will include the background to project,
the investment logic and the high-level business requirements.

Step 2: Analyse and develop shortlisted options

Identify the alternative approaches and select three or four options to analyse.
Gather information about each alternative, analyse
the options and develop the shortlisted options.

Step 3: Evaluate the options

Evaluate how the alternatives will deliver on the business objectives, then select
the preferred option, taking into account the
strategic and financial value created and the risks.

Step 4: Implementation strategy

Create the implementation plan for the preferred option, detailing how to achieve
the business objectives, who will be
accountable for each milestone, and how to mitigate the project risks.

Step 5: Recommendation ;

Confirm the recommended option. Create the business case documents and present the
business case recommendation to the
board and management team for approval to proceed.

5 Steps to Developing a Solid Business Case

Be ee cues
ea ee

Bee iT
CeCe

See ee ciills)
Peace Cry
cease Ao ee

Cree ee S

1.1 Launch the business case project 3.1 Analyse how the alternatives will

4,1 Create the implementation 5.1 Confirm the recommended option

2.1 Identify the alternative :

1.2 Confirmthe business opportunity approaches

2.2 Select three or four options to

Investment logic
analyse

1.3 Specify the high level business

requirements 2.3 Gather information about each

alternative

2.4 Analyse options and develop

shortlisted options

Chase Consulting Group

affect the business objectives plan for therecommended

option

3.2 Selectthe preferred option,

taking into. account the strategic
and financial valuecreated and
therisks

© How willyouachieve your

goal,

© Who will be accountable for

each milestone,

© How will you mitigatethe

project risks
5.2 Documentthe business case
© Project definition /scope
© Strategic benefits
© Financial benefits
© Non financial benefits
© Fitwith the corporate strategy
© Implementation approach
© Risk
© Financial analysis

5.3 Present business case for approval

Steps in Developing MOV Copyright © PROF. GUFRAN QURESHI

Definition: The first phase of a project begins with conceptualizing the project’s
goal and overall measure of success called the
Measurable Organizational Value (MOV). The Measurable Organizatioial Value (MOV) is
the goal of the project and is used to
define the value that your project will bring to your client. To provide real value
to an organization, a project must align with
and support the organization’s vision, mission, and strategy.

Steps for Developing the MOV:

1.

Identify the desired area of impact: A project can have an impact on an

organization in many different ways. (Customer,
Strategic, Financial, Operational, Social) :

Identify the desired value of the project: Once the desired area of impact is
identified, the next step involves determining
the desired value the project can bring to the organization.

Developan appropriate metric: Once there is agreement as to the value the project
will bring to the organization, the next
step is to develop a metric, or set of metric, that:

a. Provides the project team with a performance target or directive

b. Sets expectations among all stakeholders

c. Affordsa means for evaluating whether the project is a success later on.

Set a time frame for achieving the MOV: Once you have identified the area of
impact, value to the organization, and an
appropriate metric, you need to set a time frame for achieving the MOV. Keep in
mind that this time frame may not
coincide with the scheduled completion of the project work.

Verifying with stakeholders: Getting the metric value and time frame verified and
approved from the stakeholders adds
value to claims made in the business case.

Summarize the MOV ina clear, concise statement or table: Once the impact and value
to the organization are verified and
agreed upon by all the project stakeholders, the MOV should be summarized in a
single statement or table. Summarizing
the MOV provides an important chance to get final agreement and verification,
provides a simple and clear directive for the
project team, and sets explicit expectations for all project stakeholders.

Copyright © PROF. GUFRAN QURESHI

Project Success and Failure

The Best Projects:

A project was considered to be in the “Best” category if it met all of the

following criteria:

A total cost that was lower than the industry average for similar projects by 10
percent or more

An execution duration or overall cycle time that was industry average or faster

Safety performance that included no fatalities, and

No serious operational problems during startup or in the first 12 months of

operation

The Best Projects were, on average, 18 percent lower in cost, 8 percent faster in
cycle time (total length of the project) and
10 percent faster in execution.

The Worst Projects:

Triple Constraints of Project Management

1. Cost: The financial constraints of a project, also known as the project budget
2. Scope: The tasks required to fulfill the project’s goals

A project was considered to be in the “Worst” categoryif it met all of the

following criteria:

A total cost that was higher than the industry averagefor similar projects by 20
THE TRIPLE CONSTRAINT
percent or more, and

An execution or cycle time duration that was slower than industry average by 20

percent or more
The Worst Projects were, on average, 42 percent higher in cost, 49 percent slower
in

cycle time, and 29 percent slower in execution.

3. Time:The schedule for the project to reach completion SCOPE CcosT

Management & Management Control Reiger rae pean omen

Definition: Managementis a process of planning, decision making, organizing,

leading, motivation and controlling the human
resources, financial, physical, and information resources of an organization to
reach its goals efficiently and effectively.
Functions: ;

1. Planning: It is the basic function of management. According to KOONTZ, “Planning

is deciding in advance - what to do,
when to do & how to do. It bridges the gap from where we are & where we want to
be”.

2. Organizing: It is the process of bringing together physical, financial and human

resources and developing productive
relationship amongst them for achievement of organizational goals.

3. Staffing: It is the function of manning the organization structure and keeping

it manned. Staffing has assumed greater
importance in the recent years due to advancement of technology, increase in size
of business, complexity of human
behavior etc. /

4, Directing: It is that part of managerial function which actuates the

organizational methods to work efficiently for
achievement of organizational purposes. Planning

5. Controlling: It implies measurement of accomplishment against the

standards and correction of deviation if any to ensure achievement of
organizational goals.

Management Control: Management control describes the means by which Gontrotiing 7\

pe et mesty. | Organizing

the actions of individuals or groups within an organization are constrained to

perform certain actions while avoiding other actionsin an effort to achieve
organizational goals. A management function aimed at achieving defined
goals within an established timetable, and usually understood to have three
components: (1) setting standards, (2) measuring actual performance, and
(3) taking corrective action.

Staffing

Directing

Project Management Lifecycle Copyright © PROF. GUFRAN QURESHI

The project management life cycle is a series of activities that are necessary to
fulfill project goals or objectives. These activities

may go by different names, depending on the methodology, but tend to be similar in

nature.

Phases:
1. Project Goal: This is where a project starts. The purpose of this phase is to
define the project in a larger sense. Here, the
project manager starts with a kick-off meeting with a client(s) to understand the
goals and objectives and most importantly,
their expectations from it.

2. Project Plan: Once you’ ve defined all the objectives, it’s time to develop a
roadmap for everyone to follow. Itinvolves
setting goals and describing job-responsibilities to the project members. Many
project managers set S.M.A.R.T goals to
make the process achievable.

Specific: To set specific goals and’have an answer for every what, who, where,
which, when, and how.

Measurable: To define criteria that can be used to measure the success ofa goal.
Attainable: To identify what it will take to achieve those goals.

Realistic: To set goals that are actually doable and achievable in the given time.
Time-bound: To create a timeframe to achieve every goal.

3. Project Plan Execution: This is the phase when the project starts taking it
shape.
As a lot of things are happening while executing a project, maybe that’s why it’s
referred to as meat of the project. This phase is also called implementation phase.

4. Project Evaluation: Project evaluation is a systematic and objective assessment

ofan ongoing or completed project. The aim is to determine the relevance and
level of achievement.

5. Project Closure: This phase represents the completed project. It is the last
phase ee
of project management that is also called post-mortem or follow-up phase. iy <<

Initiating
Process

Planning

PROJECT \iiine
LIFECYCLE

cl Petal
Process
Executing
Peele tty
Development of Agile Copyright © PROF. GUFRAN QURESHI

Agile project management is the drocesshiy which projects can be managed atid
implemented in small chunks of work. Agile
projects deliver value in small deliveries of product, and they are called
"Features". Projects during Agile Project Management
are managed in five stages, called the Agile | Life Cycle. The stages are:
Envision, Speculate, Explore, Adapt, and Close.

Agile Phases
In general, the way that the Agile project management process works can be

summarized in the phases below: oa

1. Envision —create the product vision and scope for the customers as well as ees

determine who will be involved in the project

2. Speculate— this is an extension of the “Envision” phase where teams gather the E
a

initial broad requirements for a product/service and develop an iteration plan

based on the vision
3. Explore— work on the project deliverables with a focus on flow, aiming to get
feedback from the customer as fast as possible
4. Adapt—review delivered results and adapt as necessary to current conditions
5. Close — conclude the project, pass along key findings -
Benefits:
1. Serialized Process: Iterative approach with task broken into small increments.
(step by step)
2. Planning far in advance: Plan for what we know and we have left sufficient
allowance in our plans for what we don’t
know. (any changes that will come in future)
3. Project Timeline: It allows the development team to get feedback from the
customer throughout.
Limitations:
1. Lack of Visibility: Teams don’t realize they are behind schedule. (They have
sufficient time left as they are going fast)
2. Static Requirements: Scopeis never closed; Continual reassessment of requirement
priorities by the business.

t © PROF. GUFRAN QURESHI

Principles of Agile co

1. Satisfy the Customer: Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.

2. Welcome Change: Welcome changing requirements, even late in development. Agile

processes harness change for the
customer's competitive advantage.

3. Deliver Frequently: Deliver working software frequently, froma couple of weeks

to a couple of months, witha
preference to the shorter timescale.

4. Work Together: Business people and developers must work together daily
throughout the project. It makes sense for the
customer to become part of the team.

§. Build Projects: Build projects around motivated individuals. Give them the
environment and support they need, and trust
them to get the job done.

6. Face-To-Face Time: The most efficient and effective eaeihed of conveying

information to and within a development team
is face-to-face conversation.

7, Measure of Progress: Working software is the primary measure of progress. When

you make working software the
primary measure of progress you promote it to the primary focus of the project.

8. Sustainable Development: Agile processes promote sustainable development. The

sponsors, developers, and users should
be able to maintain a constant pace indefinitely

9, Continuous Attention: Continuous attention to 5 technival excellence and good

design enhances agility. While an elegant
design is meaningful even more valuable is a solution that will span the test of
time.

10. Keep It Simple: Nearly 30% of the functionality we build is seldom or never
rused. Agile is ruthless about cutting
functionality that does not lend value.

11. Organized Teams: The best architectures, requirements, and designs emerge from
self-organizing teams, Self-organizing
teams that are cross functional as well.

12. Reflect for Effectiveness: At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts
its behavior accordingly. We've all been on projects that end with an AAR, After
Action Review. copyright @ pror. GUFRAN QURESHI
Keys Agile SDLC Model Traditional SDLC Model
oo. The model is very flexible and can easily adapt the | Such models lack
flexibility and it is
Model Principle 4 ; : 8: 5 j ‘
project to the customer’s needs and expectations. | challenging to implement
changes in a project
It is suitable for projects of all sizes — from small | It can be used for all
types of project. However,
Project Size to large-scale. All can benefit from the flexible it makes little
allowance for human errors and

Agile SDLC model.

changes in development later are challenging.

Success Measurement

Successful work is measured by the delivered

working software.

Success is evaluated by conformity to the

original plan.

Adaptability

The changes are welcomed and accepted at any

stage of project development

It is challenging to accept changes later on in

the development process.

Documentation

Agile doesn’t require a lot of documentation.

Traditional SDLC models require intensive

documentation.

Iteration Cycles

Has many iteration cycles — as many as needed for

the product.

The number of iterations is limited.

Original Planning

There is minimal planning required in the pre-

development phase, as any changes can be made
later on in the development process.

Planning should be completed before the

development starts, as changes are difficult to
make in later stages of development.

Ch-2 Project Evaluation and Programme Management

The Business Case:

Copyright © PROF. GUFRAN QURESHI

Definition: The business case is a process to critically examine the opportunities,

alternatives, project stages and financial
investment in order to make a recommendation for the best course of action that
will create business value.
Feasibility studies can also act as a “business case’
(| Provides a justification for starting the project
L) Should show that the benefits of the project will exceed development,
implementation and operational costs
Needs to take account of business risks
A business case captures the reasoning for initiating a project or task. It is
often presented in a well-structured written
document, but may also come in the form ofa short verbal agreement or presentation.
A business case is the justification for some activity (e.g. a project) undertaken
by your organisation. It weighs up the
timescales, costs and risks of doing the activity against the benefits to be
gained. Think of it as weighing up the pros andcons
and then taking a sensible decision. Therefore, business case also known as Cost-
Benefit analysis.

Why have a business case?

* Projects should not just start on a whim or because of vanity— although a lot of
money has been wasted over the years

on such projects.

* For business organisations, justification fora project usually takes a commercial

formi.e. evaluating how much money
could be made from the investment. For example, investing money in developing a new
software app to bring first to
market, might be deemed to bring certain monetary benefits (in terms of sales)
which exceeds the costs of investment.

JRESHI
Copyright © PROF. GUFF
Project Portfolio Management Copyright © PROF. GUFRAN QURESHI

Definition: Project portfolio management (PPM) refers to a process used by project

managers and project management
organizations (PMOs) to analyze the potential return on undertaking a ptoject.

It is the centralized management of the processes, methods, and technologies used

by project managers and project
management offices (PMOs) to analyze and collectively manage current or proposed
projects based on numerous key
characteristics.

Objectives:

* The need to create a descriptive document, which contains vital information such
as name of project, estimated timeframe,
cost and business objectives.

* The project needs to be evaluated on a regular basis to ensure that the project
is meeting its target and stays in its course.

* Selection of the team players, who will work towards achieving the project's
objectives.

Benefits:

* Greater adaptability towards change.

* Constant review and close monitoring brings about a higher return.

* Management's perspectives with regards to project portfolio management is seen as

an ‘initiative towards higher return.
Therefore, this will not be considered to be a detrimental factor to work.

* Identification of dependencies is easier to identify. This will eliminate some

inefficiency from occurring.

* Helps to concentrate on the strategies, which will help to achieve the targets
rather than focusing on the project itself.

Copyright © PROF. GUFRAN QURESHE

Copyright © PROF, GUFRAN QURESHI

Evaluation of Individual Projects

Definition: It is the process of evaluating individual projects to select the ones

to be implemented, so that the broader
objectives of the organization can be fulfilled. The criteria used for selecting a
project are similar to the criteria used for
making a choice in any other aspect of business.

The models to help in deciding on projects are sophisticated but will represent
only a part of the reality. The decision will
ultimately have to be taken by the entrepreneur or the manager, and these models
will only aid the decision-making process.

1.Profitability: The most commonly used metric to select projects is their

profitability. Some entrepreneur would like to use
the rate of return or the discounted cash flows as their criteria of choice. Many
others prefer to use the payback period as the
metric to compare projects.

2. Competitive Necessity: This is the priority when the project is chosen based on
what seems most essential to maintain the
company’s competitive position in the market. ,
3. Operating Necessity: Sometimes, a project has to be undertaken because it is
vital to continue the business operations of
the company.

4, Scoring: To overcome the shortcomings of using just profitability for selecting

a project, a number of decision criteria are
taken into account in a scoring model. Scoring models can vary in their complexity
and information requirements .

Copyright © PROF. GUFRAN QURESHI

Copyright © PROF, GUFRAN QURESHI

Cost-Benefit Evaluation Techniques

Definition: Cost-benefit analysis (CBA) is the standard way of evaluating the

economic benefits of any project. It is
a technique used to compare the total costs of a programme / project with its
benefits, using a common metric (most
commonly monetary units). This enables the calculation of the net cost or benefit
associated with the programme.

» Itis one of the important and common way of carrying “economic assessment” of a
proposed information system.
» This is done by comparing the expected costs of development and operation of the
system with its benefits.
> So it takes an account:

* Expected cost of development of system

* Expected cost of operation of system

+ Benefits obtained

» Assessmentis based on:

* Whether the estimated costs are executed by the estimated income.

* And by other benefits

>» For achieving benefit where there is scarce resources, projects will be
prioritized and resource are allocated effectively.

> The standard way of evaluating economic benefits of any project is done by “cost
benefit analysis”

Copyright © PROF. GUFRAN QURESHI

* Cost benefit analysis comprises of two steps:

* Step-1: identifying and estimating all of the costs and benefits of carrying out
the project.
* Step-2: expressing these costs and benefits in common units.
* Step-1:
— Itincludes
* Development costofsystem. -
* Operating cost of system.
* Benefits obtained by system.

— When new system is developed by the proposed system, then new system should
reflect the above three as same as proposed system.

+ Example: sales order processing system which gives benefit due to use of new
system.

° Step-2:
— Calculates net benefit.
— Net benefit = total benefit - total cost.
— (cost should be expressed in monetary terms).

Copyright © PROF. GUFRAN QURESHI

Three types of cost:
* Development costs: includes ane and other employment weet tof staff involved.

* Setup costs: includes the cost of implementation of system stich as hardware, and
also file conversion, recruitment
and staff training.

* Operational cost: cost require to operate system, after it is installed.

Three categories of benefits:

1) Direct benefits: directly obtained benefit by making use of/operating the

system.
Example: reduction of salary bills, through the introduction of a new, computerized
system.

2) Assessable indirect benefits: these benefits are obtained due to updation /

upgrading the performance of current
system. It is also referred as aaa benefi ts”.
Example: “use of user — friendly screen”, which promotes reduction in errors, thus
increases the benefit,

3) Intangible benefits: these benefits are longer term, difficult to quantify. It

is also referred as “indirect benefits”.
Example: enhanced job interest leads reduction of staff turnover, in turn leads
lower recruitment costs.

Copyright © PROF. GUFRAN QURESHI

Cash Flow Forecasting Cone PROF. SUPRA. QURESHI

> Acash flow forecast is a plan that shows how much money a business expects to
receive in, and pay out, over a given
period of time.
>» Acash flow forecast is a projection of an organisations future financial
position based on anticipated payments and
receivables. The process of deriving a cash flow forecast is called cash flow
forecasting.
> The main goal ofa cash flow forecasting is to assist with managing liquidity
within an organisation and ensuring that the
business has the necessary cash to meet its obligations and avoid funding issues,
essentially better management of
working capital. Underneath the high level goal of liquidity management, there are
often a number of reasons why
companies set up a cash flow forecasting process, these include:
+ Covenant forecasting and half/ full year reporting visibility.
« Interest and debt reduction.
+ Short term liquidity planning.
* Long Term Planning / Budgeting Purposes (e.g. 3 year plan)
> Acash flow forecast is a document that helps estimate the amount of money that'll
move in and out of your business. It
also includes your projected income and expenses. Cash flow forecasts typically
cover the next 12 months, but can also be
used for shorter periods of time — like a week or a month.
Year Project A Project B Project C
0 (Year the project is implemented) -5,00,000 -7,00,000 -6,00,000
1 2,00,000 2,00,000 1,50,000
2 2,00,000 3,00,000 2,50,000
3 2,00,000 3,25,000 2,50,000
Net Profit 1,00,000 1,25,000 50,000, .vicht clpROF. GUFRAN QURESHI
Copyright © PROF. GUFRAN QURESHI

Cost Benefit Evaluation Techniques

It consider

* the timing of the costs and benefits

* the benefits relative to the size of the investment

Common method for comparing projects on the basic of their cash flow forecasting.

1) Net profit

2) Payback Period

3) Return on investment
4) Net present Value

5) Internal rate of return

I] Net Profit

» Net Profit calculated by subtracting a company's total expenses from total income
showing what the company has
earned (or lost) in a given period of time (usually one year). It also called net
income or net earnings or bottom line.

Net profit=totalincomes-total costs

» Net profittells you your true bottom line — how much money you’re actually left
with at the end of the day
» This is a simple method of calculating the total benefits of the projects.
However, this method does not show profit
relative to the size of the investment.
E.g. (Refer Cash Flow Forecasting)

Copyright © PROF. GUFRAN QURESHI

Copyright © PROF. GUFRAN QURESHI

II] Payback/Payout Period

Definition: The payback period also called the payout method is the time taken to
recover the initial investment or is the
length of time required for cumulative incoming returns to equal the cumulative
costs of an investment.

The payback period refers to the amount of time it takes to recover the cost of an
investment.

Payback period is the time required to recover the initial cost of an investment.
It is the number of years it would take to
get back the initial investment made for a project.

PBP= Year previousto BEP + Total Cash Outflow — Cumulative cash inflow previous to
BEP
Cash inflow during breakeven year
x 12 months

Advantages

* Itis simple and easy to calculate.

* Itis alsoa seriously flawed method of evaluating investments

Disadvantages

* It attaches no value to cashflows after the end of the payback period.

* It makes no adjustments for risk.

* Itis notdirectly related to wealth maximisation as NPV is.

* It ignores the time value of money.

* The "cut off" period is arbitrary.

Copyright © PROF. GUFRAN QURESHI

)+

Ex; M/s A Ltd has to invest Rs. 5 lakhs in project A or Project B. The estimated
inflows of each project are as follows:

Year Project A Project B

1 1,80,000 2,50,000
2 : 1,10,000 1,50,000
3 1,50,000 1,00,000
4 1,80,000 1,10,000
Solution:
Year Project ACIF Cumulative Project B Cumulative
| 1,80,000 1,80.000 2,50,000 2,50,000
2 1,10,000 2,90,000 1,50,000 4,00,000
3. 1,50,000 4,40,000 1,00,000 » $,00,000
4 1,80,000 6,20,000 1,10,000 6, 10,000
PBP= Year previoustoBEP + Total Cash Outflow —Cumulative cash inflow previous to
BEP x12 months
Cash inflow during breakeven year
ProjectA= 3 years + 500000 — 440000 x12 months = 3 years4 months(or)3.33 years
180000
Project B= 3 years Copyright © PROF. GUFRAN QURESHI

Copyright G PROF, GUFRAN QURESHI

III] Return on Investment (ROT)

Definition: The return on investment also called the accounting or average rate of
return (ROR) is a performance measure used to
evaluate the efficiency of an investment or compare the efficiency of a number of
different investments.

It provides a way of comparing the net profitability to the investment required.

Ahigh ROI means the investment's gains compare favourably to its cost. As a
performance measure, ROI is used to evaluate the efficiency
of an investment or to compare the efficiencies of several different investments.

ROI(%)= Avg. Net Profit, 199

/ Cash outflow
Advantages
* Itrelates net income to investments made in a division giving a better measure of
divisional profitability.
* ROl helps in making comparison between different business units in terms of
profitability and asset utilization.

Disadvantages
* Jt takes no account of the timing of the cash flows.

* Rate of returns bears no relationship to the interest rates offered or changed by

bank.

Copyright © PROF. GUFRAN QURESHI

Ex: M/s A Ltd has to invest Rs. 5 lakhs in project A or Project B. The estimated
inflows of each project are as follows:

Year Project A Project B

1 1,80,000 2,50,000
2 1,20,000 1,50,000
3 2,50,000 1,00,000
4 1,80,000 1,10,000
Solution:
Year Project ACIF Project B CIF
I 1,80,000 2,50,000
2 1,20,000 1,50,000
3 2,50,000 1,00,000
4 1,80,000 1,10,000
Total 7,30,000 6,10,000
ROI(%)= Avg. Net Profit 100
Cash outflow
ProjectA(%)= _730000/4 100 =36,5% — ProjectB(%)= 6100004 , 199 =30.5%

Copyright © PROF. GUFRAN QURESHI

IV] Net Present Value (NPV)

> Net present value is used in Capital budgeting to analyze the profitability of a
project or investment. It is calculated by
taking the difference between the present value of cash inflows and present value
of cash outflows over a period of
time.

» As the name suggests, net present value is nothing but net off of the present
value of cash inflows and outflows by
discounting the flows at a specified rate.

» If the present value of the cash inflows is greater than the present value of the
cash outflows, the project is
acceptablei.e. NPV>0, accept and NPV<0, reject.

NPV= Present Value CIF — Present Value COF

Advantages

1. Net present value method is a tool for analyzing profitability of a particular

project. It takes into consideration time
value of money.

2. Net present value takes into consideration all the inflows, outflows and risk
involved. Therefore NPV is a
comprehensive tool taking into consideration all aspects of the investment.

Disadvantages ;

1. The main limitation of Net present value is that the rate of return has to be
determined. Ifa higher rate of return is
assumed, it can show false negative NPV, also if a lower rate of return is taken it
will show the false profitability of
the project and hence result in wrong decision making.

2. NPV cannot be used to compare two projects. Considering the fact that many
businesses have a fixed budget and
sometimes have two project options, NPV cannot be used for comparing the two
projects because of the size of the
projects. Copyright © PROF. GUFRAN QURESHI
[A

Ex: M/s A Ltd has to invest Rs. 5 lakhs in project A assuming discouiting factor
15%. The estimated inflows of project are
as follows:

Year Project A
1 1,00,000
2 2,00,000
3 1,50,000
4 2,00,000
Solution:
Year Project ACIF PV@ 15% PVCIF
1 1,00,000 0.8696 86960
2. 2,00,000 0.7561 151220
3 1,50,000 0.6575 98625
4 2,00,000 0.5717 114340
Total 451145
NPV= Present Value CIF — Present Value COF
ProjectA= 451145-—500000 = (48855)

Comment: Since NPV is negative, the project is not feasible. Copyright © PROF,
GUFRAN QURESHI

Copyright © PROF. GUFRAN QURESHI

V] Internal Rate of Return (IRR)

> Internal rate of return (IRR) is the discount rate that makes the net present
value of all cash flows (both positive and
negative) equal to zero for a specific project or investment.
> In other words, if we computed the present value of future cash flows from a
potential project using the internal rate
as the discount rate and subtracted out the original investment, our net present
value of the project would be zero.
» Once the internal rate of return is determined, it is typically compared to a
company’s hurdle rate or cost of capital. If
the IRR is greaterthan or equal to the cost of capital, the company would accept
the project as a good investment.
intemal Ra RetUrTE
Cash Flaws Year 1 : Cash Flaws Year 2 ‘ Cash Flaws Year 3 . Cash Flaws Year 4 -
Initial . é
( (asiRRy (1+IRR)? (1+IRR}? (IRR) ) Investment
Advantages
1. The first and the most important thing is that the internal rate of return
considers the time value of money when
evaluating a project.. ,
2. The mostattractive thing about this method is that it is very simple to
interpret after the IRR is calculated. If the IRR
exceeds the cost of capital, then accept the project, but not otherwise.
Disadvantages
1. IRR assumes that the cash flows are reinvested at the same rate as the project,
instead of the cost of capital. Hence,
IRR may not give a true picture of the profitability.
2. IRR works only for investments that have an initial cash outflow (the purchase
of the investment) followed by one or
more cash inflows. IRR can't be used if the investment generates interim negative
cash flows.

Copyright © PROF. GUFRAN QURESHI

Example of Calculating IRR

It might be easier to look at an example than to keep explaining it. Let’s look at
Tom’s Machine Shop. Tom is considering
purchasing a new machine, but he is unsure if it’s the best use of company funds at
this point in time. With the new
$100,000 machine, Tom will be able to take on a new order that will pay $20,000,
$30,000, $40,000, and $40,000in
revenue.

Solution:
Let’s calculate Tom’s minimum rate. Since it’s difficult to isolate the discount
rate unless you use an excel IRR calculator.

You can start with an approximate rate and adjust from there. Let’s start with 8
percent.

Let ET

( $20,000 530,000 $40,000 $40,000

+

+ + ) - $200,000 = $5,393
(148%) (148%) (148%5)* (24856)*

As you can see, our ending NPV is not equal to zero. Since it’s a positive number,
we need to increase the
estimated internal rate. Let’s increase it to 10 percent and recalculate.
: Intamal 3 im

$20,000 $30,000 $40,000 $40,000

( + + + ) - $100,000 = a

{1+10%}' (1410%)? {(1410%7 (1+10%)*

As you can see, Tom’s internal return rate on this project is 10 percent. He can
compare this to other investing
opportunities to see if it makes sense to spend $100,000 on this piece of equipment
or investment the money in
another venture.

Copyright © PROF. GUFRAN QURESHI

Risk Evaluation Copyrig ROF. GUFRAN QURESHI

Definition: Risk evaluation is the process of identifying and measuring risk. It is

a fundamental business practice that can be applied to
investments, strategies, commercial agreements, programs, projects and operations.

1. Risk evaluation is meant to decide whether to proceed with the project or not,
and whether the project is meeting its objectives.
2. It is the determination of risk management priorities through establishment of
qualitative and/or quantitative relationships between

benefits and associated risks.

3. Risk occurs: a) When the project exceed its original specification. b)
Deviations from achieving it objectives and so on.

Basic concepts in Risk Management:

J| What is Software Risk?

1. Software risk encompasses the probability of occurrence for uncertain events and
their potential for loss within an organization.

2. Risk management has become an important component of software development as

organizations continue to implement more
applications across a multiple technology, multi-tiered environment. ,

3. Typically, software risk is viewed as a combination of robustness, performance

efficiency, security and transactional risk propagated
throughout the system.

4. Software risk exists because the

future is uncertain and there are
many known and unknown
things that cannot be
incorporated in the project plan.

5. A software risk can be of two PROPAGATION —

types:- i . . : : a
a. lateral risks that are within thie Critical failures in Performance Security
Risk across user Risk propagated
. production issues breaches transaction by arch. hotspot

control of the project manager. | >

b. External risks that are beyond

the control of project manager. User experience | Customer satisfaction | Brand

equity | IT productivity
II] Concept of Proactive and Reactive risk strategies: ie eae mma

a. Reactive risk strategies:

1. Reactive tisk strategy is a response based risk management approach, which is

dependent on accident evaluation and audit
based findings.

2. me Strategy attempts to reduce the tendency of the same or similar accidents

which happened in past being repeated in

uture.

3. This strategy solely depends on past accidental analysis and response.

This strategy does not have any predefine layoutrules. .

5. These risks have a smaller impact on the project.

PROACTIVE
Focus on the project's strategic vision
b. Proactive risk strategies:

Proactive risk strategy is an adaptive, closed-loop Mm

Vv
feedback control strategy based on measurement
and observation. Proactive task management Pasasityy people management
+ ~ Managing risks ~ Building relationships
2. This strategy attempts to reduce the tendency of ~ Defining and planning work =
Bike angen /
any accident happening in future by identifying the task rocus | “ASsung quality a
| peosLe root
boundaries of activities, where a breach of the ‘edna trough >
boundary can lead to an accident. Au -based |, | rea
3. This strategy combines a mixed method of past,
sha 4 Reactive task management Reactive people management
present and future prediction before finding __ | + Resolving urgent issues -
Managing people-related
solutions to avoid risks. - Fitwightng, : a imerpereonel
4. . This strategy have a predefine layout rules.
5. These risks have a great impact on the project
deployment. REACTIVE
Focus on immediate issues
é Copyright © PROF. GUFRAN QURESHI
Il] Risk Management (RM) Process ~

> Risk management process is nothing buta series of steps that help identify and
migrate the risks for the successful closure of
a project. If done correctly and sincerely, construction risk management will
reduce not only the likelihood of an event
occurring, but also the magnitude of its impact.

> Inthe simplest terms, Risk management process is taking preemptive actions to
avoid and minimize any kind of jeopardy to a

projectin future.

Process:

1. Risk Identification: Risk identification is the process of determining which

risks may affect the project and documenting
their characteristics. The key benefit of this process is documentation of existing
risks and the knowledge and skills offered
by the project team anticipate risk events.

2. Risk Assessment/ Analysis: After all the probable risks have been identified,
their valuation is done based on qualitative
and quantitative methods. With risk assessment method, available information is
used to extricate the frequency of
occurrence and the level of consequences in risk management.

3. Risk Response: After identification and assessment of the risks are done,
available options to avert the risks are marked and
discussed in case they ever crop up in future. Risk response is further
subcategorized into Risk avoidance, Risk transfer, risk
mitigation and risk acceptance depending upon the nature of the risks.

4, Risk monitoring and control: Risk

monitoring and control is the process
of identifying, analyzing, and planning
for newly discovered risks and Pre
managing identified risks. Monitoring Identifiation fy Risk Assessment
and control is done throughout the life
of the project.

Risk monitoring
and control

Risk Response
Risk Identification Copyright © PROF. GUFRAN QURESHI

Definition: Risk identification is the process of determining which risks may

affect the project and documenting their
characteristics. The key benefit of this process is documentation of existing risks
and the knowledge and skills offered by
the project team anticipate risk events.

Process:

There are five core steps within the risk identification and management process.
These steps include risk identification, risk

analysis, risk evaluation, risk treatment, and risk monitoring.

1. Risk Identification: The purpose of risk identification is to reveal what,

where, when, why, and how something could
affect a company’s ability to operate. For example, a business located in central
California might include “the possibility of
wildfire” as an event that could disrupt business operations.

2, Risk Analysis: This step involves establishing the probability that a risk event
might occur and the potential outcome of
each event. Using the California wildfire example, safety managers might assess how
much rainfall has occurred in the past
12 months and the extent of damage the company could face should a fire occur.

3. Risk Evaluation: Risk evaluation compares the magnitude of each risk and ranks
them according to prominence and
consequence. For example, the effects of a possible wildfire may be weighed against
the effects of a possible mudslide.
Whichever event is determined to have a higher probability of happening and causing
damage, it would rank higher.

4. Risk Treatment: Risk treatment is also referred to as Risk Response Planning. In

this step, risk mitigation strategies,
preventative care, and contingency plans are created based on the assessed value of
each risk. Using the wildfire example,
risk managers may choose to house additional network servers offsite, so business
operations could still resume if an onsite
server is damaged. The risk manager may also develop evacuation plans for
employees.

5. Risk Monitoring: Risk management is a non-stop process that adapts and changes
over time. Repeating and continually
monitoring the processes can help assure maximum coverage of known and unknown
risks..

Risk Identification Techniques / Tools Copyright © PROF. GUFRAN QURESHI

Techniques:

There are several tools available that can help the project manager in identifying
risks.

1. Documentation Reviews: The standard practice to identify risks is reviewing

project related documents such as lessons .
learned, articles, organizational process assets, etc.
2. SWOT: SWOT, or strengths, weaknesses, opportunities, threats, is another tool to
help with identifying risks. Begin with
strengths and determine what those are as related to the project (though this can
work on ari organization-level, too). Next,
list the weaknesses or things that could be improved or are missing from the
project. This is where the likelihood of
negative risk will raise its head, while positive risk come from the identification
of strengths. Opportunities are another
way of referring to positive risks and threats are negative risks. '-

3. Brainstorming: Brainstorming is done with a group of people who focus on

identification of risk for the project. A
brainstorming session is one in which the project team sits together and thinks up
with as many risks as possible.

4. Delphi Technique: A team of experts is consulted

anonymously, A list of required information is sent to experts,
responses are compiled, and results are sent back to them for
further review until a consensus is reached.

5. Assumption Analysis: Identification of different assumptions

' of the project and determining their validity, further helps in

identifying risks for the project.

6. Root Cause Analysis: Root causes are determined for the

identified risks. These root causes are further ysgd to identify
additional risks. -
23

Risk Assessment Copyright © PROF. GUFRAN QURESHI

Definition: Risk assessment is a step in 4 risk management procedure. Risk

assessment is the determination of quantitative or
qualitative value of risk related to a concrete situation and a recoghizéd threat.
Risk assessment involves measuring the
probability that a risk will become a reality. <

The procedure for analysis is to conduct the qualitative analysis and once the risk
qualifies then quantitative analysis is carried
out.

1]
1.

2.

uo

- aS a percentage (0% to 100%) or odds (0 to 1).

II] Quantitative Risk Analysis:

1.

we

Qualitative Risk Analysis:

Qualitative risk analysis is the process of assessing individual project risk

characteristics - the probability of occurrence and
the impact they would have on a project if happening - against a scale.

The main purpose of the qualitative risk analysis

is prioritizing risks according to their probability
and impact. A project can be exposed to a large
number of different risks.

Qualitative risk analysis is carried out using a}

risk matrix also called as a probability-impact
matrix.

The scale used for the analysis groups project

risks into three or more categories according to
their impact, such as low, medium and high.

The risk can impact numerous project elements:

budget, schedule, deliverables, scope or
available resources. The risk probability can be
evaluated using the same categories or expressed

Each threat and opportunity will be further looked at for quality of data available
and the risk ratings imnarted.
Project Risk (Threat and Opportunity) Matrix (
‘Thistwchniquehelrain

Probability Negligible Minor Moderate Significant Severe

(81-100)%
(64-80)%
(41-60)%

. . . (21-40)%
The scale can be customized to fit organizational

needs and then used across all projects within an

+ yt : (1-20)%
organization for consistency.

Copyright © PROF. GUFRAN QURESHI

Quantitative risk analysis is a numeric estimate of the overall effect of risk on

the project objectives such as cost and
schedule objectives. The results provide insight into the likelihood of project
success and is used to develop contingency
reserves.

It uses verifiable data to analyse the effects of risk in terms of cost overruns,
scope creep, resource consumption, and
schedule delays.

Quantitative Risk Analysis uses available relevant and verifiable data to produce a
numerical value which is then used to
predict the probability (and hence, acceptability) ofa risk event outcome.

Main advantages of a quantitative approach is to determine the probability of

achieving a specific project objective.

A ranking of risks based on their probability and quantum impact is created. .

Project communication plan: Risk status needs to be communicated to all those

concerned. The identification, analysis
and action needs to be communicated.

Enterprise risk procedure: Organizations may devise their own rules, procedures and
policies when it comes to dealing
with risks. In such cases the project manager will be required to follow these
rules.

Organizational process assets: There are chances that the organization may have
implemented a similar project in the past.
In such case, the project plan back then may prove to be useful in identifying and
managing risks.

Cost-Benefit Analysis and Risk Analysis

iF
2.

A cost-benefit analysis (CBA) is the process used to measure the benefits of'a
decision or taking action minus the costs
associated with taking that action.

A CBA involves measurable financial metrics such as revenue earned or costs saved
as a result of the decision to pursue a
project.

A CBA can also include intangible benefits and costs or effects from a decision
such as employee morale and customer
satisfaction.

CBA provides a sophisticated approach to the evaluation of risk. This approach

considers each possible outcome and the
probability of it occurring and the corresponding value of its outcome. :
Risk Profile Analysis copy

A risk profile is an evaluation of an individual's willingness and ability to take

risks. It can also refer to the threats to which -
an organization is exposed. A risk profile is important for determining a proper
investment asset allocation for a portfolio.
Organizations use a risk profile as a way to mitigate potential risks and threats.

A risk profile identifies the acceptable level of risk an individual is prepared

and able to accept. A corporation's risk profile
attempts to determine how a willingness to take on risk (or an aversion to risk)
will affect an overall decision-making
strategy. The risk profile for an individual should determine that person's
willingness and ability to take on risk. Risk in this
sense refers to portfolio risk.

. Risk Capacity: Risk capacity is the quantitative measure of taking a risk. It

maps your current and future financial position which includes factors like
income, savings, expenses, and liabilities. With these factors evaluated, the rate
of returns required to reach your Financial goals is determined. In simple words,
it is the level of the financial risk you can think of affording.

Risk Required: Risk required is determined by your risk capacity. It is the risk
associated with the returns needed to reach your financial targets with available
resources. Risk required educates you about what you could potentially be
taking on with a certain investment. It gives you an honest perception and a
clear picture about the type of the risk you are about to take.

. Risk Tolerance: Risk tolerance isthe level of risk you are comfortable with. It
is simply your willingness to accept the fluctuations in the market that may or
may not occur in order to achieve your financial objectives. ,

Risk Required

Risk
Profile

Decision Trees

. Adecision tree analysis is a specific technique in which a diagram (in this case
referred to as a decision tree) is used for the
purposes of assisting the project leader and the project team in making a difficult
decision.;

. In project management, a decision tree analysis exercise will allow project

leaders to easily compare different courses of
‘action against each other and evaluate the risks, probabilities of success, and
potential benefits associated with each.
. The decision tree analysis technique allows you to be better prepare for each
eventuality and make the most informed
choices for each stage of your projects.

It’s important to note that a proper decision tree has four main elements: decision
nodes, chance nodes, end nodes, and:
branches. Let’s briefly explore each of these individually.

Decision Nodes: A decision node, represented on our decision tree diagram as a

square, indicates a choice that needs to
be made.

J QURESHI

Chance Nodes: A circle represents a chance : a ean [4

node and is used to signify uncertain

outcomes. These nodes are used when rasan ages

results are not guaranteed. Leconte caine

End Nodes: End nodes, like the name suggests, Cost =- $50,000 t-4
represent the end of a diagram and illustrates Prctoppeoenit

a final outcome. 5 if

Branches: Lastly, we have branches. Branches ; 20% fuse bocpoe +4

are what connect the nodes together. Each NoPrototype °
branch represents a potential choice and Cost = $0

should be clearly labeled , 80%

Failure Li

Cost = ~$250,000
KD
UI

Programme Management

Definition: Program management or progtaitlme management is the probéss of managing

several re|

intention of improving an organization's perforinance. 7

> Program Management may provide a layer above the man

defining them in terms of their objectives and providing an

> Programme Management enables the successful implementati

Overarching approach to projects and project delivery acros

Benefits:

Copyright © PROF. GUFRAN

Puts control back in your hands. Our Programme Managers ensure that your

that each project is controlled, thereby minimising any risks,

Makes the best use of your resources. A Programme Manager fj)

holds a view of how all people are being utilised, and is able to plan

activities around availability to best maximise everyone's time,

Gives you consistency across projects. Every Project Manager

[|

brings their own flavour to their work, and it is easy for a single
project to operate in isolation from the rest of your business.
im Methodology Fi

| shee |
i B
: :
t Resourcing
I .
He Dependencies
Giclees ratty

overall costs, by making best use of resources, sharing information

across projects, aligning deliverables and cross project dependencies
and minimising overall risk.

Maximise your benefits. The Programme Manager will actively

take responsibility for ensuring that the scoped benefits are realised.

Project

Project Project Project

Project Vs Program , Copyright © PROF, GUFRAN QURESHI
Area Project Management Program Management
Focus Single objective Business strategy
Narrow Wide-ranging, cross-
poe functional
ke decisions
ined in advance Used to ma
ee doce alte completion Accrue during the programme
Many , many initially
Beitelicce Few, clearly defined Ts

d
AMasserci-me Clearly defined Loosely define

To be avoided Regarded as inevitable

Change

Sicesscaee Time, budget, specification Mission, cash-flow, ROI

Factors , |
macclal Specific, detailed, bounded _| High-level and evolving
Programme Management Framework

Copyright © PROF,

GUFRAN QURESHI

Definition: Program management or programme management is the process of managing

several related projects, often with the intention of

improving an organization's performance.

» Programme management is a technique that allows organisations to run multiple,

related projects concurrently to obtain significant benefits

from them as a group. :

» A project management framework consists of the processes, tasks, and tools used
to take a p
key components required for planning. managing. and governing projects.
There are cight important areas in the programme management framework:

roject from start to finish. It encompasses all the

Programme Management Framework

1. Vision: Vision is the high level strategy or idea to drive the organisation
towards a
goal, benefit or other desired outcome. j I | i
2, Aims and objectives: The aims and objectives is a more detailed statement that
Programme Project areca) Mua csae Mites
explains exactly what is required. This provides a point of reference to go back to
ED Ls ee
when renewed focus is required.
3. Scope: The scope gives boundaries to the programme explaining what exactly it is
that will be delivered. Vision
4, Design: Design is the way in which the projects that make up the programme are
put i's eye
together. In this process the programme manager considers which projects have nee
dependencies on others, therefore which should come first, can run concurrently,
and Scope i
those that come last. 2 |
5. Approach: The approach is the way the programme will be run, It is dependent ong
Besign (ie taye i
many factors and it is left to the skill of the programme manager to decide the
most Approach . a
effective way.
6. Resource management: Resource management looks at the scheduling and wane a
allocation of resources. Short term and longer-term views should be taken.
7. Responsibilities: Responsibilities identifies and allocates responsibility for
each area Responsibilities
of the programme. Every member of the programme must clearly understand his or
silocaepmors
‘ Benetits Realisation
her roles and the roles of the other team members.
8. Benefits realization: Benefits realisation is the process at the end of the
programme

by which the benefits identified at the beginning ofthe programme and measured.

Stages in Programme Management

Timetine

Copyright © PROF. GUFRAN QURESHI

There are four important stages in the programme management. These stages take the
programme from initiation, based on strategy and a desire

for change, right through to the final realisation of a defined business objective
or benefit,

1, Programme Identification: This is a high level process where the strategy

Programme Management Stage Mapping

and direction of the organisation are decided. It is from this that the

programmes required to realise these strategies are determined. A document :

for each programme is produced outlining the business case, alignment to
strategy. scope and the expected business objective or benefits. ——— .
2. Programme Planning: The planning stage is where the design of the ed a
programme takes place. The programme manager in establishing the | Identification
programme will: | “vision, She
i, Define clear objectives. “scope ° mee
ii Agree an approach. a
iii, Agree roles and responsibilities with the team.
iv. Set-up communication channels. pierre
v. Agree priorities of the projects that make up the programme. Q cee
vi. Complete project planning. . el] - approach
vii. It is important at this stage to identify adequate levels of resource for the
#f “management
early projects and identify the requirements for later projects. HO | cc
cesponsibliaies
3. Programme Delivery: At this stage, the individual project managers run J} |
the identified projects. The programme manager's responsibility at this stage] |
is to monitor progress, assess risks and report progress to the steering |
committee or leadership.
4. Programme Closure: Like projects, programmes have a finite life and are
closed once they achieve their defined business objective or benefit. Before z aos
=
the programme is closed. the programme manager must ¢lemionstrate to the J |
Programme Closure
steering committee or leadership that the desired benefits have been ~ benefits
realisation

realised, often called 'benefits realisation’.

Project
Manager

Project

Project
Manager

Manager

ako iss

Project
Manager

Wels

Programme Delivery

= monitor & contro!

health check

~ progress reporting
-risk management

= issues management
Timeline

[RSE a anthers oti

| | Add the twa timelines |

Managing the Allocation of Resources within Programmes

Definition: Resource allocation is the process of assigning and scheduling

available resources in the most effective and
economical manner. Programmes will always need resources and résdlurces are scarce,
The task therefore lies with the
programme manager to determine the proper timing of those resources within the
project schedule.

1. Know Your Scope: The clearer the programme scope is, the better you’ll be able
to figure out how to allocate your
resources. Therefore, take the time to get the full picture of the programme prior
to doing any resource allocation.

2. Identify Resources: Before you can allocate resources, you have to have them.
So, you have to see who’s currently
available, what equipment you’re going to need or purchase and where are you going
to perform the tasks for this
programme, and is that space available.

3. Know Your Resource Dependencies: One way to allocate resources is by not having
to allocate them at all. This isn’t as
mystical as it might sound. It involves something far less magical and more
practical, planning.

4, Track Time: You always want to keep a close eye on time, how your team is
working and if they’re being efficient. To do
this you must keep track of your team’s workload. That requires the right tools to
give you real-time data collected on one
page where you can both see and schedule ahead when needed.

5. Use Tools: Project management software, like ProjectManager.com, is a great

asset to managing your resources more
productively. With an online tool, you get project data instantly updated.

6. Don’t Over-allocate: Many managers over-allocate, whether because of poor

planning or an inability to say no, which
doesn’t help. Instead of bringing in the programme on time and within budget, over-
allocation threatens team burnout.

7. Be Realistic: Remember when we mentioned comparing your estimated to actual

utilization? This is where that process
helps keep you properly allocated. Using a tool, like ProjectManager.com, is also
key to getting an accurate sense of how
the project is going.

© PROF. GUFRAN QURESHI

Strategic Programme Management

The strategic programme management consists of six interrelated managerial tasks:

Tj Stakeholder Analysis: Stakeholders are those who can affect or be affected by

the programmes. Stakeholder analysis
though not a lengthy process is a tricky one as it requires the management to
identify the conflicting expectations of different
stakeholders and their power and influences on the organization.
Il] Vision, Mission and Objectives:

1. Vision: Sets the purpose of the business organization. It also states the
direction of where it attempting to go.

2. Mission: The mission statement outlines how the vision to be translated into
reality. It also states what is to be done to
achieve the vision.

3. Objectives: These are quantifiable targets which will enable management to gauge
the success of the strategy. It enables
measuring the success of the strategy Sane we Tteeon grees sg tomy

> Analysis of Factors influencing Strategy Formulation # % (Portfolio Management oS

a. Environment Analysis: 'Government policies, change in customer attitude, ‘ x i
ns 7
technology change. It is important that the organization be watchful for these
forces '$) | | Programme |
and predicts the environment in which it might have to operate. | 3} Ob ee, bee |
b. Firm Analysis: Very important that the firm identifies its own resources and | 2
| ( Proked! 1 \ 4
analyses them for their ability to deliver. Firms should allocate and utilize
resources | \ | Management | UU : |
in the most efficient manner to get maximum return on investment. LJ — an sey
c. Industry Analysis: It is important that the strength of the competitors is
analysed. es oo be things welt
The size and trends of the industry also need to be taken into account. scutes sa.
taepearicusieatt
d. Product Analysis: The business needs to analyse the competitive position of its
edo

Copyright

products in the context of the development in the market.

111] SWOT Analysis: SWOT analysis combines the analysis of the firm’s internal and
external environment. The strengths,
weaknesses, of the firm are in context of the opportunities and threats. The aim of
this analysis is to achieve an optimum match
of the firm’s resources with the environment with the objective of attaining
competitive advantage.

IV] Generate Strategic Options: Strategic options are generated based on the
analysis undertaken ‘so far. The strategies
generated should be able to provide the firm competitive advantage, explore
alternative strategic direction & alternative
methods to employ strategies.

V] Evaluating Strategic Options: It is very difficult to identify which strategic

option to select despite all the analysis.
Strategic management is considered to be more an art than science. Despite all this
the decision maker should resort to the
various qualitative and quantitative techniques available to finalize the strategy.

VI] Implementation, Monitoring and Review: At the implementation stage the strategy
has to be clubbed with the
operational plan, organization chart, clear job description, procedures and
manuals, budgets and control systems. Budgets
ensure that execution as per plan. Budgetary objectives and constant monitoring
ensure that strategic objectives are
accomplished. ,

Copyright © PROF. GUFRAN QURESHI

Creating a Programme

Copyright © PROF. GUFRAN QURESHI

Definition: A program is created to manage a number of related projects, each

contributing to the overall business objective,
where it’s efficient to manage them together to get the desired outcome.

I] Programme Mandate: The programme mandate is the first stage of a programme. The
purpose of the program mandate is to
describe the required outcomes from the program, based on the strategic and policy
objectives. It is also called the strategic or
embryonic business case in some organizations.

I[| Programme Brief; The purpose of the program brief is to assess whether the
program is viable and achievable. It is also
referred to as the outline business case. Information stated here evolves into many
documents including the vision statement, risk
and issue register, and business case in the “defining a program” process.

IJ] The Vision Statement: The purpose of the vision statement is to provide details
on how “defining a program” process will
be undertaken. A small team will undertake this planning and a programme manager
with similar experience will be appointed to
handle the day-to-day responsibilities of the programme.

IV] The Blueprint: | Program & Portfolio Management |

> Blueprint is expanded and developed from vision and represents , — - ———— 1
the desired future state. Blueprint is’ a model of future) EI Eee |
organisation, its working practices and processes, the information ; es HES 7 f ]
it requires and technology it needs. | Requirements | INET S: | |
> It ae presents a a aaabgsie from the current state to future [Paneer a E> | Be |
cS ae |
state. This helps teams to effectively explore the altemative [~~] * =e"
approaches to deliver the new capability. ae Ben Gis Naar
» The purpose of a blueprint statement is to specify and ensure the | Es

coherence of the entire future state and the solution set that will

Collaboration and Communication

lead to that future. :

Aids to Programme Management Copyright © PROF. GUFRAN QURESHI

1] Dependency Diagrams: All program managers must track the dependencies that exist
between the projects which make up
their program. The easiest way to do this is by using a Dependency Diagram.

A Dependency Diagram allows us to visualise the critical cross-project dependencies

throughout the duration of the program. The
Dependency Diagram should not be confused with the Program Plan, which shows the
milestones of the different projects and the
points at which benefits can start to be realised during the program.

A dependency diagram provides two key benefits to you as a program manager:

1. Itallows you to ensure the complex network of project interdependencies is

coordinated and synchronised.

_ 2. Itallows you to track that work packages produced by the different project
teams are integrated.

In this example we can see that in order for the advertising agency to be briefed
by the Marketing team, they must have the final
Hardware and Software designs. As the Hardware and Software teams are different
project teams, before the designs are given to
marketing they will bé checked for consistency by the Quality Assurance team.

During a program, a program manager will spend a large portion of MAR MAY

their time tracking and coordinating project interdependencies, and |_ :

the Dependency Diagram is the key tool use for doing this. i

Types-

1. Finish to Start: When one task must finish so the next task can
begin.

2, Startto Start: When two tasks can start at the same time.

3. Start to Finish: Second task in the relationship cannot finish

until the first task starts but the second task can finish at
anytime after the first task starts. —_

4. Finish to Finish: Two tasks can start at any time but must | [4
finish at the same time.

Copyright © PROF. GUFRAN QURESHI

II] Delivery Planning: The delivery plan of project deliverables is a strategic

element for every Project Manager.

The goal of every project is, in fact, to produce a result that serves a specific
purpose. With the word “purpose”, we can mean

the most disparate goals: a software program, a chair, a building, a translation,

etc.
» In essence, all planned activities should be directly related to the production
of a deliverable. The Project Manager must have
in mind what the delivery plan of the deliverables is.

> Any project activity that does not directly contribute to the production of a
product should be restructured or removed from
the project plan. “4a :

> Regardless of how many tasks have been completed by the project manager and his
tearn, until a deliverable is not produced
and accepted by the client, the project team may not be paid!

Some Reservations about Programme Management

» Programme management has a much broader context than project management.

According to Project Management Institute
(PMI), “A Program is a group of related projects managed in a coordinated manner to
obtain benefits and control not
available from managing them individually.”

> The objective of program management is to optimize the resource utilization among
projects and reduce the friction to
increase the organization’s performance. <a aa : ees

> This means that in a program, you will have multiple projects, which are either
similar or related to each other, and you manage them at a higher level.

> Programs may also include elements of related work outside of the scope of
PROGRAM MANACEMENT
individual projects within the program. _ Gee

> Project management addresses the management, of the project; while program i
PROJECT
management helps you set the project management processes and measure the E
MANAGEME

project results.
FRAN QURESHI

Benefits Management copyright ©

Definition: Benefits management is a structured approach for maximising good

business outcomes for an organisation as a result

of change. It is fundamental to effective programme and project management and

successful delivery.

> Benefits management involves identifying, planning, measuring and tracking

benefits from the start of the programme or
~ project investment until realisation of the last projected benefit. }

> It aims to make sure that the desired benefits are specific, measurable, agreed,
realistic and time bounded. The term bene,
management is often used interchangeably with the term benefits realisation.

>» Benefits management is the common thread between programme

and project delivery and successful change management.

>» The approach to programme, project and change management

needs to be benefit driven to ensure maximum value from the
investment in change.

> Ultimately an organisation’s approach to benefits realisation

needs to be integrated within corporate .planning to ensure a
strong management focus beyond implementation of the
programme or project.

te)
deliver

AN QURESHI

Ch-3 An Overview of Project Planning — «e700

Definition: Project planning refers to everything you do to set up your project for
success. It is the process you go through to
establish the steps required to define your project objectives, clarify the scope
of what needs to be done and develop the task
list to do it.

Project planning is at the heart of the project life cycle, and tells everyone
involved where you’re going and how you're going
to get there.

The purpose of the project planning phase is to:

» Establish business requirements.

» Establish cost, schedule, list of deliverables, and delivery dates.

» Establish resources plans.
> Obtain management approval and proceed to the next phase.

Project planning: Project

© guides the execution of the project, coordinating the activities.

© facilitates better communication between the project stakeholders.

© provides a means of tracking and monitoring the progress.

© provides a detailed documentation regarding planning decisions.

Planning

Project planning is of significant importance for the success of the project.

© Careful planning helps prevent costly mistakes.

© Good planning is the key to meet the project objectives within defined time
and budget.

Project Budget &

(eerie
3\

Introduction to Step Wise Project Planning

> Planning is the most difficult process ih project management.
> The planning phase is when the project plans are documented, the
project deliverables and requirements aré defined, and the project 1, Identify
Project
schedule is created. ee
» It involves creating a set of plans to help guide your team through
the implementation and closure phases ofthe project,

Copyright © PROF, GUFRAN QURESHI

6. Select Project

2. Identify project
infrastructure
> The plans created during this phase will help you manage time, gcilee pein C

cost, quality, changes, risk, and related issues.

» The framework described is called the Stepwise method to help to L

distinguish it from other methods. : ently the product

> Each step of project planning has different activities to perform. Aeview °
Activities within Steps: i ae reg yp ar rm a a 4
Step 0: Select project. 5: car effort for For Each Activity
Step |: Identify project scope and objectives. Lower- Level

detail

Step 2: Identify project infrastructure. |

Step 3: Analyze project characteristics, |
Step 4: Identify project products and activities. |
|

Step 5: Estimate effort for each activity. 10. Lower level planning
Step 6: Identify activity risks. eT

Step 7: Allocate resources.

Step 8: Review / Publicize plan. 9, Execute plan 8. Review/publicize plan
Step 9: Execute plan. | -

Step 10: Lower level of planning bone 4

6. Identify activity risks

7. Allocate resources
Copyright © PROF, GUFRAN QURESHI

Step 0 : Select project — This is called step 0 because in a way of project

planning, it is outside the main project planning
process. Possibility study suggests us that the project is worthwhile or not. While
feasibility study suggests that there is a
business case for the project, it would still need to be established that it should
have priority over other projects. This evaluation
can be part of project portfolio management.

Step 1 : Identify project scope and objectives — Project scope management includes
the processes required to ensure that the
project includes all the work required, and only the work required, to carry out
the project successfully. The activities in this step
ensure that all parties to the project agree on the objectives and are dedicated to
the success of the project.

Step 1.1: Project Scope Initiation Process: In this process the project sponsor
gives the project manager the authority and
resources to define the project scope.

Step 1.2: Project Scope Planning Process: The project scope planning process
identifies what work is and is not part of i
project. It primarily settles the boundaries of the project work. It is essential
to also identify what is not a part of the project work

to avoid future problems. — . _ on

Step 1.3: Project Scope Definition Process: The project scope definition process
identifies the project delivera = 7
seca datvenblex Project deliverables is the work that needs to be accomplished to
deliver a product with specific feature

and functions. | |
Step 1.4: Project Scope Verification Process: The scope verification process checks
the scope for accuracy and completeness
ep 1.4:

The scope boundaries and deliverables should be agreed upon by the project sponsor
and project manager.

ject Scope Change Controk The change control process has to approve the change to
initiate amendments in

Step 1.5: Pro s the scope boundaries from expanding

project schedule and budget. The project scope change control process also protect
unnecessary due demands of additional features and functions to the project scope.
Step 2 : Identify Project Infrastructure — Projects are rarely carried out in a
vacuum. There is usually some kind of
infrastructure into which the project must fit. Where the project managers are new
to the organization, they must find out the
precise nature of this infrastructure.

Step 2.1: Identify relationship between the project and strategic planning.
Step 2.2: Identify installation standards and procedures.

Step 2.3: Identify project team organization. Organisational

BU

Project Infrastructure refers to the organisational structure, processes, tools,

techniques and training an organisation puts in place to make projects more
successful.

Organisational Structure — Organisational structure including such suppo esis |

mechanisms as project management office, project recruiting function,
financial monitoring area etc. It also covers lines of communication and =
escalation.

Processes — Typically methodologies, checklists and guidelines.

Tools — Software and templates. UC ha

Techniques — Repeatable processes such as kick off meetings, PIRs (Post

Implementation Reviews), analysis techniques, etc.

Training — Formal and informal training and reference documentation. |

ROF, GUFRAN QURESHI

7 Copyright © PROF, GUFRAN QURESHI

Step 3: Analyze Project Characteristics — The general purpose of this part of

planning operation is to ensure that the appropriate
methods are used for the project. The project manager needs to analyse the project
characteristics and this can be done through the
project charter. It is the time to draft the project charter (Contract).

The Project Charter serves as a road map for the project manager and states the
goals that are to be achieved from the project.

A Project Charter gives a clear definition of the project, its attributes, the end
results and the project authorities.

The Project Charter Covers

* Documenting the project’s MOY: Although the project’s MOV was included in the
business case, it is important that the MOV be
clearly defined and agreed upon before developing or executing the project plan. At
this point, the MOV must be cast in stone. Once
agreed upon, the MOV for a project should not change.

+ Defining the project infrastructure: The project charter defines all of the
people, resources, technology, methods, project
management processes, and knowledge areas that are required to support the project.
In short, the project charter will detail everything
needed to carry out the project.

+ Summarizing the details of the project plan: The project charter should summarize
the scope, schedule, budget, quality objectives,
deliverables, and milestones of the project. It should serve as an important
communication tool that provides a consolidated source of
information about the project that can be referenced throughout the project life
cycle.

+ Defining roles and responsibilities: The project charter should not only identify
the project sponsor, project manager, and project
team, but also when and how they will be involved throughout the project life
cycle. In addition, the project charter should specify the
lines of reporting and who will be responsible for specific decisions.

¢ Showing explicit commitment to the project: In addition to defining the roles and
responsibilities of the various stakeholders, the
project charter should detail the resources to be provided by the project sponsor
and specify clearly who will take ownership of the
project’s product once the project is completed.

* Setting out project control mechanisms: Changes to the project’s scope, schedule,
and budget will undoubtedly be required over the
course of the project. But, the project manager can lose cantrol and the project
team can |dse its focus if these changes are not managed
properly. Therefore, the project charter should outline a process for requesting
and responding to proposed changes.
oa

Elements /Components of the Project Charter Copyright © PROF. GUFRAN QURESHI

The project charter is used to authorize a project manager and to give an overview
df a project to the key stakeholders that do not like to go into

the details of your: project.

1. Background (Introduction): Always sak with an introduction telling the redder

what is this project all about. It doesn’t have to be long
where it can be a summary of a few lines of sentences.

2. Goals (Objective): State the objective of your project. This can also be the
output of your project of what your project will produce at the
end of it.

3. Stakeholders (Roles & Responsibilities): Key stakeholders such as project

sponsor, project manager, and your functional manager
shouldn’t be out of your identification process. If you foresee the needs of other
key stakeholders such as your directors, include them as
well in here.

4. Measurable Organizational Value (MOV): Although the project’s MOV was included
in the business case, it is important that the MOV
be clearly defined and agreed upon before developing or executing the project plan.
At this point, the MOV must be cast in stone. Once
agreed upon, the MOV for a project should not change.

5. Milestones (Scope): Having scope in your charter gives an overview to your busy
stakeholders to know what you want to deliver in the
project by just glance over. Break the high-level requirements into key milestones
that your key stakeholders want to see.

6. Project Budget: Money has always been the main concern of your stakeholder. You
might not have the most accurate project budget now
because you might be relying on past project experience and a rough estimate to
come out with a project budget.

7. Constraints: Includes your constraints of the project over here. It is important

to keep your stakeholders updated about every potential
problem so that they could contribute a little to help.

8. Risks: Even at the initialization stage, you should be able to identify some
high-level risk of the project. A risk is the uncertainties that
could potentially turn out to be an issue in your project as your project moves on.

9, Assumptions: Whatever you assume will have or will not have, document them. For
instance, you could have assumption such as
“sufficient hardware servers are prepared by the client for this project” can be
used to ensure your stakeholders are aware of this.

10. Communications plan: A key event such as kick-off meeting, project progress
update, project plan update and etc should be mentioned in
your communication plan of how often it will happen and who will be involved when
such communication occurred.
11. Approval: A project charter without approval basically means nothing because no
one recognized it. You need at least your project sponsor
to sign off on that document in order for you to be officially authorized as the
project manager of that project.

Copyright © PROF. GUFRAN QURESHI

Step 4 : Identify Project Products and Activities — The more detailed planning of
the individual activities now takes place.
The longer term planning is broad and in outline, while the more immediate tasks
are planned in some detail.

Project Product / Deliverables: The next step after the development and approval of
the project scope statement is project

planning. The primary requirement for project planning is the Work Breakdown
Structure (WBS) for which the approved

project scope statement is required.

» The project scope statement defines all the project deliverables. These defined
deliverables are then clubbed together to form
the Delivery Definition Table (DDT).

» The DDT contains the sequence of the delivery of the deliverables. The DDT is
then used to create the Delivery Structure
Table which contains the work packages which is then further used to create the
Work Breakdown Structure.

> Thus, WBS is similar to Bill of Material (BOM), wherein a product is broken into
its smallest component for which
estimation of time and cost is possible.

» The idea behind WBS is to divide each component till its reaches its smallest
component, the work package.

Benefits of WBS

> It details the work required to complete the project

> It breaks down the key project deliverables into smaller portions so that they
can be understood by the group and then
parceled out to the necessary parties.

> Itdefines who the necessary parties will be who are going to complete the work
packages or perform the tasks involved.

> It facilitates the quick development ofa schedule by allocating effort estimates
to specific sections of the WBS.
Copyright © PROF. GUFRAN QURESHI

Developing the WBS :

Developing the work breakdown structure means defining the relationships between
the project goals, deliverables and scope.

Usually this process is about creating a detailed decomposition of work planned for
completion into smaller, more manageable

and measurable component. Developing the work breakdown structure involves the
following steps:

* Identify project deliverables based on stakeholder requirements.

* Define the amount of work necessary for producing the deliverables.

* Create a high-level decomposition of work using the above information.

* Specify the high-level decomposition by smaller, more manageable pieces of work

to create separate work packages.

Process:

1.. The Company Project Manager shall approve Basis of Design Documentation and
develop Project Execution Plan as basis
for developing WBS and assigning Codes of Accounts(COA). .

2. Based on approved Basis of Design and PEP Project Control Manager/Project

Service Manager shall coordinate with

Project Cost Control and Scheduler to develop WBS and assign Codes of Account (COA)

Project Cost Control shall validate and formalize

SAP/Oracle COA interface.

4, Project Manager shall approve WBS coding.

5. Project Cost Control shall re-classify the Approved

Budget into the WBS structure at the summary level.

6. Project Control Manager and Project Cost Control will

further breakdown the summary WBS/budget into the
detailed project budget for Sub-Projects.

7. Project Control Manager and Project Manager shall

approve WBS/budget breakdown.

wes
Project Activities:

1. Project Planning: It is a set of multiple processes, or we can say that it is a

task that performed before the construction of
the product starts.

2. Scope Management: It describes the scope of the project. Scope management is

important because it clearly defines what
would do and what would not.

3. Estimation management: This is not only about cost estimation because whenever
we start to develop software, but we
also figure out their size(line of code), efforts, time as well as cost.

4. Scheduling Management: Scheduling Management in software refers to all the

activities to complete in the specified order
and within time slotted to each activity. Project managers define multiple tasks
and arrange them keeping various factors in
mind.

5. Project Resource Management: In software Development, all the elements are

referred to as resources for the project. It
can be a human resource, productive tools, and libraries.

6. Project Risk Management: Risk management consists of all the

activities like identification, analyzing and preparing the plan for
predictable and unpredictable risk in the project.

7. Project Communication Management: Communication is an

essential factor in the success of the project. It is a bridge
between client, organization, team members and as well as other [ 1
stakeholders of the project such as hardware suppliers. Data Process Phyical

8. Project Configuration Management: Configuration design design design

management is about to control the changes in software like |
requirements, design, and development of the product. Relational foci

data analysis data design

Project

Analyse Design Build

Ae
4
2

Copyright © PROF. GUFRAN QURESHI

Step 5: Estimate Effort for Each Activity — There are three early estimates that
are needed for a project--effort, duration, and

cost. Of the three, effort hours must be estimated first. Once you understand the
effort that's required, you can assign resources

to determine how long the project will take (duration) and then you can éstlmate
labor and non-labor costs,

Process: '

I. Determine how accurate your estimate needs to be. Typically, the more accurate
the estimate, the more detail is needed, and
the more time that is needed.

2. Create the initial estimate of effort hours for each activity and for the entire
project. There are many techniques you can use

to estimate effort including task decomposition (Work Breakdown Structure), expert

opinion, analogy, Pert, etc.

Add specialist resource hours. Make sure you have included hours for part-time and
specialty resources. For instance, this

could include freelance people, training specialists, procurement, legal,

administrative, etc.

4. Add project management time. This is the effort required to successfully and
proactively manage a project. In general, add
15% of the effort hours for project management.

5. Add contingency hours. Contingency is used to reflect the uncertainty or risk

associated with the estimate. If you're asked to

estimate work that is not well defined, you may add 50%, 75%, or more to reflect
the uncertainty.

Calculate the total effort by adding up all the detailed work components.

7. Review and adjust as necessary. Sometimes when you add up all the components,
the estimate seems obviously high or low.

Lo

Copyright © PROF. GUFRAN QURESHI

Step 6 : Identify Activity Risks — Risk is an integral part of an IT projects and
therefore risk identification at the earliest
becomes all the more critical.
Risk identification is an iterative process, wherein the project manger and his
team are always on the lookout for risk that may
sneak into the project or may have already sneaked in.
Risk identification needs to be done throughout the project lifecycle, because as
the project develops new risk is likely to
emanate and pose a threat to the project.
Risk components:
» Performance risk—the degree of uncertainty that the product will meet its
requirements and be fit for its intended use.
> Cost risk—the degree of uncertainty that the project budget will be maintained.
> Support risk—the degree of uncertainty that the resultant software will be easy
to correct, adapt, and enhance.
» Schedule risk—the degree of uncertainty that the project schedule will be
maintained and that the product will be delivered

on time.

Step 7: Allocate Resources — Resource allocation is the process of assigning and

scheduling available resources in the most

effective and economical manner. Projects will always need resources and resources
are scarce. The task therefore lies with the

project manager to determine the proper timing of those resources within the
project schedule.

Steps for allocating resources:

1. know the scope — to know what is your project about, what you will need to
achieve it, and to be able to properly allocate
resources;

2. identify resources —to know which tools, equipment, etc. you will need it
completing the project;

3. track time — to havea deep analysis of the progress and current situation as
well as be able to control it in the real-time;

4. don’t look only at the big picture — the process of working on a project is not
done with task allocation. Once you allocate
resources you have to keep track of all of them. If you lose at least one tiny
detail, your project may fail;

5. don’t over-allocate— because your team will experience burnout and their
productivity will significantly drop.
Copyright © PROF. GUFRAN QURESHI

Step 8: Review / Publicize Plan—

> Review quality aspects of the project plan

1. Each-task should have quality criteria.

2. These quality checks have to be passed before the activity can be “signed off?
as completed.
> Document plans and obtain agreement

1. Plans should be carefully documented.

2. All the parties to the project must understand and agree.on the plan.

Step 9 & 10: Execute Plans and Lower Levels of Planning —

1. Once the project is started, plans will need to be drawn up in greater detail
for each activity as it becomes due.

2, . The project plans need to be executed in order to bring the project to

reality.

3. The project execution group is entrusted with the task of undertake the work
defined in the project plan.

4, The execution task involves coordination people and resources as well as

integrating and performing activities in
accordance with the project plan.

5. Detailed and lower level of planning of the soon stages will need to be delayed
because more information will be available
nearer the start of the stage.

6. Itis necessary to make provisional plans for the more distant tasks.

Unit I

Ch 4: Selection of an Appropriate Project Approach: Introduction, Build or Buy?

Choosing
Methodologies and Technologies, Software Processes and Process Models, Choice of
Process Models,
Structure versus Speed of Delivery, The Waterfall Model, The Spiral Model, Software
Prototyping, Other
Ways of Categorizing Prototypes, Incremental Delivery, Atern/Dynamic Systems
Development Method,
Rapid Application Development, Agile Methods, Extreme Programming (XP), Scrum, Lean
Software
Development, Managing Iterative Processes, Selecting the Most Appropriate Process
Model.

Ch 5: Software Effort Estimation: Introduction, Where are the Estimates Done?

Problems with Over- and
Under-Estimates, The Basis for Software Estimating, Software Effort Estimation
Techniques, Bottomup
Estimating, The Top-down Approach and Parametric Models, Expert Judgement,
Estimating by Analogy,
Albrecht Function Point 12 Analysis, Function Points Mark II, COSMIC Full Function
Points, COCOMO II:
A Parametric Productivity Model, Cost Estimation, Staffing Pattern, Effect of
Schedule Compression, Capers
Jones Estimating Rules of Thumb.

Copyright © PROF. GUFRAN QURESHI

V4

Ch-4 Selection of an Appropriate Project Approach °°" “os

_ Definition: It is concerned with choosing the right approach to a partictildr
project: variously called technical
planning, project analysis, methods engiheéring and methods tailoring,
> According to a recent survey as little as 29 percent of IT projects undettaken in
the government sector and 45 percent in
the private sector were successful in relation to budget, functionality and
timeliness. :
» There are various project selection methods practised by the modern business
organizations. These methods have different
features and characteristics, Therefore, each selection method is best for
different organizations.
» Although there are many differences between these project selection methods,
usually the underlying concepts and
principles are the same.
» Most ofthe IT projects are plagued by time and cost overruns. Projects that do
not complete on time and within bud get can
act as a milestone around the neck pulling the company away from the projected
trajectory of growth.
The “90/90 Rule” of project management goes like this: the first 90 percent of a
project takes 10 percent of the time and
effort; the remaining 10 percent of the project takes the other 90 percent of the
time and effort.

Ww

Build or Buy
Every project manager is faced with the eternal dilemma of whether to In-house

build a business solution from scratch or buy an off the shelf application
MGevelopmenty
to meet the needs of the organization.

cute

The decision whether to build or buy can be made in six steps:

Copyright © PROF. GUFRAN QURESHI

Step | : Validate the business need

To compete successfully, managers need to focus on validating that a business need

exists prior to deciding upon the enabling
technology and that the need can be readily associated with one of the
organization's strategic goals or objectives. Project
manager need to provide an estimated return on investment (ROI) or added value,
along with how ROI will be measured.
Step2: Identify core business requirements

A core business requirement is one that must be supported by the solution to

continue. Ifa requirement can be only partially
met or not addressed by a solution, it is nota core requirement. It takes effortto
identify these requirements, and involving the
right business people determines the success of the process.
Step 3: Identify architectural requirements

It is extremely important to identify any architectural requirements.or standards

that a solution must support before determining
ifa Commercial off-the-shelf [COTS] or custom solution is the best choice.

Step 4: Examine existing solutions

At this point, a business need has been pinpointed, ROI has been estimated, and
both core business and architectural
restrictions have been identified. Leaders should now take a good look at existing
systems.

Step 5: Do you have in-house skills to support a custom solution?

The major factor that significantly reduces the ROI of a custom solution (and in
many cases, ultimately causes the endeavor to
fail) is the lack of available personnel with proper skill sets. It takes many
skills to design and deploy a business solution that is
both scalable and extensible. -

Step 6: Does a COTS solution fit your needs?

Although the initial short-term cost of implementing COTS-based solutions is often

significantly more than a customsolution,
it has been experience that a COTS solution will usually provide the best ROI over
the long term.
Copyright © PROF. GUFRAN QURESH!

Choosing Methodologies and Technologies

> An outcome of project analysis will be the selection of the most appropriate
methodologies and technologies.
> Methodologies include techniques like the various flavours of object-oriented
(OO) development, SSADM (Structured
Systems Analysis & Design Method) and JSP (Jackson Structured Programming) while
technologies might include an
appropriate application-building environment, or the use of knowledge-based system
tools.
> As well as the products and activities, the chosen technology will influence the
following aspects of a project:
" the training requirements for development staff;
" the types of staff to be recruited;
= the development environment - both hardware and software;
= system maintenance arrangements.
> Methodologies are sets of principles, procedures and techniques that help set up
a functional project management process.
>» A methodology is a model, which project managers employ for the mi
design, planning, implementation and achievement of their project “a ei : ron
objectives. There are different project management methodologies S- _/ Ta a ran
to benefit different projects. INITIATE aia _- PLAN
» For example, there is a specific methodology, which NASA uses to

builda space station while the Navy employs a different > R © J E. lo oT

methodology to build submarines. Hence, there are different project M ANAGEM —

management methodologies that cater to the needs of different wy a ; ~ Oo
projects spanned across different business domains. an ‘> :

sSsUCCESS EouTAoL EXECUTE

Copyright © PROF. GUFRAN QURESHI

Software Processes and Process Models
Software Process: A software process (also knows as software methodology) is a set
of related activities that leads to the
production of the software. These activities may involve the development of the
software from the scratch, or, modifying an
existing system.
Any software process must include the following four activities:
1. Software specification (or requirements engineering): Define the main
functionalities of the software and the constrains around
them.
2. Software design and implementation: The software is to be designed, produced and
implemented as per the specifications.
3. Software verification and validation: The software must conforms to it’s
specification and meets the customer needs.
4. Software evolution (software maintenance): The software is being modified to
meet customer and market requirements changes.

A process also includes the process description, which includes:

Products: The outcomes of the an activity. For example, the outcome of

architectural design maybe a model for the software
architecture.

Roles: The responsibilities of the people involved in the process. For exemple the
project manager, programmer, etc.
Pre and post conditions: The conditions that must be true before and after an
activity. For example, the pre condition of the
architectural design is the requirements have been approved by the customer, while
the post condition is the diagrams describing the
architectural have been reviewed.

Software Process Models: A software process model is a simplified representation of

a software process. Each model

represents a process from a specific perspective.

» These generic models are abstractions of the process that can be used to explain
different approaches to the software development.
They can be adapted and extended to create more specific processes.

> Some methodologies are sometimes known as software development life cycle (SDLC)
methodologies, though this term could also
be used more generally to refer to any methodology. :
3a

Copyright © PROF. GUFRAN QURESHI

Choice of Process Models

The software process model framework Is specific to the project. Thus, it is
essential to select the software process model according
to the software which is to be developed.
The software project is considered efficient if the process model is selected
according to the requirements. It is also essential to
consider time and cost while choosing a process model as cost and/or time
constraints play an important role in software
development.
The basic characteristics required to select the process model are project type and
associated risks, requirements of the project, and
the users.
One of the key features of selecting a process model is to understand the project
in terms of size, complexity, funds available, and
so on.
In addition, the risks which are associated with the project should also be
considered. Note that only a few process models
emphasize risk assessment.
Based on their experience built over the years project managers have identified
twenty criteria that influence the choice of process.
These criteria have been grouped into four broad categories namely: Personnel,
Problem, Product & Resources,

Structure v/s Speed of Delivery

A structured method would mean one which consists of steps, method and rules which
when applied would generate system
products. Now each product emanating from such a well defined method would itself
be well defined.
However, the problem with such methods is that they are more time consuming and
expensive than other approaches.
The final outcome of such a system is an error prone and more maintainable system.
This kind of method is preferred on larger
projects where it is possible to maintain a balance ‘of costs and benefits.
Many customers are more interested in getting working applications delivered
quickly and at lower cost e.g. RAD and find the
structured approach cumbersome, time consuming and unnecessarily expensive.
A simpler approach to speeding up delivery is to deliver less. It means that the
entire project is broken into a series of small
increments each delivering project deliverables which comprises of useful project
functionality.

Copyright © PROF. GUFRAN QURESHI

Waterfall Model

» Waterfall approach was first SDLC Model to be used widely in Software Engineering
to ensure success of the project.
>» In"The Waterfall" approach, the whole process of software development is divided
into separate phases. In this Waterfall model,

typically, the outcome of one phase acts as the input for the next phase
sequentially.

The following illustration is a representation of the different phases of the

Waterfall Model.
The sequential phases in Waterfall model are —

1.

Requirement Gathering and analysis — All possible requirements of the system to be

sieve pets are cea in this phases and

documented in a requirement specification document. = ee

System Design — The requirement specifications from first phase are studied in a
eae
alysis |

this phase and the system design is prepared. This system design helps in Waterfall
Model
specifying hardware and system requirements and helps in defining the overall |
System |

system architecture. | Design |

Implementation — With inputs from the system design, the system is first | i

developed in small programs called units, which are integrated in the next phase. |
| i

Each unit is developed and tested for its functionality, which is referred to as
Unit | a eects }

Testing. i |
Integration and Testing — All the units developed in the implementation phase i | i
are integrated into a system after testing of each unit. Post integration the
entire
system is tested for any faults and failures. |
Deployment of system — Once the functional and non-functional testing is done; | |
the product is deployed in the customer environment or released into the market. |
|
Maintenance — There are some issues which come up in the client environment. |
To fix those issues, patches are released. Also to enhance the product some better
versions are released. Maintenance is done to deliver these changes in the

; : [i lincamermmmmlitieiatin id) Maitenanice

customer environment.

Testing

Deployment ia
|
Spiral Model Copyright © PROF. GUFRAN QURESHI

» Spiral model is one of the most important Software Development Life Cycle models,
which provides support for Risk

Handling.

» In its diagrammatic representation, it looks like a spiral with many loops. The
exact number of loops of the spiral is

unknown and can vary from project to project. Each loop of the spiral is called a
Phase of the software development process.

Each phase of Spiral Model is divided into four quadrants as shown in the figure.
The functions of these four quadrants are

discussed below-

1. Objectives determination and identify alternative solutions (Planning):

Requirements are gathered from the customers
and the objectives are identified, elaborated and analyzed at the start of every
phase. Then alternative solutions possible for
the phase are proposed in this quadrant. /

2. Identify and resolve Risks (Risk Analysis): During the second quadrant all the
possible solutions are evaluated to select
the best possible solution. Then the risks associated with that solution is
identified and the risks are resolved using the best
possible strategy. At the end of this quadrant, Prototype is built for the best
possible solution.

3. Develop next version of the Product (Development & Testing): During the
third quadrant, the identified features are developed and verified through testing.

At the end of the third quadrant, the next version of the software is available.
cote

4, Review and plan for the next Phase (Evaluation); In the fourth quadrant, the |e
Customers evaluate the so far developed version of the software. In the end, tome
an
planning for the next phase is started. 2

Advantages: 4. neview ana pier

1. High amount of risk analysis hence, avoidance of Risk in enhanced. eo

2. Good for large and mission-critical projects.

Disadvantages:

1. Can beacostly model to use.

Advantages: The customers get to see the partial product early in the life
cycle. This ensures a greater level of customer satisfaction and comfort. Maintain
[4 Test
Disadvantages: Costly w.r.t time as well as money.

Copyright © PROF. GUFRAN QURESHI

Software Prototyping
A prototype is a version of a system or part of the system that’s developed quickly
to check the customer’s requirements or
feasibility of some design decisions.
So, a prototype is useful when a customer or developer is not sure of the
requirements, or of algorithms, efficiency, business
rules, response time, etc.
In prototyping, the client is involved throughout the development process, which
increases the likelihood of client
acceptance of the final implementation.
This model can be successfully used for developing user interfaces, high technology
software-intensive systems, and
systems with complex algorithms and interfaces. It is also a very good choice to
demonstrate the technical feasibility of the

product. The phases of a prototype are:

. Establish objectives: The objectives of the prototype should be made explicit

from the start of the process. Is it to validate

system requirements, or demonstrate feasibility, etc.

. Define prototype functionality: Decide what are the inputs and the expected
output from a prototype. To reduce the
prototyping costs and accelerate the delivery schedule, you may ignore some
functionality, such as response time and °
memory utilization unless they are relevant to the objective of the prototype. Pre
Typing

. Develop the prototype: The initial prototype is developed that includes if \

only user interfaces. 4 A

. Evaluate the prototype: Once the users are trained to use the prototype, ‘Keceles
ee oe, bomen
they then discover requirements errors. Using the feedback both the ‘
specifications and the prototype can be improved. If changes are NL Riya y

introduced, then arepeat of steps 3 and 4 may be needed.

Development
ub

Copyright © PROF. GUFRAN QURESHI

Other Ways of Categorizing Prototypes

> The most important reason for having a prototype is that'there is a need td learn
about an area of uncertainty. For any prototype it is
essential that the project managers define. at the outset What it is intended‘ td
learn from the prototype.
» This has a particular relevance to student projects. Students often realize that
the software that they are to write as part of their
project could not safely be used by real user's. They therefore call the softwate a
‘prototype’. However, if it is a real prototype then
they must:
a. specify what they hope to learn from the prototype;
b. plan how the prototype is to be evaluated;
c. report on what has actually been learnt.
Prototypes may be used to find out how a new development technique can be used.
Different projects will have uncertainties at
different stages. Prototypes can therefore be used at different stages.
» Aprototype might be used, for instance, at the requirements gathering stage to
pin down requirements that seem blurred and
shifting. A prototype might, on the other hand, be used at the design stage to test
out the users’ ability to navigate through a

Ww

sequence of input screens.

Extent to which Prototyping is to be done ™!;
It would be unusual for the whole of the application to be prototyped. The
prototyping sense
might take one of the following forms, which simulates only some aspects of the
target ‘\
application. model
1. Mock-ups: A mock-up is a visual way of representing a system aspect. A mock-up :
y _, .
shows how the system is going to look like. But still, a mock-up is not clickable.
Sie erent decide Pensoue
2. Simulated Interaction: Interaction between the user and the system is simulated
{

to a certain request. However, the interaction is a simulated one and has limited }
eases
scope.
3. Partial Prototype:
a. Vertical — some of the features of the system are prototyped fully.

b. Horizontal —all features of the system are prototyped but not fully.

Incremental Delivery Copyright © PROF. GUFRAN QURESHI

> Incremental process model is also known as successive version model.
> First, asimple working system implementing only a few basic features is built and
then that is delivered to the customer. Then
thereafter many successive iterations/ versions are implemented and delivered to
the customer until the desired system is rel eased.
» Incremental development is based on the idea of developing an initial
implementation, exposing this to user feedback, and evo lving
it through several versions until an acceptable system has been developed.
>» The activities ofa process are not separated but interleaved with feedback
involved across those activities.
> Each system increment reflects a piece of the functionality that is needed by the
customer. This means that the customer can
evaluate the system at early stage in the development to see if it delivers what’s
required.

Advantages over Waterfall Model:

1, The cost of accommodating changing customer requirements is reduced. The amount
of analysis and documentation that has to be

redone is much less than that’s required with waterfall model.

2. It’s easier to get customer feedback on the work done during development than
when the system is fully developed, tested, and
delivered.
3. More rapid delivery of useful software is possible even if all the functionality
hasn’t been included. Customers are able to use and
gain value from the software earlier than it’s possible with the waterfall model.
Reairenea co rt & Desan
Disadvantages of Incremental Delivery:
1. Documentation of each version produced needs to be done which is a costly
affair.
2. Not easy for managers to measure and monitor the progress. i
3. Each phase of aniterationis rigid and do not overlap each other. Initial
Deployment
Incremental Model can be a plan-driven or agile, or both: Penk
> Incremental development is one of the most common approaches. This approach can
be
either a plan-driven or agile, or both.
>» Ina plan-driven approach, the system increments are identified in advance, but,
in the
agile approach, only the early increments are identified and the development of
later

increments depends on the progress and customer priorities.

Alarming Implimentation

Evaluation Testing

incremental-model
Atern / Dynamic Systems Development Method (DSDM)

» DSDM is an agile software development methodology. It is an iterative,

incremental approach that is largely based on the Rapid
Application Development (RAD) methodology. The method provides a five-phase
framework consisting of:

1. Feasibility Study: It establishes the essential business necessities and

constraints related to the applying to be designed then
assesses whether or not the application could be a viable candidate for the DSDM
method.

2. Business Study: It establishes the use and knowledge necessities that may permit
the applying to supply business value;
additionally, it is the essential application design and identifies the
maintainability necessities for the applying.

3. Functional Model Iteration: It produces a collection of progressive prototypes

that demonstrate practicality for the client. The
intent throughout this unvarying cycle is to collect further necessities by
eliciting feedback from users as they exercise the
paradigm.

4. Design and Build Iteration: It revisits prototypes designed throughout useful

model iteration to make sure that everyone has been
designed during a manner: that may alter it to supply operational business price
for finish users. In some cases, useful model
iteration and style and build iteration occur at the same time.

5. Implementation: It places the newest code increment (an “operationalized”

prototype) into the operational surroundings. It ought
to be noted that: (a) the increment might not 100% complete or, [ea |
(b) changes are also requested because the increment is placed into place. ania

3. Business cases are at the core of the DSDM model, ensuring delivered eee tans
projects have real business value. _

In either case, DSDM development work continues by returning to the useful

Disadvantages: Large management overhead and costly implementation makes 4a a
/oesen
this unsuitable for.small organizations. “aebine ott

Advantages:
1. Projects are delivered on time, whilst still allowing flexibility.
2. Progress can be easily understood across the organization.

model iteration activity.

nt © PROF, GUFi

How Does DSDM Help to Overcome Development Pitfalls?”

Many systems fall short of meeting the needs of the users and purpose they were
designed for, causing the system to either be
abandoned or overhauled. There are a number of ways this may happen:
1. Failure to meet the purpose /solve the problem it was designed for - DSDM allows
for user testing all through the
development process, thus allowing developers to get prompt feedback on the
usability and suitability of the product.
2. Cost outweighs benefits, or costis too high altogether - In DSDM, a Business
Study is done at the beginning of the
project, greatly decreasing the likelihood of late surprises in the financial
realm.
3. Poor communication between involved parties - DSDM stresses communication and
collaboration between all interested
parties - developers, users, etc.
4. The users finds the program either too hard to use that it does not work as
expected - DSDM allows for user testing
all through the development process, thus allowing developers to get prompt
feedback on the usability and suitability of the
product.
5. Hidden flaws surface in the system due to poor design or implementation - In
DSDM, prototyping helps to ensure that
the system is designed correctly and that everyone knows how it will work. Unit
testing helps to uncover hidden bugs, and
incremental development allows for user testing all through the development
process.

6. Users resist the instantiation of the system, either for political Functionality
Resources
reasons, or a lack of commitment to it - In DSDM, since the users | q— Fixed _»€
are actively involved in the development of the system, they are more / \ \ DSDM =/
likely to embrace it and take it on. f i

7. The system is in-flexible and/or un-maintainable, and unable to / \ \ /

adapt to change - Since DSDM emphasizes flexibility in design, this ie \ \ /

is not likely to happen with DSDM. / Traditional \, \ \

js q— Variable = v

Time Resources Functionality

Core Concepts in DSDM Copyright © PROF. GUFRAN QURESHI
1. Active User Involvement: The people who will be using the product must: be
actively involved in its development. This important
in order for the product to end up being Useful to thé people -who will be using
it.
2. The Team Must Be Empowered to Make Decisions: The team should be able to make
rapid and informed decisions, without
having to cut through red tape to get ine decisions approved. ,
3. Frequent Releases: DSDM focuses on requent releases, Frequent releases allow for
user input at crucial stages in the product's
development. They also ensure that the product is able to be released quickly at
all times.
4. Iterative Development, Driven by User Feedback: The development is the system is
done in iterations, which allows for
frequent user feedback, and a partial but prompt solution to immediate needs, with
more functionality being added in later
iterations.
5. Changes Must Be Reversible: All products should be in a fully known state at all
times. This allows for backtracking if a certain
change does not work out well.
6. Requirements are Initially Defined at a High Level: High-level requirements are
worked out at the beginning of the project,
before any coding, leaving the details to be worked out during the course of the
development.
7. Fitness for Business Purpose is the Goal: Meeting the business need is more
important than technical perfection.
8. Integrated Testing: Testing is done at every step of the way, to ensure that the
product ’
being developed is technically sound and does not develop any technical flaws, and
that LE ;
maximum use is made of user feedback. / Feasibility
9. Collaboration and Cooperation are Essential: Collaboration and cooperation
between EB
all interested parties are essential for the success of the project. All involved
parties (not

just the core team) must strive together to meet the business objective. Functional
Model : ” implementation
10. 20% / 80% Rule: DSDM assumes that 80% of the solution can be developed in 20%
of beatin § :
the time that it would take to produce the total solution. DSDM focuses on this
80%, re
leaving another 20% for later revisions. DSDM assumes that not all of the
requirements Besign ancibulld
for the final solution are known to begin with, so it is likely that the final 20%
of non- Keration
essential features are likely to be flawed anyway.
Copyrig © PROF. GUFRAN QURESHI

Rapid Application Development

» The RAD (Rapid Application Development) model is based on prototyping and

iterative development with no specific

planning involved. The process of writing the software itself involves the planning
required for developing the product.

>» RAD model distributes the analysis, design, build and test phases into a series
of short, iterative development cycles.

Following are the various phases of the RAD Model —

1. Business Modeling: The business model for the product under development is
designed in terms of flow of information
and the distribution of information between various business channels.

2. Data Modeling: The information gathered in the Business Modeling phase is

reviewed and analyzed to form sets of data
objects vital for the business. The attributes of all data sets is identified and
defined. The relation between these data objects
are established and defined in detail in relevance to the business model.

3. Process Modeling: The data object sets defined in the Data Modeling phase are
converted to establish the business
information flow needed to achieve specific business objectives as per the business
model.

4. Application Generation: The actual system is built and coding is done by using
automation tools to convert process and
data models into actual prototypes.

5. Testing and Turnover: The overall testing time is reduced in the RAD
model as the prototypes are independently tested during every iteration.

Advantages:

* More productivity with fewer people.

* Time between prototypes and iterations is short.

* Itis adaptable and flexible to changes.

Disadvantages:

* Only suitable for projects which have a small development time.

* More complex to manage when compared to other models.

* When technical risk is high, it is not suitable.

‘Testing aod
Turnever

|
[
|

Prototype 1 | Prototype 2 Prototype 3

>

>

ww

. Programming in pairs (called pair programming), with two

. Integrating and testing the whole system several times a day.

. Putting a minimal working system into the production quickly

. Keeping the customer involved all the time and obtaining iii al
constant feedback. <aigee

Agile Methods Copyright © PROF. GUFRAN QURESHI

Agile Methodology is a people-focused, results-focused approach to software

development that respects our rapidly changing
world. It’s centered around adaptive planning, self-organization, and short
delivery times. It’s flexible, fast, and aims for
continuous improvements in quality, using tools like Scrum and eXtreme Programming.

AGILE methodology is a practice that promotes continuous iteration of development

and testing throughout the software
development lifecycle of the project. Both developmentand testing activities are
concurrent unlike the Waterfall model.
Agile is a process by which a team can manage a project by breaking it up into
several stages and involving constant
collaboration with stakeholders and continuous improvement and iteration at every
stage. The Agile methodology begins with
clients describing how the end product will be used and what problem it will solve.
This clarifies the customer's expectations
to the project team.

Faster, smaller. Traditional software development relied on phases like outlining

the requirements, planning, design,
building, testing, and delivery. Agile methodology, by contrast, looks to deploy
the first increment in a couple weeks and the
entire piece of software in a couple months.

Communication. Agile teams within the business work together daily at every stage
of the project through face-to-face meetings. This collaboration and communication
ensure the process stays on track even as conditions change.

Feedback. Rather than waiting until the delivery phase to gauge success, teams
leveraging Agile methodology track the success and speed of the development
process regularly. Velocity is measured after the delivery of each increment.

Trust. Agile teams and employees are self-organizing. Rather than following a
manifesto of rules from management intended to produce the desired result, they
understand the goals and create their own path to reach them.

Adjust. Participants tune and adjust the process continually, following the KIS

or Keep It Simple principle.

cits ty

Extreme Programming (XP) Copyright © PROF. GUFRAN QURESHI

Extreme Programming (XP) is a methodology for creating software within a very

unstable environment. It allows flexibility
within the modelling process.
Extreme Programming technique is very helpful when there is constantly changing
demands or requirements from the
customers or when they are not sure about the functionality of the system.
Extreme Programming is one of several popular Agile Processes. It has already been
proven to be very successful at many
companies of all different sizes and industries world wide.

Extreme Programming emphasizes teamwork. Managers, customers, and developers are

all equal partners in a collaborative
team. The team self-organizes around the problem to solve it as efficiently as
possible.

Extreme Programming involves —

Writing unit tests before programming and keeping all of the tests running at all
times. The unit tests are automated and
eliminates defects early, thus reducing the costs.

Starting with a simple design just enough to code the features at

ce : i Si
hand and redesigning when required. oe Xe “a8 Re Ota, Refactoring

programmers at one screen, taking turns to use the keyboard.

While one of them is at the keyboard, the other constantly
reviews and provides inputs.

and upgrading it whenever required.

h5

Scrum Copyright © PROF. GUFRAN QURESHI

> Scrumis a framework for developing, délivering, and sustaining products (or, more
generally, things of value) in complex
domains and environments. . :

> Scrumis an agile project management methodology or framework used primarily for
software development projects with
the goal of delivering new software capability every 2-4 weeks.

> Itis a proven approach for building high value products in an iterative and
incremental way using teamwork and empirical
process.

> Scrumis not a process, technique, or definitive method. Rather, it is a framework

within which you can employ various
processes and techniques.

> The Scrum framework consists of Scrum Teams and their associated roles, events,
artifacts, and rules. Each component
within the framework serves a specific purpose and is essential to Scrum’s success
and usage.

Scrum Theory
Scrum is founded on empirical process control theory, or empiricism. Three pillars
uphold every implementation of empirical

process control: transparency, inspection, and adaptation.

1. Transparency: Significant aspects of the process must be visible to those

responsible for the
outcome. Transparency requires those aspects be defined by a common standard so 4 a
observers share acommon understanding of what is being seen.

2. Inspection: Scrum users must frequently inspect Scrum artifacts and progress
toward a

Sprint Goal to detect undesirable variances. Their inspection should not be so

frequent that
inspection gets in the way of the work. Inspections are most beneficial when
diligently \

performed by skilled inspectors at the point of work.

3. Adaptation: If an inspector determines that one or more aspects of a process

deviate outside
acceptable limits, and that the resulting product will be unacceptable, the process
or the
material being processed must be adjusted. An adjustment must be made as soon as
possible

to minimize further deviation.

Respect
Lean Software Development Cig PRIOR GUERIN CUMESHT

> Lean Software Development (LSD) is an agile framework based on optimizing

development time and resources, climinating waste, and ultimately
delivering only what the productneeds.

> LSD method is based on the principle "Just in time production". It aims at
increasing speed of software development and decreasing cost.

> The Lean approachis also often referred to as the Minimum Viable’ Product (MVP)
strategy, in which a team releases a bare-minimum version of its
productto the market, learns from users what they like, don’t like and want to be
added, and then iterates based on this feedback.

> LSD actually borrows its philosophy from the manufacturing industry, which
originated the lean development process as a way to optimize production
and assembly lines to minimize waste and maximize customer value.

> In fact, it was originally called the Toyota Production System, because automaker
Toyota invented this approach in the middle of the twentieth century
as a way to streamline its production of cars and eliminate wasted time and
resources.

1. Eliminate Wastes: To maximize value, We must minimize Waste. For software

systems, Waste can take the form of partially done work, delays,
hand-offs, unnecessary features etc.

2. Empower the team: Rather than taking a micromanagement approach, we should

respect team members superior knowledge of the technical steps
required on the project and let them make local decisions to be productive and
successful.

3. Deliver Fast: We can maximize the project Return on investment (ROI) by quickly
delivering valuable software and iterating through designs. We

find the best solution through the Rapid Evolution of options

4, - Optimize the Whole: We aim to see the system as more than the sum of its
parts. We go beyond the pieces of the project and look for how it aligns with the

organization. As part of optimizing the whole, we also focus on forming better

inter-group relations. Eliminate Waste

build quality into the product and continually assure quality throughout the
development
process, using techniques like refactoring, continuous integration and unit
testing.

6. Defer Decisions: We balance early planning with making decisions and committing
to i S :
things as late as possible. For example. this may mean re-prioritizing the backlog
right up j=; LEAN
until it is time to plan an iteration, or avoiding being tide to an early
technology-bounded Defer Decisions © a Deliver Fast
solution. ° "

7. Amplify Learning: This concept involves facilitating communication early and

often,
getting feedback as soonas possible, and building on what we lear. Software
projects are
business and technology learning experiences, so we should start soon and keep
learning. Agile Lean Software Development

5. Build quality in: Lean development doesn’ ttry to “test-in” quality at the end;
instead, we Amplify Learnings
es i) oe Team

Build Quality in Optimize the Whole

Managing Iterative Processes Copyright © PROF. GUFRAN QURESHI

Booch supports the iterative and incremental development of a system. He defines

two processes describing the layout of Object
Oriented development: ‘

Macro process iterative Process

1. Establish core requirements (conceptualization). These five steps can be

repreated as

2. Develop a model of the desired behavior (analysis). many times as needed.

3. Create an architecture (design). : Planning and Requirements

, ‘ 3 tion is it

4. Evolve the implementation (evolution). ere Nieman,

5. Manage post delivery evolution (maintenance). Testing

Mi

1.

Evaluation and Review

cro process nu
Identify the classes and objects at a given level of abstraction. Planning and
Requirements

zt fn ey pay de
2. Identify the semantics of these classes and objects. Analysis andoesion [eration

3. Identify the relationships among these classes and objects. icles 2

4. Specify the interface and then the implementation of these classes and objects.
i apes

» Inprinciple, the micro process represent the daily activity of the individual
developer, _ Tsering anateasremane
or of a small team of developers. Here the analysis and design phases are
intentionally (“°! °“! ‘ :
blurred.

» The macro process serves as the controlling framework of the micro process. It
represents the activities of the entire development team on the scale of weeks to
months
at atime.

» The basic philosophy of the macro process is that of incremental development: the
system as a whole is built up step by step, each successive version consisting of
the
previous ones plus a number of new functions.
equirements

doesn Iteration

Selecting the most Appropriate Process Model Copyright © PROF. GUFRAN QURESHI

» The software process model framework is specific to the project. Thus, it is

essential to select the software process model according to
the software which is to be developed.

» The software project is considered efficient if the process model is selected

according to the requirements. It is also essential to
consider time and cost while choosing a process model as cost and/or time
constraints play an important role in software development.

» The basic characteristics required to select the process model are project type
and associated risks, requirements of the project, and the
users. /

» One of the key features of selecting a process model is to understand the project
in terms of size, complexity, funds available, and so
on. In addition, the risks which are associated with the project should also be
considered.

» It is possible to use two different approaches for the construction and

installation of an application. However, this is not possible with
the evolutionary approach where both the construction ‘and installation need to be
evolutionary.
» The table below will give us a brief idea of which process model is to be used in
the given conditions:
Factors Waterfall V-Shaped | Evolutionary Prototyping | Spiral | Iterative and
Incremental| Agile
Unclear User Requirement Poor Poor Good Excellent Good Excellent
Unfamiliar Technology Poor Poor Excellent Excellent Good Poor
Complex System Good Good Excellent Excellent Good Poor |
Reliable system Good Good Poor Excellent Good Good |
Short Time Schedule Poor Poor Good Poor Excellent Excellent |
Strong Project Management | Excellent Excellent Excellent Excellent Excellent
Excellent |
Cost limitation Poor Poor Poor Poor Excellent Excellent
Visibility of Stakeholders Good Good Excellent Excellent Good Excellent
Skills limitation Good Good Poor Poor Good Poor
Documentation Excellent Excellent Good Good Excellent Poor
Component reusability Excellent Excellent Poor Poor Excellent Poor |
yt

Ch-3 Software Effort Estimation REESE S|

Definition: In software development, effort estimation is the process of predicting

the most realistic amount of effort

(expressed in terms of person-hours or money) required to develop or thaintain

software based on incomplete, uncertain and

noisy input.

» Estimation techniques are of utmost importance in software development life

cycle, where the time required to complete a
particular task is estimated before a project begins.

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

value that can be used for some purpose even
if input data may be incomplete, uncertain, or unstable.

» Effective software project estimation is one of the most challenging and

important activities in software development.
Proper project planning and control is not possible without a sound and reliable
estimate. As a whole, the software industry
doesn’t estimate projects well and doesn’t use estimates appropriately. We suffer
far more than we should as a result ands we
need to focus some effort on improving the situation. :

>» Under-estimating a project leads to under-staffing it (resulting in staff

burnout), j Estimate too low: >) eo
under-scoping the quality assurance effort (running the risk of low quality
\Etptanning alata “
deliverables), and setting too shorta schedule (resulting in loss of credibility as
a el f

deadlines are missed). Actual

» For those who figure on avoiding this situation by generously padding the Effort

estimate, over-estimating a project can be just aboutas bad for the organization!

If you give a project more resources than it really needs without sufficient scope

controls it will use them. The project is then likely to cost more than it should
(a

negative impact on the bottom line), take longer to deliver than necessary x .
(resulting in lost opportunities), and delay the use of your resources on the next
FA
project. Estimated Effort
Where are the Estimates Done? Copyright @ PROF. GUFRAN QURESHI

» Before the estimation process begins the scope of the project needs to be
understood. It is helpful to have historical data

in the form of project metrics at hand. Project metrics provide valuable input for
the generation of quantitative estimates.

» Contrary to the belief that estimation is a one time task it is an ongoing

process that is conducted at various stages of the

project. The primary stages at which estimating is done are as follows:

1. Strategic Planning: Strategic planning is the process of documenting and

establishing a direction of your small
business—by assessing both where you are and where you're going. The strategic plan
gives you a place to record your
mission, vision, and values, as well as your long-term goals and the action plans
you'll use to reach them.

2. Feasibility Study: A feasibility study is an analysis that takes all ofa

project's relevant factors into account—including
economic, technical, legal, and scheduling considerations—to ascertain the
likelihood of completing the project
successfully.

3. System Specification: The System Requirements Specification (SRS) (also knownas

a Software Requirement
Specification) document describes all data, functional and behavioral requirements
of the software under production or
development.

4. Evaluation of Suppliers Proposals: The proposal evaluation techniques refer to

the process of reviewing the proposals
given by the suppliers to support the contract award decisions of the buyer and the
project team.

5. Project Planning: It is the process you go through to establish the steps

required to define your project objectives,
clarify the scope of what needs to be done and develop the task list to do it..

+-50% Estimate +-30% Estimate +-10% Estimate

Historical Conceptual Detailed Unit-Rate

Extrapolation Estimate Estimate
Problems with Over and Under Estimates Copyright © PROF. GUFRAN QURESHI

» Given the number of variables and the volatile project environment no estimate is
going to perfect even when the project
manager is provided with project metrics from historical projects. Thus, it is
unlikely that the estimate will be right in the
first place.

» Forany projecttask, it is unlikely that your estimate of how long it will take
will be perfect. So, is it worse to overestimate
the time it will take to complete a task or underestimate it?

Cost of overestimation:

1. Overestimation creates the problem that the estimate become self-fulfilling. The
task takes longer than it would have done
with a more accurate estimate in place.

2. There are two ideas behind this linked to how people behave. Firstly, Student’s
Syndrome states that people often won’t
start working until very close to a deadline. Secondly, Parkinson’s Law states that
work expands to fill the time available.

3. Therefore, if you havea task with overestimated length, the impact is the task
might take longer than it ‘should’ do.

Costs of underestimation:
1. Ifatask is assumed to take long time than it actually needs, one of .

two things will happen. Either the task gets done at lower quality, or eee
the task doesn’t get done on time and any tasks dependent on it are . eee we
pushed out. / fi ' 7

2. Whilst obviously accurate estimates are the best outcome, over- ' Undersinte —
estimation is less bad than underestimation. / \ od

3. Underestimation can impact dependencies and the overall quality of

the project. Overestimation may be wasteful for the resources ona

particular task, but it is less likely to impact other tasks or overall

quality.

- —— How humans think about the future

Overestimate

—— How technological praductivity develops

>
The Basis of Software Estimating Copyright © PROF. GUFRAN QURESHI

» The basis of estimates is an important tool in project management. It involves

estimators and project managers to calculate the total
cost needed for the entire project. It is used to support proposals, bidding and
executing a project.

>» Effective software project estimation is an important activity in any software

development project. One of the main reasons software
programs fail is our inability to accurately estimate software size.

» Because we almost always estimate size too low, we do not adequately fund or
allow enough time for development. Poor size
estimates are usually at the heart of cost and schedule overruns.

>» All estimates are made based upon some form of analogy: Historical Analogy,
Expert Judgment, Models, and Rules-of-Thumb. The
role these methods play in generating an estimate depends upon where one is in the
overall life-cycle.

Step 1: Gather and Analyze Software Functional & Programmatic Requirements: In this
step we Analyze and refine software

requirements, software architecture, and programmatic constraints.

Step 2: Define the Work Elements and Procurements: The purpose of this step is to
define the work elements and procurements for

the software project that will be included in the software estimate.

Step 3: Estimating the size of the project: Estimating the size of the software to
be developed is the very first step to make an effective

estimation of the project. A customer's requirements and system specification forms

a baseline for estimating the size of a software.

Step 4: Estimating the Effort: When we are finished with the size estimation
process, the next step is to estimate the effort based on

the size. The estimation of effort can be made from the organisational specifics

of the software development life cycle.

Step 5: Estimating Schedule: After estimating the efforts, estimating the project

schedule from the effort estimated is the next step in the estimation process. The

schedule for a project will generally depend on human resources involved in a

process.

Step 6: Estimating the cost: To estimate the total cost of the software project is
the

purpose of this step. The cost of a project is derived not only from the estimates
of

effort and.size but from other parameters such as hardyare, travel expenses,
telecommunication costs, training cost etc. should also be taken into account.

Leg
Requirements

Piet er

Data from
Prada ce [a

bars cp rLe ci
Schedule

Estimate Efforts

Estimate Cost
Gq

Software Effort Estimation Techniques Copyright © PROF. GUFRAN QURESHI

Barry Bochm in his classic work on software effort models, identified the main ways
of deriving estimates of software
development effort as:

1. Algorithmic models - which use 'effort drivers’ representing characteristics of

the target system and the implementation
environment to predict effort;

Expert judgement - where the advice of knowledgeable stall" is solicited;

Analogy - where a similar, completed, project is identified and its actual effort
is used as a basis for the new project;
Parkinson - which identifies the staff effort available to do a project and uses
that as the ‘estimate’;

Price to win - where the 'estimate' is a figure that appears to be sufficiently low
to win a contract;

Top-down - where an overall estimate is formulated for the whole project and is
then broken down into the effort required
for component tasks;

7, Bottom-up - where component tasks are identified and sized and these individual
estimates are aggregated.

Awe wh

Heuristic/
Expert Judgments
Techniques

> Clearly, the 'Parkinson' method is not really an effort prediction method, buta
method of setting the scope ofa project. Similarly, ‘price to win' is a way of
deciding a price and not a prediction method.

» On these grounds. Boehm rejects them as prediction techniques although they

might have some value as management techniques. There is, for example, a
perfectly acceptable engineering practice of 'design to cost’ which is one example

~ of the broader approach of ‘design by objectives’.

Parametric’
Algorithmic
Techniques
Software Effort
Estimation Techniques

Regression
Techniques

Soft

Analogy
s Computir
Techniques Techniques

Bottom-Up Estimate Copyright © PROF. GUFRAN QURESHI

>» Bottom-up estimating is a project management technique in which the people who
are going to do the work take part in the
estimating process.

> Typically those people are the employees, vendors and other project team members.
They work with you, the project
manager, to develop estimates for tasks in the work breakdown structure (WBS).

> Setting the estimates of the amount of work, duration and cost at the task level
lets you combine them into estimates of
higher-level deliverables and the project as a whole.

>» Bottom-up estimating tends to develop a higher level of project team commitment
than other types of estimates (like
parametric and analogous).

Advantages:

1. Increased Company-Wide Communication: When every employee actively participates

in the decision-making process,

the overall communication among members of the organization will increase

significantly.
2. Build Morale: All members of the business community will feel included and
valued, which fosters a supportive and
communicative environment where employees can thrive and grow together. z
3. Increased Collaboration: Employees of all levels are granted the opportunity
to discuss problems, bounce ideas off of one another, and build trust across qT
departments. 5 :
Disadvantages: i Time, a
1. Bogging Down of Employees: Employees can be taken away from their own Apply
engineering principles
tasks and pulled into larger projects, causing them to lose precious time.
2. Inaccurate Reflections of Data: A variety of people working on the same
Breakdown work tasks

projects simultaneously can cause skewed results and inaccurate decisions in the 2
long term. Bottom-up
The Top-down Approach and Parametric Models Copyright © PROF. GUFRAN QURESHI

» “Top-down” means that all the project objectives, guidelines, information, plans,
and fund processes are established by
management, and expectations are communicated down to each project participant.

>» A"top-down" approach is where an executive decision maker or other top person
makes the decisions of how something
should be done.

» Companies utilize the top-down approach in order to assess, determine, and

implement business decisions made by upper
executives,

» The processes are streamlined and communicated to lower rank employees, who carry
out these tasks.

Advantages:

1. Decreased Risk: Since the highest level of managementis also usually the most
informed and most knowledgeable about
the business, there is a decreased risk involved in the decision-making process.

2. Strong Management: The upper authorities in a company will be able to determine

best practices and reach goals easier.
with decisions created and enforced at the highest ranks ofa business. \

3. Good Organization: Tasks are determined and filtered down company lines without
any confusion because business
goals are set by upper management and will not be affected by outside opinions.

Disadvantages:

1. Limited Creativity: Employees are siloed (isolated) in their responsibilities

and are unable to contribute to the overall goals of the company —
sometimes leading to frustration and a lack of motivation to perform. Normalize,
develop correlations

2. Slow Response to Challenges: When a challenge arises as a result ofa

decision, it can take time for upper management to establish a solution
because there are limited minds contributing to decisions.

Top-down

Gather, integrate historic data

Empirical models

(ontsd estimate

Algo rithmic / Parametric Models Copyright © PROF. GUFRAN QURESHI

» A parametric model is a set of related mathematical equations that incorporates
variable parameters. A scenario
is defined by selecting a value for each parameter.
» Software project managers use software parametric models and parametric
estimation tools to estimate their projects’
duration, staffing and cost.
» This technique can produce higher levels of accuracy depending upon the
sophistication and the underlying data built into
the model. ,
» Inorder for parametric models to have any validity they must be based on or
proven using actual project data.
» The prime advantage of these models is that they are objective, repeatable,
calibrated and easy to use, although calibration
to previous experience may be a disadvantage when applied to a significantly
different project.

Expert Judgement

» Expert Judgmentis a term that refers a specifically to a technique in which

judgment is made based upon a specific set of
criteria and/or expertise that has been acquired in a specific knowledge area, or
product area, a particular discipline, an
industry, etc. :

® Itis quite often recommended as one among the best tools and techniques in the
project management processes.

> Experts are treated as assets in any organization and provide inputs to planning
and estimating any activity as their
opinions are considered to be crucial.

>» The experts can be stakeholders or customers. Expert Judgment is one of the best
accepted approaches and most useful too
during the planning phases of many activities.

» The approach not only saves the time during the planning butalso highlights risks
to be considered while executing. It also
improves the quality of the estimates and provides accurate forecasts.

> Experts’ opinions are considered throughout the risk management processes to
reduce the impact of the projectrisks.

> Expert judgment is inevitable during the project life cycle and sorted across all
knowledge areas in effective project
management.
5 \

IN QURESHI

Estimating by Analogy Copyright © PROF. GUF

» Analogous estimating is a common techitique in project management to determine

cost, schedule or resource estimates.

» It is often used in situations where a rough estimate meets the needs of the
stakeholders or at a time when not many details are
known about a project.

» Applying the technique involves the selection of similar projects, the processing
of historical data and compilation of the
estimate(s).

» Analogous estimating is the act of using former projects to estimate how long or
how much a current project will take or cost. In
other words, it is a technique that centers on comparison.
>» These areas are covered in this 5-step guide to analogous estimating.
Identify Similar Projects: The first step is to identify projects or types of work
that are similar to the current endeavor, Some
companies have databases where they store data on historical projects, including
their scope, complexity, efforts and time needed
for their completion.
2, Gather Historical Data and Experience: Once you have found similar projects or
experts, you will have to gather the relevant
data. A data set for analogous estimations typically consists of a combination of
cost, time and resources-related information.
3. Compare Characteristics of Projects: Select the projects with characteristics
that
are similar to your project, You can do this by applying expert judgment or — in
case ofa
larger number of previous projects — by developing akind of scoring system.
4. Select the Type of Analogous Estimate: Decide whether your result should be a
one- @@R===5

—_

Sette
at

: 3 % “ ‘ Value(s) that Fit Rs uig

point estimate, a ratio estimate, a range or a three-point estimate. In the latter
case, you (iar pees
might also consider using the triangular or PERT method to determine a final
estimate.

5. Choose the Value(s) that Fit for Your Current Project: Once you have decided
about
the type of value that you are going to estimate, you need to pick the right
reference
project(s). For a range estimate, you will typically choose the lowest and highest
value,
respectively, from projects similar to yours. re Sa Fe
ROF. GUFRAN QURESHI

Albrecht / IFPUG Function Point Analysis

» Function point analysis is a standard method for measuring software development

from the user's point of view. It provide a
standardized method for measuring the various functions of a software application.

» FP (Function Point) is the most widespread functional type metrics suitable for
quantifying a software application. It is
based on five users identifiable logical "functions", which are divided into two
data function types and three transactional
function types.

» For a given software application, each of these elements is quantified and

weighted, counting its characteristic elements,
such as file references or logical fields.

Let us now understand how to apply the Albrecht’s Function Point method. Its
procedure is as follows —

Determine the number of components (El, EO, EQ, ILF, ad ELF)

1, El — The number of external inputs. These are elementary processes in which

derived data passes across the boundary

from outside to inside. In an example library database system, enter an existing

patron's library card number.

2, EO — The number of external output. These are elementary processes in which

derived data passes across the boundary

from inside to outside. In an example library database system, display a list of

books checked outto a patron.

3. EQ - The number of external queries. These are elementary processes with both
input and output Other applications

components that result in data retrieval from one or more internal logical files
and external interface files. |( Harddisk , CD, Server etc. }
In an example library database system, determine what books are currently checked
outto a patron.
4, ILF — The number of internal log files. These are user identifiable groups of
logically related data eat al. (es
that resides entirely within the applications boundary that are maintained through
external inputs.
In an example library database system, the file of books in the library.
5. ELF — The number of external log files. These are user identifiable groups El &
@
of logically related data that are used for reference purposes only, and | ycers
which reside entirely outside the system. In an example library database fa
Sorliaiiaeslen aise

system, the file that contains transactions in the library's billing system.
Calculation of Function Point (FP) , Copyright © PROF. GUFRAN QURESHI

Step-1: F= 14x scale

Scale varies from 0 to 5 according to character of Complexity Adjustment Factor

(CAF).

0 = No Influence, 1 =-Incidental, 2 = Moderate, 3 = Average, 4 = Significant, 5 =

Essential.
Step-2: Calculate Complexity Adjustment Factor (CAF).

CAF = 0.65 + (0.01 x F)-

Step-3: Calculate Unadjusted Function Point (UFP). Table (Required)

FUNCTION UNITS LOW AVG HIGH

EI 3 4 6
EO 4 5 7
EQ 3 4 6
ILF 7 10 15
EIF 5 7 10

Multiply each individual function point to corresponding values in TABLE.

Step-4: Calculate Function Point.

FP=UFP x CAF

Copyright © PROF. GUFRAN QURESHI

Example:

Given the following values, compute function point when all complexity adjustment
factor (CAF) and weighting factors are
average.
User Input = 50

User Output = 40

User Inquiries =35

User Files = 6

External Interface = 4

Solution:
Step-1: As complexity adjustment factor is average (given in question), hence,
scale = 3
F=14x3=42

Step-2: Calculate Complexity Adjustment Factor (CAF).

CAF = 0.65 + (0.01 x 42) = 1.07

Step-3: As weighting factors are also average (given in question) hence we will
multiply each individual function point to
corresponding values in TABLE.

UFP = (50x4) + (40x5) + (35x4) + (6x10) + (4x7) = 628

Step-4:

Function Point = 628 x 1.07 = 671.96

© PROF. GUFRAN QURESHI

Example:

Given the following values, compute futictlon point when all complexity adjustment
factor (CAF) is Essential.
User Input= 30 (simple)

User Output = 25 (Average)

User Inquiries = 20 (Average)

User Files = 10 (Simple)

External Interface = 12 (High)

Solution: Function Point = 654.75

Example:

Given the following values, compute function point when all complexity adjustment
factor (CAF) is Moderate.
User Input= 20 (High)

User Output= 45 (Low)

User Inquiries = 30 (Average)

User Files = 40 (Low)

External Interface = 9 (High)

Solution: Function Point = 734.7

Function Point Mark II Copyright © PROF. GUFRAN QURESHI

» Mark IJ is a size estimation technique of a software product. It belongs to the

class of functional point group of

measurements.

» Traditionally, software size was measured in terms of the number of source code
lines (SLOC or KLOC). The amount of
SLOC had a direct association with the relative size of software. Mark I is also
known as Mark II Function Point Analysis.

» Functional size measurement technique is the only ISO standardised technique,

that enables measuring the size of the Users
Functional Requirements.

> Functional requirements are of an independent nature , hence it can measured

irrespective of any other non-functional or
technical requirements. Itis therefore an efficient technique to measure the
effective of a software product.

Mark II FPA (Functional Point Analysis) counting rules:

1. Define the boundary count -The logical line that separates a user from the
system is called the boundary. It simply

determines the rules for user's entry and exit in the system.

2. Identify logical transactions -The number of logical transactions are counted.

3. Identify and Categorise Data Entity Types -Entities are the components that
convey a meaningful information to the user.
4. Count the data: Count the input data element types, the data entity types
referenced and output data element types.. It specifies the rules to enlist the
total Database
number of input types its references and prepare a complete report of the same. ,
5. Count the functional size -Now when the objects in the system and the Entily
data types

transactions are identified, they can be considered for finding the functional size
of
the system. The functional size of the system is counted as the number of
input/exit
transactions between the user and the system. _ oF Oty Lt.

Input data Output data

types types:

W
COSMIC Full Function Points Copyright © PROF, GUFRAN QURESHI

» COSMIC function points are the unit of measure of software functional size. The
process of measuring software size is
called functional size measurement (FSM).

» COSMIC functional size measurement is applicable to business, real-time and

infrastructure software at any level of
decomposition.

» It is independent of the technology or processes used to develop the system. It

is an ISO standard. It is a refined
improvement over its predecessors (IFPUG and Mark II FP).

» The COSMIC FFP measurement method defines an explicit model of software

functionality, derived from the functional
user requirements.

> Four types of data movement-ENTRY, EXIT, READ, aid WRITE-are defined within this
model. They form the basis for

defining the standard unit of functional size.

Entry: An ENTRY (E) is a movement of the data attributes found in one data group
from the user side of the software

boundary to the inside of the software boundary. An ENTRY (E) does not update the
data it moves.

Functional Users

2. Exit: An EXIT (X) is amovement of the data attributes found in one data Pan
group from inside the software boundary to the user side of the software 9g --- soe
pe eoceecneens leet cae

boundary. An EXIT (X) does not read the data it moves. Functional 8]

Read: A READ (R) refers to data attributes found in one data group. com |”) fae

Functionally, a READ sub-process brings data from storage, within reach ee] Le

of the functional process to which it belongs.

4. Write: A WRITE (W) refers to data attributes found in one data group.
Functionally, a WRITE sub-process sends data lying inside the functional
process to which it belongs to storage.

3
Persistent
storage

COCOMO II: A Parametric Productivity Model Copyright © PROF. GUFRAN QURESHI

» COCOMO-II is the revised version of the original Cocomo (COnstructive COst MOdel)
and is developed at University of
Southern California by Barry Boehm. It is the model that allows one to estimate the
cost, effort and schedule when planning
a new software development activity.

» COCOMO-I1is an alternative to include components of uncertainty according to

level of information available.

» It is a parametric model that establishes mathematical equations that describe

the relationships between software size -
primary cost factor usually represented in terms of function points - and other
secondary factors that look to identify features
ofa product, process, people and platform. These factors are known as cost drivers.

>» The model provides a complete framework to determine local productivity factors
based on time & effort data in past projects.

» It consists of three sub-models:

1. End User Programming: Application generators are used in this sub-model. End
user write the code by using these
application generators. Example — Spreadsheets, report generator, etc.

2. Intermediate Sector:

(a). Application Generators and Composition Aids — This category will create
Application

largely prepackaged capabilities for user programming. Their product will have
coubosion .

many reusable components. Typical firms operating in this sector are Microsoft,

Lotus, Oracle, IBM, Borland, Novell. End User Application | infrastructure

(b). Application Composition Sector — This category is too diversified and to be |

Prs@™™ing | composition
handled by prepackaged solutions. It includes GUI, Databases, domain specific
components such as financial, medical or industrial process control packages. ne .
(c). System Integration — This category deals with large scale and highly =
embedded systems.

3. Infrastructure Sector: This category provides infrastructure for the software

development like Operating System,
Database Management System, User Interface Management System, Networking System,
etc.
>

>

Cost Estimation Copyright

Cost estimation in project management is the process of forecasting the financial
and other resources needed to complete a
project within a defined scope.

Cost estimation accounts for each element required for the project—ftom materials
to labor—and calculates a total amount
that determines a project’s budget.

) PROF. GUFRAN QURESHI

Elements of cost estimation in project management:

There are two key types of costs addressed by the cost estimation Requirements
Effort

process:

1. Direct costs: These are the costs associated with a single area, oa amen
Duration
such as a department or this particular project itself. Examples
of direct costs include fixed labor, materials and equipment. ;

2. Indirect costs: These are costs incurred by the organization at One oe Loading
large, such as utilities and quality control.

» Ina classical view of software estimation process, the software requirements are
the primary input to the process and also
form the basis for the cost estimation.

» Cost driver is anything that may or will affect the cost of the software. Cost
driver are things such as design methodology,
skill-levels, risk assessment, personnel experience, programming language or system
complexity.

> In aclassical view of the estimation process, it will generate three outputs -
efforts, duration and loading. The following is
a brief description of the outputs:

a. Manpower loading - number of personnel (which also includes management

personnel) that are allocated to the project

>
>

>

>

>

Where E is the effort required at time t. E is an indication of the number of

engineers (or the staffing level) at any particular time during the duration of the
project, K is the area under the curve, and t, is the time at which the curve
attains

its

It must be remembered that the results of Norden are applicable to general R & D
projects and were not meant to model the staffing pattern of software development

as a function of time.

. Project duration - time that is needed to complete the project.

Effort - amount of effort required to complete the project and is usually measured
in units as man-months (MM) or
person-months (PM).
Staffing Pattern Copyright © PROF. GUFRAN QURESHI
Once the effort required to develop a software has been determined, it Effort cost
is necessary to determine the staffing requirement for the project. estimation
estimation
Putnam first studied the problem of what should be a proper staffing
pattern for software projects. Size
He extended the work of Norden who had earlier investigated the estniation
staffing pattern of research and development (R&D) type of projects. -
In order to -appreciate the staffing pattern of software projects,
Norden’s and Putnam’s results must be understood. Duration Project scheduling
estimation staffing
Norden’s Work
Norden studied the staffing patterns of several R & D projects. He found that

the staffing pattern can be approximated by the Rayleigh distribution curve (as
shown in fig). It specifies the relationship between applied effort and delivery
time for a software project.

Norden represented the Rayleigh curve by the following equation:

E=KA,xtxet/?ta

maximum value.

projects. Itis also called Putnam-Norden-Rayleigh curve or PNR curve.

Copyright G PROF. GUFRAN QURESHI
Putnam’s Work
» Putnam studied the problem of staffing of software projects and found in the
software development has characteristics
very similar to other R & D projects studied by Norden.
> He too observed that the Rayleigh-Norden curve can be used to relate the number
of delivered lines of code to the effort
and the time required to develop the project.
» By analyzing a large number of army projects, Putnam derived the following
expression:

L=C, K'St, #8 Putnam Model

The various terms of this expression are as follows:

* K is the total effort expended (in PM) in the product development and L is 18
_the product size in KLOC.

* td corresponds to the time of system and integration testing. Therefore, td can

be approximately considered as the time required to develop the software.

« C, is the state of technology constant and reflects constraints that impede the
aad nae
progress of the programmer. Typical values of C, = 2 for poor development al om
environment (no methodology, poor documentation, and review, etc.), C, = 8
for good software development environment (software engineering principles

are adhered to), C,, = 11 for an excellent.

>» The exact value of C, fora specific project can be computed from the historical
data of the organization developing it.

> Putnam suggested that optimal staff build-up on a project should follow the
Rayleigh curve. Only a small number of
engineers are needed at the beginning of a project to carry out planning and
specification tasks. As the project progresses
and more detailed work is required, the number of engineers reaches a peak. After
implementation and unit testing, the
number of project staff falls.

Based on Rayliegh curve - > skewed, median & mean

offset from one another

PROF. GUFRAN QURESHI

Effect of Schedule Compression copyrigh

Schedule compression is a technique used in project management to shorten an

already developed schedule. This might be done
to meet an update delivery date, a new opportunity or schedule delay. It’s done
without changing the scope of the
program. There are two techniques that are commonly used in schedule compression.
These are:

1. Crashing

2. Fast Tracking

Crashing
» Crashing assigns more resources to an activity to decrease the overall CRASHING
time to complete it.

» The cost benefits of this activity have to be explored in order to make ez]
iceman - a]
it a useful technique.

>» The trade-off between cost and schedule must be understood:to get the
best possible schedule compression.

FAST TRACKING

’ Fast Tracking
» Fast Tracking is the process of executing activities or phases that were

originally schedule sequential in parallel. >

» Activities can be overlapped, started earlier than proposed, start
activities that require different resources, and maybe combined

activities in the schedule.

» This process does add risk to the schedule and Program and must be
executed with care.
5}

Capers Jones Estimating Rules of Thumb Copyright © PROF. GUFRAN QURESHI

Capers Jones in the year 1996 formulated simple rules based on his experience in
estimating various parameters of large

software projects.

The objective behind formulating these rules was to provide the project manager
with estimating rules which would be easy to

use and yet provide him with a fairly good idea of the various aspects of the
project.

Rules Formulated by Capers Jones

> Rule 1: SLOC Function Point Equivalence - SLOC technique helps in developing
better understanding of the size of the
project and also estimating several other project parameters. However, when it
comes to estimating the size of the project
the function point analysis is used on account of its advantages. Thus, it becomes
necessary for the project manager to
determine SLOC measure from its function point measurement.

> Rule 2: Project Duration Estimation - Function points raised to the power 0.4
predicts the approximate development time
in calendar months. E.g. If the size of a project is estimated by 325 function
points ie. approximately 40,000 SLOC then the
completion time for the project would be approximately 10 months.

> Rule 3: Rate of Requirement Creep - Requirement creep is the increase in the
requirements of the user and these keep on
increasing for a variety of reasons as the project progresses. User requirements
creep in at an average rate of 2% per month
from the design through coding phases. eee

> Rule 4: Defect Removal Efficiency - Each software review, inspection or test step
will find
and remove 30% of the bugs that are present. Defect removal steps at various stages
of the
project development ensure that the final product is reliable.

> Rule 5: Project Manpower Estimation - The size of the software in function points
divided
by 150 predicts the approximate number of personnel required for developing the
application.

> Rule 6: Software Development Effort Estimate - The approximate number of staff
months
required to develop software is given by the software development time multiplied
by the
number of personnel required.

Unit III

Ch 6: Activity Planning: Introduction, Objectives of Activity Planning, When to

Plan, Project Schedules,
Projects and Activities, Sequencing and Scheduling Activities, Network Planning
Models, Formulating a
Network Model, Adding the Time Dimension, The Forward Pass, Backward Pass,
Identifying the Critical
Path, Activity Float, Shortening the Project Duration, Identifying Critical
Activities, Activity-on-Arrow
Networks.

Ch 7: Risk Management: Introduction, Risk, Categories of Risk, Risk Management

Approaches, A
Framework for Dealing with Risk, Risk Identification, Risk Assessment, Risk
Planning, Risk Management,
Evaluating Risks to the Schedule, Boehm“s Top 10 Risks and Counter Measures,
Applying the PERT
Technique, Monte Carlo Simulation, Critical Chain Concepts.

Ch 8: Resource Allocation: Introduction, Nature of Resources, Identifying Resource

Requirements,

Scheduling Resources, Creating Critical Paths, Counting the Cost, Being Specific,
Publishing the Resource
Schedule, Cost Schedules, Scheduling Sequence.

Copyright © PROF. GUFRAN QURESHI!

Ch-6 Activity Planning : Copyright © PROF. GUFRAN QURESHI
Definition: The first task is defining the term activity. In reference to project
management, the term activity means a specific
event or occurrence. Activity planning begins with outlining the structure of work
breakdown. The goal of activity planning is
pinpointing activities required to achieve deliverables. It addresses this
question: “What activities are to be performed to meet
the requirements of the work package?” The data gathered to answer this question is
the lineup of activities arran gedina

sequence. This sequence is knownas activity planning in project management. + beans

tetins
(--)
+ Activity Attributes
+ Milestone List
achievabili

prise

Objectives / Necessity of Activity Planning iene

The objective of software project planning is to provide a framework that enables

"="

the manager to make reasonable estimates of resources, cost, and schedule

1. Feasibility assessment: Is the project possible within required timescales anc

2. Resource allocation: What are the most effective ways of allocating resources to
the project. When should the resources be
available? The project plan allows us to investigate the relationship between
timescales and resource availability

3. Detailed costing: How much will the project cost and when is that expenditure
likely to take place? After producing an
activity plan and allocating specific resources, we can obtain more detailed
estimates of costs and their timing.

4. Motivation: Providing targets and being seen to monitor achievement against

targets is an effective way of motivating
staff, particularly where they have been involved in setting those targets in the
first place.

5. Co-ordination: When do the staff in different departments need to be available

to work on a particular project and when
do staffneed to be transferred between projects? The project plan, particularly
with large projects involving more than a
single project team, provides an effective vehicle for communication and
coordination among teams.

Activity planning and scheduling techniques place an emphasis on completing the

project in a minimum time at an acceptable

cost or, alternatively, meeting a set target date at minimum cost.

Cefine Activities
resource constraints? It is not until we have constructed a detailed plan that
“Rating hve | Sele
we can forecast a completion date with any reasonable knowledge of its + Tepes oe
+ Expert Judgment.

When to Plan Copyright © PROF. GUFRAN QURESHI

The project planning phase comes at the start of the project: it’s after the
initiation phase where all you’ve really done is got
approval to go ahead and put the basics in place and before the delivery phase
where you actually do the work.
2. We plan at the beginning to save time later. A good plan means that,
a. You don’thave to worry about whether those people are going to be available on
the right dates—because you’ve
planned for them to be.
b. You don’thave to worry about how to pay those invoices—because you've planned
your financial process.
c. You don’thave to worry about whether everyone agrees on whata quality outcome
looks like—because you’ve
already planned what quality measures you are going to use.
3. Project plans are also really helpful for monitoring progress. You can go back
to them and check what you said you were
going to do and how, comparing it to what you are actually doing, This gives you a
good reality check and enables you to
change course if you need to, bringing the project back on track.

The best way to estimate how long your project planning phase will
take is to look at similar projects that have happened before and see
how long it took them to plan.

The most important thing to remember is that you shouldn’t rush

project planning. Done properly, project planning takes time. And it’s
worth doing it properly because if you don’t, we guarantee that you will
hit problems later on as people won’t understand what they are
supposed to do and why.

execute the pest

specify assess.
any what

CONTROL] remedial has

i action been

needed achieved
compare achievements against plan
Project Schedules Copyright

GUFRAN QURESHI

Definition: The project schedule indicates what needs to be done, which resources
must be utilized, and when the project is

due. In short, it's a timetable that outlines start and end dates and milestones
that must be met for the project to be completed

on time.

> Itis the roadmap ofall activities to be done with specified order and within time
slot allotted to each activity.

>» The project schedule is often used in conjunction with a Work Breakdown
Structure (WBS) as a way to evenly distribute
work among team members. The project schedule should be updated on a regular basis
in order to gain a better
understanding of the project's current status.

Creating a project schedule comprises four main stages.

First step: First step in producing the plan is to decide what activities need to
be carried out and in what order they are to be

done. From this we can construct an ideal activity plan — that is, a plan of when
each activity would ideally be undertaken

were resources not a constraint. This activity plan is generated by Steps 4 and 5
of Step Wise.

Second step: The ideal activity plan will then be the subject of an activity risk
analysis, aimed at identifying potential
problems. This might suggest alterations to the ideal activity plan and will almost
certainly have implications for resource
allocation. i

Third step: This is the resource allocation step. The expected availability 1 “s ot
of resources might place constraints on when certain activities can be = go ee

carried out.
Fourth step: This is the schedule production step: The production
schedule is a project plan of how the production budget will be spent over
a given timescale, for every phase of a business project.

sere)
PROJECT

SCHEDULING

t © PROF, GUFRAN QURESHI

Projects and Activities copyi

Defining activities; A project is composed of a number of related activities. A

project may start when at least one of its

activities is ready to start. A project will be completed when all of its

activities have been completed. An activity must havea

clear start and a clear stop. An activity should havea duration. Some activities
may require that other activities are completed

before they can begin.

Identifying activities

There are three approaches to identifying the activities or tasks that make up a
project — the activity-based approach, the

product-based approach and the hybrid approach.

1. The activity-based approach

> The activity based approach consists of creating a list of all the activities
that the project is thought to involve.

» This might involve a brainstorming session involving the whole project team or it
might stern from an analysis of similar
past projects.

> When listing activities, particularly for a large project, it might be helpful to
subdivide the project into the main lifestyle
stages and consider each of these separately.
>» Generating a task list is to create a Work Breakdown Structure (WBS). This
involves identifying the main (or high level)
tasks required to complete a project and then breaking each of these down into a
set of lower level tasks.

> Activities are added to a branch in the structure if they directly

contribute to the task immediately above — if they do not contribute to
the parent task, then they should not be added to that branch. Ee “ | wm |

» The tasks at each level in any branch should include everything that is —= i Sc
required to complete the task at the higher level — if they are nota | Sa a : sein
| : Selon :
comprehensive definition of the parent task, then something is missing.

When preparing a WBS, consideration must be given to the final level

of detail. 2 A fragment of an activity-based Work Breakdown Structure
2. The product based approach
> Itconsists of producing a Product Breakdown Structure and a Product Flow
Requrements
Diagram. oi

» The PFD indicates, for each product, which other products are required as ce
seats I
inputs. on ae setae

» The PFD can therefore be easily transformed into an ordered list of activities -
—a
by identifying the transformations that turn products into others. acu | | cor,

» This approach is particularly appropriate if using a methodology such as - ee

Structured Systems Analysis and Design Method (SSADM), which clearly tee |] fanaa
1) stron |] EE | Leoatpeence
specifies, for each step or task, each of the products required and the —— —
activities required to produce it, wide || Ey = tegen || ee taney

The hybrid approach

> The WBS illustrated in Figure is based entirely on a structuring of activities.

> WBS may be based upon the project's products as illustrated in Figure which

is in turn based ona simple list of final deliverables.and, for each

x
Software
components

I
User
manuals

1
Training
course

Installed
system

deliverable, a set of activities required to produce that product.

Analyse Analyse

requirements

eview
Fequirements| requirements

requirements

>» Figure illustrates a flat WBS and it is likely that, in a project of any size,
it

2 - oa = Outline Outline Design Desi

would be beneficial to introduce additional levels — structuring both design |
design marwal | course
products and activities. eign _| ‘cesign | eet |
Integrate
system

Capture
screens

» The degree to which the structuring is -- product based or activity based

Code
software

Print
handouts

might be influenced by the nature of the project and the particular

Test
software

Do page Deliver
layout course

Test
system

development method adopted.

>» As witha purely activity based WBS, having identified the activities we are

then left with the task of sequencing them.

Print
manuals

Deliver

system
User

testing

Sequencing and Scheduling Activities Copyright © PROF. GUFF

Definition: Sequencing and Scheduling are two very important aspects that assist
with structuring and ordering the
transformation processes. Sequencing refers to the order in which activities in the
operations process occur. Scheduling refers
to the length of time activities take within the operations process.
> Throughout a project, we will require a schedule that clearly indicates when each
of the project’s. $ activities is planned to
occur and what resources it will need.
>» One way of presenting such a plan is to use a bar chart as shown in the diagram.
In drawing up the chart, we have done two
things:-
a. Sequencing the tasks i.e., identified the dependencies among activities dictated
by the development process.
b. Scheduled them i.e., specified when they should take place.

> The scheduling has had to take account of availability of

staff and the way in which the activities have been allocated
to them.

>» The schedule might look quite different were there a

different number of staff or were we to allocate the activities
differently.

» In the case of small projects the combined sequencing—

scheduling approach might be quite suitable, particularly
where we wish to allocate individuals to particular tasks at
an early planning stage.

However, on larger projects it is better to separate out B : Specify module 1 G:

Code module 2
these two activities: to sequence the tasks according to Few: lee
their logical relationships and then to schedule them taking Es oode moa
into account resources and other factors.

Task : Person
A: Andy
B : Andy
C: Andy
D: Andy
E> Bill
F: Bill
G: Charlie
H:

1: Dave

Activily key A: Overall design F: Code module 3

W
Network Planning Models Copyright © PROF. GUFRAN QURESHI

Definition: Network planning is a technique that is helpful in planning,

scheduling, and controlling the projects that consists of

many interrelated activities.

Gantt Chart

> Network planning techniques are often compared with somewhat familidt bd known as
Gantt Chart. This is an older planning and
scheduling tool, however it remains popular because of its simplicity.

» Henry Gantt, an American mechanical engineer, and social scientist designed the
Gantt chart in the 1910s.

» The Gantt chart combines two functions planning and scheduling. With the Gantt
charts, the scheduling of activities occurs
simultaneously with their planning.

» The person drawing the activity lines or bars must be aware of the
interrelationships of the activities that is the activities must be
finished before the others start and which activities can be performed
concurrently.

Advantages

1. It createsa picture of complexity: We are very much familiar with diagrams and
charts. We think in pictures. Therefore, if we

_ can see complex ideas as a picture, this will help our-understanding.

2. It organises our thoughts: We are also familiar with the concept of dividing and
conquering. A big problem is conquered by
dividing it into component parts. A Gantt chart will force us to do this.

3. It can be highly visible: It can be useful to place the chart, or a large

version of it, where everyone can see it. This helps to cond

eople of the objectives and when certain things are going to happen
Disadvantage . = . PP Ua FebI9 | Mart? In Juni
1. It can become extraordinarily complex: Except for the most simple projects,
there Plsning ae
will be large numbers of tasks undertaken and resources employed to complete the
Research | TEER |
project. cae t scents)
2. It need to be constantly updated: As you get into a project, things will change.
If ats —_— | |
you're going to use a Gantt chart you must have the ability to change the chart
Implementation | | i ed |
: att t i
eaBily and frequently. Follow up | | | — |
Formulating a Network Model Copyright © PROF. GUFRAN QURESHI

Definition: A network diagram is a graphical representation of all the tasks,

responsibilities and work-flow for a project. It

often looks like a chart with a series of boxes and arrows.

> Itis used to map out the schedule and work sequence for the project, as well as
track its progress through each stage, up to
and including completion.

> The first stage in creating a network model is to represent the activities and
their interrelationships as a graph. In CPM we
do this by representing activities as links (arrowed lines) in the graph - the
nodes (circles) representing the events of
activities starting and finishing.

> These project scheduling techniques model the project's activities and their
relationships as a network. In the network, time
flows from left to right.

>» The two best known being CPM (Critical Path Method) and PERT (Program Evaluation
Review Technique).

> Both of these techniques used an activity-on-arrow approach to visualizing the

project as a network where activities are
drawn as arrows joining circles, or nodes which represent the possible start and/or
completion of an activity or set of
activities.

> More recently a variation on these techniques, called precedence network, has
become popular. This method uses activity-
on-node networks where activities are represented as nodes and the links between
nodes represent precedence (or
sequencing) requirements.

> Precedents are the immediate preceding activities: In Figure 6.9, the Code ~—

ra

activity 'Program test’ cannot start until both 'Code' and 'Data takeon' have
been completed and activity ‘Install’ cannot start until ‘Program test’ has
finished. 'Code' and Data takeon' can therefore be said to be precedents of Oata
‘Program test’, and 'Program test’ is a precedent of Install’. Note that we
do not speak of 'Code' and 'Data takeon' as precedents of Install’ that
relationship is implicit in the previous statement. Figure 6.9 Fragment of a
precedence network
OF. GUFRAN QURESHI

Release

>» A network may not contain loops: Figure 6.10 peoprans

demonstrates a loop in a network. A loop is an error in that it

represents a situation that cannot occur in practice. While
loops, in the sense of iteration, may occur in practice, they
cannot be directly represented in a project network.

Figure 6.10 A loop represents an impossible sequence

>» A network should not contain dangles: A dangling Design Code Test Te
activity such as "Write user manual’ in Figure 6.11 should — Late ial ee
not exist as it is likely to lead to errors in sub sequent Ls]
analysis. Redraw the network with a final completion [Sino

activity — which, at least in this case, is probably amore —

accurate. = 7
lesign: Code vest install
program a | Program Program Sonvolt

> Representing lagged activities: We might come across ; }

situations where we wished to undertake two activities in

parallel so long as there is a lag between the two. We might .

wish to document amendments to a program as it was being Figure 6.12 Resolving the
dangle
tested particularly if evaluating a prototype.
» Where activities can occur in parallel with a time lag prototype protatype
specification
between them we represent the lag with a durationonthe : 2
linking arrow as shown in Figure 6.13. This indicates that es
documenting amendments can start one day after the start of omenciments
prototype testing and will be completed two days after
prototype testing is completed. Figure 6.13 Indicating tags

tight © PROF, GUFRAN QURESH'

Network Diagram Representation

Ina network representation of a project certain definitions are used

I| Activity: Any individual operation which utilizes resources and has an end and a
beginning is called activity. An arrow is
commonly used to represent an activity with its head indicating the direction of
progress in the project. These are classified
into four categories
1. Predecessor activity — Activities that must be completed immediately prior to
the | A eo 6
start of another activity are called predecessor activities. | .
2. Successor activity — Activities that cannot be started until one or more of
other
predecessor Successor

activities are completed but immediately succeed them are called successor
activities.

3. Concurrent activity — Activities which can be accomplished concurrently are

knownas concurrent activities. It may be noted that an activity can bea
predecessor or a successor to an event or it may be concurrent with one or more of
| cnty
other activities. <
4. Dummy activity — An activity which does not consume any kind of resource but
merely depicts the technological dependence is called a dummy activity. The
Ganbimene
dummy activity is inserted in the network to clarify the activity pattern in the
Activities
following two situations. events.
a. To make activities with common starting and finishing points distinguishable.
b. To identify and maintain the proper precedence relationship between activities
that is not connected by
For example, consider a situation where A and B are concurrent activities. C is C
dependent on A and D is dependent on A and B both, Such a situation can be handjed
by using a dummy activity as shown in the figure.

Activity
G

Activity
— —
A B D
()
Il] Event: An event signifies a point in timé representing the completion éfseveral
activities and the starting of new ones. This
is typically symbolizes by a circle in a nétwork whichis also known as notle or
connector
The events are divided into three categories
' 1. Merge event- Event in which more than one activity comes and a
connects an event is called as merge event. Oe
2. Burst event- It is event in which more than one activity leaves an event. ee Ss
3. Merge and Burst event - An activity can be merge and burst event
simultaneously, as regard some activities it can bea mergeeventand Merge event
Burst event Merge and Burst event
with some other activities it may be a burst event.

HI] Sequencing: The first requirement in the development of network is to keep the
precedence relationships. In order to
prepare a network, the subsequent points must be taken into considerations

1. What job or jobs follow it?

2. What job or jobs could run concurrently?

3. What job or jobs precede it?

4, What controls the start and finish of a job?

As all further calculations are on the basis of network, it is essential that a

network be drawn with full care.

Activity Activity
#2 #4
Activity Activity
# Activity Aaiivity us
#3 #S
Drawing Networks —Illustrative Examples

Again the answer js to insert another dummy activity.

PPP TR PAT ey yee ere

Drawing Networks —Illustrative Examples

1. Draw a neat network and number the events.

Activity A, B, C D E F G H
Predecessor None B B B A,D C,E
2. Table 6.1 An example project specification with estimated activity durations and
precedence requirements
Activity Precedents
A Hardware selection
B Software design
c Install hardware A
D Code & test software B
E File take-on . B
F Write user manuals :
G User training - ~ E, F
H install & test: system cD
3. Draw a neat network and number the events.
Activity .| A B Cc D E F I J K L M
Predecessor | - 2 Bl al|cl]c]rti{]e {a {fi jpeg] 1 | KL
4. 1fJ & K are last activities, draw a neat network and number the events.
Activity A, B, C D E F G,H | J K
Interdependence Starting | Depends on B, Depends on | Depends on A, Depends Depends
| Depends | Depends
activity | controls G&H | C, controls J Controls I also on C onG onE “onl &H
Drawing Networks —Illustrative Examples copyri F. GUFRAN QURESHI
5. Draw a neat AOA network and number the events.
Activity A B Cc D EB F G H I J
Predecessor - A B B Cc E D F,G H I
6. Draw AOA network diagram by using the following data:
i. Activity A, B, C are starting activity.
ii. Activity D follows activity C.
iii. Activity A precedes follows activity F.
iv. Activity E follows act B and C.
v. Activity G follows activities E.
vi. Activity G is terminal activity.
7. Draw a network diagram. Identify Critical Path & calculate total float, free
float, independent float, interfering float.
Activity A B Cc D E F G H | J K
Node 1-2 1-3 1-4 2-5 3-5 3-6 3-7 4-6 5-7 6-8 7-8
Time 4 | 14 16 6 12 20 8 12 4 10 12
8. Draw a network diagram. Identify Critical Path & calculate total float, free
float, independent float, interfering float.

Activity 1-2 13. Ji-i4 2-4

2-5

3-4

4-5

Duration 3 2 \- 6 5

4
ws)

Table 6.1 An example project specification with estimated activity durations and

G5

: s Copyright © PROF. GUFRAN QURESHI

9. Draw a AOA network diagram. Identify Critical Path & calculate total float, free
float, independent float, interfering float.
Event A B Cc D E F G H
Activity 1-2 1-3 1-4 2-3 2-5 3-5 4-6 5-6
Duration 2 4 3 0 1 6 5 7

10. Draw a network diagram. Identify Critical Path & calculate EST, EFT, LST, LFT,
TF, FF, INDF, INTF for all the activities
Activity 1-2 f 1-3 1-4 2-4 2-5 3-4 4-5
Time 3 2 6 5 7 a 4
11. Draw a network diagram. Identify Critical Path & calculate EST, EFT, LST, LFT,
TF, FF, INDF, INTF for all the activities
Activity 1-2 1-3 2-4 3-4 3-5 4-5 4-6 5-6
Duration 7 5 11 4 3 7 2 9

12. Draw a network diagram. Identify Critical Path & calculate EST, EFT, LST, LFT,
TF, FF, INDF, INTF for all the activities

Activity 1-2 2-3, | 2-4 2-5 3-10 4-6 4-7 5-10 6-8 7-8 8-9 9-10

Duration 4 5 7 4 15 7 Dummy 10 6 7 12 10
13. Draw a network diagram. Identify Critical Path & calculate EST, EFT, LST, LFT,
TF, FF, INDF, INTF for all the activities

Activity 1-2 1-3 1-4 2-3 2-5 3-5 4-6 5-6

Duration 2 4 3 0 1 6 5 7

Adding the Time Dimension Copyright © PROF. GUFRAN QURESHI

. Once we created the logical network model indicating what needs to be done and
the interrelationships between those

activities, we are now ready to start thinking about when each activity should be
undertaken.

The critical path approach is concerned with two primary objectives: planning the
project in such a way that it is completed
as quickly as possible: and identifying those activities where a delay in their
execution is likely to affect the overall end
date of the project or later activities' start dates.

The method requires that for each activity we have an estimate of its duration. The
network is then analyzed by carrying
out a forward pass, to calculate the earliest dates at which activities may
commence and the project be completed,
and a backward pass, to calculate the latest start dates for activities and the
critical path.

In practice we would use a software application to carry out these calculations for
anything but the smallest of projects. It is
important, though, that we understand how the calculations are carried out in order
to interpret the results correctly and
understand the limitations of the method.
The description and example that follow use the small example project outlined in
Table 6.1 — a project composed of eight
activities whose durations have been estimated as shown in the table.

precedence requirements

Activity Duration (weeks) Precedents

A Hardware selection 6.0

B Software design 4

c install hardware 3 A

D Code & test software 4 8

E File take-on 3 8

F Write user. manuals 10

G User training 3 EF

H Install & test systern 2 ¢,D

Definition: Forward pass is a technique to move forward Forwaro pass

Forward & Backward Pass Method Copyright © PROF. GUFRAN QURESHI

EF=5+7=12 EF=12410=22
through network diagram to determining project duration and se], faojz
scemmmtnoceen
finding the critical path or Free Float of the project. 7 1 10 EF=22+6278
> Forward Pass Calculations determine the minimum dates at 2G [28]
which each construction activity can be performed and, & 6 ES=Highestof6 ort
ultimately, the minimum duration ofa construction project. — {yIq]5 9} E12 >\ alu |
32
>» In order to calculate Early Finish, we use forward pass. | [5 3 4
Means moving from Early Start towards right to come up S % een
with Early Finish of the project by adding activity duration. 5|c]9 9] F [4
Early Finish (EF) = ES + Duration 4 * 5
Definition: Backward pass represents moving backward to the — ,, waro pass
end result to calculate late start or to find if there isany slack in =~ ee bia
the activity. Purge Hf aah 2 8 = Highest oD or E=722
> Backward Pass Calculations compute the latest dates by a2)
which each construction activity can be performed without & 22]6|28)\y. exsiaetcore
increasing the projects minimum duration. eas dE N2 ge O\ aa Fr
> In order to calculate Late Start (LS), we apply backward {1/515 19] 3 [22 98! 4
132
Pass moving from Late Finish towards left to come up with recevesot sor » Le=a2
Latest Finish of the project by deducting activity duration. —is-s-s=« 5]e]9 GC Aa
Latest Start (LS) = LF — Duration 15} 4 |19 * 23/5 |28}
19-4215
Identifying the Critical Path Copyright © PROF. GUFRAN QURESHI

The critical path method provides a structured approach to project scheduling,

allowing you to identify the operations most important for
successful project completion. You have to know how to break down your project into
tasks and how to arrange them so you can find the
critical path. Once you have identified tasks that are critical, you can focus on
them to ensure that they don't delay your project.

1.

Break Down The Work: Start by breaking down the project work into separate
operations. An operation is a self-contained task carried
out by one person, one group or a supplier, and one to which you can assign a
duration and a responsible supervisor. Ask yourself what
tasks must be carried out to start the project and what tasks are next. Continue
until you reach the tasks that indicate the project is finished.
Arrange the tasks in a list, approximately in the sequence in which you have to
carry out the work.

Arrange Tasks by Prerequisites: You can start some tasks right away without
completing any other work, but other tasks rely on
prerequisites or work that has to be completed first. Draw a column of boxes on the
left side of a sheet of paper, one box for each task that
has no prerequisites, and write the name of each task in one of the boxes. Draw a
second column of boxes with the names of the tasks that
you can start when the tasks of the first column are finished. For each task of the
second column, draw lines back to the tasks of the first
column that are its prerequisites. Continue with additional columns until you have
placed all the tasks on your chart.

Estimate Task Duration: You have to know how long each task takes before you can

schedule your project. Estimate the duration by calculating how long it takes based
on

known unit quantities, the duration of similar tasks and estimates by suppliers,
For sn _——- oe
example, you can calculate how long it takes to install 16 lights if you know it
takes an / “ag ck \
hour to install one. You can look at other projects and how long it took to.
complete Lf \
similar work. Supplier quotes usually include an estimated delivery time. Add your
estimated duration to the task boxes.

Find The Longest Path: Your critical path is the longest path from the first column
~
through the lines showing prerequisites to the last column. It determines the
project

completion date because you must complete all tasks on the path within the
estimated

time or delay the project. For small projects of several dozen tasks, you can
determine Laie ——> ase

the critical path by following each path and adding the duration of the tasks. For
large ae ay Critical alpen ee S.days
projects, you can enter the data from the boxes in{O a project management software

program and have it calculate the critical path.

Activity Float Copyright © PROF. GUFRAN QURESHI

Definition: In project management, float of slack is the amount of time that a task
in a project network can be delayed without
causing a delay to subsequent tasks or projéct completion date.
Types

1.

Total Float: Total float is the amount of time an activity can be delayed without
delaying the project completion date. This
is the type of Float that is commonly referred to as “Float”. It is the amount of
time that a schedule activity can be delayed
or extended from its early start date without delaying the project finish date or
violating a schedule constraint. Total Float is
about flexibility at the project level. It is about the flexibility that an
activity has in its execution without delaying the
Project finish date. On a critical path, the total float is zero.

Total Float or Float = Lg — Eg or Lp— Ep

Free Float: Free Float is the amount of time that a schedule activity can be
delayed without delaying the early start date of
any successor or violating a schedule constraint. Free Float is about flexibility
at the activity level. It is about the flexibility
that an activity has in its execution without delaying its successor activity. On a
critical path, the free float is zero.

Free Float = Ex (of successor)— E, (of current) or T;— Hg

Independent Float: Independent Float is the maximum amount of time an activity can
be delayed without delaying the
early start of the succeeding activities and without being affected by the
allowable delay of any predecessor activity. On a
critical path, the independent float is zero.
Independent Float = Earliest Successor’s Early Start — Earliest Predecessors’ Late
Finish — Activity’s duration
or F,-Ts

Interfering Float: Interfering Float is the amount of time a schedule activity can
be delayed or extended from its early start

date without delaying the project finish date. However, it should be understood
that delaying an activity into interfering

float will delay the start of one or more following non-critical activities. On a
critical path, the interfering float is zero.
Interfering Float = Total Float — Free Float or same as Hg

Identifying Critical Activities Conyght © PROF. GUFRAN URES

Definition: Once the project schedule is created in the form of a Gantt chart, it
offers you very valuable insights in the form of
a critical path. In simple terms, critical path is a sequence of all those
activities which can delay the whole project if they face

any delay at all.

We can choose between two options for identifying activities as critical: float and
longest path.
L,
>

yr

Float:

Float is a measure of schedule flexibility. This method calculates four dates for
each activity in the project plan: Early Start,
Late Start, Early Finish, and Late Finish. If the Early Start date and Late Start
date for an activity are the same, the activity
is said to have zero float. ,
Activities that have zero float must start on time to prevent the schedule from
slipping.

Critical activities can also have negative float. Negative float occurs when an
imposed finish date creates a schedule that is
shorter than the duration calculated to complete the activities on the critical
path. A project with negative float is behind
schedule.

. Longest path:

Longest path defines the sequence of driving activities that determine the project
end date. The longest path is broken when
activities are no longer driven by relationships; that is, when activity dates are
driven by constraints or resource leveling.
Longest path calculation includes interproject relationships. Therefore, activities
designated as on the longest path may
change depending on whether you schedule a project alone or with its related
projects.

If a project has interproject relationships and you schedule it alone, the

interproject relationships are treated as scheduling
constraints.
Activity-on-Arrow Networks

Definition: It is a network diagramming technique in which activities are

represented by arrows. The start and end of each node
or event is connected to an arrow. Between the two nodes lies an arrow that
represents the activity.

In an activity-on-arrow network, activities are represented by a line between two

circles. The first circle represents the start of
the activity and is knownas the start event (sometimes called the node). The second
circle represents the finish of the activity
and is knownas the finish event (sometimes called the j-node).

The Activity Early Start (E.S): It is the earliest time that an activity can start
with.

The Activity Early Finish (E.F): It is the earliest time that an activity can
finish with. EF = E.S + Duration (D)
The Activity Late Finish (L.F): It is the latest time that an activity can finish
with.

The Activity Late Start (L.S): It is the latest time that an activity can start
with. L.S = L.F - Duration (D)

ee Se

Space is allowed in the circles. for calculation results

from critical path analysis.

a. The calculated times are the earliest event time (EET)

and latest event time (LET). The earliest event time of ‘
the i-node is the earliest start of the activity and the i te er re
latest event time is the latest start. are

b. Similarly, the earliest event time and latest event times

of the j-node are the earliest and latest finishes of the
activity

The arrow diagram lets you calculate the "critical path" of the project—the flow of
critical steps where delays can affect

the timing of the entire project and where addition of resources can speed up the
project..

Duration (Float)

Sina a A)

N QURESHI
Ch-7 Risk Management copyright © P20

Definition: Project risk management is the process of identifying, analyzing and

then responding to any risk that arises over
the life cycle of a project to help the project remain on track and meet its goal.
Risk management isn’t reactive only; it should
be part of the planning process to figure out risk that might happen in the project
and how to control that risk if it in fact occurs.
Three simple steps for successful Risk Management

1. Identify risks — “Risk Identification”

2. Assess risks — “Risk Assessment” Risk Risk

3.. Mitigation, contingency and avoidance — “Risk Planning” Identification aerate

Mitigation
Risk Categories:

What is Software Risk? :

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

information, control or time. A possibility of suffering from loss in software

development process is called a software risk.

>» A software risk can be of two types (a) internal risks that are within the
control of the project manager and (2) external risks
that are beyond the control of project manager.

» The risk analysis process starts with detailing the risk under the various risk
analysis Hews as mitigate, monitor, and
manage.

>» The best strategy to overcome risk is to anticipate risks in the project at the
earliest so that the effect of the risks on the
projectis minimized by the risk management plan.

» To identify risks it is necessary to categorize them. There are primarily three

categories of risk:

1. Project Risks: Project risks concerns various forms schedule, resources,

budgetary and user requirement related issues.

2. Technical Risks: Technical risks concern various forms of design risk,

implementation risk, interfacing, performance, and
maintenance problems.

3. Business Risks: Business risks are various such as project being redundant on
completion, exceeding budgetary
provisions, etc.
Risk Management Approaches SERN ean SRS

Definition: The most common approach to project risk management is to manage

individual risks recorded and assessed in a

project risk register. Although this approach is relatively simple and likely to
add value if implemented competently, it should

not be assumed to be best practice. There are alternative approaches that have the
potential to add more value. A project with

high risk management capability will recognise this and select tools and techniques
appropriate to circumstances and purposes

of the project.

Approach 1: Top-down multi-pass process — This approach can be used from the outset
of a project. It is based on the

principles that:

1. One needs to start with a high level understanding of the project to be

confident that overall project risk is understood,
quantified and managed in an appropriate and rational manner.

2: The risk management process should address the key questions that require risk-
based decisions.

3. Key risk questions may change from one pass of the risk Management process to
the next dependent upon insights
gained from the previous pass and other events that have occurred in the meantime.

4. Risk management techniques should be selected to address the key questions —

different techniques may be required

during successive passes of the process. ( Progannea | [ PEs a ee ee

. J . :

5. These techniques can be used to optimise decisions that shape the <> Coats)
. . front end 1 ‘oat end 2 foal end 3 eopninn sn aiabesseh
project solution. — ony =

Advantages:

a. Can be used from project commencement.

b. Supports fundamental project decisions.

‘ Underpins a rational approach to the process. Caeer DD

Efficient identification of key insights. Eel

) PROF, GUFRAN QURESHI

Approach 2: Quantitative risk-based forecasting — This approach involves modelling
the implications of a project plans to
obtain a risk-based forecast for the project cost and/or the completion dates for
key milestones. This may be particularly
valuable information at key project authorisation points when governance
requirements include confidence forecasts. In some
cases, it may also be possible to apply similar modelling techniques to the
project’s products.

Advantages:

Combines the implications of all risks to forecast overall risk.

Produces confidence forecasts (e.g. P90 and PSO points).

Analysis statistics identify key aspects of risk.

Models can be used for “what-if” scenario modelling.

ao op

Approach 3: Risk register — This is the common-practice approach of using a single-

pass approach to identifying a list of
risks and entering them into a risk register for assessment and risk response
planning. Risks are then reviewed on a regular
basis to update the risk information and verify that risk responses are
implemented.

Advantages:

a. Relatively unsophisticated — less experience required,

b. When implemented well, fosters a good team culture.

PROF. GUFRAN QURESHI

Risk Management Framework

Definition: A risk management framework (RMF) is the structured process used to

identify potential threats to an organisation
and to define the strategy for eliminating or minimising the impact of these risks,
as well as the mechanisms to effectively
monitor and evaluate this strategy.

The risk management framework consists of:

Plan risk management: Develop a plan with your team to discuss how to capture
project risks.

1.

2, Identify risks: The identification of risks and entering risks in a log.

3. Perform qualitative risk analysis: Prioritizing risks.

4. Perform quantitative risk analysis: Performing a computation of each risks on

the project.

5. Plan risk responses: Develop a proactive response, just in case the risk
happens.

6. Control risk: Tracking and monitoring the risk log.

Phase I: The first phase, Prepare for Risk Phase 1 Phase a Phase 3
Management, of the framework lays the groundwork Prepare for Risk Perform Risk
Sustain and Improve
for the other two phases and hence should be Management Management Activities Risk
Management

completed before executing the other two phases.

Phase II: The second phase, Perform Risk Management Activities, specifies the
activities that are to be used for managing
risk. This phase is performed continuallytill the overall risks to the key
objectives of the project are eliminated.

Phase Ill: The third phase, Sustain and Improve Risk Management, is performed on a
periodic basis to ensure of that the risk
management practice remains effective over the entire course of the project.
Activities of this phase are used to identify
improvements to risk management practice.

Risk Identification Copyright © PROF. GUFRAN QURESHI

Definition: Risk identification is the process of determining which risks may

affect the project and documenting their
characteristics. The key benefit of this process is documentation of existing risks
and the knowledge and skills offered by
the project team anticipate risk events.

Risk identification is the first step in risk management. You need to identify

risks using an approach where you divide the risk in two parts, the trigger
and the consequence. veerte pon
The trigger is some averse event such as lightning hitting your house and the
“Tenn,
consequence is something that happens as a result for instance that your & : “1
Risk
house burns to the ground. , emai Mea
To identify the risks are always the biggest and the toughest task in project &
management. ws
Mitigation
Planning
Risk components and drivers: & =
1. Performance risk—the degree of uncertainty that the product will meet | - Re
its requirements and be fit for its intended use. Pian Implementation
2. Cost risk—the degree of uncertainty that the project budget will be
maintained.

3. Supportrisk—the degree of uncertainty that the resultant software will be easy

to correct, adapt, and enhance.
4. Schedule risk—the degree of uncertainty that the project schedule will be
maintained and that the product will be
delivered on time.
Risk Identification Techniq ues / Tools Copyright © PROF. GUERAN QURESHI

Techniques: Be 13

There are several tools available that can hélp the project manager in iddntifying
risks.

1. Documentation Reviews: The standard practice to identify risks is reviewing

project related documents such as lessons
learned, articles, organizational process assets, etc.

2. SWOT: SWOT, or strengths, weaknesses, opportunities, threats, is another tool to

help with identifying risks. Begin with
strengths and determine what those are as related to the project (though this can
work on an organization-level, too). Next,
list the weaknesses or things that could be improved or are missing from the
project. This is where the likelihood of
negative risk will raise its head, while positive risk come from the identification
of strengths. Opportunities are another
way of referring to positive risks and threats are negative risks.

3. Brainstorming: Brainstorming is done with a group of people who focus on

identification of risk for the project. A
brainstorming session is one in which the project team sits together and thinks up
with as many risks as possible.

4, Delphi Technique: A team of experts is consulted

anonymously. A list of required information is sent to experts,
responses are compiled, and results are sent back to them for
further review until a consensus is reached.

5. Assumption Analysis: Identification of different assumptions

of the project and determining their validity, further helps in
identifying risks for the project.

6. Root Cause Analysis: Root causes are determined for the

identified risks. These root causes are further used to identify
additional risks.

Risk Assessment Copyright © PROF. GUFRAN QURESHI

Definition: Risk assessment is a step in a risk management procedure. Risk

assessment is the determination of quantitative or
qualitative value of risk related to a concrete situation and a recognized threat.
Risk assessment involves measuring the
probability that a risk will become a reality:

The procedure for analysis is to conduct the qualitative analysis and once the risk
qualifies then quantitative analysis is carried
- out.

T] Qualitative Risk Analysis:

1. Qualitative risk analysis is the process of assessing individual project risk

characteristics - the probability of occurrence and

the impact they would have on a project if happening - against a scale.

2. The main purpose of the qualitative risk analysis
is prioritizing risks according to their probability
and impact. A project can be exposed to a large
number of different risks.

Qualitative risk analysis is carried out using a

risk matrix also called as a probability-impact

matrix. :

4. The scale used for the analysis groups project

risks into three or more categories according to
their impact, such as low, medium and high.

5. The risk can impact numerous project elements:

budget, schedule, deliverables, scope or
available resources. The risk probability can be
evaluated using the same categories or expressed
as a percentage (0% to 100%) or odds (0 to 1).

6. The scale can be customized to fit organizational

needs and then used across all projects within an
organization for consistency.

Each threat and opportunity will be further looked at for quality of data available
and the risk flings imnarted
Project Risk (Threat and Opportunity) Matrix j

Lee)

Probability Negligible Minor Moderate Significant Severe

(B1-100)%

(61-80)%

(41-60)%

(21-40)%

(1-20)% : Risk Minimum Risk

ni] Quantitative Risk Analysis:

PAR w

Copyright © PROF. GL

. Quantitative risk analysis is a numeric estimate of the overall effect of risk on

the project objectives such as cost and
schedule objectives. The results provide insight into the likelihood of project
success and is used to develop contingency
reserves.

It uses verifiable data to analyse the effects of risk in terms of cost overruns,
scope creep, resource consumption, and
schedule delays.

Quantitative Risk Analysis uses available relevant and verifiable data to produce a
numerical value which is then used to
predict the probability (and hence, acceptability) ofa risk event outcome.

Main advantages of a quantitative approach is to determine the probability of

achieving a specific project objective.

A ranking of risks based on their probability and quantum impact is created.

Project communication plan: Risk status needs to be communicated to all those

concerned. The identification, analysis
and action needs to be communicated.

Enterprise risk procedure: Organizations may devise their own rules, procedures and
policies when it comes to dealing
with risks. In such cases the project manager will be required to follow these
rules.

Organizational process assets: There are chances that the organization may have
implemented a similar project in the past.
In such case, the project plan back then may prove to be useful in identifying and
managing risks.

Risk Planning Copyright © PROF, GUFRAN QURESHI

Definition: Risk planning is the process of identifying, prioritizing, and managing

risk. Every project or initiative has
objectives, that is, goals that it seeks to accomplish. These are often called
Critical Success Factors (CSF). Risk events

threaten the successful completion of these critical success factors.

The response to risk depends on its type i.e. negative risk or positive risk.
The three most common responses to negative risk are:

1.

Z.

3.
Strategies for Dealing with

Project Risk Responses

Avoidance: The first natural response to any risk to find ways to avoid it.
This would mean creating workarounds, adjusting project objectives, or |

changing the project schedule, in short whatever required to avoid the risk. : :
Transference: The risk is transferred to a third party that is in a better
(INecIeiccray Posilive Risks or (oe urea
position to manage the risk. Thus, instead of trying to manage the risk in-

house the risk is transferred to a third party.

Mitigation: Here the project manager is left with no alternative but to tackle the
risk in-house. This would mean spending

extra time and money to reduce the probability and impact of the risk.

Bi ccrieg Opportunities Response

The three most common responses to positive risk are:

1.

2.
3.

Exploitation: The project manager tries to gain maximum benefits from the positive
risk. The idea here to utilize the risk
to maximum,

Enhancement: The project manager creates an environment that is ideal for the
positive risk to happen,

Sharing: The positive risk is shared by the project team with another entity to
gain maximum benefits from the risk. The
project team may not be capable of leveraging maximum benefits from the rjsk and
hence feels that by bringing in a third
party it may be able to derive maximum.

In addition to the above given responses there is angther response that is suitable
for both positive as well negative risk and this
is the response of Acceptance (Contingent Response), Positive and negative risk
with low impact should be accepted as it is.
13

Risk Management Copyright © PROF. GUFRAN QURESHI

> Risk management process is nothing but a series of steps that help idehtify and
migrate the risks for the successful closure

of a project. If done correctly and sincerely, construction risk manabethent will

reduce not only the likelihood of an event
occurring, but also the magnitude of its iinpact.

> In the simplest terms, Risk management process is taking preemptive actions to
avoid and minimize any kind of jeopardy to

a project in future.

Process:

1.

Vv

>

>

Va
>

Risk Identification: Risk identification is the process of determining which risks

may affect the project and documenting
their characteristics. The key benefit of this process is documentation of existing
risks and the knowledge and skills offered
by the project team anticipate risk events.

Risk Assessment / Analysis: After all the probable risks have been identified,
their valuation is done based on qualitative
and quantitative methods. With risk assessment method, available information is
used to extricate the frequency of
occurrence and the level of consequences in risk management.

Risk Response: After identification and assessment of the risks are done, available
options to avert the risks are marked
and discussed in case they ever crop up in future. Risk response is further
subcategorized into Risk avoidance, Risk

transfer, risk mitigation and risk acceptance depending upon the nature of the
risks.
Risk monitoring and control: Risk

monitoring and control is the process

of identifying, analyzing, and planning

for newly discovered risks and Risk : Tees a

PRC O MVOC iiontifiction || Sek Assessment | Risk Response pee es s

and control is done throughout the life

of the project.
Evaluating Risks to the Schedule Copyright © PROF. GUERAN QURESHI

Schedule risk is the potential for a strategy, project or task to take longer than
planned. A schedule typically includes forward-
looking estimates that are inherently uncertain. As such, there is a risk that
estimated durations, dependencies and
assumptions built into a schedule will turn out to be inaccurate.

The project schedule is the core of the project planning. As the time needed to
complete a project activity is hard to estimate,
scheduling a project is extremely difficult task.

The earliest technique used for schedule risk analysis was the Gantt chart,
developed by Henry Gantt in 1917. Gantt chart
gives a graphical summary of the progress of a number of project activities by
listing each activity vertically on a sheet of
paper, representing the start and duration of each task by a horizontal line and
then representing the current time by a vertical
line. This makes it easy to see where each activity should be and to show its
current status.

Many tasks require that prior tasks are completed before they can be initiated, but
unfortunately, Gantt charts are not a good
method of showing the interrelationship between tasks, so computers must be used to
set up and maintain the network of
tasks.

One commonly-used technique is Program Evaluation Review Technique (PERT) which

uses a detailed diagram of all
anticipated tasks in project, organized into a network to represent the dependence
of each task on those that must precede it.
PERT can be used to analyse the tasks involved in completing a project, especially
the duration of each task, and identify the
minimum time needed to complete the total project.

PERT makes it possible to schedule a project without knowing the precise details
and durations of all the activities.

The CPM is a similar project planning and management technique which also uses a
network representation. Various
enhancements were made to CPM to allow alternative resource allocations to be
explored, within specified cost constraints.
Boehm’s Top 10 Risks and Counter Measures Copyright © PROF. GUFRAN QURESHI

Barry Boehm, who was widely credited with the software cost model Constructive Cost
Model (COCOMO)-and the Spiral
Model of software process, published an article on the top 10 list of software
defect reduction. Most of the items on this list are
self-explanatory while others require some clarifications. Each item on this top 10
list i is backed by research.

Bochm’s top 10 list of software defect reduction:

1.

Finding and fixing a software problem after delivery is often 100 times more
expensive than finding and fixing it
during the requirements and design phase. This is a well-known fact about the
increasing cost of defect removal
(Holzmann, 2001) during the different stages of software development lifecycle.
This reiterates the importance of complete
detail requirement analysis and design, which is the key to defects reduction.
Conversely, the lack of them is the major
cause of defects downstream.

. Current software projects spend about 40 to 50 percent of their effort on

avoidable rework. This finding should not be

too surprising, but the actual percentage of avoidable work is frightening. With
the advent of ‘agile’ methodologies in the
last 10 years, it would be interesting to see if the percentage of avoidable rework
can be reduced. Although it might be
difficult to measure since there is this thing called ‘refactoring’ in agile
methodology. Refactoring could possibly include a
fair amount of rework.

About 80 percent of avoidable rework comes from 20 percent of the defects. Research
showed the two major sources of
avoidable rework came from ‘hastily specified requirements and nominal-case design
and development’. In addition, last
minute accommodation of ‘off-normal requirement’ often causes major changes at the
architecture level that tends to
produce code breakage.

About 80 percent of the defects come from 20 percent of the modules, and about half
the modules are defect free. The
first part of this finding is not too surprising since 20% of production code is
doing most of the processing while the other
80% of code should be just exception handling. The more often code is used; the
more defects will be discovered. The
second part of this finding is a surprise. According to Boehm and Basilli (2001, p.
136), the reasons for defects to
concentrate in half of production modules include data coupling and cohesion, size,
complexity and changes to reused code.

Copyright © PROF. GUFRAN QURESHI

About 90 percent of the downtime comes from, at most, 10 percent of the defects.
Based-on a study on the software
failure history of nine large IBM software products indicated that 0.3 percent of
defects accounted for around 90% of the
downtime. This finding might be reason for the recent interest in applying risk-
based testing as a cost-effective mean to
deduce potential downtime.

Peer reviews catch 60 percent of the defects. It is not clear how often are peer
reviews (which include requirement review,
design review, test cases review and so on) are being practised during the
development lifecycle in industry. The code
inspections I have attended in recent years are mostly just a few developers
discussing the functionalities of sections of
code. They are not the type of disciplined approach described in the textbooks. The
way that peer reviews are conducted is
also correlated to how effective they are in catching defects.

Perspective-based reviews catch 35 percent more defects than nondirected reviews.

Perspective-based review is a set of
formal software reading techniques based on different perspectives developed by
Basili (1997) for defect detection. The
techniques have been showed to improve fault detection rates anywhere from 15 to 50
percent. It is not clear if these
techniques are widely used. Most reviews used in industry are still ‘nondirected’
meaning their purpose is not directed at
defect reduction. —

Disciplined personal practices can reduce defect introduction rates by up to 75

percent. These personal practices
include the Personal Software Process (PSP) and Cleanroom software development
process. NASA data showed a 25 to 75
percent reduction in failure rate using the Cleanroom process. The PSP approach is
shown to reduce personal defect rates
significantly. However, the results at the project level are mixed. The results
depend on organizational factors such as
existing software maturity level and the willingness to operate in a highly
structured software culture.
eb

PROF. GUFRAN QURESHI

9, All other things being equal, it cost 40 percent more per sourte instruction to
develop high-dependability software
products than to develop low-depehdability software products: However, the
investment is more than worth it if the
project involves significant operatioris and maintenance costs. Slitiply put, it
costs more to develop high-dependability
software than low-dependability softwate. The first finding is based on the COCOMO
II maintenance model. It costs 50
percent more per instructions to maintain than to develop low-dependability
software while it costs 15 percent less to
maintain than to develop high dependability software. This is a ‘pay now or pay
later’ finding. The second finding is based
on the COCOMO II-related quality model. Higher dependability software removes
around four times as many defects as
lower dependability software.

10. About 40 to 50 percent of user programs contain nontrivial defects. A study of

spreadsheet error (Brown & Gould,
1987) showed that 44 percent of:27 spreadsheet programs produced by experienced
developers contain nontrivial defects
(e.g. errors in spreadsheet formula).

Applying the PERT Technique Copyright © PROF. GUFRAN QURESHI

PERT (Project Evaluation and Review Technique) was developed to take into account
uncertainty of estimates of task durations.
Instead of using a single estimate for the duration of each task, PERT requires
three estimates - Optimistic Time, Most Likely
Time, Pessimistic Time.

Optimistic Time (to ): The optimistic time is the shortest possible time in which
the activity can be completed.

Most Likely Time (tm): The most likely time is the normal amount of time the
activity would take.

Pessimistic Time (tp): The pessimistic time is the longest time the activity could
take if everything goes wrong.

The main objective of PERT is to find out the completion time for a particular
event and to determine what are the chances of
completing a job and the risk of not completing a job in time. In the network
analysis, it is assumed that the time values are
.deterministic or variations in time are insignificant. It is difficult to get a
reliable time estimate because the technology is
changing rapidly. Time values are subject to chance variations.

Each activity is specified by its starting node, finishing node, and three time
estimates. The risk-index for the activity network
can be computed as - -
Compute mean time (uk) and variance (ok?) for each activity - Mean time | Bpedted
id
and variance of each activity/ node is computed on basis of Optimistic, | opimisic
te aaa
Most Likely, Pessimistic timings of completion of project estimated by 8

software development experts.

The mean time for each activity can be approximated using the following
weighted average: :
Mean time = (Optimistic + 4 * Most likely + Pessimistic)/6
uk = (to + 4tm + tp)/6

The variance is given by:

Variance = [(Pessimistic - Optimistic) / 6]?

ok? = ((tp- to )/6)?

1,

Drawing Networks —Illustrative Examples Copyright © PROF. GUFRAN QURESH!

Asmall project is composed of 7 activities whose time estimates are listed in the
table below. Activities are identified

by their beginning (i) and ending (j) node numbers

Activity (+) 1-2 1-3 1-4 2-5 3-5 4-6 5-6 .
Optimistic 1 1 2 I 2 3
Estimated F
Duration (Weeks) Most Likely 1 4 2 1 5 6
Pessimistic 7 7 8 1 14 15

Draw the network diagram of activities in the project.

b. Find the expected duration and variance for each activity. What is the expected
project length?

Calculate the variance and standard deviation of the project length. What is
probability that the project will be

completed?
i. Atleast 4 weeks earlier than expected time.
ii. Nomore than 4 weeks later than expected time.
iii. If the project date is 19 weeks, what is the probability of not meeting the
due date (Non-Completion).

Given: Z 0.50 0.67 1.00 1.33 2.00

Probability 0.3085 0.2514 0.1587 0.0918 0.0228

Copyright © PROF. GUFRAN QURESHI

2. Aproject manager has made following 3 point time estimates for various
activities of a project.
Activity (Events) 1-2 1-3 1-4 2-5 3-5 4-6 5-6
Optimistic 6 6 12 6 12 12 18
Estimated ” 5
Duration (Days) Most Likely 6 12 12 6 30 30 30
Pessimistic 24 18 30 6 48 42 54

a. Drawthe PERT network and find out the expected project completion time
b. What project completion will have 90% confidence of completion?
c. If thereis a huge penalty for exceeding the project completion deadline of 4
days beyond estimated completion

time (50% confidence), what is the probability of being penalized (Non-Completion).

Given: z 1.29 . 0.46

Probability 0.4015 0.1772

TT

Monte Carlo Simulation Copyright © PROF. GUERAN QURESHI

Monte Carlo simulation is a computerized mathematical technique that allows people

to account for risk in quantitative analysis and
decision making. Monte Carlo simulations aré used to model the probability of
different outcomes in a process that cannot easily be
predicted due to the intervention of random Vatiables.

Working: ‘

1. Monte Carlo simulation performs risk ahalysis by building models of possible

results by substituting a range of values—

a probability distribution—for any factor that has inherent uncertainty.

It then calculates results over and over, each time using a different set of random
values from the probability functions.

Depending upon the number of uncertainties and the ranges specified for them, a
Monte Carlo simulation could involve thousands

or tens of thousands of recalculations before it is complete.

4. Monte Carlo simulation produces distributions of possible outcome values.

Monte Carlo simulation provides a number of advantages over deterministic, or

“single-point estimate” analysis:

1. Probabilistic Results: Results show not only what could happen, but how likely
each outcome is.

2. Graphical Results: Because of the data a Monte Carlo simulation generates, it’s
easy to create graphs of different outcomes and
their chances of occurrence. This is important for communicating findings to other
stakeholders.

3. Sensitivity Analysis: With just a few cases, deterministic analysis makes it

difficult to see which variables impact the outcome the
most. In Monte Carlo simulation, it’s easy to see which inputs had the biggest
effect on bottom-line results. ‘

4. Scenario Analysis: In deterministic models, it’s very difficult to model

different| rosy
combinations of values for different inputs to see the effects of truly different _
2
scenarios, Using Monte Carlo simulation, analysts can see exactly which inputs had
which values together when certain outcomes occurred. This is invaluable for
pursuing aan
further analysis. Simniation

5. Correlation of Inputs: In Monte Carlo simulation, it’s possible to model

interdependent relationships between input variables. It’s important for. accuracy
to
represent how, in reality, when some factors goes up, others go up or down
accordingly.

Ww be
Critical Chain Concepts Copyright © PROF. GUFRAN QURESHI

Definition: Critical chain project management is a scheduling method that plans and
manages projects with a focus on
allowing for resource delay. Resources can include internal and external personnel
(contractors or customers), physical space,
logistics, and equipment.

Dr. Eli Goldratt developed critical chain methodology in 1997 in his book Critical
Chain. Dr. Goldratt developed this method

due to numerous projects having issues with extended durations on activities,

missed deliveries, and budget overruns.

Steps in Critical Chain Development

There are six steps that a project manager who uses critical chain project
management will have to follow.

1. Determine Aggressive Estimates: Project manager always keeps their contracted

delivery dates at the forefront of their
mind. To help fight off procrastination or the effects of Parkinson's Law, the
project manager will determine activity
durations that are aggressive. Some recommend that the normal activity time
allotted should be reduced by 50%, (though
some consider that too aggressive and not obtainable).

2. Create the As Late As Possible Schedule: :

Project manager will use scheduling software ;

to create a schedule that works backwards oe “
from the completion date through each

e Butfer
activity, each starting on the latest possible / \\. project Butter

start date. This is in contrast to the standard _ © @26 = S|

practice of starting as early as possible. This Ei Lo

tactic will install a sense of urgency in the _ : Resource Butler é Tie sae 10m
project team and have them perform at the G caries * Eavicre yo oe

best of their abilities. . @ 5 @

Copyright © PROF. GUFRAN QURESHI

Determine the Critical Chain: Project manager will determine which set of
activities that, if delayed, will extend the end
date of the project. They will determine this based on resource availability. All
tasks not in the critical chain are part of a
feeding chain.

Decide Where Buffers Should Go: Here Project manager will decide where buffers
should be placed in the schedule.
Buffers can be one of three types:

a. Project buffer is a single buffer added to the whole schedule, between the last
activity and the ultimate deadline.

b. Feeder buffers are placed in between the last tasks from the feeding chain
leading to critical chain activities.

c. Resource buffers are artificial buffers that make up for possible fluctuations
in resource availability.

Determine Buffer Sizes: Here Project manager will add appropriate buffer size
(cushion) to activity durations. It is
recommended that a cushion proportionate to the activity uncertainty or risk be
included. This means that a more uncertain
an activity is, the larger the buffer built in.

Add the Buffers to the Schedule: When Project manager adds the buffers to the
schedule, they creates a buffered schedule
which can use to manage the critical chain project.

Ch-8 Resource Allocation Copyright © PROF. GUFRAN QURESHI

Definition: Resource allocation is the process of assigning and scheduling

available resources in the most effective and
economical manner. Projects will always need resources and resources are scarce.
The task therefore lies with the project
manager to determine the proper timing of those resources within the project
schedule.

- Steps for allocating resources:

1. know the scope—to know whatis your project about, what you will need to achieve
it, and to be able to properly allocate -
resources;

2. identify resources —to know which tools, equipment, etc. you will need it
completing the project;

3. track time — to havea deep analysis of the progress and current situation as
well as be able to control it in the real-time;

4. don’t look only at the big picture — the process of working on a project is not
done with task allocation. Once you allocate
resources you have to keep track of all of them. If you lose at least one tiny
detail, your project may fail;

5. don’t over-allocate— because your team will experience burnout and their
productivity will significantly drop.
Nature of Resources:

» Aresource is any item or person required for the execution of the program. The
project manager must concentrate on those
resources,

» Individual programmer might be committed to work on a number of project and it

will be important to book their time well
in advance.

» In general, resources will fall into one of seven categories:

1. Labour (also known as Human Resources): The main items in this category will be
members of the development project

team such as the project manager, systems analysts and software developers. Equally
important will be the quality
assurance team and other support staff and any eniplayers of the client
organization who might be required to undertake or
participate in specific activities.
79

Copyright © PROF, GUFRAN QURESHI

Equipment: Obvious items will include workstations and other cofnputing and office
equipment. We must not forget that
staff also need basic equipment such as desks and chairs.

Materials: Materials are items that are consumed, rather than equipment that is
used. They are of little consequence in
most software projects but can be important for some — software that is to be
widely distribute might, for e.g., require
suppliers of floppy disks to specially obtained.

Space: For projects that are undertaken with existing staff, space is normally
readily available. If any additional staff
(recruited and contracted) should be needed then office space will need to be
found.

Services: Some projects will require procurement of specialist services —

development of a wide area distributed system, .
for example, requires scheduling of telecommunications services.

Time: Time is the resource that is being offset against the other primary resources
— project time-scales can sometimes be
reduced by increasing other resources and will almost certainly be extended if they
are unexpectedly reduced.

Money: Money is a secondary resource — it is used to buy other resources and will
be consumed as other resources are
used. It is similar to other resources in that it is available at a cost — in this
case interest charges.

Identifying Resource Requirements Copyright © PROF. GUFRAN QURESHI

Definition: Once the project manager and the project team have completed resource
planning, the required resources to complete the
project will have been identified. The resource identification is specific to the
lowest level of the WBS. The identified resources will
need to be obtained through staff acquisition or through procurement.

5 tips to help you identify the right resources for your project:

1.

Know what work is required: Make sure that you have a clear brief before the
project starts. You should understand what was
part of the bid. You and the client should have a common understanding of what is
included in the project. Confirm the scope with
whoever needs to approve the work going ahead. This is the definitive list of
everything that is expected on the project.

Plan in advance: It’s better to plan your resource needs in advance. There is too
much risk involved with waiting until you need a
particular resource & then trying to book them. That person might be already fully
committed on another project, or on vacation or so on.
Confirm resource availability: Perhaps someone is available to your project 50% of
the time. What does that actually mean? Is it
50% of the full week? Or 50% of their time after a percentage has been sliced off
for their admin and non-billable time? Or some
other calculation? Check how much you can expect from resources — especially those
who are only contributing to the project ina

part-time capacity — before you book their time into your schedule. Topats

i ills: ) 5 j j av -to-dé WBS

Check their skills: Do the people you want on the project still have up-to-date
Lesorical Hlocteaien

skills in the appropriate areas? Check your organization’s skills catalogue and
make) cope statement
sure. It would be embarrassing to book a colleague on to a project and then find
out! Resource pool description

——

that the last time he used those skills was on another project with you three
years| Orénization policies as

; . a Duration eatimates ——
ago. Other people in the team might have got more relevant or updated skills, and
=eesee { 2
they might be more appropriate for this client engagement. ia alicia road
Remember to book equipment: We tend to focus on resources as being the human heer
judgment ve
kind, but here are other types of resource that are important for projects. If you
are Alternatives identification
designing software for a client, you might need access to your company’s test lab
or \.__ Project management solcware a
test equipment to make sure it’s’fit for purpose before it goes to the client for
user prices eici

prin initia *

acceptance testing. Equipment is another kind of resource that you can book. i
rine ee z e : : | Resource Requirements
Schedule what you need so that it is available for you when you need it. |
4. Find The Longest Path: Your critical path is the longest path from the first
column

Scheduling Resources Copyright © PROF. GUFRAN QURESHI

Definition: Resource scheduling refers to the set of actions and methodology used
by organizations to efficiently assign

the resources they have to jobs, tasks or projects they need to complete, and
schedule start and end dates for each task or project based

on resource availability.

> Resource scheduling involves the scheduling of start and end dates for each task
in the project based on the resources needed and
their availability.

>» Balancing the availability of resources with the work capacity of teams is how
to keep a project on schedule. Resource scheduling
gives project managers a tool to set the duration for their team’s tasks.

5 Tips for Great Resource Scheduling:

1. List Tasks: This is the obvious first step. You can’t have a thorough resource
schedule if you’re not sure what resources you'll
need. To know that, you must have an understanding of the tasks that are necessary
to complete the project, how long those tasks
will likely take and what resources will be needed. The more complete your list,
the more accurate your resource schedule.

2. Be Aware of Constraints: The list is only the beginning, of course. There are
other factors at play. These are the constraints, such
as the triple constraint of time, cost and scope. All of these forces are working
on your resources, so the better you can define how
they'll be impacting the tasks in the previous tip, the tighter your resource
schedule will be.

3. Know How Many Resources You Need: Again, going back to your task list, make a
determination | Project Selection |
as to how many resources each task will require. What type of resource is it? How
many of each will
be required to finish the task? This figure can be numerical, as in the quantity
needed, but it can also
be expressed in time. You might need the resource for an hour or weeks. This all
should be noted.

4. Control Availability of Resources: You want to control the future availability

of resources. To do
this requires knowing how much capacity your have. That is, for example, how much
work your
team can accomplish over a specific timeframe.

5. Assign Wisely: The final tip applies to assigning your resources after you’ ve
listed tasks, identified
constraints, know how many resources you'll need and their availability. At this
point, you have the
information necessary to build a resource schedule that can avoid costly
bottlenecks.

f
Project Scheduling

Resources
Management

© PROF. GUFRAN QURESHI

Creating Critical Paths copyrig

The critical path method provides a structured approach to project scheduling,

allowing you to identify the operations most important for

successful project completion. You have to know how to break down your project into
tasks and how to arrange them so you can find the

critical path. Once you have identified tasks that are critical, you can focus on
them to ensure that they don't delay your project.

1. Break Down The Work: Start by breaking down the project work into separate
operations. An operation is a self-contained task carried
out by one person, one group or a supplier, and one to which you can assign a
duration and a responsible supervisor. Ask yourself what
tasks must be carried out to start the project and what tasks are next. Continue
until you reach the tasks that indicate the project is finished.
-Arrange the tasks ina list, approximately in the sequence in which you have to
carry out the work.

2. Arrange Tasks by Prerequisites: You can start some tasks right away without
completing any other work, but other tasks rely on
prerequisites or work that has to be completed first. Draw a column of boxes on the
left side of a sheet of paper, one box for each task that
has no prerequisites, and write the name of each task in one of the boxes. Draw a
second column of boxes with the names of the tasks that
you can start when the tasks of the first column are finished. For each task of the
second column, draw lines back to the tasks of the first
column that are its prerequisites. Continue with additional columns until you have
placed all the tasks on your chart.

3. Estimate Task Duration: You have to know how long each task takes before you can
schedule your project. Estimate the duration by calculating how long it takes based
on

known unit quantities. the duration of similar tasks and estimates by suppliers.
For bet i .
example, you can calculate how long it takes to install 16 lights if you know it
takes an jf \
hour to install one. You can look at other projects and how long it took to
complete vA \
similar work. Supplier quotes usually include an estimated delivery time. Add your
4

estimated duration to the task boxes. — Ge

through the lines showing prerequisites to the last column. It determines the
project ay ra
completion date because you must complete all tasks on the path within the
estimated

time or delay the project. For small projects of several dozen tasks, you can
determine Task Bg Task C

the critical path by following each path and adding the duration of the tasks. For
large Critical ah 9 days

projects, you can enter the data from the boxes into a project management software
a
program and have it calculate the critical path.
& |

Counting the Cost Copyright © PROF. GUFRAN QURESHI -

Definition: A project lives and dies by its budget. Just think: a project taii only
come together with all the necessary materials
and labor, and those materials and labors cost money. And in this new écohomic
reality, businesses are looking to pay less and
less for those materials and labor while maintaining—or even increasing—quality and
scope. .
» Late completion of a software development project cannot be tolerated because it
may cause delay to a dependent project or’
result in the potential loss in profits due to a missed business opportunity.
» Time delay in such situations could incur a much higher cost than the cost of the
project itself. Consequently, the
management would undertake any possible measure to ensure that their project is
delivered on time. Fs
» One of the common practices in dealing with schedule delays is adding new
manpower. Before, the project manager
undertakes to employ more manpower he should consider the cost of employing
additional staff to the cost of delayed
delivery and the increased risk of not meeting target date of delivery.
» Once, the cost of employing additional manpower is
estimated the project manager should compare this cost to
the cost of not delivering the project on time. Sv
» The cost of not delivering on time shall include: penalty if Engineering

=
any, loss in opportunities, effect on connected projected, a oes ieaeaies
additional staff expenditure, cost of other resources, etc. eS Se
° i 2 Data Gollection

Both the costs should be compared and a decision should be ] :

made. ; Metrics
Metrics .
Computation |
Metrics — Indicators
_ Evaluation

Being Specific Copyright © PROF. GUFRAN QURESHI

Definition: Allocating resources and smoothing resource histograms is relatively

straightforward where all resources of a
given type can be considered more or less equivalent. When allocating labourers to
activities in a large building project we
need not distinguish among individuals - there are likely to be many labourers and
they may be treated as equals so far as skills
and productivity are concerned.

In allocating individuals to tasks, a number of factors need to be taken into

account.

1. Availability: We need to know whether a particular individual will be available

when required. Reference to the
departmental work plan determines this but the wise project manager w ill always
investigate the risks that might be
involved - earlier projects might, for example, over-run and affect the
availability of an individual.

2. Criticality: Allocation of more experienced personnel to activities on the

critical path often helps in shortening project
durations or at least reduces the risk of overrun.

3. Risk: Identifying those activities posing the greatest risk, and knowing the
factors influencing them, helps to allocate staff.
Allocating the most experienced staff to the highest risk activities is likely to
have the greatest effect in reducing overall
project uncertainties. More experienced staff are, however, usually: more
expensive.

. 4. Training: It will benefit the organization if positive steps are taken to

allocate junior staff to appropriate non-critical
activities where there will be sufficient slack for them to train and develop
skills. There can even be direct benefits to the
particular project since some costs may be allocated to the training budget.

5, Team Building: The selection of individuals must also takes account of the final
shape of the project team and the way they
will work together.
Publishing the Resource Schedule Copyright © PROF. GUFRAN QURESHI

Definition: Resource scheduling refers to the set of actions and methodology used
by organizations to efficiently assign

the resources they have to jobs, tasks or projects they need to complete, and
schedule start and end dates for each task

or project based on resource availability.

» The best source to publish resource schedule is through the work plan. The
purpose of the Project Work Plan is to promote
the efficient, organized, and timely completion of the work product according to
schedule, budget and contract
requirements.

» The Project Work Plan details the job scope, defines the work product and
establishes task sequencing, budget, resource
allocation, and the schedule.

» Project Work Plan answers these questions:

* What must be done?

* Who will do it?

* How will it be done?

* How long will it take?

* How much will it cost?

* What are the deliverables?

* How will quality be maintained?

* What is the schedule?

» Once the work plan is ready some information from it can be transferred to the
precedence network which will show the
scheduled start and completion dates.

Scheduling Sequence copyright

Definition: Scheduling in project management is the listing of activities,

deliverables, and milestones within a project. A

schedule also usually includes the planned start and finish date, duration, and
resources assigned to each activity. Effective

project scheduling is a critical component of successful time management.

> The activity plan and risk assessment would provide the basis for our resource
allocation and schedule from which we
would produce cost schedules.

» Inpractice, successful resource allocation often necessitates revisions to the

activity plan, which, in turn, will affect our risk
assessment. Similarly, the cost schedule might indicate the need or desirability to
reallocate resources or revise activity
plans - particularly where that schedule indicates a higher overall project cost
than originally anticipated.

» The interplay between the plans and schedules is complex - any change to any one
will affect each of the others. Some
factors can be directly compared in terms of money - the cost of hiring additional
staff can be balanced against the costs of
delaying the project's end date. Some factors, however, are difficult to express in
money terms (the cost of an increased risk,
for example) and will include an element of subjectivity.

For scheduling a project, it is necessary to -

Break down the project tasks into smaller, manageable form

Find out various tasks and correlate them

Estimate time frame required for each task

Divide time into work-units

Assign adequate number of work-units for each task

Calculate total time required for the project from start to finish

t © PROF. GUFRAN QURESHI

AWRY NS
$3

Unit IV

Ch 9: Monitoring and Contrdl: Introduction, Creating thé Framework, Collecting the

Data, Review,
Visualizing Progress, Cost Monitoring, Earned Value Analysis, Prioritizing
Monitoring, Getting the Project
Back to Target, Change Control, Software Configuration Management (SCM).

Ch 10: Managing Contracts: Introduction, Types of Contract, Stages in Contract

Placement, Typical Terms
ofa Contract, Contract Management, Acceptance.

Ch 11: Managing People in Software Environments: Introduction, Understanding

Behaviour,
Organizational Behaviour: A Background, Selecting the Right Person for the Job,
Instruction in the Best
Methods, Motivation, The Oldham—Hackman Job Characteristics Model, Stress, Stress
Management, Health
and Safety, Some Ethical and Professional Concerns.

Copyright © PROF. GUFRAN QURESHI

Ch-9 Monitoring and Control Copyright © PROF. GUFRAN QURESHI

Definition: Monitoring and Controlling Project Work involves tracking the actual
project performance with the planned project
management activities. It can mainly be looked as a Control function that takes
place at all stages of a project i.e. from
Initiation through Closing.
> Monitoring and Controlling process is an iterative process and hence continuously
performed throughout the life of the
project.
>» According to the Project Management Body of Knowledge (PMBOK), “the Monitoring
and Control Process Group consists
of those processes performed to observe project execution so that potential
problems can be identified in a timely manner
and corrective action can be taken, when necessary, to control the execution of the
project”.
> The main purpose of monitoring and controlling activities is to be proactive in
finding issues ahead of time and taking
corrective action. Taking corrective actions is a reactive approach whereas taking
preventive actions is a proactive
approach.
>» Monitoring and control keeps projects on track. The right controls can play a
major part in completing projects on time. The
data gathered also lets project managers make informed decisions. They can take
advantage of opportunities, make changes
and avoid crisis management issues.
Monitoring and control method:
» When setting up a project’s monitoring and control process, first establish the
project baselines. This includes the scope, schedule and budget. Use this
, information to benchmark the project’s progress throughout the lifecycle.
> Use a Work Breakdown Structure (WBS) to break a project down into small units
of work, or sub-tasks. This makes the work easier to manage and evaluate. This
_ enables easier detection of issues, keeps the project under control and allows
for
easier progress verification. It also helps prevent team members from feeling
overwhelmed.
Planning
Seed

Eis
bate LL
Creating the Framework

Definition: Exercising control over a project and ensuring that targets are met is
a matter of regular monitoring, finding out
what is happening, and comparing it with currenttargets.

If there is mismatch between the planned outcomes and the actual ones then either
preplanning is needed to bring the project
back on target or the target will have to be revised.

1,
2.
3:

4.
5.

Define objectives — at the beginning of the project we decide on what we want to

achieve.

Making decisions/plans— we decide how we are going to achieve the objectives i.e.
we create a plan.

Modelling — as part of the process of creating a plan we will consider different

approaches and attempt to assess the
consequences of each of these approaches in terms of how much it will cost and how
long it will take, and so on.

Implementation — the plan is now carried out. Actions

Data collection — we gather information at regular about how the project is (la
progressing. These raw details could be quite numerous and complex on a large

project. : sia

Data processing — we process the progress data and convert it into coltectlon
‘information’ which makes it easier for the project managers and others to - : bata
understand the overall condition of the project. ; E

Making decisions/plans — in the light of the comparison of actual project

objectived pacenag

progress with that planned, the plans are modified. This may require the | —— |
information
modelling of the outcomes of different possible courses of action. c

: | taking
decisions/plans
Modelling l+______} Decistons

implementation

Collecting the Data Copyright © PROF. GUFRAN QURESHI

Definition: Data collection is the process of gathering and measuring information

on targeted variables in an established
system, which then enables one to answer relevant questions and evaluate outcomes.

>

>

™ Vv

Data is necessary for project management. It serves as the backbone for all types
of decisions to be made by the project
manager. It is, therefore, important to collect, organize and present data clearly
so that all stakeholders will understand the
status of the project.
This is the reason why it is so important for good project managers to not only
know and understand but also utilize data

gathering and representation techniques. These techniques are used to collect,

organizé and present data and other
information involved in the project life cycle.

There are two types of data gathering and representation techniques used in project
management and these include:
Interviewing: Interviewing is a technique that draws the historical data to
quantify the impact of risks on the objectives of
the project, The information that needs to be collected and organized depends on
the type of probability distributions
used. It is also important to create the necessary documents such as the risk
ranges to provide important insight on the
credibility of the analysis of the data.

Probability distribution: These method uses extensive simulation

and modeling. It represents uncertain values like duration of ©

scheduled activities as well as the cost of the different components of
: Boi a AB ged val : i PHONE ONLINE IN-PERSON

the project. The probability distribution may include discrete and SURVEYS SURVEYS
INTERVIEWS
uniform depending on the data that is available. Distribution methods
are used to depict that shapes compatible wi the data developed High sence | VS |
GD Self-manage| vs | @ in-depth
during a quantitative risk analysis. Need ‘ites Time

Aside from the two methods, simulation is also another method boat SeCuisiey
CRLNISL NI

used to estimate the risk and probability distribution. © Meee

Review Copyright © PROF. GUFRAN QURESHI

Definition: A review is a systematic examination of a document by one or more

people with the main aim of finding and

removing errors early in the software dévdlopment life cycle. Reviews are used to
verify documents such as requirements,

system designs, code, test plans and test casés.

Importance:

1. Productivity of development team is improved and timescales reduced because the

correction of defects in early stages and
work-products will help to ensure that those work-products are clear and
unambiguous.

2. Testing costs and time is reduced as there is enough time spent during the
initial phase.

3. Reduction in costs because fewer defects in the final software.

Types of Reviews:

There are mainly 3 types of software reviews:

1. Peer Review: Peer review is the process of assessing the technical content and
quality of the product and it is usually
conducted by the author of the work product along with some other developers. Peer
review is performed in order to
examine or resolve the defects in the software, whose quality is also checked by
other members of the team.

Peer Review has following types: TS

i, Code Review: Computer source code is examined in a systematic way. ate ME

it Pair Programming: It is a code review where two developers develop code together
at the same platform.
iii Walkthrough: Members of the development team is guided by author and other 4
interested parties and the participants ask questions and make comments about
defects.
iv. Technical Review: A team of highly qualified individuals examines the software
product for its client’s use and identifies technical defects from specifications
and
standards.
y. Inspection: In inspection the reviewers follow a well-defined process to find
defects.

Copyright © PROF. GUFRAN QURESHI

2. Software Management Review: Software Management Review evaluates the work

status. In this section decisions

regarding downstream activities are taken.

3. Software Audit Review: Software Audit Review is a type of external review in

which one or more critics, who are nota
part of the development team, organize an independent inspection of the software
product and its processes to assess their
compliance with stated specifications and standards. This is done by managerial
level people.

Advantages of Review:

Defects can be identified earlier stage of development (especially in formal

review).

Earlier inspection also reduces the maintenance cost of software.

It can be used to train technical authors.

It can be used to remove process inadequacies that encourage defects.

VV VV
Visualizing Progress Copyright © PROF. GUFRAN QURESHI
Definition: Having collected data about project progress, a manager needs some way
of presenting that data to greatest
effect. In this section, we look at some methods of presenting a picture of the
project and its future. Some of these methods
{such as Gantt charts) provide a static picture, a single snap-shot, whereas others
(such as time-line charts) try to show how
the project has progressed and changed through time.
I. Gantt Chart :

> This is an older planning and scheduling tool, however it remains

popular because ofits simplicity. Planning

® Henry Gantt, an American mechanical engineer, and social scientist

designed the Gantt chart in the 1910s. ,

>» The Gantt chart combines two functions planning and scheduling. Design.
With the Gantt charts, the scheduling of activities occurs
simultaneously with their planning. Implementation |

» The person drawing the activity lines or bars must be aware of the ~_ ~ f
interrelationships of the activities that is the activities must be
finished before the others start and which activities can be performed
concurrently.

Il. Milestone Slip Chart

» Amilestone slip chart is a simple but very effective progress report.

> On a weekly or monthly basis milestones are plotted on a grid to

show when they are scheduled to occur. In the example 0 represents
the start of the project or programme. In the baseline schedule
milestone MI is due to occur in week 2; M2 in week 5 and M3 in
week 7.

aE a els

Research
Followup

OoOMNOUSWNAZO

=
°o

Copyright © PROF. GUFRAN QURESHI

» At the end of the first week of work, all three milestones are on schedule, by
the end of week two they are all running a
week late. At the end of week three M1 finishes a week late and the other
milestones are still running one week late.

> In week four M2 is back on schedule but M3 is still running a week late. M2
finishes on time in week five but by week six
M3 has been delayed a further week.

» The progress dates can be easily transferred from a detailed schedule to this
simple report which will be perfectly adequate
for many stakeholders who only require high level progress information.

II. Ball Chart

> A somewhat more striking way of showing whether or not targets have
been met is to use a ball chart.

> In this version of the ball chart, the circles indicate start and completion
toons
points for activities. The circles initially contain the original scheduled \ 110%
dates. Whenever revisions are produced these are added as second dates
in the appropriate circle until an activity is actually started or completed
when the relevant date replaces the revised estimate.

» Circles will therefore contain only two dates, the original and most recent
target dates, or the original and actual dates.

> Where the actual start or finish date for an activity is later than the target
date, the circle is coloured red . .

» Where an actual date is on time or earlier than the target then the circle is
coloured green. ,

Code and test module A

Code and test module B

Code and test module C

2700S
270105

17/10/05
17/10/05
e71

Copyright @ PROF. GUFRAN QURESHI

IV. Timeline Graph
> One disadvantage of the charts describéd so far is that
they do not show clearly the slippdge of the project New Product Development
Timeline
completion date through the life of the project.
» The timeline chart is a method of recording and {dea Selection ee nd of
Development
displaying the way in which targets have changed munch
throughout the duration of the project. idee Generation

>» Timeline chart is mainly used in project management for

showing milestones, deadlines and other significant
dates and events of a project. Unlike a Gantt chart, it is an Fee March apr i june
Wy AU Sep Nov ee

not very detailed and just provides a general overview of

a sequence of events over time.

> Timeline chart can also be used in other areas and =!

professions to illustrate the chronology of key events
and developments.
Cost Monitoring Copyright © PROF. GUFRAN QURESHI

Definition: Cost monitoring is an ongoing process and its importance cannot be

undermined during the project life cycle. It

can be monitored by using traditional approach of direct reporting of actual cost

against budget.

> Cost monitoring is an important component of project control. Not only in itself,
but also because it provides an indication
of the effort that has gone into (or at least been charged to) a project.

>» A project might be on time but only because more money has been spent on
activities than originally budgeted. A
cumulative expenditure chart such as that shown in figure provides a simple method
of comparing actual and planned
expenditure. ° — ion

1. Planned Cost: Planned Cost is the approved value of the work to be

completed in a given time.

2. Actual Cost: Actual Cost is the total cost incurred for the actual
work completed to date.

> It is the process of monitoring the status of the project to update the
project budget and managing changes to the cost baseline.

> It involves taking the cost baseline and performance data about what
has actually been done in order to determine the work accomplished
against the amount spent. —_—
> Monitoring the expenditure of funds without regard to the value of work being
accomplished for such expenditures has
little value to the project other than to allow the project team to stay within the
authorized funding.

> The key to effective cost control is the management of the approved cost
performance baseline and the changes to that

baseline.

Cumulative cost (£)

ROF, GUFRAN QURESHI

Earned Value Analysis copys

Definition: The Earned Value Analysis(EVA) is also known as Earned Value Method
(EVM). This method allows the project manager
to measure the amount of work actually performed on a project. It is possible to
measure the project one to the progress

achieved.
> In project management, the Earned Value method is one of the most appreciated and
well-known project ren It isa

project management technique that allows to measure performance and progress. It

combines the measures of the project
management triangle: scope, time and costs.

> In a unique integrated system, the Earned Value Method is able to give accurate
predictions on the performance problems of a
project. Earned value analysis uses three key pieces of project information: the
planned value, actual cost, and earned value, which
are shown in figure:

1. Planned Value: Planned Value is the budgeted value of the work to be completed
ina given time. This is the portion of the project
budget planned to be spent at any given point in time. We calculate Planned Value
before actually doing the work, which also
serves as a baseline. Total Planned Value for the project.is known as Budget at
Completion (BAC). Planned Value is also known as
the budgeted cost of work scheduled (BC WS). % Status Date mama!

Planned Value = % Complete (Planned) x BAC $5 : PY - planned work

2. Actual Cost: Actual Cost is the total cost incurred for the actual work
completed to gg po Cie aera
date. Simply put, it is the amount of money you have spent to date. Actual Cost
(AC) LAC = What the work
is the total cost actually incurred in accomplishing work performed for an activity
or actually cost
WBS component. Total Actual Cost for the project is known as Actual at Completion
25 | actual work]
(AAC). Actual Cost is also known as the actual cost of work performed (ACWP).
accomplished

Actual Cost = % Complete (Actual) x AAC ole :

3. Earned Value: Earned Value (EV) is the percent of the total budget actually
completed time | 6 12 ac 24

at a point in time. Earned Value (EV) is the value of work performed expressed in
terms of the approved budget assigned to that
work for an activity or WBS component. This is also known as the budgeted cost of
work performed (BCWP).
Earned Value = % Complete (Actual) x BAC
t © PROF. GUFRAN QURESHI

For example, if a Work Package is the installation of 500 new computers in an

office, and 350 computers are installed, the
Work Package progress is 70% complete (350/500). If the budget for this Work
Package is US$200,000, the earned value is

US$140,000 (0.70 x $200,000).

An effective method to show the relationship between PV, EV, and AC is shown in
figure below.

The work with the

schedule and budget Costs

ste — Actual
Scheduled | P\

Work
Performed

Earned Value looks at the

budget amount for the The work performed (done)

work performed and the costs for that-work

are ACTUAL results
Measurement of Variances

GUFRAN QURESHI

Definition: The variance analysis is a method where the achieved results of a

project are compared to the expected results.
When a project is approved, certain expected results are established, as well as a
planning in order to achieve them. The variance
analysis, in case of failure to achieve those results, helps to understand the
amount of difference between the expected results
and those actually achieved. .

This technique is used to highlight cost and time variances, i.e., the cost
variance and the schedule variance.

1. Cost Variance (CV): This value indicates how the project is evolving with
respect to the initially estimated’ budget. The cost

variance is calculated by subtracting the earned value from the costs actually
incurred, here is the formula: CV = EV — AC.
If the result equals 0, it means that the project is perfectly respecting the
budget.

If the result is negative, this means that the project is out of budget, i.e., the
costs incurred are greater than those planned. It
is therefore necessary to take action.

On the other hand, if the result is positive, it means that the project is under
budget, i.e., the costs incurred are lower than
those planned.

i “Cost Variance
CW EEV-AC
CV .< 05 Over Budget

Schedule Variance (SV): With respect to the scheduling initially approved, '
the project may be late, in advance or in line with the initial planning. This
value represents the Schedule Variance (SV). It is essential to understand
how this value does not provide data on the impact that any delay in
work has on the project and its results. It simply indicates whether the work
is in line with the planning or not. Here is the formula: SV= EV — PV.

If the result is 0, it means that the project is in line with the planning.

If the result is positive, it means that the project is ahead of schedule.

On the other hand, if the result is negative, it means that the project
is behind the schedule and it is necessary to take action. Data Date o-

Cost Performance Index

CPI=EV/AC
CPI< 1} Over Budget

Schedule Variance LO
sv2EV-PV &
SV <0 Behind Schedule

Schedule Performance Index

SPl= EV / PV
SPI<1-> Behind Schedule

© PROF. GUFRAN QURESHI

Performance Indices as a Measure of Efficiency —»v«

Definition: Another analysis that can be performed using the Earned Value Method is
that of project efficiency.
In particular, there are two types of efficiency analysis: the Schedule Performance
Index (SPI) and the Cost Performance Index

(CPI).

1.

Schedule Performance Index (SPI): The SPI is an indicator of the efficiency of the
program of a project.

In fact, it is the ratio between the earned value (EV) and the planned value (PV):
SPI= EV / PV.

If the SPI is equal to or greater than one, this indicates a favorable condition.
This means that the project is being carried out
efficiently.

On the contrary, a value lower than one indicates a negative situation.

Cost Performance Index (CPI): The CPI is the indicator of economic efficiency of a
project and is the ratio between the
earned value (EV) and the actual costs (AC): CPI = EV/AC.

A CPI equal to or greater than one indicates a favorable condition and a value
below one indicates a negative situation.
Therefore, in general, it is possible that our project is in line with the planning
or is efficient or inefficient.

___ CPI & SPI Se ee eee See

Ce ss 5 a
epic io Over Budget, Behind Over Budget, On ver Budget,

_ Schedule Schedule Ahead of Schedule

eae pies a On Budget, Behind On Budget, On On Budget, Ahead
aie Bas Schedule Schedule of Schedule
_ Under Budget, Under Budget, On — Under Budget,

hl> 1-0 Behind Schedule Schedule Ahead of Schedule

Forecasting Parameters

Definition: There are three basic forecasting parameters in the EVM (Earned Value
Management) relating to completion costs.
These are budget at completion (BAC), estimate to complete (ETC), and estimate at
completion (EAC). These estimates allow
us to see when the project will be completed and how much it will cost to complete
it.

1. Budget at Completion (BAC): The BAC indicates the total value of the costs
initially foreseen for the project and is

calculated by summing the initial costs foreseen for each individual activity.
The BAC must always be equal to the total PV of the project.
If these two values do not match, the calculations related to the earned value will
be inaccurate,

- Estimate to Complete (ETC): It is the. expected additional cost needed to

complete the project. ETC to complete the
balance work could be assessed on the basis of CPI achieved up to the review date.
ETC is used for the calculation of EAC.
ETC =(BAC ~ EV) / CPI
iyi EINE i oncopsenalgliiidtsSa Sad MEAG
. Estimate at Completion (EAC): The EAC is the total cost | ie ee .
expected for a scheduled activity. | Now pon ae —
It is considered that the remaining work is performed on | ET Contingencies

schedule and based on the current CPI and SPI.

The EAC is a periodic evaluation of the project.

It is usually carried out on a monthly basis or when there is

a significant change in the project.

A common formula that allows to determine the EAC is

expressed as the budget to completion divided by the current
project CPI: EAC = BAC / CPI.

DOLLARS

(re
th,
a
sO

Y/Y *S 1 NOTE: Most ETC & EAC formulas

: include an adjustment based on
project performance (CPI, SPi)
TIME
: Prioritizing Monitoring Copyright © PROF. GUFRA
Definition: Although, monitoring each and every activity of the project is
essential it is not ~~ —
financially feasible as monitoring is costly and therefore cannot be undertaken
with the same. Jprmrostemtecsematemtemtnne
intensity for each activity of the project. | Monitor progress
1, Critical path activities: Any delay in an activity on the critical path will
cause a delay in the ’
completion date for the project. Critical path activities are therefore likely to
have a very high |
priority for close monitoring. | ¥
2, Activities with no free float: A delay in any activity with no free float will
delay at least fo
some subsequent activities even though, if the delay is less than the total float,
it might not | Evaluate progress
delay the project completion date. These subsequent delays can have serious effects
on our | emenpennne
resource schedule as a delay in a any subsequent activity. i Satisfactory?
3. Activities with less than a specified float / time: If any activity has very
little float it might eo
use up this float before the regular activity monitoring brings the problem to the
project | No
manager’s attention. It is common practice to monitor closely those activities with
less than, oa
say, one week free float. | Assess possible
4, High risk activities: A set of high risk activities should have been identified
as part of the - | control actions
_ initial risk: profiling exercise. If we are using the PERT three-estimate
approach we will | ——
designate as high risk those activities that have a high estimated duration
variance. These | i
‘activities will be given close attention because they are most likely to overrun
or overspend. pope a mat
5. Activities using critical resources: Activities can be critical because they are
very expensive Select and
(as in the case of specialized contract programmers). Staff or other resources
might be bien implement contro!
available only for a limited period, especially if they are controlled outside the
project team. | action

In any event, an activity that demands a critical resource requires a high level of
monitoring,
a |

Getting the Project Back to Target

Definition: Almost any project will, at 6fé time or another, be subjett to delays
and unexpected events. One of the tasks of
the project manager is to recognize wherl this is happening (or, if poss{bié, about
to happen) and, with the minimum delay and
disruption to the project team, attempt to {itigate the effects of the probleth.

There are two main strategies to consider when drawing up plans to bring a project
back on target - shortening the critical path

or altering the activity precedence requirements. ,

‘I. Shorten the critical path (Crashing): The overall duration of a project is
determined by the current critical path, so
speeding up non-critical path activities will not bring forward a project
completion date.

Resource levels can be increased by making them available for longer. Thus, staff
might be asked to work overtime for the
duration of an activity and computing resources might be made available at times
(such as evenings and week-ends) when
they might otherwise be inaccessible.

Where these do not provide a sufficient solution, the project manager might
consider allocating more efficient resources to
activities on the critical path or swapping resources between critical and non-
critical activities.

2, Reconsider the precedence requirements: If attempting to shorten

critical activities proves insufficient, the next step is to consider the

constraints by which some activities have to be deferred pending
completion of others. The original project network would most
probably have been drawn up assuming ‘ideal’ conditions and
‘normal’ working practices.
One way to overcome precedence constraints is to subdivide an
activity into a component that can start immediately and one that is
still constrained as before. For example, a user handbook can be
drawn up ina draft form from the system specification and then be
revised later to take account of subsequent changes.

Eyoject start | Split Target Project Finish

Change Control

Definition: The change control process in. project management ensures that each
change proposed during a project is

adequately defined, reviewed and approved before implementation. The change control
process helps avoid
unnecessary changes that might disrupt services and also ensures the efficient use
of resources. Change control is a systematic
approach to managing all changes made to a product.

Change control contains five stages:

1. Proposing a Change: This process gives the ability for anyone in the project
team (including the customer} to suggest a
change to the project. The proposal must include a description of the change and
expected benefits or other reason for the
change. The change is presented using the Change Request Form and added to the
Change Log for the project.

2. Summary of Impact: This process is carried out by the project manager, who will
consider the overall ‘effect on the
project, covering the following items: Quantifiable cost savings and benefits,
Legal, regulatory or other unquantifiable
reason for change, Estimated cost of the change, Impact on timescales, Extra
resources needed, Impact on other projects
and business activities, New risks and issues. ;

3. Decision: This process involves a review of the change request by an (2) Request
for Change
approved authority who will consider all the information provided by the
project manager and person making the request.

4. Implementing a Change: If the change is approved it is planned,

scheduled and executed at a time agreed with the stakeholders. As part of
the planning, a regression test plan is needed in case the change needs to
be backed out. After implementation, it is usual to carry out a post-
implementation review.

5. Closing a Change: Once implemented, the requester checks and agrees Y

on the change, and it is closed in the Change Log by the project manager. Implement
Change 6 g Approve / Deny

Review / Reporting @ e Impact Analysis

Software Configuration Management (SCM) Copy

QURESHI

Definition: Software configuration management (SCM) is a supporting-software life

cycle process that benefits project
management, development and maintenance activities, quality assurance activities,
as well as the customers and users of the
end product.

1.

Roger Pressman says that SCM is a “set of activities designed to control change by
identifying the work products that are
likely to change, establishing relationships among them, defining mechanisms for
managing different versions of these
work products, controlling the changes imposed, and auditing and reporting on the
changes made.”

Software project managers pay attention to the planning and execution of

configuration management, an integral task,
because it facilitates the ability to communicate status of documents and code as
well as changes that have been made to
them.

High-quality released software has been tested and used, making it a reusable asset
and saving development costs. Reused
components aren’t free, though—they require integration into new products, a
difficult task without knowing exactly what
they are and where they are.

__ Analysis
'___and-Design ,

> ‘ j

Virtually everyone on a software project is affected by SCM. From the

framers of the project plan to the final tester, we rely on it to tell us how
to find the object with the latest changes.

Because SCM is such a key tool in improving the quality of delivered E

products, understanding it and how to implement it in your organization Mairjte
and on your projects is a critical success factor. \

coe r
Management :

Ch-10 Managing Contracts copyrigh

Definition: Contract management or contract administration is the process of
managing contract creation, execution, and
analysis to maximize operational and financial performance at an organization, all
while reducing financial risk. Organizations
encounter an ever-increasing amount of pressure to reduce costs and improve company
performance.

>

>

mV

Contract management is the process of managing contracts from vendors, partners,

customers, or employees. It supports the
entire customer and contract lifecycle which covers any process that contributes,
creates or utilizes contract data.

Effective Contract Management requires an understanding of every step in the

contract process, including any step that
contributes, creates, or utilizes contract data.

It is not always that the project manger is a permanent employee of the

organization. Many a times, we find organizations
availing of the independent IT professionals for the implementation of specific IT
projects.

From the organizations point of view, the biggest advantages of working with an
outside professional is that apart from
bringing in the required technical expertise and fresh perspective they are totally
into the projectall the time.

While dealing with an external project manager the organization demands the
following:

Bid: An indication of how much the IT professional would charge the client to carry
out the potential project when
competing with other freelancers / businesses. CREATE NEGOTIATE APPROVE SION
Estimate: An approximation of the overall project costs based

on past projects of similar scope or extrapolating on whatever © ——- © — © aaa ©

information is available.

Proposal: An interpretation of the client’s specific needs and

how the IT professional plans to execute and charge for it.

Contract: A legally binding agreement between the IT F

professional and the client that includes any contract @ — & = © — ©
provisions.

EXIT RENEW TRACK EXECUTE

CONTRACT LIFECYCLE MANAGEMENT

Elements of a Proposal Copyright © PROF. GUPRAN QURESHI

Definition: The elements of project proposal are a document which éxplains a clear
strategic direction of project, why the
project exists in a particular situation, what kind of problems the project
attempts to address, what make the project successful,
and what are the required resources.

Elements:

1.

Summary of Project: The project summary is a one page document that consists of
separate overview, intellectual merits,
and broader impacts sections. Each of these three sections is required to be
present and must be clearly defined.

. Overall budget and costs: Identify what the overall project budget looks like. At
this point the IT professional will have to

negotiate with the organization and give a written estimate of total cost.

Breakdown of each task and associated costs: Identify the specifics of each task
and justify associated costs: Some costs
may be fixed while others may be more variable. Some costs may be speculative and
hence need to be indicated.

Payment Schedule: States the manner in which the payment for the work undertaken is
expected.

Provisions: Identify any provisions that are specific to the project. Provisions
are an extremely important piece of the
proposal as they allow the IT professional to set his terms in a legally-binding
manner. The provisions included within the
project proposal should include any that are specific to the project as well as any
that are general to, the business.

. Signatures: Even though the proposal likely won’t be a legally binding contract
once it has been negotiated and agreed

upon, itis still good to sign off and have the client sign off on it as well.

Elements of a Contract Copyright © PROF. GUFRAN QURESHI

Definition: An agreement between private parties creating mutual obligations

enforceable by law. The basic elements required
for the agreement to be a legally enforceable contract are: mutual assent,
expressed by a valid offer and acceptance; adequate
consideration; capacity; and legality.

After the proposal has been finalized and agreed upon, it is time for the contract.
Some of the very essential elements of a
contract are:

Le

The scope of work: The Scope of Work should describe in detail what the freelancing
IT professional is expected to do for
the organization. A vague or incomplete Scope of Work is a recipe for problems down
the road, with the client claiming
that the work doesn’t meet their specifications. So, clarity in Scope of Work is of
utmost importance. The ‘client should
know exactly what to expect before the work stars.

Deadlines: Few things cause more disruption in a freelancer’s life than a client
suddenly moving up a deadline. Make sure
the contract states when the work is due. If the project is broken up into phases,
assign a deadline to each phase. It can’t
hurt to say in the contract that if the scope of work changes, the deadline is also
subject to change, and vice versa.
Payment: The IT professional can be paid by the hour, by the project, or whatever
other arrangement the two parties
devise. But whatever the arrangement it has to be clearly mentioned in the
contract.

Payment timing and late fees: The timing of the payment is as important as the
amount that is being paid. In some cases
payment is made against the delivery of the work while in some cases time is given
to the client to make the payment. If an
advance is expected the freelancer should mention so.

Early termination: Clients sometimes change their minds and cancel projects. If the
work has already commenced and the
client pulls the plug, the freelancer is likely to suffer. In contract-speak this
scenario is known as “early termination and it’s
important that the freelancer and the client havea plan in place should it happen.
‘
Types of Contract Copyright © PROF, GUFRAN

Definition: The contract is simply an elaborated agreement between two or more

parties. One or more parties may provide
products or services in return to something provided by other parties (client). The
contract type is the key relationship between
the parties engaged in the business and the contract type determines the project
risk. s

1.

Fixed Price (Lump Sum): This is the simplest type of all contracts. The terms are
quite straightforward and easy to
understand. To put in simple, the service provider agrees to provide a defined
service for a specific period of time and the
client agrees to pay a fixed amount of money for the service. The main advantages
of this type of contract is that the
contractor knows the total project cost before the project commences.

Unit Price: In this model, the project is divided into units and the charge for
each unit is defined. This contract type can be
introduced as one of the more flexible methods compared to fixed price contract.
This is a good approach when different
project units require different expertise to complete.

Cost Plus: In this contract model, the services provider is reimbursed for their
machinery, labourand other costs, in
addition to contractor paying an agreed fee to the service provider. In this
method, the service provider should offer a
detailed schedule and the resource allocation for the project. Apart from that, all
the costs should be properly listed and
should be reported to the contractor periodically. :

Incentive: Incentive contracts are usually used when there is some level of
uncertainty in the project cost. Although there
are nearly-accurate estimations, the technological challenges may impact on the
overall resources as well as the effort.
There are three cost factors in an Incentive contract; target price, target profit
and the maximum cost.

Retainer (Time and Material - T&M): This is one of the most beautiful engagements
that can get into by two or more
parties. This engagement type is the most risk-free type where the time and
material used for the project are priced. Unlike
most of the other contract types, retainer contracts are mostly used for long-term
business engagements.

Percentage of Construction Fee: This type of contracts is used for engineering

projects. Based on the resources and
material required, the cost for the construction is estimated. Then, the client
contracts a service provider and pays a
percentage of the cost of the project as the fee for the service provider.

Stages in Contract Placement o

Definition: Contract management or contract administration is the process of
managing contract creation, execution, and
analysis to maximize operational and financial performance at an organization, all
while reducing financial risk.
Organizations encounter an ever-increasing amount of pressure to reduce costs and
improve company performance.

1.

Contract Preparation—Identify Your Needs, Establish Goals, Set Expectations, and

Define Risk: Contracts are
legally binding documents that should not be approached lightly. It’s important to
be organized and prepared with the
right resources. Properly identifying the needs, reasons, and ultimate goals that
require a contract makes any decisions
down the line much easier.

. Author the Contract: Consulting with In-House Counsel or an attorney is wise,

especially if there are any uncertainties.

Better yet, using a preset template drafted by your legal team to ensure all the
information is up-to-date and all required
clauses and terms are automatically included.

Negotiate the Contract: No matter how much research, planning, and preparation goes
into the first draft of a contract,
negotiation almost always follows. Negotiation should begin with transparency and
trust. Anticipating and researching the
other party’s needs before the conversation simplifies the process and creates a
strong foundation for a lasting
relationship. ;

Get Approval Before Finalizing the Contract: After negotiations are complete and
both parties agree, next comes
approval. In larger companies that need manager approval or have audit procedures,
all the requirements for approval will
need to be met before finalizing the deal.

Execute the Contract: The signing should be the simplest part of a contract: both
parties agree, the wording is exact, and
the next step is simply making it official. Howeyer, many businesses make
ggreements across the country or even the
globe, and getting signatures isn’t as straightforward as meeting in person.
6.

<

Copyright © PROF. GUF

AN QURESHI

Keep Up With Amendments and Revisions: Contracts are rarely stagnant. Revisions and
amendments are a common part
of the lifecycle of a contract. Tracking thanges and the effects for each party can
be confusing; however, this is another
reason to implement a reliable process, such as a contract lifecycle thanagement
platform, to easily record edits and add
amendments. It’s important to stay aliead of the changes and make sure both parties
are fully aware and in agreement on
any revisions.

Manage After the Signature—Obligations, Auditing, and Renewals: Contract management

doesn’t stop once the ink
dries, Performing regular audits will ensure obligations are met and value is
realized. Alerts should be set for deadlines and
renewals. Missed renewals mean lost opportunities to continue a relationship, and
most importantly for a company, lost
revenue.

CREATE NEGOTIATE APPROVE SIGN

CONTRACT LIFECYCLE MANAGEMENT

6 e060 6

EXIT RENEW TRACK EXECUTE

Typical Terms of a Contract Copyright © PROF. GUFRAN QURESHI

Definition: The terminology used in the contract document may need to be defined,
for example, who is meant by the words
‘client’ and 'supplier’.

1.

2.

3.

Form of agreement: For example, is it a contract of sale, a lease, or a licence?

Also, can the subject of the contract, such
as a licence to use a software application, be transferred to another party?

Goods and services to be supplied: Equipment and software to be supplied This

includes an actual list of the individual
pieces of equipment to be delivered, complete with the specific model numbers.

Ownership of the software: Who has ownership of the software? There are two key
issues here: firstly, whether the
customer can sell the software to others and, secondly, whether the supplier can
sell the software to others. Where off-the-
shelf software is concerned, the supplier often simply grants a license for you to
use the software.

Environment: Where physical equipment is to be installed, the demarcation line

between the supplier's and customer's
responsibilities with regard to such matters as accommodation and electrical supply
needs to be specified.

Customer commitments: Even when work is carried out by external contractors, a

development project still needs the
participation of the customer. The customer will have to provide accommodation for
the suppliers and perhaps other
facilities such as telephone lines.

Acceptance procedures: Good practice would be to accept a delivered system only

after it has undergone user acceptance
tests. This part of the contract would specify such details as the time that the
customer will have to conduct the tests,
deliverables upon which the acceptance tests depend and the procedure for signing
off the testing as completed.

Standards: This covers the standards with which the goods and services should
comply. For example, a customer can
require the supplier to conform to the ISO 12207 standard relating to the software
life cycle and its documentation (or,
more likely, a customized sub-set of the standard).

Project and quality management: The arrangements for the management of the project
must be agreed. Among these
would be frequency and nature of progress meetings and the progress information to
be supplied to the customer. The
contract could require that appropriate ISO 9000-series standards be followed.
Contract Management Copyright © PROF, GUFRAN QURESHI

Definition: Contract management is a continuous process, starting with analysis and

evaluation of the customer’s inquiry, and
carrying on until contract closure, upon fulfillment of all contractual
obligations. This process overview indicates that contract
management activities seem to belong to the responsibilities of the project manager
and the whole project team.

(1) Negotiation between the two contract parties: In most claim situations, we will
be able to settle the case after negotiating
with the other party.

(2) Independent expert opinion: The contract parties agree to call a neutral third
party for determination of specific contract
elements, their interpretation, and an expert opinion on the case.

(3) Executive tribunal or mini-trial: This is a process, sometimes called 'mini-

trial’, in which the parties make formal but
abbreviated presentations of their best legal case to a panel of senior executives
from each party, usually with a mediator or
expert as neutral chairperson, Following the presentations, the executives meet
(with or without the mediator or expert) to
negotiate a settlement on the basis of what they have heard.

(4) Dispute review board: The dispute review board is a 'standing' adjudication
panel used in major construction contracts.
This board is normally appointed at the beginning of the project and stays in close
touch with it, adjudicating disputes as they
arise.

(5) Conciliation or mediation: Conciliation and mediation are similar. "omer by the
| ’ [Accopencs by] |. ~
Conciliation refers to a process in which the third party takes a more | Company |
theCustomer | = |
activist role in putting forward terms of settlement or any opinion on [+ |
the case between the two parties. While in mediation, the third party | i | baw L¢é
Ske)
provides support to the parties during their negotiation but does not Negotiation a
interfere with the content of the case or its settlement. | Customerreacts

| too late or with changes | ‘ Acceptance by | _

{ 7 | the Company | ~~

|_ new offer by Customer |

Copyright © PROF. GUFRAN QURESHI

(6) Adjudication: In this process a neutral third-party, the adjudicator, makes
summary binding decisions on contractual
disputes without following the procedures of arbitration.

(7) Arbitration: This is a formal process, agreed by the parties, regularly with
three arbitrators who are neutral and
independent. They make a final and binding decision as first instance. On average,
the process duration is two to three years. It
follows the arbitration clauses set by the International Chamber of Commerce (ICC),
Paris, and it requires the support of
external lawyers.

(8) Court trial After arbitration as first instance, we usually can go for a formal
court trial as second and then third instance.
q+

Acceptance Copyright © PROF. GUFRAN QURESH

Definition: Acceptance of an offer is the expression of assent to its tertns,

Acceptance must generally be made in the manner
specified by the offer. If no manner of acbéptance is specified by the offer, then
acceptance may be made in a manner that is
reasonable under the circumstances.

» An acceptance is only valid, however, if the offeree knows of the offer, the
offeree manifests an intention to accept, and the
acceptance is expressed as an unequivocal and unconditional agreement to the terms
of the offer.

> Many offers specify the method of acceptance, whether it be oral or written, by
phone or in person, by handshake or by
ceremony. Other offers leave open the method of acceptance, allowing the offeree to
accept in a reasonable manner.

» Most consumer transactions fall into this category, as when a shopper “accepts” a
merchant's offer by taking possession of a
particular good and paying for it at the cash register. But what constitutes a
“reasonable” acceptance will vary according to
the contract.

» Some offers may only be accepted by the performance or non-performance of a

particular act. Once formed, these types of
agreements are called unilateral contracts.

» Other offers may only be accepted by a return promise of performance from the
offeree. Once formed, these agreements are
called bilateral contracts.

> The two most important things the contract manager does during

‘onerbythe| «| Acceptance by] =~.

this activity is: | Company | | the Customer

1. Ensure that your right to test and accept the item has not lapsed by io! |

failing to act within the committed time frame. | It oe \ p oe

2. The contract manger must document when final acceptance has Rant [ at

occurred. That is because final acceptance is frequently a trigger | Customerreacts

: | too fate or with changes | t

for when the warranty period commences. Wan changes | 4, «| Acceptanceby) |

the Company
| new offer by Customer |

Ch-11 Managing People in Software Environments coy. curs ausesi

Definition: Managing People in Projects provides a focused, rational method for
improving the performance of project
managers and those working with and for them. We have to learn who to involve in
projects—and when and how to utilize
them. We’ll also have to determine how to set expectations, track and analyze
performance, and provide feedback.
People management is the process of training, motivating and directing employees in
order to optimize workplace
productivity and promote professional growth. Workplace leaders, such as team
leads, managers and department heads
use people management to oversee workflow and boost employee performance every day.
Results delivered
1. Getting people to perform on your projects, even if they don't report to you
2. Analyzing why people aren't performing on your projects and revising your
approach
3. Identifying factors that block the success of your projects
4. Improving project results
5. Having people want to work on your projects
>

A manager’s most important and most difficult job is to ATTRACT

manage people. Manager’s role does not end in leading his REWARD | EDUCATE

people but motivating and inspiring them as well. Indeed,

PEOPLE

your employees are the biggest asset that you have. That’s
eS NOee ENT ~~

why we must invest on our own people.

TRAIN

» The most important task of manager is to bring out the best in

his people. Managers should not only focus on hiring the right
talent but also providing them the appropriate training and
development.

:
Understanding Behaviour Copyright © PROF. GUFRAN QURESHI

Managing people at work is a challenge irrespective of their qualification and

experience and it is no different in software

projects. The project manager has to adopt social science research methods to study
individual and group behaviour in

software projects.

There are 4 main behaviour styles, which fall under various headings depending on
what training method is used; these

behavioural styles are Dominance, Influence, Steadiness and Compliance.

1. Dominance: Sometimes known as the ‘doer’, these individuals are driven and they
want to succeed. Generally seen as
target-focused, they are direct, work to deadlines, and will want to achieve
results at any cost — meaning that they can
also be aggressive, dominant and forceful.

2. Influence: Those who influence are seen as leaders — they are creative, and able
to see the wider picture. Sociable and
extroverted, influencers communicate assertively and loudly to achieve goals. They
are natural leaders, who can also be
egotistical, self-centred, and impulsive.

3. Compliance: A compliant person is conscientious and meticulous — they will

work carefully, precisely, and to budget. They are introverted, enjoy working
alone, and are very adverse to risks — meaning that they can also be calculating,
private and unsociable. ae

4. Steadiness: Those who display steadiness are generally team players, who can (2
8s
be introverted but always want the best for others. Caring and friendly, steady ees
people like routine, and are known for their reliability and consistency. But
neeairiy
although they are good with people, they can become sulky, withdrawn and ie
resistant when exposed to sudden change.

Py
bi
¢
a}
a
3
oO,
uv

Organizational Behaviour: A Background Copyright © PROF. GUFRAN QURESHI

Definition: Organizational behaviour is the study of what people think, feel, and
do in and around organizations. It is a
combination of responses to external and internal stimuli by a person as an
individual or as a part of a group. All companies
function within a given internal and external environment.
Importance
1. It helps in explaining the interpersonal relationships employees share with each
other as well as with their higher and
lower subordinates.
The prediction of individual behavior can be explained.
It balances the cordial relationship in an enterprise by maintaining effective
communication.
It helps in predicting human behavior & their application to achieve organizational
goals.

= hy

There are three major factors that affect OB. The working environment being the
base for all three factors, they are also

known as the determinants of OB.

1. People: An organization consists of people with different traits, personality,

skills, qualities, interests, background,

beliefs, values and intelligence. In order to maintain a healthy environment, all

the employees should be treated equally

and be judged according to their work and other aspects that affects the firm.

Organizational Structure: Structure is the layout design of an

organization. It is the construction and arrangement of relationships,

strategies according to the organizational goal.

3. Technology: Technology can be defined as the implementation of

scientific knowledge for practical usage. |{ also provides the
resources required by the people that affect their work and task
performance in the right direction :

2
4

Selecting the Right Person for the Job Copyrigiit © PROF, GUFRAN QURESHI

Definition: Having the right people on staff is crucial to the success of an

organization. Various selection devices help
employers predict which applicants will be successful if hired. THese devices aim
to be not only valid, but also
reliable. Validity is proof that the relationship between the seléction device and
some relevant job criterion
exists. Reliability is an indicator that the device measures the same thing
Lonsistently.

There are three essential elements to selecting the right person for the job:

1. Skill fit: The person must have the knowledge and skills to do the job and this
is determined by their past experience,
education, ongoing leaming etc. You can determine the skill fit from the resume,
but you will need to verify if all that is
written is true. Most people exaggerate their skills, knowledge and accomplishments
and might even lie about their
education. Background checks can help verify the information.

2. Company fit: The person must fit with the company and more specifically with the
people in the department and the
team members. This is something you determine in the interview. It is basically
measuring how you feel about the
person. Itis important to stay as objective as you can during the interview and
treat all candidates the same.

3. Job fit: The person must also fit with the job. This means the persons
thinking :
style; behavioral style and job interests are within a good range for the job
requirements. This can only be reliably determined quickly using assessments.
There are many excellent assessments on the market but not all are designed or
suitable for use in hiring.

Bare:
fit

(presentation)

Useemaiets)

Copyright © PROF. GUFRAN QURESHI

Process of Staff Recruitment

Recruitment is a process of finding and attracting the potential resources for

filling up the vacant positions in an organization.

It sources the candidates with the abilities and attitude, which are required for
achieving the objectives of an organization.
1. Recruitment Planning: Recruitment planning is the first step of the recruitment
process, where the vacant positions are
analyzed and described. It includes job specifications and its nature, experience,
enlaliiesaems and skills required for the
job, etc.

2. Recruitment Strategy: Recruitment strategy is the second step of the recruitment

process, where a strategy is prepared
for hiring the resources. After completing the preparation of job descriptions and
job specifications, the next step is to
decide which strategy to adopt for recruiting the potential candidates for the
organization.

3. Searching the Right Candidates: Searching is the process of recruitment where

the resources are sourced depending
upon the requirement of the job. After the recruitment strategy is done, the
searching of candidates will be initialized.

4. Screening / Shortlisting: Screening starts after completion of the process of ~

7 no
sourcing the candidates. Screening is the process of filtering the applications of
RECRUITMENT PROCESS
the candidates for further selection process. Screening is an integral part of
recruitment process that helps in removing unqualified or irrelevant candidates,
which were received through sourcing.

5, Evaluation and Control: Evaluation and control is the last stage in the process
of
recruitment. In this process, the effectiveness and the validity of the process and
methods are assessed. Recruitment is a costly process, hence it is important that
the performance of the recruitment process is thoroughly evaluated.
Instruction in the Best Methods

Definition: The key to success in diverse situation is selecting and implementing

powerful instructional methods that
simultaneously address a variety of different learning needs. Some of the methods
that have worked well within a given

Copyright © PROF. GUFRAN QURESHI

scenario include multiple intelligences, cooperative learning, tiered lessons,

learning centers, and graphic organizers.

INSTRUCTIONAL Differentiated “ ‘ 5: Multicultural

METHODS TeteHetori Universal Design Sheltered Instruction Rdueatie

Multiple Encourages process and] Allows for multiple Encourages the use of |
Encourages respect for

Intelligences product differentiation |means ofreceiving and | visual cues to

diversity in learning
demonstrating knowledge| supplement language | styles

Cooperative Uses differentiationin |Capitalizes onlearners' | Supports English

Encourages respect for

Learning role assignment heterogeneity language learners cooperative learning

through peer mediation | styles

Tiered Lessons Encourages process and| Allows for multiple Provides avehicle for |
Encourages respect for

product differentiation

means of receiving and

demonstrating knowledge

differentiating
language levels

diversity in learning
styles

Learning Centers

Encourages process and

product differentiation

Allows for multiple

means of receiving and
demonstrating knowledge

Provides a vehicle for

differentiating
language levels

Encourages respect for

diversity in learning
styles

Graphic Organizers

Provides a vehicle for

scaffolding instruction

Provides a vehicle for

scaffolding instruction

Provides a vehicle for

scaffolding instruction

Embraces diverse
learners' needs

Definition: Motivation is one of the key factors driving us towards achieving

something.
Without motivation, we will do nothing. Therefore, motivation is one of the key
aspects when
it comes to corporaté management. In order to achieve the best business results,
the

Motivation

organization needs to keep employees motivated.

In order to motivate the employees, organizations do various activities. The

activities the
companies do basically the results and findings of certain motivational theories.

There are three things required to have a motivated employee:

Copyright © PROF.
Timely Feedback
first, provide clear ownership of a defined task; second, ensure the person has the
ways and means to do the task; and finally,
follow-up with timely feedback and hold the individual accountable for results.
Importance:
1. Need satisfaction: Motivation satisfies the needs of individuals as well groups.
Every individual or group of individuals
joins an organisation to fulfill certain personal needs. The motivation function of
the manager serves to help such fulfillment.

RAN QURESHI

2. Job satisfaction: Motivation also promotes job satisfaction. When an employee’s

needs are satisfied, he is on the whole
happy. His job satisfaction is of more direct concern. It is the key to other
important consequences.

3. Productivity: An individual’s contribution to output is the resultant of two

variables-his capacity for work and his
willingness to work. If P is performance, A ability and M motivation, then P =A x
M. It is clear that performance is not equal
to the sum of an individual's ability and motivation but rather to the product of
these two variables.

4. Learning: Motivation helps the learning process. Without motivation learning

does not take place. There must be motivation
or drive before there can be learning. Motivation stimulates interest and the
attitude of willing to learn.

5. Discipline: Motivation promotes self-discipline. The idea of discipline

generally carries a negative connotation. Subordinates

, obey a superior and maintain orderly behaviour for fear of punishment. But
motivation raises discipline to a positive level.

6. Dynamism: There is an element of dynamism i} motivation. When the rank and file
workers and managers are properly

motivated, a kinetic energy is generated which produces a tremendous impact

not;merely on the productivity and profits of
an organisation but also on its industrial relations, public image, stability and
future development
I.

Il.

. Love and belongingness needs - after physiological and safety needs have been

. Esteem needs are the fourth level in Maslow’s hierarchy - which Maslow classified
into

. Self-actualization needs are the highest level in Maslow's hierarchy, and refer
to the

yo\

Theories of Motivation Copyright © PROF. GUFRAN QURESHI

Maslow’s Need Hierarchy

Psychologist Abraham Maslow first developed his famous theory of thdividual
development and motivation in the 1940’s. He
suggested that human beings have a hlerarchy of neéds.
Maslow's hierarchy of needs is a motivational theory in psychology comprising a
five-tier model of human needs, often
depicted as hierarchical levels within a pyramid.
Needs lower down in the hierarchy must be satisfied before individuals can attend
to needs higher up. From the bottom of the
hierarchy upwards, the needs are: physiological, safety, love and belonging,
esteem, and self-actualization.

. Physiological needs - these are biological requirements for human survival, e.g.
air, food, drink, shelter, clothing, warmth,

sex, sleep. If these needs are not satisfied the human body cannot function
optimally.

. Safety needs - Once an individual’s physiological needs are satisfied, the needs
for security and safety become salient.

People want to experience order, predictability and control in their lives. These
needs can be fulfilled by the family and
society (e.g. police, schools, business and medical care).

fulfilled, the third level of human needs is social and involves feelings of
belongingness.
The need for interpersonal relationships motivates behavior. Examples include
friendship, intimacy, trust, and acceptance, receiving and giving affection and
love.

Self-fulfillment

two categories: (i) esteem for oneself (dignity, achievement, mastery,

independence) and
(ii) the desire for reputation or respect from others (e.g., status, prestige).
esige con
pee Aaciios needs:

intimate eee friends

realization of a person's potential, self-fulfillment, seeking personal growth and

peak
experiences. Maslow (1943) describes this level as the desire to accomplish
everything
that one can, to become the most that one can be.

Copyright © PROF. GUFRAN QURESHI

Herzberg’s Two Factor Theory (Motivation-Hygiene Theory)

Herzberg’s Motivation Theory model, or Two Factor Theory (1959), argues that there
are two factors that an organization can

adjust to influence motivation in the workplace.

These factors are:

1.
2.

In

. Low Hygiene and Low Motivation: This is obviously a bad situation for an

Motivators (Satisfaction, No Satisfaction): Which can encourage employees to work

harder.
Hygiene (Maintenance) factors (Dissatisfaction, No Dissatisfaction): These won’t
encourage employees to work
harder but they will cause them to become unmotivated if they are not present.

a general sense, there are four states an organization or team can find themselves
in when it comes to Two Factor

Theory.
. High Hygiene and High Motivation: This is the ideal situation and the one which a
CUrA uate ATCO CeCe am Aste) a
every manager should strive for. Here, all employees are motivated and have very
few

grievances.

High Hygiene and Low Motivation: In this situation, employees have few
grievances but they are not highly motivated. An example of this situation is where
ie
pay and working conditions are competitive but the work isn’t very interesting. ee
Se
Employees are simply there to collect their salary. Aes Bees

, a ue os ‘ ‘ uae tales}
Low Hygiene and High Motivation: In this situation, employees are highly eee Re
motivated but they have a lot of grievances. A typical example of this situation is
rs ss
where the work is exciting and really interesting but the pay and conditions are
behind in eae

competitors in the same industry. Relnitale

organization or team to find itself in. Here, employees aren’t motivated and the
hygiene factors are not up to scratch.
ILL. Theory X and Theory Y

* In the 1960s, social psychologist Douglas McGregor developed two contrasting

theories that explained how managers' belief about what. motivates their people can
affect their management style. He labelled these Theory X and Theory Y.

» These theories continue to be important even today. It describes two contrasting

sets
of assumptions that managers make about their people:

Theory X

1. In this theory, the basic underlying assumption is that people don’t want to
work,
Rather than having a positive approach to their jobs, this theory assumes that
people
don’t like their jobs and they only work them because they need money.

2. Therefore, in this theory of motivation, it is incumbent on the manager or

supervisor
to play a hands on role in day to day activities.

3. Without active management and direct supervision, employees will simply do as

little

- as possible to get by (according to this theory). Naed tobe atively

Theory Y thas

1. Under this theory, the employees are highly self-motivated, and they need little
encouragement from upper management to deliver quality results on a day to day
basis. ) Theory Y

2. Employees who are viewed in this framework are happy to come to the office each

day, they look forward to the chance to deliver quality work, and they take

responsibility for the role they play in the organization.

As such, the management structure in businesses which take a Theory Y approach is

usually much leaner, as there is less of a need for supervision over workers who
are

motivated to do their best each day.

presets) Cer tele Lat e)] Ng Eves murli yale]

to

The Oldham—Hackman Job Characteristics Model ‘ispyetcheB rRORIGURRAN URESHN

Definition: The.job characteristics model, designed by Hackman and Oldham in 1974,
is based on the idea that the task itself
is key to employee motivation. Specifically, a boring and monotonous job stifles
motivation to perform well, whereas a
challenging job enhances motivation.
It states that there are five core job characteristics (skill variety, task
identity, task significance, autonomy, and feedback)
which impact three critical psychological states (experienced meaningfulness,
experienced responsibility for outcomes, and
knowledge of the actual results) , in turn influencing work outcomes (job
satisfaction, absenteeism, work motivation, etc.).
1. Meaningfulness of work: The work must be experienced as. meaningful (his/her
contribution significantly affects the
overall effectiveness of the organization). This is derived from:
a. Skill variety: Using an appropriate variety of your skills and talents: too many
might be overwhelming, too few, boring.
b. Task Identity: Being able to identify with the work at hand as more whole and.
complete, and hence enabling more pride
to be taken in the outcome of that.
c. Task Significance: Being able to identify the task as contributing to something
wider, to society or a group over and

beyond the self. Core Dimensi Psychological Stat te

2. Responsibility: Responsibility is derived from autonomy, as in ——— se ae Cooma

the job provides substantial freedom, independence and | Skill Variety . os

discretion to the individual in scheduling the work and in | Task Identity ~ aa

determining the procedures to be used in carrying it out) Tage High job per-
3. Knowledge of outcomes: This comes from feedback. It implies Gieeeniat ormance

an employee awareness of how effective he/she is converting Autonomy |——

foreutcomes Y ——=| High job satis-

his/her effort into performance. This can be, anything from faction

production figures through to customer satisfaction scores. The tema

point is that the feedback offers information that once you know, Knowledge of =
4 Results

you can use to do things differently if you wish. Feedback can

come from other people or the job itself. ,
| 03

Stress Me Copyright © PROF. GUFRAN QURESHI ~

Definition: Stress can be described as the distress that is caused as a testult of
demands placed on physical or mental energy.
Stress often affects behaviour, so that stréss in one person is also likely to put
stress on those around them, whether family,
friends or colleagues.
> Most often, employees find themselves in a state of confusion as to What their
job entails and they may even worry as to
whether they might lose their jobs given the current economic situation. This could
lead to a lot of stress in the workplace.
> Stress is defined in terms of how it impacts physical and psychological health;
it includes mental, physical, and emotional
strain. Stress occurs when a demand exceeds an individual’s coping ability and
disrupts his or her psychological
equilibrium. :
> Stress occurs in the workplace when an employee perceives a situation to be too
strenuous to handle, and therefore
threatening to his or her well-being.

Categories of Work Stress: .

1. Task Demands — This is the sense of not knowing where a job will lead you and
whether the activities and tasks will
change. This uncertainty causes stress that manifests itself in feelings of lack of
control, concern about career progress, and
time pressures.

2. Role Demands—Role conflict happens when an employee is exposed to inconsistent

or difficult expectations. Examples
include: interole conflict (when there are two or more expectations or separate
roles for one person), intrarole conflict
(varying expectations of one role), person-role conflict (ethics are challenged),
and role ambiguity (confusion about their
experiences in relation to the expectations of others).

3. Interpersonal Demands — Examples include: emotional issues (abrasive

personalities, offensive co-workers), sexual
harassment (directed mostly toward women), and poor leadership (lack of management
experience, poor style, cannot
handle having power).

4, Physical Demands —Many types of work are physically demanding, including

strenuous activity, extreme working
conditions, travel, exposure to hazardous materials, and working in a tight, loud
office.

Copyright © PROF. GUFRAN QURESHI

Causes of Stress at Organizational Level

Stress can be caused by a wide variety of things. Positive stress may result in an
increase in energy, enthusiasm, and
motivation. Negative stress has more serious consequences. The common causes are
organizational stressors and life
stressors.

Organizational stressors may relate to task demands, physical demands, role

demands, or inter-personal demands.
1. Task demands are stressors associated with the specific task or job the person
is performing. Some occupations are

naturally more stressful than others.

2. Physical demands are stressors associated with the job setting. Environmental
temperatures, poorly designed offices, and

threats to health can lead to stress. :

3. Role demands are stressors associated with a_ particular Bod y wo =~ M I nd
position in a group or organization. Examples are role ambiguity impaired judgement
and the various role conflicts that people experience in groups. ee
4, Inter-personal demands are stressors associated with the negativity
characteristics of the relationships that confront people in
organizations. Examples are group pressure, personality style, and
leadership style.

hendaches
frequent infections

tant muscles

muscular twitches

fatigue

skin irrilatiens

‘{breathiesaness

hasty decisions
accident prane
loss Of appetire
logs. of sex drive

loss of confidence:
mre fussy
irritability
depression

drinking more
apathy insomnia
alicnation restlessness

apprehension [smoking more :

Stress Management
Definition: Stress management is a “set of techniques and programs intended to help
people deal more effectively with stress in their
lives by analysing the specific stressors and taking positive actions to minimize
their effects”.
Strategies / Techniques:
1. Tackling the Problem: Before finding solutions to stress management, a person
needs to identify the root cause of his stress. Is it a
person, place or thing that is the constant source of his stress.
2. Avoid Stress: This is easier said than done if a person knows that something is
a constant source of stress in their life they should
avoid it. Like a stressful job or a person. A person should also avoid places where
he is more likely to get into trouble. And overall keep
a distance from things that upset him.
3. Exercise: Exercise is very important in managing stress, exercising every day
helps control the level of stress and maintain a healthy
mind and body. People don’t feel like exercising when they are stressed, when in
fact that is exactly what they need, so make a habit of
exercising regularly.
4, Meditation and Relaxation: Yoga helps in managing stress a lot. Meditation by
deep breathing brings the body in a relaxed state, the
mind does not think about the problem but focuses on the breath. Yoga teaches
various breathing techniques that instantly make you feel
better and relaxed. A person should have a mix of yoga and gym exercise in their
schedule as this will greatly help the mind and body.
5. Eat Well: A person’s diet also plays a very important role in managing stress.
If a person eats oily and fatty food in the morning, the
body undergoes a lot of stress to digest such foods. And when the body is stressed
emotionally a person feels stressed too. Eating a light
meal that has vegetables and having fruits helps keep the body light. Junk food
should be avoided as much as possible.
6. Sleep Well: Today jobs have become very stressful, people are spending close to
12-12 Sleep Well Tackling the fo
hours a day in their office, this does not leave them time to exercise, meditate
and even get eG quyProtien ee
sufficient amount of sleep. Sleep disorders are the most dangerous sources of
stress. ie
7. Vacation: A lot of time changing the surrounding and place helps in managing
stress, At . f
try to go on a vacation to calm and quiet place. A relaxing environment will
instantly put {vacation Tips for Stress Management '-Fyercise

a
Avoid Stress

the body ina relaxing state. cy

8. Hobby: A person should pursue his hobby, whatever it may be. Doing what you like
— Meditationand ©? es can wal
puts you ina good mood. A positive frame of mind helps a person deal with unwanted
and Relaxation) 2

stressful thoughts. Hobby ey

\
Organizational Strategies for Stress Management

Definition: The physiological, psychological and behavioural are important to the

understanding of job stress and coping strategies in

contemporary organization. Stress cannot be eliminated from daily life; the only
solution is to manage it effectively.

Strategies / Techniques: :

1. Create Supportive Organizational System: There should be decentralized and

participative decision-making structure where upward
communication is more, Clarify organizational policies to everyone and provide more
job control and proper job description. The
organizational culture should be such that, innovative thinking is encouraged even
if it leads to failed ideas, this also helps in bringing
down the stress experienced by the employees. '

2. Ergonomics and Environmental Design: Need for improvement in equipment used and
their good physical working conditions are in
much demand in present tech-savvy world, and undoubtedly this will become one of
the best stress coping strategies at organizational
level. Therefore, organizations should provide all resources to get better output
and avoid worker’s frustration.

3. Awareness About New Technology: The use of the computer and other software
technology has been inevitable and necessary.
Therefore all the employees should be exposed to various computer tools, and the
proper training should be held on continuous and
regular bases,

4. Stress Counselling: The employees can be provided with a counsellor for helping
them to deal with work related and personal problems
in order to understand and solve stress related problems to control mostly
behavioral and emotional outcomes of employees.

5. Educational and Training Programs: Plan and develop career paths and provide
educational programs especially tailored to suit
employees’ job profiles. The employees can be given weekly sessions of Yoga and
other such relaxing exercises so that they are able to
deal with stress in a more constructive manner. Life style modification programs at
individual and organizational level are
recommended, ;

6. Organizational get together and Fun: An informal get together would help in
creating personal bonds between the various individuals
belonging to the organization and this will definitely contribute towards better
relations at the work place.

7. Stress-audit: Conducting stress-audit at organizational level to understand what

causes stress and its impact on themselves. This leads
to design the best suitable strategies for managing the stress.

8. Work Balance Initiatives: Companies have introdycod a variety of strategies to

help employees achieve work — life balance in India.
They include flexible time options, Job sharing, work from home, use of telecommuti
ng in fulfil the job, and child care support.

yrigh
Health and Safety Copyright © PROF. GUFRAN QURESHI

Definition: Health and safety is concemed with identifying possiblé adverse effects
and then conitatrer is risk of their
occurrence. A method can be employed which tries to afford a relative measure of
their severity. Based upon this and
experience certain procedures can be put in place to minimise any health and safety
risk.

Some ways of minimising risk may well include:

1. Communication: The Project Manager must be aware of the safety issues in any
project and make sure all involved are
committed. This will require good communication at all levels of the project.
Personnel must be aware of the project’s
position on health and safety and have knowledge ofall relevant procedures.

2. Senior management backing: Senior management must give full support through
health and safety which will have
process and legal ramifications.

3. Legal aspects: This area must be covered comprehensively. As regulations and the
law is continually changing you will

‘ need to get advice from experts. You must be in a position to carry out all of
your legal obligations. As well as health and
safety there may be other related areas that you should be aware of. For example,
smoking restrictions or Duty of Care in
the UK. Countries and specific industries will have their own regulations.

4, Human aspects: Apart from thinking about typical health and safety risk issues
you should also consider human aspects.
For example, temperature, ventilation or the pressure of work.

5. Training: Training will play a major role in minimising health and safety risks.
If a project uses local labour then it may
well be a good idea to use familiar technology as extra training with advanced
equipment may well introduce additional
hazards. This may be worth considering even if the project timescale is extended
because of it. If possible carry out
training using internal trainers.

6. Recording: All health and safety issues should be recorded, together with any
resulting actions, responsibilities and the
potential consequences should an incident arise. Health and safety should be the
subject of regular review within the
project. This should include previous incidents with records of any actions
required. A record of all incidents should be
maintained. -

Some Ethical and Professional Concerns canyiignbecbROR GUN CURES

Definition: Professionals are capable of applying their skills and making judgments
in their particular profession. Professional ethics is
defined as the personal and corporate rules that. govern behavior within the
context of a particular profession. Many organizations define
ethical approach to their professionals. These include:

1. Honesty: Honesty is the trait of a good leader. But in the software industry a
dishonest project manager causes lot of damage to his or her
organization. A software project manager who is not honest will cause damage in the
following ways:

a. Informal Managerial Processes: If he is not honest with his organization and due
to lake of professional ethics he will use informal

_ practices to do his tasks and made informal plans to complete the task.

b. Corruption: Dishonesty sometime leads to corruption, as the project manager is

also responsible with project costs. An unethical project
manager shows his dishonesty and does dishonest things with funds. He will take the
cost of a small project to very high level only due to
frauds and corruption in funds.

2. Transparency: Transparency is the main vitae of good governance. Software

project management must be transparent about all their
activities, as this will build the trust of employees to the management team. But
in project management activities are only limited to
management team and no one knows about this. Sometimes employees are talking about
suspicious activities of project manager and in
other cases employees are not clear about project scope because it is ngt fully
explained by top management.

3. Confidentiality: Confidentiality includes rules, promises and restrictions that

limit access of information to specific person or place. A
Software project manager must be a trustworthy person because he has lot of
information about ongoing projects, their time, budget and
they also knows about company weakness and strengths. In some cases management team
is provoked by other competitors to leak the
confidential information of their company.

4, Respect: Respect is a feeling that is expressed to admire someone or something

due to their qualities, achievements and abilities.
Software project management team is a bridge between clients and employees of a
company; they must respect their employees in order
to get better results from them. But in some organizations software project
managers don’t know how to respect their employees, They
just give deadlines and want that work on the given deadline. They don’t know that
admiring someone is the key to getting more work
done.

5. Loyalty: Software project manager must be loyal to his work and to his
employees. He is the main person or software project
management team is the main department to be responsible for successful completion
of their work so, they must be loyal to each other
with their juniors and with their clients in order to make everything done and
achieve excellent results.
Unit V

Ch 12: Working in Teams: Introduction, Becoming a Team, Decision Making,

Organization and Team
Structures, Coordination Dependencies, Dispersed and Virtual Teams, Communication
Genres,
Communication Plans, Leadership.

Ch 13: Software Quality : Introduction, The Place of Software Quality in Project

Planning, Importance of _
Software Quality, Defining Software Quality, Software Quality Models, ISO 9126,
Product and Process
Metrics, Product versus Process Quality Management, Quality Management Systems,
Process Capability
Models, Techniques to Help Enhance Software Quality, Testing, Software Reliability,
Quality Plans.

Ch 14: Project Closeout: Introduction, Reasons for Project Closure, Project Closure
Process, Performing a
Financial Closure, Project Closeout Report.

Copyright © PROF. GUFRAN QURESHI

Ch-12 Working in Teams Copyright © PROF. GUFRAN QURESHI

Introduction: In today’s organisations, more and more work is carried out by teams
and groups of people working together
towards a common objective. Making teams and groups work effectively is a
challenging task for the manager. Bringing
individuals together can slow down and complicate everyday processes and conflict
can make even the simplest task difficult
to achieve.

Team working has benefits in many aspects. It provides a structure and means of
bringing together people with a suitable mix
of skills and knowledge. This encourages the exchange of ideas, creativity,
motivation and job satisfaction ahd can extend
individual roles and learning. In turn, this can improve productivity, quality and
customer focus. It can also encourage
employees to be more flexible and can improve the ability of the organisation to
respond to fast-changing environments.

Definition: Teamwork is the collaborative effort of a group to achieve a common

goal or to complete a task in the most

effective and efficient way. This concept is seen within the greater framework of a
team, which is a group

of interdependent individuals who work together towards acommon goal. Daley na —

x Performance reviews
Becoming a Team: wv’ Results at ms

1. A project manager is not only expected to manage project

tasks, deadlines and resources but also deal with individuals .fomiacng Pregike mat

with varied personalities, ambitions and motivations. aa thiciete rae es

2. Therefore being a project manager is more about being a Managing Team

leader, it is about getting to know your team: recognize the iste]

leader within the team, the person ready to go the extra mile,

ones who are ready to help others and the ones who always

havea habit of cribbing. ee nbiae ia

3. The best way to manage a team is to set the example yourself. Goeratina
$tameagy roveerens 4 eet ee

Standard Operating
Procedures
lot

Meaning of the term ‘Team’: Copyright © PROF. GUFRAN QURESHI

A team is a small number of people with complementary skills who are coinmitted to
a common purpose, set performance goals
and approach for which they hold themselves mutually accountable.

Characteristics:

1. Clear direction: Sometimes, organizations are in such a hurry to move on their

projects that they pull together groups of
people without first deciding on the goals and desired outcomes.

2. Open and honest communication: Communication is the close brother of chemistry.

In any team, communication is crucial
to building a sense of camaraderie(friendship) between members. The manner of
communication — how freely and
frequently team members communicate — determines the effectiveness of the team.

3. Support risk taking and change: Good teams support appropriate risk taking and
experimentation for change. They look on
first time mistakes as opportunities for learning.

4, Defined roles: Roles might shift somewhat once the team is assembled, but
understand the skill sets and thinking styles are
needed on the team. If a team needs to develop a new product for market, that team
will need a detail-oriented person (the

_ task-master), who is methodical and can keep the team on track.

5, Mutually accountable: Teams accept responsibility as individuals and as a team.

They don’t blame one another for team
mistakes and failures. No one should spend any time, useless time, in personal
justifications.

6. Communicate freely: The manner of communication — how freely and frequently team
members communicate —
determines the effectiveness of the team. Put simply, the more freely you talk to
your fellow team members, the more
comfortable you are in sharing insights and ideas.

7. Common goals: A chief characteristic of any successful team is that members

place the common goal above individual
interests.

8. Encourage differences in opinions: Agreeing on a common goal is essential. But

it shouldn’t come at the cost of
suppressing alternative ideas and opinions.

9, Team trust: Team members who cannot trust one other or who don’t believe in the
process and goals of the team seldom find

success. Effective teams focus on solving problems.

¢
Benefits from Team:

Team building has radically evolved as a technique to develop and manage effective
teams in the workplace. The aim to

achieve long-term organizational objectives developed the need for carrying out
team building activities frequently.

Benefits:

1. Problem solving: A group of people can bring together various perspectives and
combine views and opinions to rapidly
and effectively solve an issue. Due to the team's culture, each team member has a
responsibility to contribute equally and
offer their unique perspective on a problem to arrive at the best possible
solution. Overall, teamwork can lead to better
decisions, products, or services. The effectiveness of teamwork depends on the
following six components
of collaboration among team members: communication, coordination, balance of member
contributions, mutual support,
effort, and cohesion.

2. Healthy competition: A healthy competition in groups can be used to motivate

individuals and help the team excel.

3. Developing relationships: A team that continues to work together will eventually

develop an increased level of bonding.
This can help members avoid unnecessary conflicts since they have become well
acquainted with each other through
teamwork. By building strong relationships between members, team members’
satisfaction with their team increases,
therefore improving both teamwork and performance.

4. Individual qualities: Every team member can offer their unique knowledge and
ability to help improve other team
members. Through teamwork the sharing of these qualities will allow team members to
be more productive in the future.

5. Motivation: Working collaboratively can lead to increased motivation levels

within a team due to increasing
accountability for individual performance. When groups are being compared, members
tend to become more ambitious to
perform better. Providing groups with a comparison standard increases their
performance level thus encouraging members
to work collaboratively.
Team Development: t R

The process of learning to work together effectively is known as team development.

Research has shown that teams go thr — dstiitive

stages during development. Bruce Tuckman, an educational psychologist, identified a

five-stage development process that most teams follow

to become high performing. He called the stages: forming, storming, norming,

performing, and adjourning. Team progress through the stages
is shown in the following diagram.

Stages:

1. Forming stage: The forming stage involves a period of orientation and getting
acquainted. Uncertainty is high during this stage, and
people are looking for leadership and authority. A member who asserts authority or
is knowledgeable may be looked to take control.

2. Storming stage: The storming stage is the most difficult and critical stage to
pass through. It is a period marked by conflict and
competition as individual personalities emerge. Team performance may actually
decrease in this stage because energy is put into
unproductive activities. Members may disagree on team goals, and subgroups and
cliques may form around strong personalities or areas
of agreement. To get through this stage, members must work to overcome obstacles.
to accept individual differences, and to work
through conflicting ideas on team tasks and goals.

3. Norming stage: If teams get through the storming stage. conflict is resolved and
some degree of unity emerges. In the norming stage.
consensus develops around who the leader or leaders are, and individual member’s
roles. Interpersonal differences begin to be resolved.
and a sense of cohesion and unity emerges. Team performance increases during this
stage as members learn to cooperate and begin to
focus on team goals. .

4, Performing stage: In the performing stage, consensus and cooperation have been
well-established and the team is mature, organized,
and well-functioning. There is a clear and stable structure, and members are
committed to the team’s mission. Problems and conflicts still
emerge, but they are dealt with constructively, The team is focused on problem
solving and meeting team goals.

5. Adjourning stage: In the adjourning stage, most of the team’s goals have been
accomplished. performing
The emphasis is on wrapping up final tasks and documenting the effort and results.
As the
work load is diminished, individual members may be reassigned to other teams, and
the team
disbands. There may be regret as the team ends, so a ceremonial acknowledgement of
the
work and success of the team can be helpful. If the team is a standing committee
with
ongoing responsibility, members may be replaced by new people and the team can go
back to
a forming or storming stage and repeat the development process.
adjourning

Team Effectiveness

Decision Making Copyright © PROF. GUE

Definition: Decision making is the process of making choices by identifying a
decision, gathering information, and assessing altesiative
resolutions. Using a step-by-step decision-making process can help you make more
deliberate, thoughtful decisions by organizing relevant
information and defining alternatives.
Step 1: Identify the decision: You realize that you need to make a decision. Try to
clearly define the nature of the decision you must make.
This first step is very important.
Step 2: Gather relevant information: Collect some pertinent information before you
make your decision: what information is needed, the
best sources of information, and how to get it. This step involves both internal
and external “work.” Some information is internal: you'll seek it
through a process of self-assessment. Other information is external: you'll find it
online, in books, from other people, and from other sources.
Step 3: Identify the alternatives: As you collect information, you will probably
identify several possible paths of action, or alternatives. You
can also use your imagination and additional information to construct new
alternatives. In this step, you will list all possible and desirable
alternatives.
Step-4: Weigh the evidence: Draw on your information and emotions to imagine what
it would be like if you carried out each of the
alternatives to the end. Evaluate whether the need identified in Step 1 would be
met or resolved through the use of each alternative. As you go
through this difficult internal process, you'll begin to favor certain
alternatives: those that seem to have a higher potential for reaching your
goal. Finally, place the alternatives ina priority order, based upon your own value
system.
Step 5: Choose among alternatives: Once you have weighed all the evidence, you are
ready to select the alternative that seems to be best one
for you. You may even choose a combination of alternatives. Your choice in Step 5
may
very likely be the same or similar to the alternative you placed at the top of your
list at FAFatpnbervatc
the end of Step 4. :
Step 6: Take action: You're now ready to take some positive action by beginning to

7 STEPS TO EFFECTIVE

eae

ee REVIEW YOUR
Ss DECISION
implement the alternative you chose in Step 5. Sy ttactow
Step 7: Review your decision & its consequences: In this final step, consider the
results [i aS, et

of your decision and evaluate whether or not it has resolved the need you
identified in Sy wear» Anan

Step 1. If the decision has not met the identified need. yoy may want to repeat
certain Ce me

steps of the process to make a new decision. For example, you might want to gather
more 3 Bion
detailed or somewhat different information or explore additional alternatives. He
oKON
Organization and Team Structures rigit@ ror. euenanduresin

Definition: The structure of an organization or a team refers to its orgattizing

framework or how its various parts fit together

and are expected to function. The structure of an organization creates the

foundation for the system in which its teams and

work groups are embedded.

In any organization there are various forins of links which may take placé some
formal and some informal.

There may be a reporting link where one individual has to report to andther which
is the normal nature of relationship in an

organization or there might be an informal link which may take place due to sharing
of the same facilities like premises,

transportation etc.

There may be several different ways in which one may be linked to another
individual and then could also be a combination of

the formal as well as informal linkage.

Organizational links:

1. Functions: Function within an organization structure is an area of

responsibility and the individual who undertakes to
perform that function has either specialized training, education or / and
experience, In the organization of the product
development process we will have individuals who will be linked by functions.

2. Projects: Projects are a set of activities in the project development process to

which individuals apply their expertise let us
-say developing of the concept or designing the product building and testing
prototypes etc.

3. Combination: We also have individuals from different functions working on the

same project or many projects.

Organizational Structures:
1. Functional Organization: In a functional organization structure, the
organization

is grouped into departments where people with similar skills are kept together in
forms of groups; e.g., IT department, marketing department, finance department,

Headquarters
etc. This helps organizations enhance the efficiencies of each functional group. 2
. * se . oe f + | Research & caltct Accounting &
Project managers typically do not exist in this type of organization structure: if
this |pevelopment| | Production | | Marketing Finance
position exists, the role of the project manager will be very limited.
. Copyright © PROF. GUFRAN QURESHI
2. Project Organization: A project organization is the ideal organization oabraiet
etl
type for a project manager. Project managers are the real bosses here, with ----\~.
. . . f
the freedom to apply your expertise and have a say in the proceedings. * saan PRI
Hae
f | Manager | | eae | | Manager

However, once a project is delivered, project managers become redundant.

There is no job security in this type of organization.

3. Matrix Organization: The matrix organization structure is a combination

of two or more types of organizational structures, such as the projectized ‘\
organization structure and the functional organization structure. This ~~~ ~-~--~-
combination can help organizations improve efficiency, readiness, and
market adaptation. This type of structure is most suitable for organizations
operating in a dynamic environment; they often can respond faster to
market or customer demand while decreasing the lead time to produce a
new product.

a. Heavyweight Project Organization: In a heavyweight project

organization, the involved individuals have a stronger link to the project
than to their function (e.g. to marketing, design, and manufacturing).
Project members are typically working for one single project at a time, Lightweight
Heavyweight
and might be co-located with the project members from other functions.

b. Lightweight Project Organization: Unlike heavy projects here projects

involved are light or less important to the organization and the functional
links are stronger. The functional has more authority and is incharge of the <>
performance evaluation as well as budgets. The project manager is only Pecit,
responsible for scheduling and coordination of the people in the project

eee eee
Coord ination Dependencies Copyright © PROF. GUFRAN QURESHI

Definition: Coordination, defined as “managing dependencies between activities”, is

a central feature of collective action.

Coordination theory (Malone and Crowston 1994) synthesizes contributions from

different disciplines to develop a systematic

approach to the study of coordination. Dependencies are the relationships among

tasks which connects and show the

relationship between preceding task and succeeding task. It determines the order in
which activities need to be performed.

There may be several different ways in which one may be linked to another
individual and then could also be a combination of

the formal as well as informal linkage.

J. Shared Resources: These are resources that are needed for short durations but
would not be utilized for the entire duration
of the project. Some of the shared resources in an organization are database
administrators, programming language experts,
functional specialists, or other technical experts. The project manager has to
ensure the availability of these shared
resources when required on the project.

Il. Producer-Customer “right time” Relationship:

In some cases the project activity may depend on a project being

Coordination is managing dependencies among activities |

delivered to the customer first and hence until the product is not a i, z \

i Wi j < ifferent of activiti

delivered the subsequent activity cannot commence. This can oe kinds Smee
work smoothly if the customer is from within the organization but managed-by

* . : ® ‘ wi Co-ordination mechanisms are

may become an issue if an outside organization is involved and ~ - ubiquitous ic.
found ia

. P : many processes
hence such forms of dependencies need to be taken into = TAYEPSSS a
consideration. many types of dependency related to multiple
. . fit fl hy iviti
1. Task-sub task dependencies: Every task comprises of sub yo. eee
7
tasks that need to be completed to complete the main task.
Thus, this is a technical dependency that is forced on the a consist of the
following dependencies aes
project. usabiligy transfer prerequisite teen ave
(right-thing) (right-place) (right-time) coordination
tmechanisms
Copyright © PROF. GUFRAN QURESHI

2, Accessibility “right thing” dependencies: Although examples of this form of

dependencies are few in software projects
it primarily indicates the movement of activities over a large geographical area.
The dnly example of this form of
dependency in software projects can be the availability of ICT equipment at
different location.

3. Usability “right thing” dependencies: The usability dependency refers to the

“fitness for purpose” which in turn means
the ability of the software product to fulfil its purpose and satisfy user
requirement. In software projects this could mean
the adoption of prototyping, which will ensure that the system being created will
be as per the requirement of the user.

4, Fit requirements: This requirement ensures that different system components work
cohesively. Integration of the entire
system as one is essential for its smooth functioning. Also, effects of changes
made in part should not have knock-out
effect on other areas of the system.
\)

Dispersed and Virtual Teams Copyright © PROF. GUFRAN QURESHI

Definition: A virtual team (also known as a geographically dispersed téart,

distributed team, or remote team) usually refers to a

group of individuals who work together from differént geographic locations and rely
on communication technology such as email,

FAX, and video or voice conferencing services in order to collaborate.

Types: :

1. Networked Teams: Networked teams are composed of cross-functional members

brought together to share their expertise and
knowledge on a specific issue. Membership is fluid in that new members are added
whenever necessary, while existing
members are removed when their role is complete.

2. Parallel Teams: Parallel teams are generally formed by members of the same
organization to develop recommendations in a
process or system. Parallel teams are usually formed for a short period of time and
membership is constant in that members of
a parallel team remain intact until the goal is realized.

3. Product Development Teams: Product development teams are composed of experts

from different parts of the world to
perform a specifically outlined task such as the development of a new product,
information system, or organizational process.
For example, bringing in a team of experts from the United States, Canada, and Hong
Kong for a period of one year to develop
a new engine.

4. Production Teams: Production teams are formed from members of one role coming
together to perform regular and ongoing
work. Members of a production team are given clearly defined roles and work
independently. The individual outputs of each
member are combined together to produce the end result.

5. Service Teams: Service teams are formed by members from different time zones.
Each member does work independently but
the work produced by each member is a continuation of the previous member. For
example, customer support teams in Canada
finish their shift while support teams in Asia start their shift and continue the
work.

6. Management Teams: Management teams are formed by managers of the same

organization who work in different
geographical regions. Members of management teams largely discuss corporate-level
strategies.

7. Action Teams: Action teams are formed for a very short duration of time to
respond to immediate problems. Upon resolving
the problem, the team is adjourned.

© PI
Copyrigt ROF. GUFRAN QURESHI

Advantages of Virtual Teams

1. Lower office costs: Members are able to work at home or at a remote location
where they do not need to utilize company
office space.

2. Flexibility: Members are able to achieve better personal flexibility.

3. Increased productivity: Members of a virtual team tend to be more productive, as

there is less time wasted on commuting
and traveling.

4. A24-hour workday: Companies can operate on a 24-hour schedule by having shifts

in different countries (different time
zones). :

5, Greater availability of talent: Members can be hired anywhere, thus eliminating

the restriction of having to rely solely on
the local talent pool.

Disadvantages of Virtual Teams

1. Technological issues: Virtual teams are reliant on the internet and computer for
completing work. Therefore, technological
issues may cause difficulties and put work on hold until the technological issue is
resolved.

2. Communication issues: Non-verbal communication can be easily misjudged and can

lead to a lack of trust and common
knowledge sharing.

3. Poor team bonding: A typical virtual team involves members connecting with each
other for a specific issue or problem
and the disbandment of the team once the issue or problem is resolved. Virtual
teams lack time to get to know each other
and bond. This may lead to miscommunication and a lack of effective collaboration.

4. Management problems: Virtual teams can be hard to manage if the members are not
great communicators and lack
leadership skills. For example, a member may resort to silence instead of speaking
out about a poorly performing team
member. This would hurt team cohesion and create hostility among the team members.
Communication Genres GapiyeightW PRR GOFRAN ORES
Definition: Communication genres refer to the types of communication and the ground
rules for when and how such
communication should be carried out. Communication genres are communicative actions
habitually used by project members
to achieve some purpose.
Types:
I. PROJECT PERSPECTIVE: From a project perspective, communication can be looked at
as either internal or external.
1. Internal communication is the communication that takes place between project
team members. Generally, this type of
communication is "raw." It may involve a lot of back-and-forth discussion as plans
or issues are worked out.
2. External communication is communication between project team members and the
other project stakeholders. Examples
include communication with internal and external customers, other projects, and the
media. Generally, this type of
communication is cleaned up or otherwise prepared before being presented or sent to
the receiving party.

Il. ORGANIZATIONAL PERSPECTIVE: Communication from an organizational perspective

can be categorized
as vertical, horizontal, or diagonal. This perspective takes into account the way
organizations are structured.

1. Vertical communication is the upward and downward communication flow that

happens between different hierarchical
levels of the organization. An example of upward communication is when a project
team member provides the project
manager with a status update of his assigned tasks. An example of downward
communication is when the project manager
shares the project goals with the project team.

2. Horizontal communication refers to communication between people at the same

organizational level. An example of
horizontal communication is when project team members discuss project topics with
each other.

3, Diagonal communication takes place between different functional divisions of the

organization. Diagonal communication
has become more important as matrix and project-based organizations become more
common. To be effective in these types
of organizations, a project manager has to be familiar with the different functions
and managers within the organization and
then plan his communications accordingly.

. Copyright © PROF. GUFRAN QURESHI

Il. FORMALITY PERSPECTIVE:

Another way to look at project communication is on whether it is formal or

informal.

1. Formal communication include reports, presentations, and media releases. This

type of communication is usually planned
and takes some time and effort to prepare.

2. Informal communication includes emails and ad-hoc discussions. Informal

communication has increased as many
projects start to use social networking. Many people don't put much thought into
their informal communications. However,
effective project managers realize this type of communication is just as important
as formal communication. Whether
formal or informal, you need to make sure you communicate with a purpose and that
you put some thought into how you
communicate in order to get the results you want.

IV. CHANNEL PERSPECTIVE:

Project managers also need to give consideration to the communication channel they
will deliver their message over.
This perspective deals with how your message will be communicated. Will it be...

1. Verbal or Non-Verbal

2. Written or Oral

3. Face-to-Face or via Telephone

\13

Communication Plans onfitheennoreurianaoeesia

Definition: A project communication plan is a simple tool that enables you to

communicate effectively on a project with your
client, team, and other stakeholders. It sets clear guidelines for how inférmation
will be shared, as well as who’s responsible for
and needs to be looped in on each project communication. A project management
communication plan identifies how important
information will be communicated to stakeholders throughout the project.

Steps:

1. Choose a format: Choose a platform where it will be easy to gather feedback on

your communication plan and to share or
store the plan for your team and stakeholders to reference.

2. Set a communication goal: Whatever you hope to achieve, the first step to
crafting a successful communication plan is to
write that goal down. Referring back to the importance of a communication plan,
your goal will likely be to keep stakeholders
updated on the project status or even to keep stakeholders mindful of the project’s
benefits so they’ll continue to advocate for
it.

3. Identify stakeholders: Most projects have many stakeholders, most of whom have
different levels of interest in and influence
on the: project. You'll need to identify the stakeholders with whom you'll
communicate throughout the project and list them.

4. Identify methods of communication: One purpose of your communication plan is to

get the right eyes on the right
information, so along with listing who your stakeholders are, your communication
plan should also list how you intend on
communicating with those stakeholders. The communication method you choose may also
depend on the information you
need to deliver. You likely don’t need a formal in-person meeting every week to
share updates on the project; you could send
a weekly email with updates and hold meetings when the team reaches a major
milestone.

5. Determine frequency of communication: List how often you will send out each type
of communication (e.g., send a weekly
email on Mondays with project progress, links to completed deliverables, current
budget, etc.) or how often you need to loop
in each stakeholder.

6. Determine who provides communication updates: Most often, this task will fall on
the project manager, but if not, the
owner of a specific update needs to be clearly identified in your communications
plan.

Performance Reporting Copyright © PROF, GUFRAN QURESHI

Definition: The performance reporting process involves the collection of all

baseline data, and distribution of performance

information to stakeholders. Generally, this performance information includes how

resources are being used to achieve project

objectives. Performance reporting should generally provide information on scope,

schedule, cost, and quality. Many projects
also require information on risk and procurement. Reports may be prepared
comprehensively or on an exception basis.

Performance Reporting: Tools and Techniques

1, Information Presentation Tools: Software packages that include table reporting,

spreadsheet analysis, presentations, or

graphic capabilities can be used to create presentation-quality images of project

performance data.

2. Performance Information Gathering and Compilation: Information can be gathered

and compiled from a variety of
media including manual filing systems, electronic databases, project management
software, and systems that allow access
to technical documentation, such as engineering drawings, design specifications and
test plans, to produce forecasts as
well as performance, status and progress reports.

3. Status Review Meetings: Status review meetings are

regularly scheduled events to exchange information about
the project. On most projects, status review meetings will
be held at various frequencies and on different levels. For
example, the project management team can meet weekly
by itself and monthly with the customer.

4. Time Reporting Systems: Time reporting systems

record and provide time expended for the project.

5. Cost Reporting Systems: Cost reporting systems record

and provide the cost expended for the project.

belvi ee ti a3

Tools & Techniques

1 Performance reports

.2 Forecasts

.3 Requested changes

4 Recommended corrective
actions

5 Organizational process
assets (updates)

.1 Information presentation
tools
2 Performance information
gathering and compilation

.3 Status review meetings

.4 Time reporting systems

.& Cast reporting systems

Copyright © PROF. GUFRAN QURESHI

Performance Reporting: Outputs

1.

Definition: Project leadership, most simply, is the act of leading a team towards
the successful completion of a project. But of

Performance Reports: Performance reports organize and summarize the information

gathered, and present the results of
any analysis as compared to the performance measurement baseline. Reports should
provide the status and progress
information, and the level of detail required by various stakeholders, as
documented in the communications management
plan. Common formats for performance reports include bar charts, S-curves,
histograms, and tables. Earned value
analysis data is often included as part of performance reporting.

Forecasts: Forecasts are updated and reissued based on work performance information
provided as the project is
executed. This information is about the project's past performance that could
impact the project in the future, for example,
estimate at completion and estimate to complete.

Requested Changes: Analysis of project performance often generates requested

changes to some aspect of the project.
These requested changes are processed and dispositioned through the Integrated
Change Control process.

Recommended Corrective Actions: Recommended corrective actions include changes that

bring the expected future
performance of the project in line with the project management plan.

Organizational Process Assets (Updates): Lessons leamed documentation includes the

causes of issues, reasoning
behind the corrective action chosen, and other types of lessons learned about
performance reporting. Lessons learned are
documented so that they become part of the historical database for both this
project and the performing organization.

Leadership Copyright © PROF, GUFRAN

URESHI

course, itis much more than that. It’s about getting something done well through
others.
Attributes:

1.

2.

TEAM BUILDER: A team which works together well and happily is a more efficient team
since their union can bring out
the best in them. Making a team work together requires a keen understanding of
people. °
DELEGATION: Delegating tasks to the right individual is an important management
skill for team leaders in the
software development industry as it allows them to be focused on the truly
important aspects of the project.
AUTONOMY: Autonomy is essential to build trust in employee engagement. In an Agile
environment, leaders provide
the team members with clear goals and let them find the best way to achieve them.

MOTIVATION: Provide your team with the needed training to advance in their careers
and to become knowledgeable
about the newest technologies.

COACHING: A team leader in software development needs to understand the problems,

help the team overcome them,
and more importantly, learn from the problem so that it does not happen again.

PROBLEM SOLVING: Leaders must have the ability to guide teams through the problem
solving process and come up
with positive results. They also realize that the team needs to have some
guidelines to keep them on track.
INTEGRITY: Integrity is a concept of consistency of actions, values, methods,
expectations, and outcomes. It is an
important attribute of a great leader to demonstrate commitment to do the right
thing for the right reason, regardless of the
circumstances, and to make the team members follow him/her in these values and
ethical practices.
[\5

Copyright © PROF, GUFRAN QURESHI

Leadership Styles:

Definition: Leadership style is the mantier and approach of providing ditection,

implementing plans, and motivating people.

As seen by the employees, it includes the total pattern of explicit and implicit
actions performed by their leader,

1, authoritarian or autocratic - the leader tells his or her employées what to do

and how to do it, without getting their
advice. This style is used when leaders tell their employees what they want done
and how they want it accomplished,
without getting the advice of their followers. Some of the appropriate conditions
to use this style is when you have all the
information to solve the problem, you are short on time, and/or your employees are
well motivated.

2. participative or democratic - the leader includes one or more employees in the

decision making process, but the leader
normally maintains the final decision making authority. This style involves the
leader including one or more employees in
the decision making process (determining what to do and how to do it). However, the
leader maintains the final decision
making authority. Using this style is not a sign of weakness, rather it is a sign
of strength that your employees will respect.

3. delegative or laissez-fair (free-rein) - the leader allows the employees to

Autocratic
make the decisions, however, the leader is still responsible for the decisions
that are made. In this style, the leader allows the employees to make the
decisions. However, the leader is still responsible for the decisions that are
made. This is used when employees are able to analyze the situation and
determine what needs to be done and how to do it, You cannot do
everything! You must set priorities and delegate certain tasks.

Particpative Free-rein

Leader Whole Group Employees

Ch- 1 3 Softwa re Quality Copyright © PROF. GUFRAN QURESHI

Definition: Quality software refers to a software which is reasonably bug or defect

free, is delivered in time and within the

specified budget, meets the requirements and/or expectations, and is maintainable.

In the software project management

context, software quality reflects both functional quality as well as structural

quality. .

a. Software Functional Quality — It reflects how well it satisfies a given design,

based on the functional requirements or
specifications.
b. Software Structural Quality — It deals with the handling of non-functional
requirements that support the delivery of the
functional requirements, such as robustness or maintainability, and the degree to
which the software was produced
correctly.

Software quality management is split into three main eae .

activities: |

1, Quality assurance. The development of a framework of |

organizational procedures and standards that lead to high aa [Gmc
quality software. Quality control 0) Tigao ania

2. Quality planning. The selection of appropriate |

procedures and standards from this framework and adapt ee P

Ela oc9

Btosiits
for a specific software project. é
or aspecific s proj

3. Quality control Definition’ of processes ensuring that

i Quality Product || Stakeholders’

software development follows the quality procedures and we eae ts prerequisites

standards. a Ere
The Place of Software Quality in Project Planning

Definition: Quality will be of concern at all stages of project planning and

execution, but will be of particular interest at the following points in the Step
Wise framework.

Step 1 : Identifying project scope and objectives: Some objective could -

relate to the quality of the application to be delivered. enero

Step 2 : Identifying project infrastructure: Within this step activity identifies

installation standards and procedures. Some of these will almost certainly be 3

analyse
about quality requirements. characteristics
Step 3 : Analyze project characteristics: In this activity the application to be ¥
implemented will be examined to see if it has any special quality identify the
requirements. ‘ Review | Precuvies
Step 4 : Identify the product and activities of the project: It is at that point
pei oe ¥ sameiiaiete are a
the entry, exit and process requirement are identified for each activity. 1 [8
estimate
Step 8 : Review and publicize plan: At this stage the overall quality aspects Lower
“acvity ror
of the project plan are reviewed. | ¥ each. |
i ls Identity =m
i Gentil i
The project planning process is the longest and most important of the project Jie |
management cycle, Without proper planning, a project has a poor chance of ga ¥ ;
success. — level ' Allocate {
. . . . . planning resources
Team members must decide on a budget, set timelines, and identify
resources and any roadblocks to success. 3s Ls lf ¥ I
Execute ag Reviews |
plan I publicize plan I
L. i
Importance of Software Quality

I
|
|
|
|
|
|
|
i
i

Copyright © PROF. GUFRAN QURESHI

Definition: Software quality is a nuanced concept that requires a framework that

addresses functional, structural and the
process of the software delivery understand. Measurement of each aspect is a key
tool for understanding whether we are
delivering a quality product and whether our efforts to improve quality are having
the intended impact. However,
measurement can be costly. To balancing the effort required to measure quality
versus the benefit, you first need to
understand the reasons for measuring quality. Five of reasons quality is important
to measure include:

lL.

Safety — Poor quality in software can be hazardous to human life and safety,
Quality problems can impact the
functionality of the software products.

Cost — Quality issues cost money to fix. Whether you believe that a defect is 100x
more costly to fix late in the
development cycle or not, doing work over because it is defective does not deliver
more value than doing it right once.
Customer Satisfaction (internal) — Poor quality leads stakeholders to look for
someone else to do your job or perhaps
shipping your job and all your friend’s jobs somewhere else. Recognize that the
stakeholders experience as the software
is being developed, tested and implemented is just as critical as the raw number of
defects.

Customer Satisfaction (external) — Software products that don’t work, are hard to
use (when they don’t need to be), or
are buggy don’t tend not to last long in the marketplace. Remember that in today’s
social media driven world every
complaint that gets online has a ripple effect. Our goal should be to avoid
problems that can be avoided.

Future Value — Avoiding quality problems increases the amount of time available for
the next project or the next set of
features. Increasing quality also improves team morale, improved team morale is
directly correlated with increased
productivity (which will increase customer satisfaction and reduce cost).
IF

Defining Software Quality Copyright © PROF. GUFRAN QURESHI

Definition: Software quality is defined as a field of study and practice that

describes the desirable attributes of software products.

Software quality measures how well software is designed (quality of desigi), and
how well the software conforms to that design

(quality of conformance). It is often described as the ‘fitness for purpose’ of a

piece of software. There are two main approaches to

software quality: defect management and quality attributes. ;

Quality of the Deliverables:

Every project must have a clearly stated objective as to what the project will
produce. Once the objective are in place they can help in

formulating the project requirements. The project requirements evolve through

progressive elaborations into project scope baseline.

The quality of the deliverables of a service is measured in value by several

factors:

1. Value of the implementation: Here the true cost of the implementation should be
measured with the benefits that the
implementation will provide. The cost-benefit ratio should justify the
implementation.

2. Value of the service: The value of the service to the organization should be
measured by comparing the organization before and
after the project has been implemented.

3. Value of the experience: The value of the experience that the user derives after
using the service determines the success of the
project.

4. Value of longevity: The life of the service should offer reasonable Return-on-
investment (ROI). The project manager should
research and ensure that the service is not replaced by a better, faster, more
reliable or less expensive one before ROI achieved.

5. Value of Reliability: The reliability of the service shouldn’t be a matter of

concern for the users. Once the service has been
implemented it should not consistently fails or is unavailable as this would deem
that the service lacks quality.

6. Value of the project: The cost incurred on the IT product should be ( Define ) (
Develop
justified by way of the benefits that it is able to deliver to the user. Se a

7. Value of usability: The product has to deliver on its promise to

prove to be usable. The usability of the product is the reason for the
existence of the project.
Assess produd
quality

Improve
process

Standardise
process

Software Quality Criteria Copyright © PROF. GUFRAN QURESHI

Definition: Software Quality Criteria are the specific elements or functions that
will be selected, tested and measured in order to confirm
that the quality objectives have been met.
McCall’s Quality Criteria:
A quality criteria is an attribute of a quality factor that is related to software
development. For example, modularity is an attribute of the
architecture of a software system.
List of Quality Criteria:

1. Access Audit: Ease with which the software and data can be checked for
compliance with standards.
2. _ Access Control: Provisions for control and protection of the software. :

3. Accuracy: Precisions of computations and output.

4. Completeness: Degree to which full implementation of required functionalities

have been achieved.
5. Communicativeness: Ease with which the inputs and outputs can be assimilated.

6. Conciseness: Compactness of the source code, in terms of lines of code.

7. Consistency: Use of uniform design and implementation techniques.

8. Data commonality: Use of standard data representation. e

9. Error tolerance: Degree to which continuity of operation is ensured under
adverse conditions.

10, Execution efficiency: Run time efficiency of the software.

11. Expandability: Degree to which storage requirements or software functions can

be expanded,

12. Hardware independence: Degree to which a software is dependent on the

underlying hardware. "

13. Modularity: Provision of highly independent modules.

14. Operability: Ease of operation of the software.

15. Simplicity: Ease with which the software can be understood.

16. Software efficiency: Run time storage requirements of the software.

17. Traceability: Ability to link software components to requirements.

18, Training: Ease with which new users can use the system.
eet i

Software Quality Models Copyright @ PROF. GUFRAN QURESHI

Definition: Software Quality Models are a standardised way of measuring a software

product. With the increasing trend in
software industry, new applications are planned and developed everyday. This
eventually gives rise to the need for reassuring
that the product so built meets at least the expected standards.

McCall’s Quality Model (1977):

This model classifies all software requirements into 11 software quality factors.
The 11 factors are grouped into three
categories — product operation, product revision, and product transition factors.

Product operation factors — Correctness, Reliability, Efficiency, Integrity,

Usability.

Product revision factors — Maintainability, Flexibility, Testability.

Product transition factors — Portability, Reusability, Interoperability.

iE

ios)

Correctness:- Correctness requirements deal with the correctness of the output of

the software system. They include
Output mission. The required accuracy of output that can be negatively affected by
inaccurate data or inaccurate
calculations. The completeness of the output information, which can be affected by
incomplete data. ©
Reliability:- Reliability requirements deal with service failure. They
determine the maximum allowed failure rate of the software system, and —
Maintainability - Can /jivit?
. . . Flexibility - Can J change it?
can refer to the entire system or to one or more ofits separate functions. —
Festabitty- Car testi?
Efficiency:- Efficiency deals with the hardware resources needed to
perform the different functions of the software system. It includes pea aS UD
processing capabilities, its storage capacity and the data communication.
Integrity:- Integrity deals with the software system security, that is, to
prevent access to unauthorized persons, also to distinguish between the

group of people to be given read as well as write permit.

Portability - Will J be able to use

on another machine?

Reusability - IWil! J be able to

reuse some of the sofware?
Interoperability - Fill I be able to
interface it with nother machine?
Peni a
Operations

Correctness - Does it do what want?

Reliability = Does it do it accurately all the time?

Usability:- Usability requirements deal with the staff resources needed to

Efficlency + Wil tm on ny machive as well as it can?
“i = Integrity - Js it secure? .
train a new employee and to operate the software system. Usabilty = Cau Zrun it?
Copyright © PRO: N QURESHI

Maintainability:- Maintainability considers the efforts that will be needed by

users and maintenance personnel to identify
the reasons for software failures, to correct the failures, and to verify the
success of the corrections.

Flexibility:- Flexibility deals with the capabilities and efforts required to

support adaptive maintenance activities of the
software. These include adapting the current software to additional circumstances
and customers without changing the
software. This factor’s requirements also support perfective maintenance
activities, such as changes and additions to the
software in order to improve its service and to adapt it to changes in the firm’s
technical or commercial environment.
Testability:- Testability requirements deal with the testing of the software system
as well as with its operation. It includes
predefined intermediate results, log files, and also the automatic diagnostics
performed by the software system prior to
starting the system, to find out whether all components of the system are in
working order and to obtain a report about the
detected faults. Another type of these requirements deals with automatic diagnostic
checks applied by the maintenance
technicians to detect the causes of software failures.

Portability:- Portability requirements tend to the adaptation of a software system

to other environments consisting of
different hardware, different operating systems, and so forth. The software should
be possible to continue using the same
basic software in diverse situations.

. Reusability:- Reusability deals with the use of software modules originally

designed for one project in a new software

project currently being developed. They may also enable future projects to make use
of a given module or a group of
modules of the currently developed software. The reuse of software is expected to
save development resources, shorten
the development period, and provide higher quality modules.

. Interoperability: Interoperability requirements focus on creating interfaces with

other software systems or with other

equipment firmware. For example, the firmware of the production machinery and
testing equipment interfaces with the
production control software.
Boehm’s Quality eae ' Copyright © PROF. GUFRAN QURESHI

In 1978, B.W. Boehm introduced his sdftwate quality model. The model represents a
hierarchical quality model similar to

McCall Quality Model to define software quality using a predefined set of

attributes and metrics, each of which contributes to

overall quality of software.

The difference between Boehm’s and McCall’s model is that McCall’s thodel primarily
focuses on precise measurement of

high-level characteristics, whereas Boehm’s quality model is based on a wider range

of characteristics. .

The Boehm’s model has three levels for quality attributes. These levels are divided
based on their characteristics. These levels

are primary uses (high: level characteristics), intermediate constructs(mid-level

characteristics) and _ primitive

constructs(primitive characteristics).

A. The high-level characteristics explains around how the elevation of software

quality could be put. Here the three main
things needs to be taken care of: Bek conteinscnas

1. Usability (As is utility): How well (easily, reliably, efficiently) can I use it
as-is?

2. Maintainability: How easy is it to understand, modify and retest?

3. Portability: Can | still use it if 1 change my environment?

accuracy

Reliability J Completeness

Rabustness/integrit)

Efficiency

Robustness/integrit
Human Engineerin Accessibilit

\_ Communicativeness

B. The Mid-level characteristics represents the Boehm's 7 quality factors

which are the most important qualities to be expected from a software:
1. Portability- The code possesses the capabilities of operating easily Cheeta
qunty nde 2 Device Indesendence
and well on a system configuration other than the current one. \ OSS: isin

2. Reliability- The code possesses the capabilities of performing the sbi [-

conminetenes
given functions or task successfully in case of any system crash or strueturedness
failure. Maintainability Consistene

Structurednass
Conciseness

Understandability

3. Efficiency- The code possesses the capabilities of fulfilling its

purpose without any waste of resources. :

Structuredness

Modifiabllity

Copyright © PROF. GUFRAN QURESHI

Usability- Code possesses the characteristic usability to the extent that it is
reliable, efficient and human-engineered.
Testability- The code supports the establishment of verification criteria and
evaluation of its performance.
Understandability- The code possesses the characteristics as the purpose of the
code is clear to the inspector.
Flexibility- The ease of changing the software to meet revised requirements. —

IAMS

C. The lowest level structure of the characteristics hierarchy is the primitive

characteristics metrics hierarchy. There are
many factors responsible for following such models, like accuracy, consistency,
robustness, accessibility, efficiency,
device independence, completeness, accountability, communication,
detailed.understanding, legibility, structuredness,
Augmentability, conciseness.

Advantages: .
It focuses and tries to satisfy the needs of the user.

It focuses on software maintenance cost effectiveness.

Disadvantages:

It doesn’t suggest, how to measure the quality characteristics.

It is difficult to evaluate the quality of software using the top-down approach.

Dromey’s Quality Model (1995): Copyright © PROF. GUFRAN QURESHI
This model emphasises on evaluating one software's quality with another. It helps
to find out defects if any, and also to point out the
factors that caused such defects. This model is designed on the basis of the
relationship that exist between software properties and
its quality attributes.

Dromey has built a quality evaluation framework that analyzes the quality of
software components through the measurement of
tangible quality properties. Each artifact produced in the software lifecycle can
be associated with a quality evaluation model.
Dromey gives the following examples of what he means by software components for
each of the different models:

+ Variables, functions, statements, etc. can be considered components of the

implementation model;

+ Arequirement can be considered a component of the requirements model;

* A module can be considered a component of the design model etc.

According to Dromey (1995), these components all possess intrinsic properties that
can be classified into four categories:

> Correctness: Evaluates if some basic principles are violated.

> Internal: Measure how well a component has been deployed according to its
intended use.

> Contextual: Deals with the external influences by and on the use of a component.

> Descriptive: Measure the descriptiveness of a component (for example, does it

have a meaningful name?). ©

These properties are used to evaluate the quality of the components. This is
illustrated in Figure for a variable component present in

the implementation model. C

Dromey identified five steps to build his model:

1. Choose a set of high-level attributes that you need to use for your

evaluation.

Functionality, Reliability

Maintainability, Reliability,
, Efficiency
2. Make alist of all the components or modules in the system.

3. Identify quality-carrying properties for each component. (That is, qualities

of the component that has the most impact on the product properties from
the list created in last step).

Decide on how each property affects the quality attributes.

5. Evaluate the model and identify weaknesses.

Maintainability, Reusability,
Portability, Reliability

Maintainability, Reusability
Portability, Usability,

ISO 9126 pyright © PROF. GUFR

Definition: ISO 9126 is an international standard for the evaluation of software.

The standard i divided i into ; four parts, celtic
addresses, respectively, the following subjects: quality model; external metrics;
internal metrics; and quality in use metrics.
ISO 9126 Part one, referred to as ISO 9126-1 is an extension of previous work done
by McCall (1977), Boehm
(1978), FURPS and others in defining a set of software quality characteristics.

“One of the advantages of the ISO 9126 model is that it identifies the internal
characteristics and external quality

characteristics of a software product. However, at the same time it has the

disadvantage of not showing very clearly howe

these aspects can be measured”.

The ISO 9126-1 software quality model identifies 6 main quality characteristics,
namely:

1. Functionality: Functionality is the essential purpose of any product or service.

For certain items this is eladively easy to
define, for example a ship's anchor has the function of holding a ship at a given
location. The more functions a product
has, e.g. an ATM machine, then the more complicated it becomes to define it's
functionality.

2. Reliability: Once a software system is functioning, as specified, and delivered

the reliability characteristic defines the
capability of the system to maintain its service provision under defined conditions
for defined periods of time. One aspect
of this characteristic is fault tolerance that is the ability of a system to
withstand component failure. For example if the
network goes down for 20 seconds then comes back the system should be able to
recover and continue functioning.
3. Usability: Usability only exists with regard to functionality and en Suitabitity
. i Pactra aaa} Accuracy
refers to the ease of use for a given function. For example a ee Portability
Functionality [Aa ay
function of an ATM machine is to dispense cash as requested. ~Adaptabitity

ee

Placing common amounts on the screen for selection, i.e. siiGailty =—

$20.00, $40.00, $100.00 etc, does not impact the function of Aravsabitiy | on

the ATM but addresses the Usability of the function. The ability ey

to learn how to use a system (learnability) is also a major Learnabitity

Efficiency Usability {Understandabitity

subcharacteristic of usability. Resource befaviout 5 Taperapitity

Maintainability Reliability _(Recoverabitity

Fault tolerance

Time behaviour
Copyrig PROF. GUFRAN QURESHI

4, Efficiency: This characteristic is concerned with the system resources used when
providing the required functionality. The
amount of disk space, memory, network etc. provides a good indication of this
characteristic. As with a number of these
characteristics, there are overlaps. For example the usability of a system is
influenced by the system's Performance, in that
if a system takes 3 hours to respond the system would not be easy to use although
the essential issue is a performance or
efficiency characteristic.

5. Maintainability: The ability to identify and fix a fault within a software

component is what the maintainability
characteristic addresses. In other software quality models this characteristic is
referenced as supportability. Maintainability
is impacted by code readability or complexity as well as modularization. Anything
that helps with identifying the cause of
a fault and then fixing the fault is the concern of maintainability. Also the
ability to verify (or test) a system, i.e. testability,
is one of the subcharacteristics of maintainability.

6. Portability: This characteristic refers to how well the software can adopt to
changes in its environment or with its
requirements. The subcharacteristics of this characteristic include adaptability.
Object oriented design and implementation
practices can contribute to the extent to which this characteristic is present in a
given system.

The full table of Characteristics and Subcharacteristics for the ISO 9126-1 Quality
Modelis:
Characteristics| Subcharacteristics . Definitions
Suitabilit [This is the essential Functionality characteristic and refers to the
appropriateness (to specification) of
Y [the functions of the software.
Accursteness (This refers to the correctness of the functions, an ATM may providea
cash dispensing function but is
[the amount correct?
seailt ie |A given software component or system does not typically function in
isolation. This subcharacteristic
palngeee ty pnteraper ably concerns the ability of a software component to interact
with other components or systems.
cowipliance Where appropriate certain industry (or government) laws and guidelines
need to be complied with, i.e.
p SOX (Sarbanes-Oxley Act). This subcharacteristic addresses the compliant
capability of software.
Security [This subcharacteristic relates to unauthorized access to the software
functions,
Copyright © PROF. GUFRAN QURESHI
Maturity his subcharacteristic concerns frequency of failure of the software.
Reliability Fault tolerance [The ability of software to withstand (and recover)
from component, or environmental, failure.
Recoverability Ability to bring back a failed system to full operation, including
data and network connections.
Understandabili Determines the ease of which the systems functions can be
understood, relates to user mental models in Human
erstanganility Computer Interaction methods.
sn : fordi ie Hevieg: :
Usability Learnability Learning effort for different users, i.e. novice, expert,
casual etc
\Operability Ability of the software to be easily operated by a given user in a
given environment.
Efficiency [Time behavior Characterizes response times for a given throughput, i.e.
transaction rate.
Resourcebehavior |Characterizes resources used, i.e. memory, cpu, disk and network
usage.
Analyzability Characterizes the ability to identify the root cause of a failure
within the software.
Maintainability _|Changeability Characterizes the amount of effort to change a
system. .
stabilit Characterizes the sensitivity to change of a given system thatis the
negative impact that may be caused by
uty system changes.
[Testability Characterizes the effort needed to verify (test) a system change.
\Adaptability Characterizes the ability of the system to change to new
specifications or operating environments.

Portability Installability Characterizes the effort required to install the

software.

Conf Similar to compliance for functionality, but this characteristic relates to

portability. One example would be Open
eRTete nee SQL conformance which relates to portability of database used.

Repl bili Characterizes the plug and play aspect of software components, that is
how easy is it to exchange a given
eplaceabillty software component within a specified environment.
Product and Process Metrics copyright
Definition: Software Process and Product Metrics are quantitative measures of-
1. They are a management tool.
2. They offer insight into the effectiveness of the software process and the
projects that are conducted using the process as a
framework.
Basic quality and productivity data are collected.
These data are analyzed, compared against ‘past averages, and assessed.
The goal is to determine whether quality and productivity improvements have
occurred.
The data can also be used to pinpoint problem areas.
7. Remedies can then be developed and the software process can be improved.
Process metrics are collected across all projects and over long periods of time.
These are the measures of various characteristics of the
software development process. For example, the efficiency of fault detection. They
are used to measure the characteristics of methods,
techniques, and tools that are used for developing software. E.g. No. of defects,
time to produce the product, productivity etc.
‘|. They are used for making strategic decisions.
2. The intent is to provide a set of process indicators that lead to long-term
software process improvement.
The only way to know how/where to improve any process is to ,
1. Measure specific attributes of the process.
2. Develop a set of meaningful metrics based on these attributes. nee
3. Use the metrics to provide indicators that will lead to a strategy for
improvement. 7 Widsets
Product metrics focus on the quality of deliverables. These are the measures of &
Software > of |e
various characteristics of the software product. Product metrics are combined
across

Dn sw

several projects to produce process metrics. E.g. size, complexity, performance

etc. > a

Metrics for the product: (goto)

: Product | Eee

1. Measures of the Analysis Model. ee

2. Complexity of the Design Model

3. Code metrics.

Designing Software Metrics PRO

An effective software metrics helps software engineers to identify shortcomings in

the software development life cycle so

that the software can be developed as per the user requirements, within estimated
schedule and cost, with required quality
level, and so on. To develop effective software metrics, the following steps are
used.

1. Definitions: To develop an effective metric, it is necessary to have a clear and

concise definition of entities and their
attributes that are to be measured. Terms like defect, size, quality,
maintainability, user-friendly, and so on should be well
defined so that no issues to ambiguity occur.

2. Define a model: A model for the metrics is derived. This model is helpful in
defining how metrics are calculated. The
model should be easy to modify according to the future requirements. While defining
a model, the following questions
should be addressed.

* Does the model provide more information than is available?

+ Is the information practical?

Does it provide the desired information?

3. Establish counting criteria: The model is broken down into its lowest-level
metric entities and the counting criteria
(which are used to measure each entity) are defined. This specifies the method for
the measurement of each metric
primitive. For example, to estimate the size of a software project, line of code
(LOC) is a commonly used metric. Before
measuring size in LOC, clear and specific counting criteria should be defined.

4. Decide what is good: Once it is decided what to measure and how to measure, it
is necessary to determine whether
action is needed. For example, if software is meeting the quality standards, no
corrective action is necessary. However, if
this is not true, then goals can be established to help the software conform to the
quality standards laid down. Note that
the goals should be reasonable, within the time frame, and based on supporting
actions.

5. Metrics reporting: Once all the data for metric is collected, the data should be
reported to the concerned person. This
involves defining report format, data extraction and reporting cycle, reporting
mechanisms, ‘and so on.

6, Additional qualifiers: Additional metric qualifiers that are ‘generic’ in natyre

should be determined. In other words,
metric that is valid for several additional extraction qualifiers should be
determined.

QURESHI
\ 2%

Product versus Process Quality Management Copyright © PROF. GUERAN QURESHI

Product Quality means to incorporate features that. have a capacity to theet
consumer needs (wants) and gives custonier satisfaction by improving ptoducts
Product vs Process
(goods) and making them free from any deficiencies or defects. There are various
supe patch narnia
important aspects which define a product quality like: Storage, Quality of Design,
a. ,

Quality of Conformance, Reliability, Safety. Product Quality is the degree to Sa |

wortpreeess [sur —>

Custamers

which a product or service emerges as planned. ie

Process Quality is defined as all the steps used in the manufacturing the final <>
Cwaste >)
product. Its focus are on all activities and steps used to achieve a maximum Modern
method
acceptance regardless of its final product. Process Quality is the repeatability of
Sailr i ‘memes
the series of steps taken to produce the product or service. Consistent product
Pp Pp pi or service, Co p —

INPUT, Work process »

quality is therefore a result of consistent process quality. This is why fast food
chains specify how to make food so that every hamburger comes out as planned
and advertised. Same for haircuts, automobiles, shirts, shoes, etc.

|__| a
INFORMATION People processes. INFORMATION:
$.NO PRODUCT © PROCESS

While process is a set of sequence steps that have to be

L. Product is the final production of the project. followed to create a project.

Whereas the process is focused on completing each step being

2. A product focuses on the final result.

developed.
3. In case of product, the firm guidelines are followed. In contrast, the process
consistently follows guidelines.
4, A product is tend to be short term. Whereas the process is tend to be long term.
5 The main goal of the product is to complete the work While the purpose of the
process is to make better the quality
, successfully. of the project.
Quality Management Systems Copyright © PROF. GUFRAN QURESHI

Definition: In project management, the quality management system is the

organizational framework that provides structure
to the processes, policies, procedures, and resources to implement the quality
management plan.
> It is one of the aspects of running an organization as it serves as the core that
impact the ability of the organization to meet
the requirements of the customer. -
> This crucial project management element integrates different internal processes
within the organization and provides the
process approach needed to execute the project.
> Moreover, it also allows the organization to identify, measure, control as well
as improve the different
business process that can lead to the improvement of the business performance.
Benefits:
Implementing a quality management system affects every aspect of an organization’s
performance. Benefits of a documented
quality management system include:
1. Meeting the customer’s requirements, which helps to instill confidence in the
organization, in turn leading to more
customers, more sales, and more repeat business
2. Meeting the organization’s requirements, which ensures compliance with
regulations and provision of products and
services in the most cost- and resource-efficient manner, creating room for
expansion, growth, and profit.
>» Quality Assurance is known as QA and focuses on preventing defect. Quality 5;
Assurance ensures that the approaches, techniques, methods and processes are
designed for the projects are implemented correctly.
> Quality Control is known as QC and focuses on identifying a defect. QC ensures
that the approaches, techniques, methods and processes are designed in the
project are following correctly. Quality Control is a reactive process and is
detection in nature. It recognizes the defects. Quality Control has to complete
after Quality Assurance.

Quality Assurance

A. Quality Control
Process Capability Models Copyright © PROF. GUFRAN QURESHI
Definition: Every production process is subject to variations that limit our
ability to produce a defect-free product. Process
capability models (PCMs) are used to quantify likely process variations, which can
then be included during the analysis of a
product design. PCMs facilitate the flowback of capability information from
manufacturing/sourcing to design and are an
essential element of Design for Six Sigma. °

Capability Maturity Model(CMM):

The Capability Maturity Model is a methodology used to develop and refine an
organization's seinen development process.
The model describes a five-level evolutionary path of increasingly organized and
systematically more mature processes.
Level One :Initial - The software process is characterized as inconsistent, and
occasionally even chaotic. Defined processes
and standard practices that exist are abandoned during a crisis. Success of the
organization majorly depends on an individual
effort, talent, and heroics. The heroes eventually move on to other organizations
taking their wealth .of knowledge or lessons
learnt with them.
Level Two: Repeatable - This level of Software Development css ones
Organization has a basic and consistent project management processes
to track cost, schedule, and functionality. The process is in place to
repeat the earlier successes on projects with similar applications.
Program management is a key characteristic of'a level two organization.
Level Three: Defined - The software process for both management and evelopment
metnodclogy
engineering activities are documented, standardized, and integrated into :

a standard software process for the entire organization and all projects De
Repeatable rita
across the organization use an approved, tailored version of the :
organization's standard software process for developing, testing and voce: nb pat
cntled area
maintaining the application.

ects tallor their processes from the organizations

Copyright © PROF. GUFRAN QURESHI

Level Four: Managed - Management can effectively control the software development
effort using precise measurements.
At this level, organization set a quantitative quality goal for both software
process and software maintenance. At this maturity
level, the performance of processes is controlled using statistical and other
quantitative techniques, and is quantitatively
predictable.
Level Five: Optimizing (Maturity) - The Key characteristic of this level is
focusing on continually improving process
performance through both incremental and innovative technological improvements. At
this level, changes to the process are
to improve the process performance and at the same time maintaining statistical
probability to achieve the established
quantitative process-improvement objectives.
|25

Techniques to Help Enhance Software Quality

Copyright © PR

Definition: Software quality is defined as a field of study and practice that,

describes the desirable attributes of software products,
Software quality measures how well software is designed (quality of design), and
how well the software conforms to that design
(quality of conformance). From an IT projéct managers perspective quality falls
into two areas:

I.

7.

IL.

Quality of the Deliverables: Every project must have a clearly stated objective as
to what the project will produce. Once the
objective are in place they can help in formulating the project requirements. The
project requirements evolve through progressive
elaborations into project scope baseline. The quality of the deliverables of a
service is measured in value by several factors:

Value of the implementation: Here the true cost of the implementation should be
measured with the benefits that the
implementation will provide. The cost-benefit ratio should justify the
implementation.

Value of the service: The value of the service to the organization should be
measured by comparing the organization before and
after the project has been implemented.

Value of the experience: The value of the experience that the user derives after
using the service determines the success of the
project.

Value of longevity: The life of the service should offer reasonable Return-on-
investment (ROI). The project manager should
research and ensure that the service is not replaced by a better, faster, more
reliable or less expensive one before ROI achieved.
Value of reliability: The reliability of the service shouldn’t be a matter of
concern for the users. Once the service has been
implemented it should not consistently fails or is unavailable as this would deem
that the service lacks quality.

Value of the project: The cost incurred on the IT product should be justified by
way of the benefits that it is able to deliver to the
user.

Value of usability: The product has to deliver on its promise to prove to be

usable. The usability of the product is the reason for
the existence of the project.

Quality of the process that produces the deliverables: To produce any product or
service a process has to be followed.
Likewise, in a project there is logical path of completing a project. To ensure the
quality of the deliverable, the quality of each and
every process along the path has to be ensured. The project manager should follow a
proven process to create deliverables that are
efficient and valuable to the organization.

Enhancing Software Quality | Capyright @ PROF.

Definition: Excellent software quality will enable cost effectiveness and superior
performance to deliver your projects. Finding ways to implement
effective testing strategies at the earliest possible stage will help you detect
and solve defects. Solving problems at the earliest stage of project
management creates a win-win scenario. Increased efficiency results in better
quality software and reduced costs. Conversely, poor software quality
exacerbates problems and can become a time-consuming and expensive exercise.

Following are some of the effective methods that can be adopted to enhance software
quality:

1.

Testing: To improve software quality, it is absolutely paramount to Test early and

Test often. Early testing will ensure that any defects do not
snowball into larger, more complicated issues. The bigger the defect, the more
expensive it becomes to iron out any issues. The earlier you get
your testers involved, the better.

Implement quality controls from the beginning: Testers can monitor quality controls
and create awareness in partnership with developers to
ensure standards are continually being met. Quality control starts from the
beginning, which is an ongoing process throughout the delivery.

Stress on the importance of quality assurance: Quality assurance should be ever-

present throughout the software development process, Quality
Assurance is a governance provided by the project team that instils confidence in
the overall software quality.

Encourage innovations: Innovations are so important because they can lead to

improvements in software quality that have the capability to
transform how projects are delivered. Research and development (R&D) should be
encouraged. Empower teams to explore, experiment and
investigate continuously.

Communication: For any relationship to be successful, whether it’s personal or

business, communication is key. To improve software quality it is
important that all parties to the project have full information through fluid
communication channels.

Plan for a changeable environment: Software contains so many variables and is in

continuous evolution. It relies on several different external
factors such as web browsers, hardware, libraries, and operating systems.

Have a risk register: A risk register is a fantastic management tool to manage

risks. A risk register is more Synonymous with financial auditing.
however it is still a vital element in software development.
Outline your deliverables: From the outset of your project it is imperative that
your team outline what they are going to deliver. A clear and
concise plan of what the project will deliver helps ensure there is an emphasis on
quality from the outset.

Review, revise, and remember: Review — Testing often is a pillar of ensuring

software quality. It ensures that standards ate continuously met and
bugs, errors and distractions can be fixed before they spiral out of control.
Revise — Study what has worked throughout the software process.
Utilise what is working and see if innovation can transcend your software quality
even further. Remember — When you deliver quality remember
what worked well and did not work well. Keep an updated record of both the
positives and negatives of any given project and tum to it frequently
when you start the next project from scratch.
Fagan Inspection Ssnidisdirnarscxasneuness:

Definition: A Fagan inspection is a process of trying to find defects in documents

(such as source code or - formal specifications)

during various phases of the software development process. It is named after

Michael Fagan, who is credited as being the inventor

of formal software inspections.

Inspection Activities/Process

A formal inspection method consists of the following activities.

1. Planning :The moderator begins with planning the inspection activities, that is,
forming the inspection team, gathering the
necessary resources required during the inspection process, and distributes the
necessary documents among the inspection
team prior beginning the inspection process. Every document required for inspection
should be clear, for instance the code
should execute cleanly, and the listings (for defects) should be numbered.

2. Overview Meeting :This part of the inspection process is concerned with

discussions regarding the important features of the
product. This process may be skipped if the key points are known to the
participants in advance.

3. Preparation :Participants are expected to examine the work product before

beginning with the inspection process, to be able
to raise issues or to see if any defect is detected. In short one needs to prepare
himself in advance for the inspection meeting
so that whatever is to be discussed, they are able to provide their individual
feedback.

4. Inspection Meeting :This is the phase where the moderator begins leading the
team, that is, the inspection process begins.
The team is led by the moderator and the reader. If the moderator feels that the
time allotted to the inspection meeting is
insufficient, then he can reschedule the meeting at a later date.

5. Casual Analysis :This method deals with identifying the causes that leads to the
occurrence of defects, thus allowing us to
figure out ways to take preventive measures to avoid such defects to arise further,

6. Rework :The author shoulders the responsibility of solving issues or defects.

The author must at least prepare an approximate

estimation to deal with defects.

7. Follow-up :By the time the necessary rework is done, the moderator follows up
with the author to check whether changes

have been made correctly or not. The product must pass the inspection followed by
this process. The defects should have
resolved by now and the unresolved issues must be documented in a defect tracking
system.

Testing casyegutio PROR-UPRANOG

Definition: Testing is the process of evaluating a system or its component(s) with
the intent to find whether it satisfi ies the specified
requirements or not. Testing is executing a system in order to identify any gaps,
errors, or missing requirements in contrary to the
actual requirements.

Sr. No. Key Unit Testing System Testing

Unit testing is a testing in which tester tests |On other hand System testing is
the type of testing where each
1 Definition [only single module at a time and not the module is treated as
separate target for testing and these modules
integrated version of the application. are getting integrate one by one after
testing completed on them.

In case of unit testing single module testing [While in case of System testing it
comprise the bottom-up

2 Approach Japproach is taken in practice. approach testing and top-down approach

testing along with all
modules in integrated mode.

. As single module is tested in Unit testing so |On other hand incase of System
testing modules are getting

3 Defects {defects get easily identified and are locked [integrated after testing
so defects are not easily identified as
as per module. modules get dependent on each other up to some extent.

4 | Abbreviation |Unit testing is also called white box testing. |On other hand
System testing is also called black box testing.

Parallel testing is not supported incase of {On other hand in case of System
testing parallel testing is

Parallel ' : : ' : :

5 Testin Unit testing as single module plays role in —_|supported as multiple
modules can be get tested in parallel.
g case of Unit testing.
Coat Unit testing have less cost as compare to On other hand in case of System
testing cost is comparatively
6 . System testing as less number of resources higher as more number of resources
is required in this type of
effective Fae ; :
are required in this type of testing. testing.
Performance of unit testing is high as (On other hand System testing has lower
performance as compare

7 |Performance|compare to System testing as single module |to Unit testing as

multiple and integrated modules get tested at
is get tested at a time. same time.
\24+

Software Reliability Copyright © PROF. GUFRAN QURESHI

Definition: Software Reliability is the probability of failure-free software
operation for a specified period of time in a specified
environment. Software Reliability is also an important factor affectig systeni
reliability. It differs from hardware reliability in that it
reflects the design perfection, rather than rariufacturing perfection. The
high’complexity of software is the major contributing factor
of Software Reliability problems.
Software Reliability is an important attribute of software quality, together with
functionality, usability, performance, serviceability,
capability, installability, maintainability, and documentation. Software
Reliability is hard to achieve, because the complexity of

software tends to be high. ‘ati

resting

hase
P Useful life

Characteristics of Software Reliability:

1. Failure cause: Software defects are mainly design defects.

2. Wear-out: Software does not have energy related wear-out phase. Errors can
OCCULT, ire
without warning. rate

3. Repairable system concept: Periodic restarts can help fix software problems.

4. Time dependency and life cycle: Software reliability is not a function of

operational

Obsolescence

ume: 5 aes . . —— Time —_>

5. Environmental factors: Do not affect Software reliability, except it might
affect
program inputs. Fig. 2: Software reliability curve (failure rate versus time)

6. Reliability prediction: Software reliability can not be predicted from any

physical basis, since it depends completely on human -

factors in design.

Redundancy: Can not improve Software reliability if identical software components

are used.

Interfaces: Software interfaces are purely conceptual other than visual.

Failure rate motivators: Usually not predictable from analyses of separate

statements.
0. Built with standard components: Well-understood and extensively-tested standard
parts will help improve maintainability and
reliability. But in software industry, we have not observed this trend. Code reuse
has been around for some time, but to a very
limited extent. Strictly speaking there are no standard parts for software, except
some standardized logic structures.

a ee A

F, GUFRAN QURESHI

Software Reliability Metrics Copyright

Definition: Measuring software reliability remains a difficult problem because we

don't have a good understanding of the nature of

software. There is no clear definition to what aspects are related to software

reliability. We can not find a suitable way to measure

software reliability, and most of the aspects related to software reliability. Even
the most obvious product metrics such as software
size have not uniform definition. :

It is tempting to measure something related to reliability to reflect the

characteristics, if we can not measure reliability directly. The

current practices of software reliability measurement can be divided into four

categories:

1. Product metrics: Software size is thought to be reflective of complexity,

development effort and reliability. Lines Of Code
(LOC), or LOC in thousands(K LOC), is an intuitive initial approach to measuring
software size. But there is not a standard way
of counting. Typically, source code is used(SLOC, KSLOC) and comments and other
non-executable statements are not counted.
This method can not faithfully compare software not written in the same language.
The advent of new technologies of code reuse
and code generation technique also cast doubt on this simple method.

2. Project management metrics: Researchers have realized that good management can
result in better products. Research has
demonstrated that a relationship exists between the development process and the
ability to complete projects on time and within
the desired quality objectives. Costs increase when developers use inadequate
processes. Higher reliability can be achieved by
using better development process, risk management process, configuration management
process, etc.

3. Process metrics: Based on the assumption that the quality of the product is a
direct function of the process, process metrics can
be used to estimate, monitor and improve the reliability and quality of software.
[SO-9000 certification, or "quality management
standards", is the generic reference for a family of standards developed by the
International Standards Organization(ISO).

4. Fault and failure metrics: The goal of collecting fault and failure metrics is
to be able to determine when the software is
approaching failure-free execution. Minimally, both the number of faults found
during testing (i.e., before delivery) and the
failures (or other problems) reported by users after delivery are collected,
summarized and analyzed to achieve this goal. Test
strategy is highly relative to the effectiveness of fault metrics, because if the
testing scenario does not cover the full functionality
of the software, the software may pass all tests and yet be prone to failure once
delivered. Usually, failure metrics are based upon
customer information regarding failures found after release of the software. The
failure data collected is therefore used to
calculate failure density, Mean Time Between Failures (MTBF) or other parameters to
measure or predict software reliability.
Quality Plans ™ cceencesneés

Definition: Quality planning is the task of determining what factors are important
to a project and figuring ¢ out how to meet hose

factors. Such factors often include the resources that will be used, the steps
needed to complete the project and any other

specifications.

For the project manager it is fundamental that all quality aspects of the project
are incorporated at the planning phase. Each project

deliverable should have metrics that prove its quality.

Major Approaches to Quality Planning :

1. Cost-Benefit Analysis: The cost-benefit analysis is similar to a cost-benefit

ratio. The costs and benefits are measured to analyze
the trade-offs of providing quality.

2. Cost of Quality: Cost of quality (COQ) includes all the costs that conform to
the required quality of the project, including the
cost to ensure conformance to requirements as well as the cost of nonconformance,
and finding the right balance. Modern quality
management philosophy emphasizes preventing mistakes rather than detecting them
later because the cost of nonconformance is
very high.

3. Benchmarking: Benchmarking involves comparing the current project or activity to

similar projects or activities. This process
generates ideas for improvement and provides a standard to measure quality
performance. Benchmarks can be created from a
variety of standards, including experience on other projects within the company,
experience by vendors outside the company, or
published industry standards.

4. Flowcharts: Flowcharts show the logical steps in a process and how various
elements within a system are related. They can be
used to determine and analyze potential problems in quality planning and quality
control. The system, or process, flowchart is
probably the one that people are most familiar with. This type of flowchart
outlines the logical steps to complete a process. By
documenting these logical steps, the team can identify where quality problems might
occur and then develop approaches to
proactively manage them. Flowcharting also helps create a process that is
repeatable.

5. Design of Experiments: Design of experiments is the process of going through

what-if scenarios with a limited number of
samples to determine the optimal solution to improve quality. It is a statistical
method that identifies the variables that will have
the greatest effect on the quality of the project. Typically, this method is used
on the product of the project, but it also can be
applied to the project management process.
Ch-14 Project Closeout

Definition: Project Closure involves handing over the deliverables to your

customer, passing the documentation to the business,

cancelling supplier contracts, releasing staff and equipment, and informing

stakeholders of the closure of the project.

» “Close Project or Phase is the process of finalizing all activities for the
project, phase, or contract.”

>» The key benefits of this process are the project or phase information is
archived, the planned work is completed, and
organizational team resources are released to pursue new endeavors.

» Project need to be closed. Whether it is successfully completed, terminated, or

affected by external factors. The closing process
could vary depend on the closure situation. However, in all cases the project
closure process should be documented to formally
close the project.

There are primarily two types of closures; contract closure and administrative
closure.

1. Contract Closure: It indicates that all agreed upon project deliverables and
agreed upon terms have been completed and that the
project can now officially end. It also paves the way for all the specifically
assigned resources to be reassigned to new projects
and dues under the contract to be paid.

Among other activities contract closure includes:

i. Confirming the project has addressed the terms and conditions of the contracts
au

ii. Confirming completion of exit criteria for contract closure Project Dual Close-
Out Process

iii. Formally closing out all contracts associated with the completed project.

Project Close-Out

2. Administrative Closure: It involves documenting of all project related

information that
would prove valuable for future project. Although each phase has a closing process,
the [™2cs2"" Squat
major emphasis is during the final project closure process. ime

Among other activities administrative closure includes:

i. Confirming the project has met all sponsor, customer, and stakeholder
requirements
ii. Verifying that all deliverables have been delivered and accepted

iii. Validating exit criteria have been met.

Pot tripevaresticn
Bwaluagan Rapot”
Reasons for Project Closure Copyright © PR

1. Expensive or does not meet compumy’s goal: Make an estimaté of the total cost of
the project in the planning stage
itself, A few thousand dollars here and there are manageable, but when you see the
figure going way over your
approximate value, it is better to put an end to the project right in the
initiation stage. Also, if the project does not go well
with the strategic plan of the company, it should not be given the green signal.

2.. Your competitors are doing a better job: As a project manager, you may be
motivated to prove your mettle and take
your company ahead in the market, but think logically and determine if it is
possible. Many a times, you may be
motivated at the start of the project but once you begin with it and have to face
grave challenges one after another, the
positive drive may fizzle out and you may be left with a project that is going
nowhere. Even if you realize it midway on
the project, do not hesitate to pull the plug.

3. Project gets out of control: When operations get way beyond control or when
damages cannot be repaired anymore, you

know itis time to terminate the project. SLE LL a ee rT

4. Important or priority project comes up: Businesses take up several projects

(Objectives
simultaneously. However, there are some projects which need more time, energy <a
and resources. If a certain project is stopping you from allocating the required
dime inital
resources in a bigger, important project, it is better to let go of the smaller \
Cost ~ - Banning,
project . Sa Reasons peed

2 ° . . . . . . * t for

5. Failure in testing process: It is sad to see a project fail during testing. \

Project

However, if the team members gave it all that they could and the project still \ SS

could not succeed, putting an end to the project is a sensible choice rather than
spending twice the energy and resources on it again.

Project Closure Process Copyright © PROF. GUFRAN QURESHI

Project Closure Step #1: Confirm workis done as per the requirements: Once the
project is closing, all deliverables of
the project must have been completed and delivered to the customer. You should also
take formal acceptance of the customer
for the completed work.

Project Closure Step #2: Complete procurement closure: Since the project is
closing, you should complete any remaining
payments that need to be made to the suppliers or partners. The procurement steps
are also completed.

Project Closure Step #3: Gain formal acceptance: Formal acceptance of the project
and project deliverables are taken from
the customer. Usually, the customer presents a written document, it can be an email
or a signed off document, which states
that the project has been completed and they accept the outputs of the project.

Project Closure Step #4: Complete final performance reporting: The final
performance of the project is calculated and
recorded. These include cost performance, schedule performance, quality performance
etc. For instance, whether the project
has been completed under budget or if it could not be completed, how much did the
project exceeded the planned budget?
Project Closure Step #5: Index and archive records: Collected documents are
finalized. Final versions of the project
management plans and all necessary documents about the project are archived in the
company records.

Project Closure Step #6: Update lessons learned: Lessons learned is collected and
gathered from all stakeholders. Lessons
learned documentation is stored in the organizational process assets of the
company.

Step #7: Hand-offcompleted product: Once the project is completed, the product of
the project is handed over for the use
of the end customer. The handover may need a predetermined period of assistance or
some documents describing how to use
or how to operate with the product.

Step #8: Release the resources: After the project is completed successfully, all
assignments of the project resources are
closed, lessons learned inputs from the project resources are collected and then
these resources are released respectively.

OF. GUFRAN QURESHI

Performing a Financial Closure

Definition: Financial closure is the process of completing all project-related

financial transactions, finalizing and closing the

project financial accounts, disposing of project assets and releasing the work
site. It is a prerequisite to project closure and the

post-implementation review.

> A project cannot be closed until all financial transactions are complete,
otherwise there might not be the authority or funds
to pay outstanding charges and invoices.

> Financial closure establishes final project costs for comparison against budgeted
costs as part of the post-implementation
review. Finally, financial closure ensures proper disposition of all project
assets.

> As the project reaches the final stage and is all set for closure the project
manager should initiate the following steps with
respect to financial closure of the project:

1. Inadvance, establish and announce (in writing!) to all project staff and vendors
the deadline date for the completion of all

financial transactions and closing of financial accounts.

Verify that all acceptance criteria in the statement of work have been met prior to
payments to vendors and consultants, if

applicable.

Annotate “Final Payment” on all wondhes:

Verify that there are no outstanding invoices or unresolved financial obligations.

Close financial accounts according to applicable corporate, state and federal

accounting procedures.

Comply with all applicable funding source requirements for records retention.

Comply with all applicable funding source requirements for financial reporting.

Notify top management that all final payments have been processed for all project
related contracts.

Transfer or dispose of assets acquired for the project as per organizational

policy.

10. Release the project space (work site) according to agreements with facilities
management or other appropriate entity.
11. Implement procedures for retaining the financial records.

=)
SPN AMERY

Project Closeout Report Copyright

Definition: The Project Closeout Report is documented to identify the variances

from the baseline plans, in terms of project
performance, project cost and schedule. Besides stating the planned and actual
figure, it is important to state the variances and, most
important, an explanation of why such variances exist.

Steps:

1. Evaluate Overall Project Performance: Document how the project performed against
each performance goals established in
the Project Performance Plan.

2. Document Actual Project Cost: State the planned and actual cost for the project.
The planned cost should be approved in the
initial cost baseline and the project charter, while the actual cost is the actual
project cost at completion. Document the variances
and explain why such variances exist.

3. Document Actual Project Schedule: Compare the initial approved schedule baseline
against the actual completion dates.
Document all planned and actual start and finish dates, describe the schedule
variances with explanation.

4. Document Scope Changes: Document any changes to the project scope and their
impact on performance, cost, or schedule
baselines.

5. Describe Resources’ Statuses: Describe the use of resources throughout the

project.

6. Perform Operations and Maintenance Plan: Describe the plan for operation and
maintenance of the project deliverables.

7. Identify Storage of Project Documentation: Identify all project documentation

materials stored in the project library or other
repositories (e.g. Project Management Repository).

8. Record Post-Implementation Review: Identify the date for completing the post
implementation report and the person
responsible for this action.

9. Identify Open Issues: List and describe the open issues for resolution within
the context of project closeout.

10. Archive Project Documents & Artifacts: Ensure that all project documents and
artifacts are properly stored for future use or
references. Make sure all necessary approvals and signatures are present. Archive
the required final versions of documents in
auditable form in the agreed upon place and ensure that they cannot be edited, and
store the other project artifacts according to
the agreed upon procedures.
\S\

Project Audit ’ Copyright © PROF. GUFRAN QURESHI

Definition: A project management audit is ari examination designed to detérthine

the true status of work performed on a project and

its conformance with the project statement of work, including schedule and budget
constraints.

» Project auditing is a formal type of "pfojéct review", most often designetl to

evaluate the extent to which project management
standards are being followed. 64 uy

» The ultimate goal of a project audit is to ensure that the project is meeting
project management standards through investigations
and evaluations. The following are five ‘main objectives of a project audit: | . .

1. Assure Quality of Products and Services: A project audit acts as a quality

assurance instrument. It scrutinizes (analysis) the
project life cycle system by evaluating the deliverables produced during various
phases of the project from the design phase all
the way to the implementation phase.

2, Assure Quality of Project Management: A project audit assures that project

management is meeting the standards by
evaluating if it follows the organization’s policies, processes and procedures. It
scrutinizes the methodology used to help identify
the gaps in order to make the necessary improvements.

3. Identify Business Risk: Project audits help identify business risks that may
involve budget, time, scope and quality. After all,
the company is the client itself, which has a bigger stake at the outcome of the
project. The project audit evaluates the feasibility
of the project in terms of affordability and returns by providing transparency to
the project status and performance by evaluating
the cost, time and resources. ,

4. Enhance Project Performance: Auditing the various phases in the project life
cycle can help improve performance of the project team.
It also improves resource and budget allocation. Identifying priorities, corrective
measures and preventative actions can lead to a

successful project outcome. ‘ aes

5. Leam: A project audit can lead to learning opportunities through assessments
cian” a reeney

of project management (organizational, team and individual) competency. & BB

Providing reviews and feedbacks allow individuals and project teams to reflect g \

on their performance. Sas a . es

ran Say? ERs tity ny lk