Software Project Planning and Management

What is Software Engineering?

The term software engineering is the product of two words, software, and engineering.

The software is a collection of integrated programs.

Software subsists of carefully-organized instructions and code written by developers on any of

various particular computer languages.

Computer programs and related documentation such as requirements, design models and user
manuals.

Engineering is the application of scientific and practical knowledge to invent, design, build,
maintain, and improve frameworks, processes, etc.

Software Engineering is an engineering branch related to the evolution of software product

using well-defined scientific principles, techniques, and procedures. The result of software
engineering is an effective and reliable software product.

Why is Software Engineering required?

Software Engineering is required due to the following reasons:

o To manage Large software

o For more Scalability
o Cost Management
o To manage the dynamic nature of software
o For better quality Management

Need of Software Engineering

The necessity of software engineering appears because of a higher rate of progress in user
requirements and the environment on which the program is working.

o Huge Programming: It is simpler to manufacture a wall than to a house or building,

similarly, as the measure of programming become extensive engineering has to step to
give it a scientific process.
o Adaptability: If the software procedure were not based on scientific and engineering
ideas, it would be simpler to re-create new software than to scale an existing one.
o Cost: As the hardware industry has demonstrated its skills and huge manufacturing has
let down the cost of computer and electronic hardware. But the cost of programming
remains high if the proper process is not adapted.
o Dynamic Nature: The continually growing and adapting nature of programming hugely
depends upon the environment in which the client works. If the quality of the software is
continually changing, new upgrades need to be done in the existing one.
o Quality Management: Better procedure of software development provides a better and
quality software product.

Characteristics of a good software engineer

The features that good software engineers should possess are as follows:

Exposure to systematic methods, i.e., familiarity with software engineering principles.

Good technical knowledge of the project range (Domain knowledge).

Good programming abilities.

Good communication skills. These skills comprise of oral, written, and interpersonal skills.

High motivation.

Sound knowledge of fundamentals of computer science.

Intelligence.

Ability to work in a team

Discipline, etc.

Importance of Software Engineering

The importance of Software engineering is as follows:

1. Reduces complexity: Big software is always complicated and challenging to progress.

Software engineering has a great solution to reduce the complication of any project.
Software engineering divides big problems into various small issues. And then start
solving each small issue one by one. All these small problems are solved independently
to each other.
2. To minimize software cost: Software needs a lot of hard work and software engineers
are highly paid experts. A lot of manpower is required to develop software with a large
number of codes. But in software engineering, programmers project everything and
decrease all those things that are not needed. In turn, the cost for software productions
becomes less as compared to any software that does not use software engineering
method.
3. To decrease time: Anything that is not made according to the project always wastes
time. And if you are making great software, then you may need to run many codes to get
the definitive running code. This is a very time-consuming procedure, and if it is not well
 handled, then this can take a lot of time. So if you are making your software according to
the software engineering method, then it will decrease a lot of time.
4. Handling big projects: Big projects are not done in a couple of days, and they need lots
of patience, planning, and management. And to invest six and seven months of any
company, it requires heaps of planning, direction, testing, and maintenance. No one can
say that he has given four months of a company to the task, and the project is still in its
first stage. Because the company has provided many resources to the plan and it should
be completed. So to handle a big project without any problem, the company has to go for
a software engineering method.
5. Reliable software: Software should be secure, means if you have delivered the software,
then it should work for at least its given time or subscription. And if any bugs come in the
software, the company is responsible for solving all these bugs. Because in software
engineering, testing and maintenance are given, so there is no worry of its reliability.
6. Effectiveness: Effectiveness comes if anything has made according to the standards.
Software standards are the big target of companies to make it more effective. So Software
becomes more effective in the act with the help of software engineering.

What is Project?

A project is 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.

What is software project management?

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.

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

Prerequisite of software project management?

There are three needs for software project management. These are:
 1. Time
2. Cost
3. Quality

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.

Project Manager

A project manager is a character who has the overall responsibility for the planning, design,
execution, monitoring, controlling and closure of a project. A project manager represents an
essential role in the achievement of the projects.

A project manager is a character who is responsible for giving decisions, both large and small
projects. The project manager is used to manage the risk and minimize uncertainty. Every
decision the project manager makes must directly profit their project.

Role of a Project Manager:

1. Leader

A project manager must lead his team and should provide them direction to make them
understand what is expected from all of them.

2. Medium:

The Project manager is a medium between his clients and his team. He must coordinate and
transfer all the appropriate information from the clients to his team and report to the senior
management.

3. Mentor:

He should be there to guide his team at each step and make sure that the team has an attachment.
He provides a recommendation to his team and points them in the right direction.

Responsibilities of a Project Manager:

1. Managing risks and issues.
2. Create the project team and assigns tasks to several team members.
3. Activity planning and sequencing.
4. Monitoring and reporting progress.
5. Modifies the project plan to deal with the situation.
Activities

Software Project Management consists of many activities, that includes planning of the project,
deciding the scope of product, estimation of cost in different terms, scheduling of tasks, etc.

The list of activities are as follows:

1. Project planning and Tracking

2. Project Resource Management
3. Scope Management
4. Estimation Management
5. Project Risk Management
6. Scheduling Management
7. Project Communication Management
8. Configuration Management

Now we will discuss all these activities -

1. Project Planning: It is a set of multiple processes, or we can say that it 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. Scope Management create the
project to contain restricted and quantitative tasks, which may merely be documented and
successively avoids price and time overrun.

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.

If we talk about the size, then Line of code depends upon user or software requirement.

If we talk about effort, we should know about the size of the software, because based on the size
we can quickly estimate how big team required to produce the software.

If we talk about time, when size and efforts are estimated, the time required to develop the
software can easily determine.

And if we talk about cost, it includes all the elements such as:

o Size of software
o Quality
o Hardware
o Communication
 o Training
o Additional Software and tools
o Skilled manpower

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.

For scheduling, it is compulsory -

o Find out multiple tasks and correlate them.

o Divide time into units.
o Assign the respective number of work-units for every job.
o Calculate the total time from start to finish.
o Break down the project into modules.

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.

Resource management includes:

o Create a project team and assign responsibilities to every team member

o Developing a resource plan is derived from the project plan.
o Adjustment of resources.

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.

Several points show the risks in the project:

o The Experienced team leaves the project, and the new team joins it.
o Changes in requirement.
o Change in technologies and the environment.
o Market competition.

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
stakeholders of the project such as hardware suppliers.

From the planning to closure, communication plays a vital role. In all the phases, communication
must be clear and understood. Miscommunication can create a big blunder in the project.
8. Project Configuration Management: Configuration management is about to control the
changes in software like requirements, design, and development of the product.

The Primary goal is to increase productivity with fewer errors.

Some reasons show the need for configuration management:

o Several people work on software that is continually update.

o Help to build coordination among suppliers.
o Changes in requirement, budget, schedule need to accommodate.
o Software should run on multiple systems.

Tasks perform in Configuration management:

o Identification
o Baseline
o Change Control
o Configuration Status Accounting
o Configuration Audits and Reviews

People involved in Configuration Management:

Project Management Tools

To manage the Project management system adequately and efficiently, we use Project
management tools.
Here are some standard tools:

Gantt chart

Gantt Chart first developed by Henry Gantt in 1917. Gantt chart usually utilized in project
management, and it is one of the most popular and helpful ways of showing activities displayed
against time. Each activity represented by a bar.

Gantt chart is a useful tool when you want to see the entire landscape of either one or multiple
projects. It helps you to view which tasks are dependent on one another and which event is
coming up.

PERT chart
PERT is an acronym of Programme Evaluation Review Technique. In the 1950s, it is developed
by the U.S. Navy to handle the Polaris submarine missile programme.

In Project Management, PERT chart represented as a network diagram concerning the number of
nodes, which represents events.

The direction of the lines indicates the sequence of the task. In the above example, tasks between
"Task 1 to Task 9" must complete, and these are known as a dependent or serial task. Between
Task 4 and 5, and Task 4 and 6, nodes are not depended and can undertake simultaneously.
These are known as Parallel or concurrent tasks. Without resource or completion time, the task
must complete in the sequence which is considered as event dependency, and these are known as
Dummy activity and represented by dotted lines.

Logic Network

The Logic Network shows the order of activities over time. It shows the sequence in which
activities are to do. Distinguishing events and pinning down the project are the two primary uses.
Moreover, it will help with understanding task dependencies, a timescale, and overall project
workflow.

Product Breakdown Structure

Product Breakdown Structure (BBS) is a management tool and necessary a part of the project
designing. It's a task-oriented system for subdividing a project into product parts. The product
breakdown structure describes subtasks or work packages and represents the connection between
work packages. Within the product breakdown Structure, the project work has diagrammatically
pictured with various types of lists. The product breakdown structure is just like the work
breakdown structure (WBS).

Work Breakdown Structure

It is an important project deliverable that classifies the team's work into flexible segments.
"Project Management Body of Knowledge (PMBOK)" is a group of terminology that describes
the work breakdown structure as a "deliverable-oriented hierarchical breakdown of the work
which is performed by the project team."

There are two ways to generate a Work Breakdown Structure ?

The top-down andThe bottom-up approach.

In the top-down approach, the WBS derived by crumbling the overall project into subprojects
or lower-level tasks.

The bottom-up approach is more alike to a brainstorming exercise where team members are
asked to make a list of low-level tasks which is required to complete the project.
Resource Histogram

The resource histogram is precisely a bar chart that used for displaying the amounts of time that
a resource is scheduled to be worked on over a prearranged and specific period. Resource
histograms can also contain the related feature of resource availability, used for comparison on
purposes of contrast.

Critical Path Analysis

Critical path analysis is a technique that is used to categorize the activities which are required to
complete a task, as well as classifying the time which is needed to finish each activity and the
relationships between the activities. It is also called a critical path method. CPA helps in
predicting whether a project will expire on time.

Software Configuration Management

When we develop software, the product (software) undergoes many changes in their
maintenance phase; we need to handle these changes effectively.

Several individuals (programs) works together to achieve these common goals. This individual
produces several work product (SC Items) e.g., Intermediate version of modules or test data used
during debugging, parts of the final product.

The elements that comprise all information produced as a part of the software process are
collectively called a software configuration.

As software development progresses, the number of Software Configuration elements (SCI's)

grow rapidly.

These are handled and controlled by SCM. This is where we require software configuration
management.

A configuration of the product refers not only to the product's constituent but also to a particular
version of the component.

Therefore, SCM is the discipline which

o Identify change
o Monitor and control change
o Ensure the proper implementation of change made to the item.
o Auditing and reporting on the change made.

Configuration Management (CM) is a technic of identifying, organizing, and controlling

modification to software being built by a programming team.
The objective is to maximize productivity by minimizing mistakes (errors).

CM is used to essential due to the inventory management, library management, and updation
management of the items essential for the project.

Why do we need Configuration Management?

Multiple people are working on software which is consistently updating. It may be a method
where multiple version, branches, authors are involved in a software project, and the team is
geographically distributed and works concurrently. It changes in user requirements, and policy,
budget, schedules need to be accommodated.

Importance of SCM

It is practical in controlling and managing the access to various SCIs e.g., by preventing the two
members of a team for checking out the same component for modification at the same time.

It provides the tool to ensure that changes are being properly implemented.

It has the capability of describing and storing the various constituent of software.

SCM is used in keeping a system in a consistent state by automatically producing derived

version upon modification of the same component.

SCM Process

It uses the tools which keep that the necessary change has been implemented adequately to the
appropriate component. The SCM process defines a number of tasks:

o Identification of objects in the software configuration

o Version Control
o Change Control
o Configuration Audit
o Status Reporting
Identification

Basic Object: Unit of Text created by a software engineer during analysis, design, code, or test.

Aggregate Object: A collection of essential objects and other aggregate objects. Design
Specification is an aggregate object.

Each object has a set of distinct characteristics that identify it uniquely: a name, a description, a
list of resources, and a "realization."

The interrelationships between configuration objects can be described with a Module

Interconnection Language (MIL).

Version Control

Version Control combines procedures and tools to handle different version of configuration
objects that are generated during the software process.

Clemm defines version control in the context of SCM: Configuration management allows a
user to specify the alternative configuration of the software system through the selection of
appropriate versions. This is supported by associating attributes with each software version, and
then allowing a configuration to be specified [and constructed] by describing the set of desired
attributes.
Change Control

James Bach describes change control in the context of SCM is: Change Control is Vital. But the
forces that make it essential also make it annoying.

We worry about change because a small confusion in the code can create a big failure in the
product. But it can also fix a significant failure or enable incredible new capabilities.

We worry about change because a single rogue developer could sink the project, yet brilliant
ideas originate in the mind of those rogues, and

A burdensome change control process could effectively discourage them from doing creative
work.

A change request is submitted and calculated to assess technical merit; potential side effects, the
overall impact on other configuration objects and system functions, and projected cost of the
change.

The results of the evaluations are presented as a change report, which is used by a change control
authority (CCA) - a person or a group who makes a final decision on the status and priority of
the change.

The "check-in" and "check-out" process implements two necessary elements of change control-
access control and synchronization control.

Access Control governs which software engineers have the authority to access and modify a
particular configuration object.

Synchronization Control helps to ensure that parallel changes, performed by two different
people, don't overwrite one another.

Configuration Audit

SCM audits to verify that the software product satisfies the baselines requirements and ensures
that what is built and what is delivered.

SCM audits also ensure that traceability is maintained between all CIs and that all work requests
are associated with one or more CI modification.

SCM audits are the "watchdogs" that ensures that the integrity of the project's scope is
preserved.

Status Reporting

Configuration Status reporting (sometimes also called status accounting) providing accurate
status and current configuration data to developers, testers, end users, customers and
stakeholders through admin guides, user guides, FAQs, Release Notes, Installation Guide,
Configuration Guide, etc.

Software Quality Assurance

What is Quality?

Quality defines to any measurable characteristics such as correctness, maintainability,

portability, testability, usability, reliability, efficiency, integrity, reusability, and interoperability.

There are two kinds of Quality:

Quality of Design: Quality of Design refers to the characteristics that designers specify for an
item. The grade of materials, tolerances, and performance specifications that all contribute to the
quality of design.

Quality of conformance: Quality of conformance is the degree to which the design

specifications are followed during manufacturing. Greater the degree of conformance, the higher
is the level of quality of conformance.

Software Quality: Software Quality is defined as the conformance to explicitly state functional
and performance requirements, explicitly documented development standards, and inherent
characteristics that are expected of all professionally developed software.

Quality Control: Quality Control involves a series of inspections, reviews, and tests used
throughout the software process to ensure each work product meets the requirements place upon
it. Quality control includes a feedback loop to the process that created the work product.

Quality Assurance: Quality Assurance is the preventive set of activities that provide greater
confidence that the project will be completed successfully.

Quality Assurance focuses on how the engineering and management activity will be done?
As anyone is interested in the quality of the final product, it should be assured that we are
building the right product.

It can be assured only when we do inspection & review of intermediate products, if there are any
bugs, then it is debugged. This quality can be enhanced.

Importance of Quality

We would expect the quality to be a concern of all producers of goods and services. However,
the distinctive characteristics of software and in particular its intangibility and complexity, make
special demands.

Increasing criticality of software: The final customer or user is naturally concerned about the
general quality of software, especially its reliability. This is increasing in the case as
organizations become more dependent on their computer systems and software is used more and
more in safety-critical areas. For example, to control aircraft.

The intangibility of software: This makes it challenging to know that a particular task in a
project has been completed satisfactorily. The results of these tasks can be made tangible by
demanding that the developers produce 'deliverables' that can be examined for quality.

Accumulating errors during software development: As computer system development is

made up of several steps where the output from one level is input to the next, the errors in the
earlier ?deliverables? will be added to those in the later stages leading to accumulated
determinable effects. In general the later in a project that an error is found, the more expensive it
will be to fix. In addition, because the number of errors in the system is unknown, the debugging
phases of a project are particularly challenging to control.

Software Quality Assurance

Software quality assurance is a planned and systematic plan of all actions necessary to provide
adequate confidence that an item or product conforms to establish technical requirements.

A set of activities designed to calculate the process by which the products are developed or
manufactured.

SQA Encompasses

o A quality management approach

o Effective Software engineering technology (methods and tools)
o Formal technical reviews that are tested throughout the software process
o A multitier testing strategy
o Control of software documentation and the changes made to it.
o A procedure to ensure compliances with software development standards
 o Measuring and reporting mechanisms.

SQA Activities

Software quality assurance is composed of a variety of functions associated with two different
constituencies ? the software engineers who do technical work and an SQA group that has
responsibility for quality assurance planning, record keeping, analysis, and reporting.

Following activities are performed by an independent SQA group:

1. Prepares an SQA plan for a project: The program is developed during project planning
and is reviewed by all stakeholders. The plan governs quality assurance activities
performed by the software engineering team and the SQA group. The plan identifies
calculation to be performed, audits and reviews to be performed, standards that apply to
the project, techniques for error reporting and tracking, documents to be produced by the
SQA team, and amount of feedback provided to the software project team.
2. Participates in the development of the project's software process description: The
software team selects a process for the work to be performed. The SQA group reviews
the process description for compliance with organizational policy, internal software
standards, externally imposed standards (e.g. ISO-9001), and other parts of the software
project plan.
3. Reviews software engineering activities to verify compliance with the defined
software process: The SQA group identifies, reports, and tracks deviations from the
process and verifies that corrections have been made.
4. Audits designated software work products to verify compliance with those defined
as a part of the software process: The SQA group reviews selected work products,
identifies, documents and tracks deviations, verify that corrections have been made, and
periodically reports the results of its work to the project manager.
5. Ensures that deviations in software work and work products are documented and
handled according to a documented procedure: Deviations may be encountered in the
project method, process description, applicable standards, or technical work products.
6. Records any noncompliance and reports to senior management: Non- compliance
items are tracked until they are resolved.

Quality Assurance v/s Quality control

 Quality Assurance Quality Control

Quality Assurance (QA) is the set of

Quality Control (QC) is described
actions including facilitation, training,
as the processes and methods used to
measurement, and analysis needed to
compare product quality to
provide adequate confidence that processes
requirements and applicable
are established and continuously improved
standards, and the actions are taken
to produce products or services that
when a nonconformance is detected.
conform to specifications and are fit for use.

QA is an activity that establishes and

QC is an activity that demonstrates
calculates the processes that produce the
whether or not the product produced
product. If there is no process, there is no
met standards.
role for QA.

QC relates to a particular product or

QA helps establish process
service

QC verified whether particular

QA sets up a measurement program to
attributes exist, or do not exist, in a
evaluate processes
explicit product or service.

QA identifies weakness in processes and QC identifies defects for the primary

improves them goals of correcting errors.

Quality Assurance is a managerial tool. Quality Control is a corrective tool.

Verification is an example of QA. Validation is an example of QC.

Project Monitoring and Control

Monitoring and Controlling are processes needed to track, review, and regulate the progress and
performance of the project. It also identifies any areas where changes to the project management
method are required and initiates the required changes.

The Monitoring & Controlling process group includes eleven processes, which are:
1. Monitor and control project work: The generic step under which all other monitoring
and controlling activities fall under.
2. Perform integrated change control: The functions involved in making changes to the
project plan. When changes to the schedule, cost, or any other area of the project
management plan are necessary, the program is changed and re-approved by the project
sponsor.
3. Validate scope: The activities involved with gaining approval of the project's
deliverables.
4. Control scope: Ensuring that the scope of the project does not change and that
unauthorized activities are not performed as part of the plan (scope creep).
5. Control schedule: The functions involved with ensuring the project work is performed
according to the schedule, and that project deadlines are met.
6. Control costs: The tasks involved with ensuring the project costs stay within the
approved budget.
7. Control quality: Ensuring that the quality of the project?s deliverables is to the standard
defined in the project management plan.
8. Control communications: Providing for the communication needs of each project
stakeholder.
9. Control Risks: Safeguarding the project from unexpected events that negatively impact
the project's budget, schedule, stakeholder needs, or any other project success criteria.
10. Control procurements: Ensuring the project's subcontractors and vendors meet the
project goals.
11. Control stakeholder engagement: The tasks involved with ensuring that all of the
project's stakeholders are left satisfied with the project work.
Software Metrics
A software metric is a measure of software characteristics which are measurable or countable.
Software metrics are valuable for many reasons, including measuring software performance,
planning work items, measuring productivity, and many other uses.

Within the software development process, many metrics are that are all connected. Software
metrics are similar to the four functions of management: Planning, Organization, Control, or
Improvement.

Classification of Software Metrics

Software metrics can be classified into two types as follows:

1. Product Metrics: These are the measures of various characteristics of the software product.
The two important software characteristics are:

1. Size and complexity of software.

2. Quality and reliability of software.

These metrics can be computed for different stages of SDLC.

2. Process Metrics: 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.
Types of Metrics

Internal metrics: Internal metrics are the metrics used for measuring properties that are viewed
to be of greater importance to a software developer. For example, Lines of Code (LOC) measure.

External metrics: External metrics are the metrics used for measuring properties that are viewed
to be of greater importance to the user, e.g., portability, reliability, functionality, usability, etc.

Hybrid metrics: Hybrid metrics are the metrics that combine product, process, and resource
metrics. For example, cost per FP where FP stands for Function Point Metric.

Project metrics: Project metrics are the metrics used by the project manager to check the
project's progress. Data from the past projects are used to collect various metrics, like time and
cost; these estimates are used as a base of new software. Note that as the project proceeds, the
project manager will check its progress from time-to-time and will compare the effort, cost, and
time with the original effort, cost and time. Also understand that these metrics are used to
decrease the development costs, time efforts and risks. The project quality can also be improved.
As quality improves, the number of errors and time, as well as cost required, is also reduced.

Advantage of Software Metrics

 Comparative study of various design methodology of software systems.

 For analysis, comparison, and critical study of different programming language
concerning their characteristics.
 In comparing and evaluating the capabilities and productivity of people involved in
software development.
 In the preparation of software quality specifications.
 In the verification of compliance of software systems requirements and specifications.
 In making inference about the effort to be put in the design and development of the
software systems.
 In getting an idea about the complexity of the code.
 In taking decisions regarding further division of a complex module is to be done or not.
 In guiding resource manager for their proper utilization.
 In comparison and making design tradeoffs between software development and
maintenance cost.
 In providing feedback to software managers about the progress and quality during various
phases of the software development life cycle.
 In the allocation of testing resources for testing the code.

Disadvantage of Software Metrics

 The application of software metrics is not always easy, and in some cases, it is difficult
and costly.
 The verification and justification of software metrics are based on historical/empirical
data whose validity is difficult to verify.
 These are useful for managing software products but not for evaluating the performance
of the technical staff.
 The definition and derivation of Software metrics are usually based on assuming which
are not standardized and may depend upon tools available and working environment.

Size Oriented Metrics

 LOC Metrics

It is one of the earliest and simpler metrics for calculating the size of the computer program. It is
generally used in calculating and comparing the productivity of programmers. These metrics are
derived by normalizing the quality and productivity measures by considering the size of the
product as a metric.

Following are the points regarding LOC measures:

1. In size-oriented metrics, LOC is considered to be the normalization value.

 2. It is an older method that was developed when FORTRAN and COBOL programming
were very popular.
3. Productivity is defined as KLOC / EFFORT, where effort is measured in person-months.
4. Size-oriented metrics depend on the programming language used.
5. As productivity depends on KLOC, so assembly language code will have more
productivity.
6. LOC measure requires a level of detail which may not be practically achievable.
7. The more expressive is the programming language, the lower is the productivity.
8. LOC method of measurement does not apply to projects that deal with visual (GUI-
based) programming. As already explained, Graphical User Interfaces (GUIs) use forms
basically. LOC metric is not applicable here.
9. It requires that all organizations must use the same method for counting LOC. This is so
because some organizations use only executable statements, some useful comments, and
some do not. Thus, the standard needs to be established.
10. These metrics are not universally accepted.

Based on the LOC/KLOC count of software, many other metrics can be computed:

a. Errors/KLOC.
b. $/ KLOC.
c. Defects/KLOC.
d. Pages of documentation/KLOC.
e. Errors/PM.
f. Productivity = KLOC/PM (effort is measured in person-months).
g. $/ Page of documentation.

Advantages of LOC

1. Simple to measure

Disadvantage of LOC

1. It is defined on the code. For example, it cannot measure the size of the specification.
2. It characterizes only one specific view of size, namely length, it takes no account of
functionality or complexity
3. Bad software design may cause an excessive line of code
4. It is language dependent
5. Users cannot easily understand it
Halstead's Software Metrics

According to Halstead's "A computer program is an implementation of an algorithm considered

to be a collection of tokens which can be classified as either operators or operand."

Token Count

In these metrics, a computer program is considered to be a collection of tokens, which may be

classified as either operators or operands. All software science metrics can be defined in terms of
these basic symbols. These symbols are called as a token.

The basic measures are

n1 = count of unique operators.

n2 = count of unique operands.
N1 = count of total occurrences of operators.
N2 = count of total occurrence of operands.

In terms of the total tokens used, the size of the program can be expressed as N = N1 + N2.

Halstead metrics are:

Program Volume (V)

The unit of measurement of volume is the standard unit for size "bits." It is the actual size of a
program if a uniform binary encoding for the vocabulary is used.

V=N*log2n

Program Level (L)

The value of L ranges between zero and one, with L=1 representing a program written at the
highest possible level (i.e., with minimum size).

L=V*/V

Program Difficulty

The difficulty level or error-proneness (D) of the program is proportional to the number of the
unique operator in the program.

D= (n1/2) * (N2/n2)

Programming Effort (E)

The unit of measurement of E is elementary mental discriminations.

 E=V/L=D*V

Estimated Program Length

According to Halstead, The first Hypothesis of software science is that the length of a well-
structured program is a function only of the number of unique operators and operands.

N=N1+N2

And estimated program length is denoted by N^

N^ = n1log2n1 + n2log2n2

The following alternate expressions have been published to estimate program length:

o NJ = log2 (n1!) + log2 (n2!)

o NB = n1 * log2n2 + n2 * log2n1
o NC = n1 * sqrt(n1) + n2 * sqrt(n2)
o NS = (n * log2n) / 2

Potential Minimum Volume

The potential minimum volume V* is defined as the volume of the most short program in which
a problem can be coded.

V* = (2 + n2*) * log2 (2 + n2*)

Here, n2* is the count of unique input and output parameters

Size of Vocabulary (n)

The size of the vocabulary of a program, which consists of the number of unique tokens used to
build a program, is defined as:

n=n1+n2

where

n=vocabulary of a program
n1=number of unique operators
n2=number of unique operands

Language Level - Shows the algorithm implementation program language level. The same
algorithm demands additional effort if it is written in a low-level program language. For
example, it is easier to program in Pascal than in Assembler.
 L' = V / D / D
lambda = L * V* = L2 * V

Extended Function Point (EFP) Metrics

FP metric has been further extended to compute:

a. Feature points.
b. 3D function points.

Feature Points

1. Feature point is the superset of function point measure that can be applied to systems and
engineering software applications.
2. The feature points are used in those applications in which the algorithmic complexity is
high like real-time systems where time constraints are there, embedded systems, etc.
3. Feature points are computed by counting the information domain values and are weighed
by only single weight.
4. Feature point includes another measurement parameter-ALGORITHM.
5. The table for the computation of feature point is as follows:

Data Structure Metrics

Essentially the need for software development and other activities are to process data. Some data
is input to a system, program or module; some data may be used internally, and some data is the
output from a system, program, or module.

Example:
Program Data Input Internal Data Data

Payroll Name/Social Security No./Pay rate/Number Withholding rates Overtime Factors Gross
of hours worked Insurance Premium Rates Pay P

Spreadsheet Item Names/Item Amounts/Relationships Cell computations Subtotal Sprea

among Items totals

Software Program Size/No of Software developer on Model Parameter Constants Coefficients Est. p
Planner team durat
That's why an important set of metrics which capture in the amount of data input, processed in an
output form software. A count of this data structure is called Data Structured Metrics. In these
concentrations is on variables (and given constant) within each module & ignores the input-
output dependencies.

There are some Data Structure metrics to compute the effort and time required to complete the
project. There metrics are:

1. The Amount of Data.

2. The Usage of data within a Module.
3. Program weakness.
4. The sharing of Data among Modules.

1. The Amount of Data: To measure the amount of Data, there are further many different
metrics, and these are:

o Number of variable (VARS): In this metric, the Number of variables used in the
program is counted.
o Number of Operands (η2): In this metric, the Number of operands used in the program
is counted.
η2 = VARS + Constants + Labels
o Total number of occurrence of the variable (N2): In this metric, the total number of
occurrence of the variables are computed

2. The Usage of data within a Module: The measure this metric, the average numbers of live
variables are computed. A variable is live from its first to its last references within the procedure.

3. Program weakness: Program weakness depends on its Modules weakness. If Modules are
weak(less Cohesive), then it increases the effort and time metrics required to complete the
project.

Module Weakness (WM) = LV* γ

A program is normally a combination of various modules; hence, program weakness can be a

useful measure and is defined as:
Where

WMi: Weakness of the ith module

WP: Weakness of the program

m: No of modules in the program

[Link] Sharing of Data among Module: As the data sharing between the Modules increases
(higher Coupling), no parameter passing between Modules also increased, As a result, more
effort and time are required to complete the project. So Sharing Data among Module is an
important metrics to calculate effort and time.
Information Flow Metrics

The other set of metrics we would live to consider are known as Information Flow Metrics. The
basis of information flow metrics is found upon the following concept the simplest system
consists of the component, and it is the work that these components do and how they are fitted
together that identify the complexity of the system. The following are the working definitions
that are used in Information flow:
Component: Any element identified by decomposing a (software) system into it's constituent's
parts.

Cohesion: The degree to which a component performs a single function.

Coupling: The term used to describe the degree of linkage between one component to others in
the same system.

Information Flow metrics deal with this type of complexity by observing the flow of information
among system components or modules. This metrics is given by Henry and Kafura. So it is also
known as Henry and Kafura's Metric.

This metrics is based on the measurement of the information flow among system modules. It is
sensitive to the complexity due to interconnection among system component. This measure
includes the complexity of a software module is defined to be the sum of complexities of the
procedures included in the module. A process contributes complexity due to the following two
factors.

1. The complexity of the procedure code itself.

2. The complexity due to the procedure's connections to its environment. The effect of the
first factor has been included through LOC (Line Of Code) measure. For the
quantification of the second factor, Henry and Kafura have defined two terms, namely
FAN-IN and FAN-OUT.

FAN-IN: FAN-IN of a procedure is the number of local flows into that procedure plus the
number of data structures from which this procedure retrieve information.

FAN -OUT: FAN-OUT is the number of local flows from that procedure plus the number of
data structures which that procedure updates.
Cyclomatic Complexity

Cyclomatic complexity is a software metric used to measure the complexity of a program.

Thomas J. McCabe developed this metric in [Link] interprets a computer program as a
set of a strongly connected directed graph. Nodes represent parts of the source code having no
branches and arcs represent possible control flow transfers during program execution. The notion
of program graph has been used for this measure, and it is used to measure and control the
number of paths through a program. The complexity of a computer program can be correlated
with the topological complexity of a graph.

Example:

Properties of Cyclomatic complexity:

Following are the properties of Cyclomatic complexity:

1. V (G) is the maximum number of independent paths in the graph

2. V (G) >=1
3. G will have one path if V (G) = 1
4. Minimize complexity to 10

Case Tools For Software Metrics

Many CASE tools (Computer Aided Software Engineering tools) exist for measuring software.
They are either open source or are paid tools. Some of them are listed below:

1. Analyst4j tool is based on the Eclipse platform and available as a stand-alone Rich
Client Application or as an Eclipse IDE plug-in. It features search, metrics, analyzing
quality, and report generation for Java programs.
2. CCCC is an open source command-line tool. It analyzes C++ and Java lines and
generates reports on various metrics, including Lines of Code and metrics proposed by
Chidamber & Kemerer and Henry & Kafura.
3. Chidamber & Kemerer Java Metrics is an open source command-line tool. It
calculates the C&K object-oriented metrics by processing the byte-code of compiled
Java.
4. Dependency Finder is an open source. It is a suite of tools for analyzing compiled Java
code. Its core is a dependency analysis application that extracts dependency graphs and
mines them for useful information. This application comes as a command-line tool, a
Swing-based application, and a web application.
5. Eclipse Metrics Plug-in 1.3.6 by Frank Sauer is an open source metrics calculation and
dependency analyzer plugin for the Eclipse IDE. It measures various metrics and detects
cycles in package and type dependencies.
6. Eclipse Metrics Plug-in 3.4 by Lance Walton is open source. It calculates various
metrics during build cycles and warns, via the problems view, of metrics 'range
violations'.
7. OOMeter is an experimental software metrics tool developed by Alghamdi. It accepts
Java/C# source code and UML models in XMI and calculates various metrics.
8. Semmle is an Eclipse plug-in. It provides an SQL like querying language for object-
oriented code, which allows searching for bugs, measure code metrics, etc.
9. Project Management Tools
10. To manage the Project management system adequately and efficiently, we use Project
management tools.
Here are some standard tools:
11. Gantt chart
12. Gantt Chart first developed by Henry Gantt in 1917. Gantt chart usually utilized in
project management, and it is one of the most popular and helpful ways of showing
activities displayed against time. Each activity represented by a bar.
13. Gantt chart is a useful tool when you want to see the entire landscape of either one or
multiple projects. It helps you to view which tasks are dependent on one another and
which event is coming up.
14. PERT chart

15. PERT is an acronym of Programme Evaluation Review Technique. In the 1950s, it is

developed by the U.S. Navy to handle the Polaris submarine missile programme.
16. In Project Management, PERT chart represented as a network diagram concerning the
number of nodes, which represents events.
17. The direction of the lines indicates the sequence of the task. In the above example, tasks
between "Task 1 to Task 9" must complete, and these are known as a dependent or serial
task. Between Task 4 and 5, and Task 4 and 6, nodes are not depended and can undertake
simultaneously. These are known as Parallel or concurrent tasks. Without resource or
completion time, the task must complete in the sequence which is considered as event
dependency, and these are known as Dummy activity and represented by dotted lines.
18. Logic Network
19. The Logic Network shows the order of activities over time. It shows the sequence in
which activities are to do. Distinguishing events and pinning down the project are the two
 primary uses. Moreover, it will help with understanding task dependencies, a timescale,
and overall project workflow.
20. Product Breakdown Structure

21.
22. Product Breakdown Structure (BBS) is a management tool and necessary a part of the
project designing. It's a task-oriented system for subdividing a project into product parts.
The product breakdown structure describes subtasks or work packages and represents the
connection between work packages. Within the product breakdown Structure, the project
work has diagrammatically pictured with various types of lists. The product breakdown
structure is just like the work breakdown structure (WBS).
23. Work Breakdown Structure
24. It is an important project deliverable that classifies the team's work into flexible
segments. "Project Management Body of Knowledge (PMBOK)" is a group of
terminology that describes the work breakdown structure as a "deliverable-oriented
hierarchical breakdown of the work which is performed by the project team."
25. There are two ways to generate a Work Breakdown Structure ? The top-down and
26. The bottom-up approach.
27. In the top-down approach, the WBS derived by crumbling the overall project into
subprojects or lower-level tasks.
28. The bottom-up approach is more alike to a brainstorming exercise where team members
are asked to make a list of low-level tasks which is required to complete the project.
29. Resource Histogram
30. The resource histogram is precisely a bar chart that used for displaying the amounts of
time that a resource is scheduled to be worked on over a prearranged and specific period.
Resource histograms can also contain the related feature of resource availability, used for
comparison on purposes of contrast.
31. Critical Path Analysis
32. Critical path analysis is a technique that is used to categorize the activities which are
required to complete a task, as well as classifying the time which is needed to finish each
 activity and the relationships between the activities. It is also called a critical path
method. CPA helps in predicting whether a project will expire on time.

Software Project Planning

A Software Project is the complete methodology of programming advancement from

requirement gathering to testing and support, completed by the execution procedures, in a
specified period to achieve intended software product.

Need of Software Project Management

Software development is a sort of all new streams in world business, and there's next to no
involvement in structure programming items. Most programming items are customized to
accommodate customer's necessities. The most significant is that the underlying technology
changes and advances so generally and rapidly that experience of one element may not be
connected to the other one. All such business and ecological imperatives bring risk in software
development; hence, it is fundamental to manage software projects efficiently.

Software Project Manager

Software manager is responsible for planning and scheduling project development. They manage
the work to ensure that it is completed to the required standard. They monitor the progress to
check that the event is on time and within budget. The project planning must incorporate the
major issues like size & cost estimation scheduling, project monitoring, personnel selection
evaluation & risk management. To plan a successful software project, we must understand:

o Scope of work to be completed

o Risk analysis
o The resources mandatory
o The project to be accomplished
o Record of being followed

Software Project planning starts before technical work start. The various steps of planning
activities are:
The size is the crucial parameter for the estimation of other activities. Resources requirement are
required based on cost and development time. Project schedule may prove to be very useful for
controlling and monitoring the progress of the project. This is dependent on resources &
development time.

Software Cost Estimation

For any new software project, it is necessary to know how much it will cost to develop and how
much development time will it take. These estimates are needed before development is initiated,
but how is this done? Several estimation procedures have been developed and are having the
following attributes in common.

1. Project scope must be established in advanced.

2. Software metrics are used as a support from which evaluation is made.
3. The project is broken into small PCs which are estimated individually.
To achieve true cost & schedule estimate, several option arise.
4. Delay estimation
5. Used symbol decomposition techniques to generate project cost and schedule estimates.
6. Acquire one or more automated estimation tools.

Uses of Cost Estimation

1. During the planning stage, one needs to choose how many engineers are required for the
project and to develop a schedule.
 2. In monitoring the project's progress, one needs to access whether the project is
progressing according to the procedure and takes corrective action, if necessary.

Cost Estimation Models

A model may be static or dynamic. In a static model, a single variable is taken as a key element
for calculating cost and time. In a dynamic model, all variable are interdependent, and there is no
basic variable.

Static, Single Variable Models: When a model makes use of single variables to calculate
desired values such as cost, time, efforts, etc. is said to be a single variable model. The most
common equation is:

C=aLb

Where C=Costs
L=size
a and b are constants

Static, Multivariable Models: These models are based on method (1), they depend on several
variables describing various aspects of the software development environment. In some model,
several variables are needed to describe the software development process, and selected equation
combined these variables to give the estimate of time & cost. These models are called
multivariable models.

The necessary steps in this model are:

1. Get an initial estimate of the development effort from evaluation of thousands of

delivered lines of source code (KDLOC).
2. Determine a set of 15 multiplying factors from various attributes of the project.
3. Calculate the effort estimate by multiplying the initial estimate with all the multiplying
factors i.e., multiply the values in step1 and step2.
The initial estimate (also called nominal estimate) is determined by an equation of the form used
in the static single variable models, using KDLOC as the measure of the size. To determine the
initial effort Ei in person-months the equation used is of the type is shown below

Ei=a*(KDLOC)b

The value of the constant a and b are depends on the project type.

In COCOMO, projects are categorized into three types:

1. Organic
2. Semidetached
3. Embedded

[Link]: A development project can be treated of the organic type, if the project deals with
developing a well-understood application program, the size of the development team is
reasonably small, and the team members are experienced in developing similar methods of
projects. Examples of this type of projects are simple business systems, simple inventory
management systems, and data processing systems.

2. Semidetached: A development project can be treated with semidetached type if the

development consists of a mixture of experienced and inexperienced staff. Team members may
have finite experience in related systems but may be unfamiliar with some aspects of the order
being developed. Example of Semidetached system includes developing a new operating
system (OS), a Database Management System (DBMS), and complex inventory
management system.

3. Embedded: A development project is treated to be of an embedded type, if the software being

developed is strongly coupled to complex hardware, or if the stringent regulations on the
operational method exist. For Example: ATM, Air Traffic control.

For three product categories, Bohem provides a different set of expression to predict effort (in a
unit of person month)and development time from the size of estimation in KLOC(Kilo Line of
code) efforts estimation takes into account the productivity loss due to holidays, weekly off,
coffee breaks, etc.

The Six phases of detailed COCOMO Model are:

1. Planning and requirements

2. System structure
3. Complete structure
4. Module code and test
 5. Integration and test
6. Cost Constructive model

The effort is determined as a function of program estimate, and a set of cost drivers are given
according to every phase of the software lifecycle.

What is Risk?

"Tomorrow problems are today's risk." Hence, a clear definition of a "risk" is a problem that
could cause some loss or threaten the progress of the project, but which has not happened yet.

These potential issues might harm cost, schedule or technical success of the project and the
quality of our software device, or project team morale.

Risk Management is the system of identifying addressing and eliminating these problems before
they can damage the project.

We need to differentiate risks, as potential issues, from the current problems of the project.

Different methods are required to address these two kinds of issues.

For example, staff storage, because we have not been able to select people with the right
technical skills is a current problem, but the threat of our technical persons being hired away by
the competition is a risk.

Risk Management

A software project can be concerned with a large variety of risks. In order to be adept to
systematically identify the significant risks which might affect a software project, it is essential
to classify risks into different classes. The project manager can then check which risks from each
class are relevant to the project.

There are three main classifications of risks which can affect a software project:

1. Project risks
2. Technical risks
3. Business risks

1. Project risks: Project risks concern differ forms of budgetary, schedule, personnel, resource,
and customer-related problems. A vital project risk is schedule slippage. Since the software is
intangible, it is very tough to monitor and control a software project. It is very tough to control
something which cannot be identified. For any manufacturing program, such as the
manufacturing of cars, the plan executive can recognize the product taking shape.
2. Technical risks: Technical risks concern potential method, implementation, interfacing,
testing, and maintenance issue. It also consists of an ambiguous specification, incomplete
specification, changing specification, technical uncertainty, and technical obsolescence. Most
technical risks appear due to the development team's insufficient knowledge about the project.

3. Business risks: This type of risks contain risks of building an excellent product that no one
need, losing budgetary or personnel commitments, etc.

Other risk categories

1. 1. Known risks: Those risks that can be uncovered after careful assessment of the project
program, the business and technical environment in which the plan is being developed,
and more reliable data sources (e.g., unrealistic delivery date)
2. 2. Predictable risks: Those risks that are hypothesized from previous project experience
(e.g., past turnover)
3. 3. Unpredictable risks: Those risks that can and do occur, but are extremely tough to
identify in advance.

Principle of Risk Management

1. Global Perspective: In this, we review the bigger system description, design, and
implementation. We look at the chance and the impact the risk is going to have.
2. Take a forward-looking view: Consider the threat which may appear in the future and
create future plans for directing the next events.
3. Open Communication: This is to allow the free flow of communications between the
client and the team members so that they have certainty about the risks.
4. Integrated management: In this method risk management is made an integral part of
project management.
5. Continuous process: In this phase, the risks are tracked continuously throughout the risk
management paradigm.

Risk Management Activities

Risk management consists of three main activities, as shown in fig:
Risk Assessment

The objective of risk assessment is to division the risks in the condition of their loss, causing
potential. For risk assessment, first, every risk should be rated in two methods:

o The possibility of a risk coming true (denoted as r).

o The consequence of the issues relates to that risk (denoted as s).

Based on these two methods, the priority of each risk can be estimated:

p=r*s

Where p is the priority with which the risk must be controlled, r is the probability of the risk
becoming true, and s is the severity of loss caused due to the risk becoming true. If all identified
risks are set up, then the most likely and damaging risks can be controlled first, and more
comprehensive risk abatement methods can be designed for these risks.

1. Risk Identification: The project organizer needs to anticipate the risk in the project as early
as possible so that the impact of risk can be reduced by making effective risk management
planning.

A project can be of use by a large variety of risk. To identify the significant risk, this might
affect a project. It is necessary to categories into the different risk of classes.
There are different types of risks which can affect a software project:

1. Technology risks: Risks that assume from the software or hardware technologies that are
used to develop the system.
2. People risks: Risks that are connected with the person in the development team.
3. Organizational risks: Risks that assume from the organizational environment where the
software is being developed.
4. Tools risks: Risks that assume from the software tools and other support software used to
create the system.
5. Requirement risks: Risks that assume from the changes to the customer requirement and
the process of managing the requirements change.
6. Estimation risks: Risks that assume from the management estimates of the resources
required to build the system

2. Risk Analysis: During the risk analysis process, you have to consider every identified risk and
make a perception of the probability and seriousness of that risk.

There is no simple way to do this. You have to rely on your perception and experience of
previous projects and the problems that arise in them.

It is not possible to make an exact, the numerical estimate of the probability and seriousness of
each risk. Instead, you should authorize the risk to one of several bands:

1. The probability of the risk might be determined as very low (0-10%), low (10-25%),
moderate (25-50%), high (50-75%) or very high (+75%).
2. The effect of the risk might be determined as catastrophic (threaten the survival of the
plan), serious (would cause significant delays), tolerable (delays are within allowed
contingency), or insignificant.

Risk Control

It is the process of managing risks to achieve desired outcomes. After all, the identified risks of a
plan are determined; the project must be made to include the most harmful and the most likely
risks. Different risks need different containment methods. In fact, most risks need ingenuity on
the part of the project manager in tackling the risk.

There are three main methods to plan for risk management:

1. Avoid the risk: This may take several ways such as discussing with the client to change
the requirements to decrease the scope of the work, giving incentives to the engineers to
avoid the risk of human resources turnover, etc.
 2. Transfer the risk: This method involves getting the risky element developed by a third
party, buying insurance cover, etc.
3. Risk reduction: This means planning method to include the loss due to risk. For
instance, if there is a risk that some key personnel might leave, new recruitment can be
planned.

Risk Leverage: To choose between the various methods of handling risk, the project plan must
consider the amount of controlling the risk and the corresponding reduction of risk. For this, the
risk leverage of the various risks can be estimated.

Risk leverage is the variation in risk exposure divided by the amount of reducing the risk.

Risk leverage = (risk exposure before reduction - risk exposure after reduction) / (cost of
reduction)

1. Risk planning: The risk planning method considers each of the key risks that have been
identified and develop ways to maintain these risks.

For each of the risks, you have to think of the behavior that you may take to minimize the
disruption to the plan if the issue identified in the risk occurs.

You also should think about data that you might need to collect while monitoring the plan so that
issues can be anticipated.

Again, there is no easy process that can be followed for contingency planning. It rely on the
judgment and experience of the project manager.

3. Risk Monitoring: Risk monitoring is the method king that your assumption about the
product, process, and business risks has not changed.

Role of Risk Management in Overall Project Management

The Importance of Risk Management in Project Management

Risk management affects the essential factors to the success of your project such as your
schedule, the scope, budget, communications, stakeholder engagement, agreed quality of the
deliverables, and more. When an unforeseen event happens and there is no risk planning that has
been done, it is difficult to manage the situation and might contribute to the failure of the project.

Although risks are generally known as negative, they can also be opportunities for the project
team to grow by learning more from the experience.

There is no assurance that these possible events or risks will happen and if they will, they can
happen any time. There is a need to identify these risks, discuss and monitor on them, as well as
involve everyone.
It is important that all team members learn everything in managing risks and estimate when they
could possibly happen. They must agree on the strategies to do for every risk and undertake
actions to prevent negative events from happening.

Project risk management is not just developing the plan, recording these risk strategies on file
and sharing it occasionally. Risk management is an undertaking wherein it is important that
members know how to deal with them when they happen.

To manage these project risks, the procedure always starts with planning then identifying the
possible risks that might happen. The next step is to perform qualitative and quantitative risk
analysis. Plan how to respond when they happen and when they do, always monitor to control
them.

Effective risk management strategies allow you to identify your project’s strengths, weaknesses,
opportunities and threats. By planning for unexpected events, you can be ready to respond if they
arise. To ensure your project’s success, define how you will handle potential risks so you can
identify, mitigate or avoid problems when you need to do. Successful project managers
recognize that risk management is important, because achieving a project’s goals depends on
planning, preparation, results and evaluation that contribute to achieving strategic goals.

(i) Planning for Success: Risk management plans contribute to project success by establishing a
list of internal and external risks. This plan typically includes the identified risks, probability of
occurrence, potential impact and proposed actions. Low risk events usually have little or no
impact on cost, schedule or performance. Moderate risk causes some increase in cost, disruption
of schedule or degradation of performance. High risk events are likely to cause a significant
increase in the budget, disruption of the schedule or performance problems.

(ii) Communicating with Stakeholders: To ensure that projects run smoothly, effective project
managers communicate their plan to the project sponsors, stakeholders and team members. This
sets expectations to people who provide funding and are affected by the outcomes. It ensures that
the project runs smoothly so one step proceeds to the next without disruption. By identifying,
avoiding and dealing with potential risks in advance, you ensure that your employees can
respond effectively when challenges emerge and require intervention.

(iii) Maximizes Results and Meet Deadlines: By defining risk management processes for your
company, you make success more likely by minimizing and eliminating negative risks so
projects can be finished on time. This enables you to meet your budget and fulfill targeted
objectives. When you don’t have risk management strategies in place, your projects get exposed
to problems and become vulnerable. Effective risk management strategies allow your company
to maximize profits and minimize expenses on activities that don’t produce a return on
investment. Through detailed analysis, effective leaders prioritize ongoing work based on the
results produced, despite the odds.

(iv) Be Proactive Not Reactive: Having a risk management plan in place allow you to be
proactive and take steps to mitigate possible harms before they arise, instead of constantly fire
fighting. The project team can take the risk that have been identified and convert them to
actionable steps that will reduce likelihood. Those steps then become contingency plans that
hopefully can be aside. Should a risk event occur, the contingency plan can be whipped out
quickly, reducing the downtime on a project.

(v) Evaluates the Entire Project: To evaluate your project’s success so you can use the best
practices on your next project, assess the impact of your activities on mitigating exposure to
problems and exploiting opportunities that capitalize on your company’s strengths. For example,
if you develop and deliver a training program that creates awareness about internet security,
including phishing, viruses and identity theft, measure the number of help desk calls received
about these problems. If they go down, you can reasonably assume your risk management
initiatives have contributed to success. If not, revise your training program.

Risk Management Process

The risk management process is a framework for the actions that need to be taken. There are five
basic steps that are taken to manage risk; these steps are referred to as the risk management
process. It begins with identifying risks, goes on to analyze risks, then the risk is prioritized, a
solution is implemented, and finally, the risk is monitored. In manual systems, each step involves
a lot of documentation and administration.

Here Are The Five Essential Steps of A Risk Management Process

1. Identify the Risk

2. Analyze the Risk
3. Evaluate or Rank the Risk
4. Treat the Risk
5. Monitor and Review the Risk

Step 1: Identify the Risk

The initial step in the risk management process is to identify the risks that the business is
exposed to in its operating environment.

There are many different types of risks:

 Legal risks
 Environmental risks
 Market risks
 Regulatory risks etc.

It is important to identify as many of these risk factors as possible. In a manual environment,

these risks are noted down manually. If the organization has a risk management solution
employed all this information is inserted directly into the system.
The advantage of this approach is that these risks are now visible to every stakeholder in the
organization with access to the system. Instead of this vital information being locked away in a
report which has to be requested via email, anyone who wants to see which risks have been
identified can access the information in the risk management system.

Step 2: Analyze the Risk

Once a risk has been identified it needs to be analyzed. The scope of the risk must be determined.
It is also important to understand the link between the risk and different factors within the
organization. To determine the severity and seriousness of the risk it is necessary to see how
many business functions the risk affects. There are risks that can bring the whole business to a
standstill if actualized, while there are risks that will only be minor inconveniences in the
analysis.

In a manual risk management environment, this analysis must be done [Link] a risk
management solution is implemented one of the most important basic steps is to map risks to
different documents, policies, procedures, and business processes. This means that the system
will already have a mapped risk management framework that will evaluate risks and let you
know the far-reaching effects of each risk.

Step 3: Evaluate the Risk or Risk Assessment

Risks need to be ranked and prioritized. Most risk management solutions have different
categories of risks, depending on the severity of the risk. A risk that may cause some
inconvenience is rated lowly, risks that can result in catastrophic loss are rated the highest. It is
important to rank risks because it allows the organization to gain a holistic view of the risk
exposure of the whole organization. The business may be vulnerable to several low-level risks,
but it may not require upper management intervention. On the other hand, just one of the highest-
rated risks is enough to require immediate intervention.

There are two types of risk assessments: Qualitative Risk Assessment and Quantitative Risk
Assessment.

Qualitative Risk Assessment

Risk assessments are inherently qualitative – while we can derive metrics from the risks, most
risks are not quantifiable. For instance, the risk of climate change that many businesses are now
focusing on cannot be quantified as a whole, only different aspects of it can be quantified. There
needs to be a way to perform qualitative risk assessments while still ensuring objectivity and
standardization in the assessments throughout the enterprise.

Quantitative Risk Assessment

Finance related risks are best assessed through quantitative risk assessments. Such risk
assessments are so common in the financial sector because the sector primarily deals in numbers
– whether that number is the money, the metrics, the interest rates, or any other data point that is
critical for risk assessments in the financial sector. Quantitative risk assessments are easier to
automate than qualitative risk assessments and are generally considered more objective.

Go in more depth Bringing Quantitative Risk Analysis to Enterprise Risk Management

Step 4: Treat the Risk

Every risk needs to be eliminated or contained as much as possible. This is done by connecting
with the experts of the field to which the risk belongs. In a manual environment, this entails
contacting each and every stakeholder and then setting up meetings so everyone can talk and
discuss the issues. The problem is that the discussion is broken into many different email threads,
across different documents and spreadsheets, and many different phone calls. In a risk
management solution, all the relevant stakeholders can be sent notifications from within the
system. The discussion regarding the risk and its possible solution can take place from within the
system. Upper management can also keep a close eye on the solutions being suggested and the
progress being made within the system. Instead of everyone contacting each other to get updates,
everyone can get updates directly from within the risk management solution.

Check our recent post: Improving Risk and Compliance Results With Smarter Data

Step 5: Monitor and Review the Risk

Not all risks can be eliminated – some risks are always present. Market risks and environmental
risks are just two examples of risks that always need to be monitored. Under manual systems
monitoring happens through diligent employees. These professionals must make sure that they
keep a close watch on all risk factors. Under a digital environment, the risk management system
monitors the entire risk framework of the organization. If any factor or risk changes, it is
immediately visible to everyone. Computers are also much better at continuously monitoring
risks than people. Monitoring risks also allows your business to ensure continuity. We can tell
you How you can create a risk management plan to monitor and review the risk.

The Basics of The Risk Management Process Stay the Same

Even under a digital environment, the basics of the risk management process stay the same.
What changes is how efficiently these steps can be taken, and as it should be clear by now, there
is simply no competition between a manual risk management system and a digital one. There are
also many new risks that businesses are facing for the first time in 2019, and modern problems
require modern solutions.

Risk Management Evaluation

Any business that wants to maximize its risk management efficiency needs to focus on risk
management evaluations. These evaluations and assessments help businesses truly understand
their own capabilities, strengths, and vulnerabilities. More evaluations result in more insights
about where the business needs to improve its risk management framework. It can be difficult to
carry out these evaluations manually, but risk management solutions and technology can
simplify the evaluation and assessment workflow. It is important to do an evaluation before
making any major changes to the risk management framework.

What is Risk Management

Risk management is an important business practice that helps businesses identify, evaluate,
track, and improve the risk mitigation process in the business environment. Risk management is
practiced by the business of all sizes; small businesses do it informally, while enterprises codify
it.

Businesses want to ensure stability as they grow. Managing the risks that are affecting the
business is a critical part of this stability. Not knowing about the risks that can affect the business
can result in losses for the organization. Being unaware of a competitive risk can result in loss of
market share, being unaware of financial risk can result in financial losses, being aware of a
safety risk can result in an accident, and so on.

Businesses have dedicated risk management resources; small businesses may have just one risk
manager or a small team while enterprises have a risk management department. People who
work in the risk management domain monitor the organization and its environment. They look at
the business processes being followed within the organization and they look at the external
factors which can affect the organization one way or the other.

A business that can predict a risk will always be at an advantage. A business that can predict a
financial risk will limit its investments and focus on strengthening its finances. A business that
can assess the impact of a safety risk can devise a safe way to work which can be a major
competitive advantage.

If we think of the business world as a racecourse then the risks are the potholes which every
business on the course must avoid if they want to win the race. Risk management is the process
of identifying all the potholes, assessing their depth to understand how damaging they can be,
and then preparing a strategy to avoid damages. A small pothole may simply require the business
to slow down while a major pothole will require the business to avoid it completely.

Knowing the severity of a risk and the probability of risk helps businesses allocate their
resources effectively. If businesses understand the risks that affect them then they will know
which risks need the most attention and resources and which ones the business can disregard.
Risk management allows businesses to act proactively in mitigating vulnerabilities before any
major damage is incurred. There are different types of risk management strategies and solutions
for different types of risks.

Risk Management Steps in Software Engineering

Risk Management is an important part of project planning activities. It involves identifying and
estimating the probability of risks with their order of impact on the project.
Risk Management Steps:
There are some steps that need to be followed in order to reduce risk. These steps are as follows:
1. Risk Identification:
Risk identification involves brainstorming activities. it also involves the preparation of a risk list.
Brainstorming is a group discussion technique where all the stakeholders meet together. this
technique produces new ideas and promotes creative thinking.
Preparation of risk list involves identification of risks that are occurring continuously in previous
software projects.
2. Risk Analysis and Prioritization:
It is a process that consists of the following steps:

 Identifying the problems causing risk in projects

 Identifying the probability of occurrence of problem
 Identifying the impact of problem
 Assigning values to step 2 and step 3 in the range of 1 to 10
 Calculate the risk exposure factor which is the product of values of step 2 and step 3
 Prepare a table consisting of all the values and order risk on the basis of risk exposure factor
For example,
TABLE (Required)

Risk Probability of occurrence Impact of Risk

No Problem of problem problem exposure Priority

Issue of incorrect
R1 2 2 4 10
password

Testing reveals a lot

R2 1 9 9 7
of defects

R3 Design is not robust 2 7 14 5

3. Risk Avoidance and Mitigation:
The purpose of this technique is to altogether eliminate the occurrence of risks. so the method to
avoid risks is to reduce the scope of projects by removing non-essential requirements.
4. Risk Monitoring:
In this technique, the risk is monitored continuously by reevaluating the risks, the impact of risk,
and the probability of occurrence of the risk.
This ensures that:

 Risk has been reduced

 New risks are discovered
 Impact and magnitude of risk are measured

Essential Activities of Risk Management

Risk management is the area which tries to ensure that the impact of risks on cost, quality and
schedule is minimized. The main purpose of risk management is to identify and manage the risks
associated with a software project and solve the problem. Estimating the risks that can affect the
project schedule or the quality of the software being developed and taking action to avoid the
risk is the important task of a project manager. Identifying and preparing plans to reduce their
impact on the project is called risk management. The basic motivation of risk management is to
avoid disaster or heavy losses. The risk can be categorised as follows.
1. Project Risks : These are the risks which affect the project schedule or resources.
2. Product Risks : These are the risks which affect the quality or performance of the being
developed.
3. Business Risks : These are the risks which affect the organization developing or procuring
the software.
This classification is not a special classification. If an experienced programmer leaves a project
then it is a project risk because the delivery of the system may be delayed, the product may be a
risk because the replacement may not be a seasoned one and therefore may be mistakes and
business. Risk management is very important for software projects due to the inherent
uncertainties that most projects face. The process of risk management is shown in
fig.

Th
e process of risk management involves several stages are as follows-
1. Risk Identification : In this stage, the possible project, product and business risks are
identified.
2. Risk Analysis : In this stage or process, the likelihood and consequences of these risks
assessed.
3. Risk Planning : In this stage, risk avoidance in either planned to affect the plan or mitigate
its effects on the project.
4. Risk Monitoring : In this stage, risk assessment is done continuously and the risk reduction
plan is revised as more information about risk is available.
Like all other project planning, the risk management process is an iterative process that continues
throughout the project. Risk management process results should be documented in a risk
management plan. This should include a discussion of the risks that the project faces, analyzing
these risks and requiring plans to manage these [Link] may also include some results of the risk
management. The risk management has to deal with identifying the undesirable events that may
occur, the likelihood of them occurring and the losses that occur when undesirable events occur.
knowing this, strategies can be devised to reduce the possibility of reducing the risk or impact of
the content. Therefore, risk management revolves around risk assessment and risk control. These
are top 10 item techniques for managing them:

[Link]> Risk Item Risk Management Techniques

Staffing with top talent; Job matching; Team building; Key-

(1) Personnel shortfalls
personnel agreement; Training; Prescheduling key people.

Detailed multisource cost and schedule estimation; Design

Unrealistic schedules
(2) to cost; Incremental development; Software reuse;
and budgets
Requirements scrubbing.

Organization analysis; Mission analysis; OPS concept

Developing the wrong
(3) formulation; User surveys; Prototyping; Early users’
software functions
manuals.

Developing the wrong Prototyping; Scenarios; Task analysis; User

(4)
user interface characterization (functionality, style, workload).

Requirements scrubbing; Prototyping; Cost benefit

(5) Gold plating
analysis; Design to cost.

Continuing stream of High change threshold; Information hiding; Incremental

(6)
requirements changes development (defer changes to later increments).

Shortfalls in externally Benchmarking; Inspection; Reference checking;

(7)
furnished components Compatibility analysis.

Shortfalls in externally Reference checking; preaward audits; Awardfee contracts;

(8)
performed tasks Competitive design or prototyping teambuilding.
[Link]> Risk Item Risk Management Techniques

Real time performance Simulation; Benchmarking; Modeling; Prototyping;

(9)
shortfalls Instrumentation; Tuning.

Straining computer Technical analysis; Cost-benefit analysis; Prototyping;

(10)
science capabilities Reference checking.

Risk Mitigation-

Each new business venture in an organization comes with unknown dangers. These risks may
occur at any point throughout the project, which could seriously delay its completion.
Organizations then need to spend a lot of effort and money on this. Therefore, there are risk
management techniques that each project team member can use to ensure that the project is
done on time and without any major obstacles. This will lower the costs for the company.

The risk mitigation procedures included in the risk management methods utilized by
companies enable them to foresee all project-related hazards' possible implications in
advance. To readily recognize, monitor, and analyze all potential risks and their effects as
they work to accomplish their project, the team members employ a variety of mitigation
measures throughout the project's lifespan.

What is Risk Mitigation in Project Management?

Risk mitigation is minimizing the effects of probable hazards by creating a strategy to

manage, erase, or substantially limit setbacks. Management will monitor progress after
developing and implementing the plan and evaluate whether to adjust any measures as needed.
Although copying a risk management approach from another organization could be tempting,
your project will be based on your business strategy. The effort to establish a unique risk
mitigation strategy could mean the difference between keeping a positive client connection
and losing out on business.

Now that we know what risk mitigation in project management is let us talk about the
different types of risks. You can be exposed to various risks than a company in a different
industry with a diverse clientele or clientele. However, a few fundamental dangers apply to all
companies and industries, including:

1. Compliance Danger

A threat to business earnings or reputation when it breaks external or internal laws, rules, or
standards. Companies that violate compliance regulations risk losing clients or incurring
fines.

2. Legal Danger

Compliance risk arises when a business violates the laws and regulations that apply to
businesses. Companies may become involved in costly litigation when they face legal
dangers.

3. Strategic Hazard

The consequence of a company's poor or lack of business strategy.

4. Continuity Risk

A risk might harm the company's reputation or the public's perception of it. Reputational risks
can cause economic losses and a reduction in shareholder trust.

5. Operational Hazard

Current activities might potentially eat away at a company's profitability. Operational hazards
can be relied on by both internal systems as well as outside variables.

Why is Risk Mitigation Important?

The chances of finishing a project from top to bottom in one go are always close to zero,
according to project managers. Roadblocks come in both expected and unanticipated types;
therefore, both need to be anticipated.
The most prepared optimists are those who have a backup plan in place for every conceivable
scenario. Risk mitigation planning is crucial to ensure control over the project development
process and its success. Project managers are given the most appropriate strategy, resources,
and tools to deal with the worst-case event via risk mitigation, which might slow down project
progress if not considered.

One might ask why one should spend money and time on something that may or may not
happen. While this may be a credible reason for little projects, thorough risk mitigation is not
an alternative but a need for corporate projects where expenditures might reach millions. Here
are some further reasonings:

1. Prompt Crisis Management

Planning for risk mitigation provides a view into all potential future problems. As a reason,
project managers and leaders may make the most informed choices to not only lessen the
impact on the project scope when they occur but, in the best circumstances, to avoid them
through the use of the best contingency plans.

2. Close Gaps More Efficiently and Quickly

Planning for risk mitigation typically focuses on the project's weak point. Project managers
can develop workable solutions along the lines of trigger points if they are aware of any
potential dangers, saving time and money.

3. Budgeting in Realistic Terms

Planning for risk mitigation gives project managers the perfect insight to deploy resources in
advance for known and unknown risk events. Project managers can offer resource and budget
estimations to stakeholders based on the real conditions on the ground. This helps lessen
conflict during risky situations and frees project teams and other stakeholders to focus on
what matters.

4. Simple Cooperation and Escalation

Last but not least, a thorough risk mitigation strategy creates the foundation for future
partnerships that are frictionless, and goal driven. The sub-teams are fully conscious of their
responsibilities and have the necessary escalation matrix to refer to incidents that fall outside
their purview to the appropriate stakeholders.

What is the Goal of Risk Mitigation?

Risk mitigation ascertains specific goals to tackle potential risks a project will likely face
during the compilation process. Given below are a few of these objectives:

 Foresee future problems and create a plan to deal with them.

 Examine both internal and external threats to a business.
 Develop a contingency plan.
 Designing a risk management strategy after assessing risks
 Identifying and assessing hazards
 Manage risks through project execution.
What’s in a Risk Mitigation Plan?

A critical competency of a successful project manager is the capacity to anticipate hazards

that could materialize at any moment in the future. A clear risk management strategy enables
you to prepare for unforeseen events and reduce unexpected expenses by conserving essential
resources like time, money, assets, and people. The following six-step approach can assist you
in identifying and controlling risk before things spiral out of control.

Step 1: Make Risk Management a Component of your Projects.

Integrating risk management into your projects is the first and most critical thing you can do
to enhance your project management. Project risk management is now being applied by many
businesses and organizations to teach their workers how to identify problems before they
worsen.

In addition to hiring competent project managers and team members, you might organize "risk
brainstorming sessions" to identify potential risks. It is helpful to experiment with various risk
identification techniques to find unanticipated hazards that might occur. For instance, you can
consider data loss a concern and look into the finest backup systems for your company.

According to a study by the Project Management Institute (PMI), 83% of high-performing

project management businesses regularly implement risk management, compared to only 49%
of low-performing firms. These high performers spend 13 times less money and achieve their
goals 2.5 times more frequently than low performers.

Step 2: Share Risks with Others

Isn't it fantastic when a team member foresees and mentions a potential danger in a team
meeting, and you already had a backup in mind when that risk materialized? At this point, risk
communication enters the picture.
Major failures might sometimes have been avoided with regular communication. The most
practical approach would be to discuss the risks involved while you work on particular tasks
so that you may be equipped with a Plan B if the situation doesn't go as expected.

When discussing risk, including information on how it will affect your project, how unlikely
it is to occur, and what you can do to reduce the chances of it.

If you're the project manager, create an atmosphere where people can feel free to openly
discuss risks at meetings or one-on-one conversations without worrying about the
consequences.

Step 3: Prioritize Risks

Low-degree threats and dangers are the two different categories of risks. Low-degree risks, as
their name implies, may have an impact but are still managed. High-level risks, however,
could considerably affect the outcome and significantly impede progress. Recognizing that
some dangers have a more significant effect than others is essential.

Invest some time in ranking risks according to their importance and determining how they
will affect the project. Either prioritize risks based entirely on your instincts or establish a set
of criteria. It is recommended to select a strategy that is reasonably realistic and helps you to
estimate the chances and ramifications of a danger.

When deciding which risks to prioritize, consider the following:

1. Will the risk impact the project, the products, or both, right?
2. Is the project significant to your business?
3. Is the user crucial importance for the project?
4. Will the risk influence the client relationship? How important is that client?
5. Does the client already understand the risk? Do the parties involved already know?
Step 4: Consider Risks

Risk analysis is an essential component of risk management that can genuinely assist you in
making important decisions in favor of a project. Understanding a risk's characteristics and
possible outcomes is, therefore, essential. Always remember that risk analysis operates on
multiple levels and is not merely one-dimensional.

Risks initially seem safe and minor but can occasionally increase massively and negatively
impact. This is the point at which a project manager starts demonstrating their worth. This
study can show how much a project will affect the budget, timelines, and final output quality.
Step 5: Implement Risk Mitigation Measures as Soon as You Can

The previous ideas help you identify and rank risks, but the real impact on a project will come
from putting risk responses into practice. Risk minimization, avoiding danger, and risk
acceptance are the three options available.

It is best to take the risk if the impacts on a project are small or impossible to alter. You can
plan or modify the project to ensure that trouble will be encountered as little as possible while
avoiding it. To reduce danger, you should work to change its root causes or increase its
positive effects to make up for it.

Step 6: Follow up Frequently

Regular risk recording can assist you, and the team in identifying the most prevalent risks and
their effects on projects. The easiest is going to be to compile a report once the project has
been finished, identify risk tasks, their causes, and products, and evaluate them, so you know
how to deal with them in case you run into them on a future project.

Types of Project Risk Mitigation Strategies

The four main types of risk-mitigating strategies are as follows:

1. Risk Avoidance

The goal of risk avoidance is to avoid the threat altogether. Project termination, postponing
the commencement of the project, or modifying the project are all examples of risk avoidance.
It is easier to avoid risk than to engage in troublesome activities. To reduce risk, you could
implement the necessary program changes—such as adding cash, imposing new rules or
standards, or altering the schedule. Risk avoidance is usually applied when a danger's effects
are too severe. Risk prevention and risk removal are other terms for risk avoidance.

You take actions to prevent the danger from happening when you use a risk avoidance
technique. Ensure you're doing everything you can to minimize the threat, this may require
sacrificing other tools or tactics. For instance, you run the risk of not being able to finish a
task for a significant project when you don't have enough experts. You could hire many
specialists to lessen this risk if one becomes ill or is otherwise unavailable.

2. Risk Acceptance

This acknowledges that the risk currently exists and that there is no possible way to change it.
The project leads' permission is necessary to achieve risk acceptance. Risk acceptance is often
chosen as a final resort after exploring and ruling out all other possibilities. Sometimes taking
the chance is better in the long run since the potential benefit can outweigh the danger.

It's also plausible that there's a slim chance the risk will materialize, or the implications won't
be too severe. A business may have an ongoing strategy to accept the risk for things in this
"Low" risk category. When taking a risk, it is essential to keep a close eye on it for any
changes in its impact or chances of occurring. You might also want to keep comparing the risk
to your tolerance for risk and determine whether taking on the risk is still the best course of
action.

3. Risk Transfer

Moving the burden of risks from one party to another is known as risk transfer. Risk transfer
is frequently used when the effects of the risk are severe but not enough to justify avoidance
for your department. Services level agreements, warranties, and insurance are typical types of
risk transfers. Another way to transfer risk is to give another department or company custody
of the risk, which will make them responsible.

For example, a contractor might be penalized for any revenue lost by the company if a project
is delayed while anticipating a part or function from an outside contractor.

4. Risk Monitoring

Risk monitoring is another technique for handling risks. The practice of analyzing hazards,
observing changes, and updating the risk register is known as risk monitoring. Risk
monitoring is chosen when risk outcomes are not severe and risk mitigation is not an option.
Setting up notifications or holding regular meetings could be acceptable risk monitoring. The
providing insight team can be informed if a danger worsens and decide on a different risk
mitigation approach. A risk matrix can be developed as part of risk monitoring.

Risk Mitigation Best Practices

Now that we have discussed the steps you need to follow for risk mitigation techniques in
project management, we are going to address in detail all the various ways you can implement
risk mitigation:

1. Participating Stakeholders

The stakeholders should be included at every stage of the risk management process, starting
with the initial risk assessment. Managers, users, employees, investors, unions, etc., can be
stakeholders. Many of these people can be essential employees who play a crucial role in your
risk management procedures. These people each represent different positions and duties inside
your business, providing you with a concise overview of all of your company's elements and
the risks associated with it.

2. Tone from Above

Our subsequent best approach is developing a strong risk culture, which is crucial in any
effective risk management program. Risk culture collects people's shared values, attitudes,
and beliefs around risks. Management and the board of directors are in charge of outlining the
company's core values and creating the tone for compliance. Management buy-in is essential
to ensure that risk awareness is spread throughout the entire firm.

3. Communication

Communication is the first step in implementing effective risk management and risk
assessment practices. An additional crucial component of risk management is communicating
risks to all levels of your firm. All departments identify and keep track of critical risks or
threats with a high organizational impact. Any new hazards are appropriately discovered,
evaluated, and addressed. By interacting with everyone in your organization, you must raise
risk awareness.

4. Prudent Risk Management Procedures

Does your risk assessment policy include a written description? Are positions and
responsibilities outlined in detail? Do policies and processes specifying the mitigation of all
identified risks have clear definitions? Do your company's plans for absorbing unforeseen
risks and responding to them, such as your business continuity and incident response plans,
exist? Are all employees receiving communication skills about these policies?

It is going to be easier for you to look out for all the risks that might have an impact on your
company, their likelihood, and influence, how you intend to mitigate and prevent them, and
how you will keep an eye out for and manage possible threats if you have these clear policies
in place.

5. Monitoring of Risks Continuously

You must first be aware of your risks to manage them. After conducting your initial risk
assessment and implementing the required procedures to address and mitigate these risks, the
most critical step is monitoring. To ensure that all risk reduction actions are appropriate,
precise monitoring procedures must be implemented. Any Risk Management model must
include this as a critical component.

Conclusion
We are habituated to evaluating hazards because it is one of our survival strategies. Risk
reduction, also known as risk mitigation, impacts a company's ability to survive. Imagine a
situation where business leaders frequently seize fresh possibilities without taking the time to
evaluate how doing so would affect their company. That would not last, would it? We need to
have a fundamental understanding of risk mitigation to mitigate losses effectively inside a
company.

This article, given above, talks about everything you need to know regarding risk mitigation.
If you want more in-depth learning experience about what a risk mitigation situation is, we
suggest KnowledgeHut training for Project Management start your learning process from the
start.

RISK MANAGEMENT TECHNIQUES

Risk management techniques and business are important understand for all organisations as risks
can lead to problems for the company if not managed correctly. In this article, we will go
over risk management techniques and project management, the different types of risk
management techniques the most effective project race management techniques and how
Sinnaps project management software can help you to effectively manage the risks of your
projects.

RISK MANAGEMENT TECHNIQUES IN PROJECT MANAGEMENT

The different types of risk management techniques and project management cover three general
areas which are identification, analysis and planning:
 Identification: The first step in risk management techniques is identification. Identifying
the potential risks to your project allows you to recognise, define and describe the potential
risks that could affect the results of your project. In this step, project management
techniques such as brainstorming, risk surveys, SWOT analysis and checklist analysis
come into play.
 Analysis: After having identified the potential risks to your project, risk management
techniques required analysis. This is a more detailed description of how exactly the risks
could affect your project. Analysis can be qualitative and quantitative.
 Planning: After having identified and analysed all of the potential risks to your project, it
is important to plan out your project and how you were going to mitigate the risk’s
effectively. This can be done with a project planning to such as Sinnaps project
management software.
TYPES OF RISK MANAGEMENT TECHNIQUES: QUALITATIVE AND
QUANTITATIVE

Any risk management techniques examples will highlight the importance of risk analysis. Risk
analysis can be done in two forms: by using qualitative and quantitative risk management
techniques. Let’s take a look at some of the ways to carry out the analysis.

 Qualitative Risk Analysis

1. Expert judgment: Experts in the area of your project can offer opinions and advice on the
risk you are analysing.
2. Probability and impact assessment: This is one of the internal risk management
techniques that allows you to analyse the risk using impact and probability on cost,
performance and schedule.
3. Risk categorisation: Grouping risks caused by common roots so that effective responses
can be developed.
4. Risk urgency: This is where risks are ranked according to their levels of urgency.

 Quantitative Risk Analysis

1. Probability distributions: Used to determine uncertain values and the probability of
their occurrence.
 Cost and Schedule risk analysis

1. Expected Monetary Value analysis: This allows you to calculate the average
outcome scenarios.
2. Sensitivity analysis: Used to determine the impact that a risk could have on the
project.
SELECTING AND IMPLEMENTING RISK MANAGEMENT TECHNIQUES

Selecting and implementing risk management techniques should be done carefully and in context
with your project team and the type of project you are managing. Whether you are focusing on
specifically market risk management techniques or general risk management techniques,
implementing the measures usually comes in the planning stage of project risk management.
Let’s take a look at a number ways to implement project risk management techniques:
 Meetings and assessments: Meetings and assessments should be continuously carried out
throughout the project and the status of risks should be monitored. Every meeting your
project team holds should include discussion on past, current and potential future risks.
 Risk audits: Risk audits allow you and your project team to overview how you dealt with
certain risks and to identify the effectiveness of the measures taken. This is beneficial not
only for the current project but also for future projects and risks.
 Trend analysis: Performance data can be used to compare actual and planned results so
that risks can be controlled and monitored closely.
 Technical performance measurement: Tools such as KPIs can be used to compare the
technical accomplishments of the project throughout its lifecycle which helps to determine
the health status of the project.

THE MOST EFFECTIVE RISK MANAGEMENT TECHNIQUES WITH SINNAPS

Communication cannot be excluded from the list of the most effective risk management
techniques. Whether there is a need to bring up any potential project risks that you have noticed,
or you need to share the project risk mitigation plan, communication is key. Sinnaps project
management software offers various communicative tools within the project plan such as
the project wall, live in-chat features and weekly email updates to all project team members.
Brainstorming is one of the most effective project risk management techniques. It allows for
everyone to take part, stimulates discussion and debate and encourages all team members to
participate by increasing involvement. Sinnaps allows for teams to brainstorm, write up their
own documents and attach them to the project and to effectively share information.
Testmode is a tool offered by Sinnaps that allows project managers to test any potential
changes to the project and to see the effects of the change before fully committing to the change.
This allows project managers to visualise how a change may impact the project and to therefor
spot any risks before they arise.
 KPIs or Key Performance Indicators are also included as part of the Sinnaps app that allow
project managers and teams to monitor and keep track of the health status of the project.
Forecasting allows teams to see how the project is expected to turn out based on current
performance and therefor allows time for planning and preparing for any potential future
risks.

Experts in any field are valued thanks to their accumulated knowledge through experience and
the time they have spent in an industry. Their opinions and advice can greatly help and serve
as one of the most useful alternative risk management techniques. Sinnaps is not only a
project planning software, but also a community of people who can share their project
management experience and even successful project plan templates that you and your team can
apply to your projects.
Overall, risk management techniques are crucial for all types of project teams to understand and
implement. Every project faces its own set of risks. In this article, we covered the various types
of project risk management techniques and the tools that Sinnaps project management software
offers to help you effectively and efficiently manage your project risks. 😊

7 Risk Management Metrics to Track

We all know that managing risk across projects, programs and your entire portfolio, is
important. Risk management is something that’s embedded into the way businesses are run and
into project management methodologies. However, beyond the risk log, what kind of tracking do
you do on risk?

In this article we will share seven metrics you can use to track the way risk management is being
managed in your project teams. First, let’s look at why you should bother tracking risk in this
way at all.

Why Track Risk Management Metrics?

Typically, risk management approaches allow you to actively manage risk within a defined area
of the business, like a project. That’s good, and necessary, and needs to continue. However, this
kind of risk management doesn’t tell you how good the business is at identifying and managing
risk overall. It doesn’t flag up areas where people managing risk might be struggling, and it
doesn’t help you identify where your risk management processes might need a little work.
You need to look at and track how risk is managed to do that. This is where risk management
metrics come into play. You can better understand risk exposure for a project, a program or the
business overall if you have a sense of whether risk in the business is being effectively managed.

Risk Management Metrics & The PMO

The PMO has a role to play in aggregating information from all projects to provide a view of the
risk exposure across the portfolio.

You can use project management software tools to surface risks and display them in a way that
improves risk awareness. Tools like Adrega PI can extract information from P6 to show it in a
dashboard format that executives can quickly scan. However, that kind of dashboard reporting
generally looks at the highest risks themselves and not how risk management is being done. You
can easily add reports to your reporting bundles to look at risk management metrics in a more
granular way.

Before you can report on anything, you need to establish what it is that is valuable to your
organization. The PMO should have some input into which risk management metrics (if any –
your business’ risk management maturity levels may dictate that this isn’t something you can do
right now) should be tracked at the department or portfolio level.

Here are seven measures that you could adopt to help you take a view of the effectiveness of risk
management in your organization.

7 Risk Management Metrics

Before we list the metrics, take note that you won’t be able to track all of these all the time.
Some of them are only relevant once a risk happens and becomes a real-life issue to the project.

1. Number of risks identified

This is a relatively easy measure. You can track number of risks identified per project or
program. There is no ‘right answer’ to how many risks a project should have identified. It
completely depends on the type of project. A project you have carried out many times before will
be low risk. A project with multiple areas of complexity using a methodology that is new to the
team will inherently be more risky. However, this measure is useful for comparing projects
where the PMO can apply some basic principles. If you know that two projects are similar in
many respects (like duration, priority, complexity) then you can assume they would have around
the same number of risks. If one project manager has identified 90 risks and the other project
manager has identified 19, you would be justified in comparing how robustly they are doing risk
analysis on the project.

2. Number of risks that occurred (i.e. became issues)

You can also track the number of risks that materialize and turn into ‘real-life’ issues on the
project. Hopefully there aren’t that many. However, this measure can also tell you that risk
analysis is being done thoroughly. For example, if lots of risks are tracked that then turn into
issues, you can give the team credit for spotting that these things might cause problems. If lots of
risks are tracked but none turn into issues, this could be that the team are tracking the wrong
things – issues pop up out of nowhere and never make it on to the risk log.

As with all of these metrics, you need to consider the narrative around the metric to get the full
picture.

3. Number of risks that occurred more than once

This can be a sign that lessons aren’t being learned. If a risk occurs multiple times, across the
same project or several projects, it can show you that teams aren’t learning from past experience.

4. Predicted Risk Severity compared to Actual Severity

When the risk occurs, and becomes an issue, you’ll be able to see how much of an impact it had
on the project. Comparing predicted severity to actual severity can be a bit of a professional
guess, but it’s worth giving it a go. It’s interesting to see whether your risk mitigating plans had
the impact you expected in reducing the risk. You can look at whether residual risk was
adequately identified and managed too.

5. Number of risks that were not identified

How do you track something you didn’t know was going to happen? This is a tricky one! Think
of it as a way to track issues that occur that should have been flagged as a risk but weren’t. Look
at the number of issues on the issue log that could have been foreseen but bypassed the risk
stage.

6. Cost of risk management

You can track actual spent on risk management activities against forecasted spend. This is a
really interesting one for future projects because it can help you estimate the cost of risk on new
projects.

7. Number of risks closed

Track how many risks passed by without happening, whether you took active measures to
manage them or not. This can be a counterbalance to the number of risks identified. If you
identify a lot and close a lot, you can work out the key risks facing the project. This measure is
also a sign that active risk management is happening during the project. A large number of
identified risks and no closed risks shows that risk analysis was carried out at the start of the
project and then not followed up throughout the project lifecycle.

You can include risk management metrics in your project closure report, and you should.
However, to be able to take any practical steps to better risk management, or for spotting trends,
you should be looking at your key metrics long before you write the project closure report.

Some of the metrics above can only be calculated at project shut down, but where you can track
measures across a project or program on an ongoing basis, that is better. It gives you a chance to
spot trends, compare projects on a more real-time basis and do something about the data you
uncover to help improve risk management across the organization.

Planning and Tracking the Project

1. Have a plan
2. Know objectives
3. Get everyone on board
4. Choose iterative
5. Order features
6. Know when to detail
7. Align to external milestones
8. Choose a simple format
9. Time-box iterations
10. Start with short iterations
11. Use same size iterations
12. Estimate size, derive duration
13. Define verifiable tasks
14. Resist 'guesstimating' effort
15. Estimate collaboratively
16. Have 'floating' tasks
17. Think in hours, not days
18. Do not fake precision
19. It takes longer than you might think
20. Include things taken for granted
21. Plan sincerely
22. Track visibly
23. Refine regularly
24. Add buffers
25. Drop features when behind
26. Do not slack when ahead

Project planning and tracking is a vital part of any non-trivial project. Most students use ad hoc
'back of the napkin' 'inside your head' planning. They tend to avoid elaborate project planning or
'fake it' for the sake of appearances because of two reasons:
  It is a frustrating activity. Since things rarely go according to the plan, it seems like a
waste of energy to draw up a plan.
 They think they know all that is there to know about planning. Since the meaning of
'planning' is well-known, students think there is nothing much more to learn about it.

In reality, a typical student project can get by without much elaborate planning because of the
flexibility in available time and expected deliverables. For example, they can respond to a project
crisis by skipping other course work to spend more time on the project, heroics such as overnight
coding sessions, or simply not delivering what was initially promised.

However, project planning is integral to the learning experience of a project [Link] is why
sincere project planning is usually given extra credit. Dilligent students who want to use the
project to learn the valuable skill of project planning will find the tips in this section very useful.

1 HAVE A PLAN
The most important tip we can give about project planning is 'do it'. We may not get it right the
first time; but our project planning skills will improve over time, and our plans will get closer to
reality. There is much to be learned about planning (and related activities like estimation and
scheduling), and much to be gained from practising it during your project. Here are some:

 Treating project planning as a distinct part of the project (rather than an implicit thing we
do in our heads) forces us to think through what we are going to do in the project and
how we are going to do it. This gives you a far better result than if you just 'winged it'.
 A plan helps us to foresee and mitigate risks. For example, planning might alert us to
tasks that are in the critical path. i.e. any delay in their completion can directly affect the
delivery date.
 A plan supports better decision making. For example, having a plan helps when you have
to decide whether to keep working on a given feature or abandon it for the sake of a more
important feature: "According to the project plan, we should start feature 'foo' by today if
we want to include in the final product. This means we cannot deliver 'foo' if we keep
working on 'bar''.
 A plan helps us cross-check our understanding of the project. For example, instructors
can use it to assess whether you have underestimated the work: "How come this team
allocated five hours to feature 'foo' while all other teams allocated more than 20 hours?".
 It helps us to assess progress: "Hey, feature 'foo' is supposed to be done by 20th. At this
rate, I don't think we are going to make it".

2 KNOW OBJECTIVES
What is the objective of a project plan? A project plan should help us answer at least some of the
following questions:
  What (and when) are the project milestones?
 What are the deliverables at each project milestone (external and internal)?
 Who does what, in which order, by when?
 Which part of the product each team member will implement?
 At a given point of time, what is the assigned task for each team member?
 What are the roles played by each project member?

3 GET EVERYONE ON BOARD

Preferably, planning should be done as a collaborative activity. When the plan is built upon team
consensus, your plan itself tends to be of better quality and others tend to follow the plan more
willingly. Even if your team wants you - the team leader - to draw up the plan, do not simply
allocate work to others at your discretion. Instead, present them with a draft plan and get their
feedback before adopting it.

4 CHOOSE ITERATIVE

Any non-trivial student project should be done in iterative fashion. The waterfall
process [[Link] may suit certain kinds of projects, for example,
when a team of seasoned programmers builds a product they have prior experience in. Most
certainly your project does not fall into this category.

If you are serious about having a well-defined process for your project, you can choose from
many available processes such as eXtreme programming, Unified Process, SCRUM, etc.
However, smaller projects can survive just fine by simply using an iterative approach to
developing the product. Elaborate process-specific practices advocated by those processes may
turn out to be an overkill for small, short-term projects.

5 ORDER FEATURES

If we are following an iterative process (we should) and the product has many features, we have
to figure out in which order we will implement them. While many factors influence this decision,
two most important ones are the value and the risk. One strategy is to use the following order
[adapted from the book Agile Estimation and Planning by Mike Cohn]: first, we implement high
risk, high value features; then, low risk, high value; last, low risk, low value, leaving out high
risk, low value features.

This order emphasises that 'critical' features - those that are difficult to implement (i.e. 'high risk')
yet vital to the proper functioning of the product (i.e. 'high value') should be scheduled early in
the project although the client/instructor does not demand it that way. This gives us enough time
to recover if something goes wrong while implementing those features.

Another important factor we must consider is feature dependencies. This analysis might even
discover a critical path of features in the project. A critical path is a tightly packed chain of
features each one dependent on the previous one. A delay in one feature will cause a delay in the
final delivery date.

6 KNOW WHEN TO DETAIL

"It'll be done when it's done!" is not a plan [quoted from [Link]], neither is it a
good attitude to have. "Design 4 weeks, implement next 6 weeks, test during the last 6 weeks" is
a plan, but it is too high-level (and not a very good one either - for one thing, it follows the
waterfall model). So what is the appropriate level of details for your project plan?

First, there is a limit to how detailed it can be. The element of uncertainty common to all
software projects and our own lack of expertise in similar projects prevent us from knowing in
advance every detail of how we will do the project.

Second, we may not want to detail out certain things upfront even if we could. For example, we
may not want to be specific about which function we will be implementing on Monday of the
11th week from today. Instead, we might stop at specifying which set of features we will be
implementing during weeks 8-12.

In general, we prefer to define major milestones in the high-level plan (we can call this the
master plan) using features rather than components, functions, or tasks. This emphasises our
focus on delivering values to the customer and not merely 'doing some project work'. Here is an
outline of such a plan :

iteration 1 [weeks 1-2] V0.0 : skeleton architecture, feature 1.

iteration 2 [weeks 2-3] V0.1 : feature 2, feature 3.
iteration 3 [weeks 3-4] V0.9 : feature 4.
iterations 4-7 [2 months] V1.0: features 5,6,7 and 2 additional features from the 'nice to have'
list.

This plan tells us which features we will deliver from each iteration. At the end of each iteration,
we plan our next iteration in more detail (we can call this the iteration plan). Here, we will break
down each feature in that iteration into fine-grain tasks, estimate the effort required, and schedule
them appropriately.

7 ALIGN TO EXTERNAL MILESTONES

Align your iterations appropriately with external milestones imposed by the course instructor or
the external client. For example, if your iteration ends one day before the external milestone, you
have a buffer of one day to pit against any last minute delays.
8 CHOOSE A SIMPLE FORMAT

If we can use a simple table or a spreadsheet to document the project plan and still achieve all the
objectives easily, there is no need for fancy templates, diagrams, and charts.
See here [[Link] for a sample project plan, maintained as a simple
MSWord document.

9 TIME-BOX ITERATIONS

A floating deadline (i.e. "Let's finish our tasks and email each when we are done") is a sure way
to slow down the project. Estimate how long the iteration will take, and fix a deadline based on
the estimates. Deadlines are a way to get a commitment from all, and push the project tasks up
their priority list ("I have to finish this by Friday, or the team will let me have it!"). Of course if
you find yourself finishing the work before the deadline, set a shorter deadline next time.

10 START WITH SHORT ITERATIONS

Start with one-week iterations. If things go according to the plan, you can try longer iterations; if
they do not, make the next iteration even shorter. If you can gather all team members together for
a couple of hours, consider starting with a mini-iteration that lasts only a couple of hours.

11 USE SAME SIZE ITERATIONS

Once you have found an iteration size that fits you, try to stick to it. Try to schedule milestones
on the same day of the week. Doing so helps your team to 'get into a rhythm' and makes
subsequent iterations easier to plan. This especially makes sense since most of your work from
other courses also follows a similar pattern.

12 ESTIMATE SIZE, DERIVE DURATION

Answering question such as "How long do you need to do task X?" in fact requires answering
two questions: "How much effort will it take?" and "How long will it take you do that amount of
work?". The first question is primarily about estimating the size of a task. The answer to the
second question depends on the person who does it and when it will be done.

...
13 DEFINE VERIFIABLE TASKS

When you need to define tasks, make sure they are verifiable. 'Complete the parser' is a
verifiable task. Either the parser is complete, or it is not. 'Add more functionality to the parser' or
'Finish 50% of the parser' are not verifiable. Always plan an iteration using verifiable tasks. How
else will you decide when the task is done?

14 RESIST 'GUESSTIMATING' EFFORT

While you may not have a lot of past data/experience to help in estimating, and while you are not
usually required to use sophisticated estimation techniques, do resist the temptation to give the
first number that pops into your head. Take some time to consider the following factors:

 Try to break the feature/task into smaller (but not ridiculously small) parts.
 If it is a coding task, estimate how many LOC it will require. Use your LOC/hour rate to
calculate an initial estimate.
 Does it require learning new technologies/tools? If it does, you need to allocate time for
it.
 Does it require you to work with other team members? The more team members you
have to work with, the slower the progress will be.
 Have you done any similar work before? If you have, how much effort did it take?

In rare cases when you have absolutely no idea of the size of a task, you may want to try out a
similar task at a MUCH smaller scale before venturing an estimate. Such a tryout is called
a spike solution. While this delays the planning process a bit, it is much better than planning
based on guesstimates.

15 ESTIMATE COLLABORATIVELY

We can estimate the task size as a team or as a sub-group of teammates related to the task. You
can ask the person who is likely to do the task for an estimate. Then, others can add their
opinion, especially if they think the task is being over/underestimated by a big margin.

If you feel that some team members are padding estimates to evade work, here is a bit more
elaborate and fun way to estimate task size (this approach is called planning
poker [[Link]

 Everyone who takes part in estimation meets together.

 One person outlines the task that needs to be estimated.
 Each person mentally calculates an estimate (but does not tell others).
 After everyone is done estimating, all reveal their estimate at the same moment. The
easiest way to do this is to use your fingers: Fold the right number of fingers in your hand
to indicate your estimate, but keep them out of view from others (under the table or
behind your back) until it is time to reveal your estimate.
  If the estimates are different, each one justifies his estimate. This should lead to a useful
discussion about the best way to do the task.
 With the new knowledge gathered from the discussion, the whole group takes another
shot at estimating the task. This goes on until some level of consensus is achieved about
the estimate.
 We repeat the process for all tasks that need estimation.

16 HAVE 'FLOATING' TASKS

Floating tasks are the tasks not in the critical path. Their completion time is generally flexible.
E.g. 'looking for a good format for the user manual' can be done any time, as long as it is done
before starting the user manual. Identify floating task for idle team members (those who have
completed their tasks, and waiting for others to finish) to do.

17 THINK IN HOURS, NOT DAYS

Unlike industry practitioners, your commitment to the project is not full-time (because you are
taking other courses at the same time). This means the number of hours you spend on the project
is different from one day to another. Therefore, estimate task duration using person hours, not
person days.
E.g. If you think a task has a size of five hours, and the time you can devote for the project is
Monday - two hours, Tuesday - zero hours, Wednesday four hours, you should ask for time until
the end of Wednesday to finish the task.

18 DO NOT FAKE PRECISION

Let's face it: estimates can never be 100% accurate. The larger the task is, the less precise the
estimate will be. First, break larger tasks into smaller ones. Second, do not give seemingly
precise values to largely uncertain estimates. Using scales such as 1,2,3,5,8 (Fibonacci series) or
1,2,4,8 reflects that when the task is bigger, our estimates are less precise [adapted from the
book Agile Estimation and Planning by Mike Cohn]. For example, using the first scale means
when a task is bigger than five hours, we put it into the eight hours bucket instead of choosing
between six, seven, and eight hours.

19 IT TAKES LONGER THAN YOU MIGHT THINK

According to Ed Yourdon's book Death March, one reason for project failure is the naïve 'we can
do it over the weekend' optimism. An overconfident student might think he can
develop any system over a weekend, and things such as documentation, error-handling, and
testing are so 'minor' that they do not need much time.
We should keep accurate measures of the time we spend on each task, compare it with our initial
estimates, and adjust our future estimates accordingly. Do not be surprised if you found your
estimates were less than half of the actual time you took.

20 INCLUDE THINGS TAKEN FOR GRANTED

Things like unit testing, adding comments, and routine refactorings are usually considered
integral parts of coding and, therefore, should not generally be shown as separate activities in the
project plan. However, it is better for student teams to include them as separate activities
[adapted from the book Agile Estimation and Planning by Mike Cohn], at least until they become
a habit. This practice will help us to consciously allocate time for these important activities that
may be overlooked otherwise. Also, remember to allocate time for fixing bugs (found in features
delivered in previous iterations).

Do not forget to include meeting times in the project plan, too. However, we should not include
things that do not add value to the project (e.g. answering emails).

21 PLAN SINCERELY

Some teams allocate one member to 'do the project plan'. This member creates a nice project plan
and submits it, while others never get to see it, let alone follow it. Instead, each team member
should have an intimate knowledge of the project plan, at least the part that applies to him. One
should always be able to answer the following question: "According to the project plan, what
should you be doing today?"

It is not enough to know the plan. You should also try to follow the plan. Always refer to the plan
when choosing what to do next.

22 TRACK VISIBLY

Each iteration should start by drawing up a detailed plan for that particular iteration. For
increased visibility, you can send a copy of the plan to the supervisor at this stage itself.

You can also maintain the project plan as a GoogleDoc (or some other online format), and give
access to the supervisor. In this case, it is easy for the team members to update the document as
and when required. For example, a team member can mark a task as 'done', as soon as it is done.
GoogleDocs also keeps track of the past versions of the document, and shows who made which
change. You can also consider more specialised project tracking tools mentioned in Chapter 9.
23 REFINE REGULARLY

Planning is not over until the project is over. 'Revise plan' should appear frequently in the project
plan. It is also advisable to put someone in charge of this aspect.

Do a post-mortem analysis at the end of an iteration. What did not go according to the plan, and
why? Change the master plan as necessary.

When there is a mismatch between what you actually did and what the plan says, it means the
plan needs adjusting. But remember, you should not adjust the past plan to match what you did
up to now, but you should adjust the future part of the plan to match what you now think you can
do (as opposed to what you originally thought).

Evaluators know that a project plan never revised at least once is most likely a fake.

24 ADD BUFFERS

Do not assume that everything will go according to the plan. Insert buffers to strategic locations
of the task chain. If task B depends on the completion of task A, try not to schedule
task A immediately before task B. Scheduling task A a little earlier creates a buffer
between A and B. That way, a delay in A is less likely to affect B.

Note that buffers should be explicitly shown in the plan. Inflating all estimates by 10% is not the
same as adding buffers.

25 DROP FEATURES WHEN BEHIND

Consider the following true story: A team claims to have implemented all the features of the
product, but did not have enough time to hook up the functionality with the GUI, and therefore,
had no way of demonstrating those features. They offer to take the evaluator through the code to
prove their claims, an offer he politely declines. The team receives a very low grade, although
they supposedly fell only a small step short of the complete product. They could have got a much
higher grade if they had omitted some features and used that time to hook up the remaining
features to the GUI.
The moral of the story: When short of time, you have to sacrifice some features so that at least
the other features survive. If you realise you are behind schedule, and if late submissions are
heavily penalised (they should be!), you should not carry on with the current plan as if nothing is
wrong. Choose wisely what you will include in the product, and what you will have to omit. Do
not blindly re-allocate time from one task to another (e.g. from documentation to coding) - the
decision should depend on the amount of credit you stand to gain from each. Do not skimp on
testing no matter what - it is better to have 90% of the features 100% tested (i.e. a good product
that lacks some features) than 100% of the features 90% tested (i.e. a lousy product. Period).
Similarly, when you cannot make the iteration deadline (an internal deadline set by the team),
drop/postpone features rather than extend the deadline. Changing deadlines disrupt the rhythm of
your team.

26. DO NOT SLACK WHEN AHEAD

If you are ahead of the schedule, do not 'take it easy' until the plan catches up with you, and do
not use the extra time for 'gold plating' (i.e. adding unnecessary adornments to the product). It
simply means the plan was wrong, fortunately, in a good way. Do what you would do if you
were behind schedule; consider the current status, revise the schedule accordingly, and carry on.

Software Engineering | Software Project Management

Plan (SPMP)
Once project designing is complete, project managers document their plans during a software package Project
Management set up (SPMP) document. The SPMP document ought to discuss an inventory of various things
that are mentioned below.
This list will be used as a doable organization of the SPMP document. Organization of the software package
Project Management set up (SPMP) document.
1. Introduction:
 Objectives
 Major Functions
 Performance Issues
 Management and Technical Constraints
2. Project Estimates:
 Historical Data Used
 Estimation Techniques Used
 Effort, Resource, Cost, and Project Duration Estimates
3. Schedule:
 Work Breakdown Structure
 Task Network Representation
 Gantt Chart Representation
 PERT Chart Representation
4. Project Resources:
 People
 Hardware and Software
 Special Resources
5. Staff Organization:
 Team Structure
 Management Reporting
6. Risk Management Plan:
 Risk Analysis
 Risk Identification
 Risk Estimation
 Risk Abatement Procedures
7. Project Tracking and Control Plan
8. Miscellaneous Plans:
 Process Tailoring
 Quality Assurance Plan
  Configuration Management Plan
 Validation and Verification
 System Testing Plan
 Delivery, Installation, and Maintenance Plan
7

Project Scheduling

Project-task scheduling is a significant project planning activity. It comprises deciding which

functions would be taken up when. To schedule the project plan, a software project manager
wants to do the following:

1. Identify all the functions required to complete the project.

2. Break down large functions into small activities.
3. Determine the dependency among various activities.
4. Establish the most likely size for the time duration required to complete the activities.
5. Allocate resources to activities.
6. Plan the beginning and ending dates for different activities.
7. Determine the critical path. A critical way is the group of activities that decide the
duration of the project.

The first method in scheduling a software plan involves identifying all the functions required to
complete the project. A good judgment of the intricacies of the project and the development
process helps the supervisor to identify the critical role of the project effectively. Next, the large
functions are broken down into a valid set of small activities which would be assigned to various
engineers. The work breakdown structure formalism supports the manager to breakdown the
function systematically after the project manager has broken down the purpose and constructs
the work breakdown structure; he has to find the dependency among the activities. Dependency
among the various activities determines the order in which the various events would be carried
out. If an activity A necessary the results of another activity B, then activity A must be scheduled
after activity B. In general, the function dependencies describe a partial ordering among
functions, i.e., each service may precede a subset of other functions, but some functions might
not have any precedence ordering describe between them (called concurrent function). The
dependency among the activities is defined in the pattern of an activity network.

Once the activity network representation has been processed out, resources are allocated to every
activity. Resource allocation is usually done using a Gantt chart. After resource allocation is
completed, a PERT chart representation is developed. The PERT chart representation is useful
for program monitoring and control. For task scheduling, the project plan needs to decompose
the project functions into a set of activities. The time frame when every activity is to be
performed is to be determined. The end of every action is called a milestone. The project
manager tracks the function of a project by audit the timely completion of the milestones. If he
examines that the milestones start getting delayed, then he has to handle the activities carefully
so that the complete deadline can still be met.

Personnel Planning

Personnel Planning deals with staffing. Staffing deals with the appoint personnel for the position
that is identified by the organizational structure.

It involves:

o Defining requirement for personnel

o Recruiting (identifying, interviewing, and selecting candidates)
o Compensating
o Developing and promoting agent

For personnel planning and scheduling, it is helpful to have efforts and schedule size for the
subsystems and necessary component in the system.

At planning time, when the system method has not been completed, the planner can only think to
know about the large subsystems in the system and possibly the major modules in these
subsystems.

Once the project plan is estimated, and the effort and schedule of various phases and functions
are known, staff requirements can be achieved.

From the cost and overall duration of the projects, the average staff size for the projects can be
determined by dividing the total efforts (in person-months) by the whole project duration (in
months).

Typically the staff required for the project is small during requirement and design, the maximum
during implementation and testing, and drops again during the last stage of integration and
testing.

Using the COCOMO model, average staff requirement for various phases can be calculated as
the effort and schedule for each method are known.
When the schedule and average staff level for every action are well-known, the overall personnel
allocation for the project can be planned.

This plan will indicate how many people will be required for different activities at different times
for the duration of the project.

The total effort for each month and the total effort for each step can easily be calculated from this
plan.

Team Structure

Team structure addresses the issue of arrangement of the individual project teams. There are
some possible methods in which the different project teams can be organized. There are
primarily three formal team structures: chief programmer, Ego-less or democratic, and the
mixed team organizations even several other variations to these structures are possible.
Problems of various complexities and sizes often need different team structures for the chief
solution.

Ego-Less or Democratic Teams

Ego-Less teams subsist of a team of fewer programmers. The objective of the group is set by
consensus, and input from each member is taken for significant decisions. Group leadership
revolves among the group members. Due to its nature, egoless teams are consistently known as
democratic teams.

The structure allows input from all representatives, which can lead to better decisions in various
problems. This suggests that this method is well suited for long-term research-type projects that
do not have time constraints.
Chief Programmer Team

A chief-programmer team, in contrast to the ego-less team, has a hierarchy. It consists of a chief-
programmer, who has a backup programmer, a program librarian, and some programmers.

The chief programmer is essential for all major technical decisions of the project.

He does most of the designs, and he assigns coding of the different part of the design to the
programmers.

The backup programmer uses the chief programmer makes technical decisions, and takes over
the chief programmer if the chief programmer drops sick or leaves.

The program librarian is vital for maintaining the documentation and other communication-
related work.

This structure considerably reduces interpersonal communication. The communication paths, as

shown in fig:
Controlled Decentralized Team

(Hierarchical Team Structure)

A third team structure known as the controlled decentralized team tries to combine the strength
of the democratic and chief programmer teams.

It consists of project leaders who have a class of senior programmers under him, while under
every senior programmer is a group of a junior programmer.

The group of a senior programmer and his junior programmers behave like an ego-less team, but
communication among different groups occurs only through the senior programmers of the
group.

The senior programmer also communicates with the project leader.

Such a team has fewer communication paths than a democratic team but more paths compared to
a chief programmer team.

This structure works best for large projects that are reasonably straightforward. It is not well
suited for simple projects or research-type projects.
 What is configuration audit in project management?

“A Functional Configuration Audit (FCA) examines the functional characteristics of the

configured product and verifies that the product has met the requirements specified in its
Functional Baseline documentation approved at the Preliminary Design Review (PDR) and
Critical Design Review (CDR).09-Dec-2022
There are two types of configuration audits:
 Functional audit. The objective of the functional audit is to provide an independent evaluation of
a software product, verifying that its configuration items' actual functionality and performance is
consistent with the relevant requirement specification. ...
 Physical audit.

What is configuration management in project management?

Configuration management is a discipline that gives precise control over the project's
assets allowing managers to: specify the versions of products in use and in existence and
hold information on their status, who owns them and relationships between them.
What are the 4 types of audits?
 The four types of auditor opinions are:
 Unqualified opinion-clean report.
 Qualified opinion-qualified report.
 Disclaimer of opinion-disclaimer report.
 Adverse opinion-adverse audit report.
What are the five stages of the configuration management process?
The 5 steps of a SCM plan
 Planning and Identification. The first step in the process is planning and identification. ...
 Version Control and Baseline. ...
 Change Control. ...
 Configuration Status Accounting. ...
 Audits and Reviews.
These are the five types of testing methods used during audits.
 Inquiry.
 Observation.
 Examination or Inspection of Evidence.
 Re-performance.
 Computer Assisted Audit Technique (CAAT)

What is a software configuration management tool?

A software configuration management tool is an automation program that can conduct various
maintenance tasks repetitively to ensure that software functions properly. These tools perform a
series of program tests, data validation, security checks and other process monitoring tasks to
evaluate operational system performance and identify potential problems. Depending on the
specific software configuration management tool, it may offer notifications for users to resolve
issues or apply patches, updates or upgrades automatically. Software configuration management
tools can provide routine reports on software data that identify areas for improvement or
recommendations to optimize software use.

12 software configuration management tools

1. Ansible

Ansible is an open-source software that can operate on desktop devices and integrate with
commonly used web-based platforms for easy integration. This tool offers a minimal interface
for teams to learn how to use the program, along with a test mode for users to preview script
changes and software updates before implementing them. Through Ansible's website, you can
access a free 60-day trial and request custom price quotes for their Standard or Premium versions
made for enterprise IT operations and mission-critical DevOps level users, respectively.

2. Auvik

Auvik offers a free 14 day trial for its cloud-based network monitoring and management tools.
These tools provide users with application programming interfaces that can integrate with other
platforms and remote management capabilities through global dashboards. Both the Essential
and Performance versions of Auvik allow unlimited numbers of users, network sites, endpoints
and support.

3. CFEngine

CFEngine is available for desktop drives as an open-source and cross-platform system for large-
scale computer system management. This tool offers real-time reporting and notification to
inform users about performance and compliance levels, with customizable alerts and automated
actions for specified scenarios. You can download the Community version of CFENgine for free
on their website or request a free trial and quote for the Enterprise version to help you determine
which version might be best for you.

4. Chef

Chef offers integrations with popular web-based platforms to provide real-time configuration
processes for small and large-scale operating systems. This tool's programming considers
existing system processes and virtualization hypervisors to implement changes for compatible
and efficient software operations. You can contact Chef for pricing on its Desktop, Compliance,
App Delivery or Infrastructure Management tools, along with the Enterprise Automation Stack
for full access to Chef's capabilities.

5. Desktop Central

Desktop central is a desktop and mobile device management software with automated features
for patch installations, operating system and software deployment. With Desktop Central you can
manage your various devices and apply restrictions to customize the automation operations and
schedules for your tool. You can request a free trial and personalized quote for the UEM,
Enterprise or Professional editions through Desktop Central's website.
6. HyScale

HyScaleis a management and automation application for containerization and implementation

with a graphic interface featuring data visualizations. This tool's visual reporting capabilities
allow users to analyze and interpret software performance, strengths and weaknesses to improve
processing. You can access a free trial for HyScale, along with price quotes for Solo, Small
Team and Enterprise versions through the HyScale website.

7. Juju

Juju offers a free download of their client for various desktop operating systems to provide
lifecycle management and software configuration tools. With Juju you can manage your
applications and services through web-based platforms, along with deployment, integration and
management. Juju offers small applications within its client to perform common maintenance
processes and customizable scenarios.

8. Octopus Deploy

Octopus Deploy is available as an on-premise or cloud application for complex software

deployments between environments. In Octopus Deployment's interface, you can define
environments and variables for deployment targets. Through the Octopus Deploy website, you
can start a free 30 day trial for either the Clod or Server versions.

9. Puppet

Puppet is an open-source software that operates on desktop devices for software deployment and
configuration management automation. This tool offers various online support resources, live
technical account managers and custom consulting services, along with technical support
packages at Standard or Premium levels for different contact capabilities. Puppet offers product
demos and price quotes upon request for their Relay, Remediate and Enterprise products.

10. Rudder

Rudder offers an application programming interface that communicates with other servers to
automate inventory for software and hardware. You can customize Rudder's maintenance
operations to suit your operating system and infrastructure requirements. Rudder offers three
paid plan packages for Basic, Standard or Premium level users with a pricing structure based on
nodes per year.

11. Saltstack

Saltstack is available on desktop devices as an open-source software for remote task execution
and automation, including software configuration management. You can use Saltstack to deploy
and manage networks for simultaneous management of all operating systems within your
information technology infrastructure. You can access and download the free version of
Saltstack through their website to help you determine if it's the right tool for you before
purchasing the Enterprise version.

12. Solarwinds

Solarwinds offers a network configuration manager with software tools that provide users with
hardware inventory and server tracking. You can utilize Solarwinds' monitoring capabilities to
receive reports on output changes and other significant deviations. Solarwinds provides a free 30
day trial and download of their configuration monitor upon request through their website.

Activities SPECIFIC TO Project Tracking

Software Project Management consists of many activities, that includes planning of the project,
deciding the scope of product, estimation of cost in different terms, scheduling of tasks, etc. One
of the best ways to keep track of a project is creating an outline or document that includes the team's tasks,
dependencies, deadlines, and goals, and then delegating which team member is responsible for what.

The list of activities are as follows:

1. Project planning and Tracking

2. Project Resource Management
3. Scope Management
4. Estimation Management
5. Project Risk Management
6. Scheduling Management
7. Project Communication Management
8. Configuration Management

Now we will discuss all these activities -

1. Project Planning: It is a set of multiple processes, or we can say that it 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. Scope Management create the
project to contain restricted and quantitative tasks, which may merely be documented and
successively avoids price and time overrun.

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.

If we talk about the size, then Line of code depends upon user or software requirement.
If we talk about effort, we should know about the size of the software, because based on the size
we can quickly estimate how big team required to produce the software.

If we talk about time, when size and efforts are estimated, the time required to develop the
software can easily determine.

And if we talk about cost, it includes all the elements such as:

o Size of software
o Quality
o Hardware
o Communication
o Training
o Additional Software and tools
o Skilled manpower

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.

For scheduling, it is compulsory -

o Find out multiple tasks and correlate them.

o Divide time into units.
o Assign the respective number of work-units for every job.
o Calculate the total time from start to finish.
o Break down the project into modules.

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.

Resource management includes:

o Create a project team and assign responsibilities to every team member

o Developing a resource plan is derived from the project plan.
o Adjustment of resources.

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.

Several points show the risks in the project:

 o The Experienced team leaves the project, and the new team joins it.
o Changes in requirement.
o Change in technologies and the environment.
o Market competition.

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
stakeholders of the project such as hardware suppliers.

From the planning to closure, communication plays a vital role. In all the phases, communication
must be clear and understood. Miscommunication can create a big blunder in the project.

8. Project Configuration Management: Configuration management is about to control the

changes in software like requirements, design, and development of the product.

The Primary goal is to increase productivity with fewer errors.

1. Some reasons show the need for configuration management:

o Several people work on software that is continually update.

o Help to build coordination among suppliers.
o Changes in requirement, budget, schedule need to accommodate.
o Software should run on multiple systems.

2. Tasks perform in Configuration management:

o Identification
o Baseline
o Change Control
o Configuration Status Accounting
o Configuration Audits and Reviews

2. People involved in Configuration Management:

Interfaces in Process Database
A database management system (DBMS) interface is a user interface that allows for the ability to input queries
to a database without using the query language itself.
User-friendly interfaces provided by DBMS may include the following:

1. Menu-Based Interfaces for Web Clients or Browsing –

These interfaces present the user with lists of options (called menus) that lead the user through the
formation of a request. Basic advantage of using menus is that they removes the tension of remembering
specific commands and syntax of any query language. The query is basically composed step by step by
collecting or picking options from a menu that is shown by the system. Pull-down menus are a very popular
technique in Web based interfaces. They are also often used in browsing interface which allow a user to
look through the contents of a database in an exploratory and unstructured manner.

2. Forms-Based Interfaces –
A forms-based interface displays a form to each user. Users can fill out all of the form entries to insert new
data, or they can fill out only certain entries, in which case the DBMS will redeem same type of data for
other remaining entries. These types of forms are usually designed or created and programmed for the users
that have no expertise in operating system. Many DBMSs have forms specification languages which are
special languages that help specify such forms.
Example: SQL* Forms is a form-based language that specifies queries using a form designed in
conjunction with the relational database schema.

3. Graphical User Interface –

A GUI typically displays a schema to the user in diagrammatic [Link] user then can specify a query by
manipulating the diagram. In many cases, GUIs utilize both menus and forms. Most GUIs use a pointing
device such as mouse, to pick a certain part of the displayed schema diagram.
4. Natural language Interfaces –
These interfaces accept request written in English or some other language and attempt to understand them.
A Natural language interface has its own schema, which is similar to the database conceptual schema as
well as a dictionary of important words.
The natural language interface refers to the words in its schema as well as to the set of standard words in a
dictionary to interpret the [Link] the interpretation is successful, the interface generates a high-level
query corresponding to the natural language and submits it to the DBMS for processing, otherwise a
dialogue is started with the user to clarify any provided condition or request. The main disadvantage with
this is that the capabilities of this type of interfaces are not that much advance.

5. Speech Input and Output –

There is limited use of speech be it for a query or an answer to a question or being a result of a request it is
becoming commonplace. Applications with limited vocabularies such as inquiries for telephone directory,
flight arrival/departure, and bank account information are allowed speech for input and output to enable
ordinary folks to access this information.
The Speech input is detected using predefined words and used to set up the parameters that are supplied to
the queries. For output, a similar conversion from text or numbers into speech takes place.

6. Interfaces for DBA –

Most database system contains privileged commands that can be used only by the DBA’s staff. These
include commands for creating accounts, setting system parameters, granting account authorization,
changing a schema, reorganizing the storage structures of a databases.

5 Steps to Project Closure

So much time and effort is put into the planning of a project, it is often forgotten that the end of a
project—project closure—is equally important. There’s a lot of work involved even once a
project is technically complete.

For example, there are many tasks that you still must complete. They might be procedural, but
that doesn’t make them any less important. There are approvals, signatures, payments, all of
which might seem like pushing paperwork to you, but tell that to the team member waiting to get
paid.

Not to mention, when you are ending one project, you’re likely planning another. Therefore, you
want to get transition support for this changeover. You’ll have to release resources, archive
documents and don’t forget to acknowledge the project success with a party or some type of
celebration. That’s important, too.
What Is Project Closure?

Project closure is the last phase of a project. It’s when the project manager verifies that the client,
stakeholder or customer has accepted the project deliverables. If the project or product is
ongoing after the project, then maintenance must be set up.

The project manager will also review the entire project before closing it, rating performance and
comparing that to the baseline. The project team will be part of this process, offering their
observations and feedback, which is collected in a lesson’s learned document. This provides
guidance for future projects.

The importance of project closure is more than just signing off on all documentation, fulfilling
any contracts with vendors and releasing the team to participate in other projects. It makes sure
that the original objectives of the project have been met and ties up any loose ends, such as risk
or issues that have remained open.

Steps to Closing a Project

The close of the project is the final phase of your job, it’s the last turn of the project life cycle,
and like any other aspect of a project, it requires a process. The following are five steps you
should take to make sure you’ve dotted all the I’s and crossed all the T’s, as well as taken full
advantage of the experience.

1. Arrange a Post Mortem

Managing a project isn’t only about tasks and resources, budget and deadlines, it’s an
experience you can constantly learn from. While you should have been learning throughout the
project, now is a great time to look back without the pressure and distractions that might have
dulled your focus.

Gather the core team to invite feedback about what worked, and what didn’t. Encourage honesty.
By documenting the mistakes and the successes of the project, you’re building a catalog that
offers historic data. You can go back and look over the information for precedents
when planning for new projects.
Projects are never standalone things, but part of a continuum, where the specifics might vary, but
the general methods usually remain the same. There’s a wealth of knowledge produced after any
project closes.

2. Complete Paperwork

As noted, projects generate reams of documents. These documents are going to have to get sign
off and approval from stakeholders. Everything needs attention and must be signed for, which is
the legal proof that in fact these documents have concluded. That includes closing all contracts
you might have made with internal partners or vendors or any other resources you contracted
with.

This includes addressing all outstanding payments. You want to make sure that all invoices,
commissions, fees, bonus, what have you, are paid. Complete all the costs involved with the
project. It’s not done if it’s not paid for.

Project management software can help you organize all these documents. ProjectManager acts
like a hub for all your project files. You can track them on our list view, which is more than the
usual to-do list app. For one thing, you can see the percentage complete for each item on the list.
Now you know if that contractor has been paid and whether you can sign off on the contract.
You can even set up notifications to make sure your payments are delivered on time. Try it out
for yourself with this free trial.

3. Release Resources

You assemble a team for the project, and now you must cut them loose. It’s a formal process,
and a crucial one, which frees them for the next project. Each team is brought together for the
mix of skills and experience they bring to a project. The project determines the team members
you’ll want to work with, and each project is going to be a little bit different, which will be
reflected in the team hired to execute it.

This is true for internal as well as external resources. The external ones might be more obvious,
as you contracted with them, and that contract is going to have a duration. When it’s over, make
sure they’re all paid in full so they can sign off and leave. But internal resources remain, so you
have to remind yourself that their time on the project is also limited, and you might be blocking
other team’s projects if you don’t release your resources once the project is done.
4. Archive Documents

There are lessons to be learned from old projects, which is why you meet with your team
regularly during the project and look back on the process afterwards. However, if you don’t have
an archive in which to pull the old records, then whatever knowledge you gain is lost because of
poor organization and management. You worked hard to have great project documentation, don’t
lose it.

Before you close a project, archive all the documents and any notes and data that could prove
useful. Even if you never access it, there’s a need to keep a paper trail of the work done on any
project for other people in the organization. This might include legal teams, or HR teams, or
even your successor. You never know when someone might have to go back and respond to a
question or want to learn how an old issue was resolved. Consider it like putting away provisions
for the winter.

5. Celebrate Success

If it sounds silly to you, then you’re not doing your job. There’s nothing silly about rewarding
your team to acknowledge a job well done. It creates closure, which is what this part of the
project is all about, but it also plants a seed that will bloom in later projects when you work with
members of the old team.

Project Closure Checklist

To make sure you close your project properly, follow this step-by-step project closure checklist.

1. Start at the beginning with the project scope document you created and make sure
that you’ve met all the requirements listed there.

2. Make sure that all deliverables have been handed off and signed by stakeholders,
getting their approval and satisfaction.

3. Other project documents must also be signed by the appropriate person, this
includes any outstanding contracts and agreements with vendors and other
contractors.
 4. Once documents are signed off on, then process them and pay off all invoices and
close out any project-related contracts.

5. Add all documents together, including finalizing all project reports, then organize
and archive them as historical data to be used for future reference.

6. Use collected paperwork to identify and document the lessons learned over the
course of the project, including any feedback from stakeholders, so you don’t make
the same mistakes in future projects.

7. Assign a transition support person to shepherd the project after completion so that
the project closure is thorough.

8. Release or reassign the project resources, which includes your team and other
project personnel and any equipment or site rentals used for the project.

9. If you’ve not used a project management software, get one, as it helps control not
only the life cycle of the project but also the process of closing the project
thoroughly.

10. Finally, but perhaps most importantly, celebrate with your project team. They did
the work and deserve credit and an opportunity to blow off steam until the next
project is started.

Facing Project Closeout Challenges or Issues

Technical Challenges
 Start-up problems with new products or new designs
 Thorough identification and agreement on all remaining deliverables
 Loss of control of the charges to the project as things are winding down people start doing
'whatever it takes' to get through the final push often damaging the project budget
 Hand-off issues in transition to tech support
Project Team Challenges
 Loss of team functionality as some members complete their tasks
 Project team members become heavily involved in startup activities on new projects
 Loss of interest in tasks such as documentation and administrative work
 Fear of no future work team members and consultants may drag their feet
Customer Challenges
 Agreement on what outstanding commitments still exist
 Absence of a clear hand-off strategy
 Change of responsible personnel at critical transition points
 Unavailability of key personnel
 Difficulty agreeing on signoff on remaining punch-list issues
That final push should be easy but it isn't. This list probably isn't all-inclusive in fact I know it's
not and I welcome your thoughts and input on this. From my experience on projects that final
push has become the most difficult when a few remaining issues exist. What looked like a day's
work to resolve minor outstanding technical issues can sometimes becomes weeks full of effort
trying to go to an agreed upon stopping point. This is often due to the customer feeling like
they'll be left out in the cold if they agree to signoff and allow implementation with anything left
on the table in terms of issues.

What is project closure?

The project lifecycle consists of five groups:

 Initiating process group

 Planning process group
 Executing process group
 Monitoring and controlling process group
 Closing process group

The closing phase of project management is the final phase of the project lifecycle. This is
the stage where all deliverables are finalized and formally transferred, and all documentation
is signed off, approved, and archived.

The project closure process ensures that:

 All work has been completed according to the project plan and scope.
 All project management processes have been executed.
 You have received final sign-off and approval from all parties.

The project management closure process also gives the team the opportunity to review and
evaluate the project’s performance to ensure future projects’ success.

Importance of closing a project

At first glance, it might seem like completing the first four phases of the project lifecycle
would be all you need to do to tie up your project and call it good.
 However, without a formal closing process, you risk letting crucial details fall through the
cracks, which can result in confusion, a never-ending project, dissatisfied clients, and even
liability issues.

Project closure helps avoid:

 Repeating mistakes on future projects and objectives

 Having final products or deliverables without dedicated support and resources
 Failing to identify the team or individuals who will own and maintain the solution
following final delivery
 Creating liability issues resulting from incomplete payments, contracts, or deliverables

Following a clear project closure plan helps you properly transition your solution to the
client or end-user. This process ensures the final stakeholders have the information,
resources, and training to successfully manage and use the end product.

The project closure process also ensures the project is formally completed and is no longer
considered a project, allowing you to hand the reins over to the correct team in charge of
managing and maintaining the project’s outputs.

By officially closing a project, you minimize risks, increase client satisfaction, and ensure all
parties are on the same page. In other words, project closure is a process you can’t afford to
skip.

7 steps to closing a project

The closing phase of project management involves several steps. Work through the following
checklist to ensure your project is successfully completed.

1. Formally transfer all deliverables

The first step to closing out your project is to finalize and transfer the project deliverables to
the client. Go through your project plan to identify all deliverables and make sure they have
been fully completed and handed off.

2. Confirm project completion

Next, confirm the project is complete. It’s not enough to declare a project done yourself.
Each person involved needs to agree on the project’s completion before you can formally
close it out and move on.
 If you skip this step, you may continue to receive (and be charged for) change requests by
the client.

To confirm the project’s completion, obtain approvals for the project deliverables (i.e., all
stakeholders must agree that you delivered on all parts of the project plan) with official sign-
offs from the project stakeholders.

Be sure to document this step so you have proof that the project close was formally signed
off.

3. Review all contracts and documentation

Once you have completed the project hand-off and received approvals from the clients, you
can begin closing out your contracts.

Review all the project documentation to ensure all parties have been paid for the work and
there are no outstanding invoices.

4. Release resources

Formally release resources from the project, including suppliers, contractors, team members,
and any other partners. Notify them of the end of the project, confirm any final payments or
obligations, and officially release them so they are free to work on other projects.

5. Conduct a post-mortem

A post-mortem or project review is one of the most valuable steps of the project closure
process. This is a time to review the successes, failures, and challenges of the project and
identify opportunities for improvement going forward.

As you begin your post-mortem, conduct a performance review of the project. In other
words, calculate the project’s performance in terms of cost, schedule, and quality.

Consider these questions:

 Did you stay on budget?

 Did the team members involved manage their time wisely?
 Were there issues with the quality or compromises along the way?
 How closely did the project meet the customer's needs?

Next, conduct a survey or hold a meeting with the project management team to get feedback
on how the project went. These individual answers will help paint a more comprehensive
 picture of the project’s performance. (If you follow scrum methodology, your team should
conduct a sprint retrospective to gather this information.)

Have your team consider the following questions:

 What went well?

 What were the challenges or failures?
 How well did the team communicate?
 Did the team follow the outlined processes and plan?
 Was the client satisfied with the results?
 What would you change or improve for future projects?

With the project performance and feedback in mind, you can then identify lessons learned
and opportunities for the future.

hat is requirements gathering?

Requirements Gathering

Requirements gathering is the process of understanding what you are trying to build and why
you are building it. Requirements gathering is often regarded as a part of developing software
applications or of cyber-physical systems like aircraft, spacecraft, and automobiles (where
specifications cover both software and hardware). It can, however, be applied to any product or
project, from designing a new sailboat to building a patio deck to remodeling a bathroom.

Three Main Subprocesses of Requirements Gathering

The key ingredients of the requirements gathering process are three overlapping subprocesses:
requirements elicitation, requirements documentation, and requirements understanding.

Requirements elicitation is the process of asking for and collecting top-level requirements
from all relevant stakeholders. Effort should be made to account for the needs of
customers, their users, the internal stakeholders within your own company, and your
key suppliers.
Requirements documentation organizes the input from the requirements elicitation process
into whatever format is appropriate for your organization. This formatting may include:
 User stories
 Functional decompositions (especially for complex cyber-physical systems)
 Feature descriptions
These will be collected in a top-level requirements specification like a product requirements
document (PRD) or a system specification. The purpose of this top-level specification is to make
those stories and descriptions available to all members of the project team.
Requirements confirmation is the process of making sure all stakeholders and team members
have a common understanding of what you’re trying to build. This involves reviewing and
refining the requirements. It will very likely require additional elicitation and revision of
the documentation as well.
What are the Benefits of Requirements Gathering?

Beyond the obvious advantage of having requirements with which to work, a good
requirements gathering process offers the following benefits:

 Greatly improves the chances that customers and users will get what they
wanted. Stakeholders often have difficulty putting into words exactly what it is that
they need. You’re going to have to help them, and it’s going to take some digging.
 Decreases the chances of a failed project. A frequently heard lament following
unsuccessful projects is, “The requirements weren’t clear.”
 Reduces the overall cost of the project by catching requirements problems before
development begins. Requirements that are ambiguous or not fully understood often result
in costly scrap and rework. Numerous studies have shown that the cost of fixing requirements
errors rises exponentially over subsequent phases of development.
RELATED ARTICLE: Best Practices Guide to Requirements & Requirements Management
Some Key Challenges of Requirements Gathering

One of the reasons projects fail due to poor requirements is this: requirements gathering isn’t
easy. Here are some of the main challenges:

Finding All the Right Stakeholders

Projects often have “hidden” stakeholders. It’s important to uncover them. The group you canvas
should include more than just the obvious decision-makers. Don’t forget to talk to customer
support reps, maintenance technicians, and others who come into direct contact
with customers. They are themselves, in effect, users of your existing products.

“Disgruntled users who are forced to use a system every day that was designed without their
input are a key ingredient for a failed project,” says Jordan Hirsch, Director of
Innovation at Phase2 Technology.
Understanding What Stakeholders Really Want

Your stakeholders may not have a clear vision of what they want. They may not be able to tell
you a complete story. They may have hidden pain points or desires, unstated goals, or
assumptions. You’re going to have to ask a lot of probing questions and compare
answers. You’re also going to have to go through several iterations of your process to arrive at a
consensus.
Planning for Change

Throughout the requirements gathering process, you’re going to come across questions you
forgot to ask and things stakeholders forgot to tell you. You’ll come up against shifting
priorities and problems encountered during implementation.

It’s wise to have a plan for dealing with those changes. You’ll need to allow time for addressing
problems, documenting new requirements, and conducting additional reviews.

A 6-Step Requirements Gathering Process

The requirements gathering process consists of six steps. Three of those (steps three through five
—the bulk of the process) we’ve already mentioned as the key subprocesses of requirements
gathering. The full six steps are:

 Identify the relevant stakeholders

 Establish project goals and objectives
 Elicit requirements from stakeholders
 Document the requirements
 Confirm the requirements
 Prioritize the requirements

It is important to note that while these steps are typically initiated in the order listed, there is a
great deal of overlap and iteration among them. It may, therefore, be better to think of them as
subprocesses rather than steps as we look at each one individually.

Identify the Relevant Stakeholders

Find qualified representatives from each relevant stakeholder group. Depending on your
project, these may include:

 Customers stakeholders
 Decision-makers
 Users
 System administrators
 Other impacted customer departments
 Internal stakeholders
 Executives
 Engineering
 Marketing
 Sales
  Customer support (including on-site maintenance teams, if applicable)
 Key suppliers
 Distributers and other partners

Remember to search for “hidden stakeholders.” Ask probing questions in early meetings, before
you begin eliciting requirements. Identify all stakeholder groups who need to be
involved. Ideally, you want input from every group who has skin in the game; give them all the
opportunity to state their needs.

Establish Project Goals and Objectives

What are you trying to achieve with this new product or project? What are the overall outcomes
your customers want from the product? What are your company’s business goals? What are the
actionable, measurable objectives you need to achieve to realize those goals and outcomes?

Write them down. State them clearly, and get all your stakeholders to sign-off on them. Your
goals and objectives will act as a framework for your decision-making.

Each requirement you write should help satisfy a project objective and accomplish a goal. If it
doesn’t, you should either discard it or made it a candidate for a future release.

Elicit Requirements From Your Stakeholders

This is the first of three requirements gathering subprocesses which are highly iterative and
overlapping. Even in an agile environment, you are likely to go through several cycles of
elicitation, documentation, and review/confirmation before you achieve a workable specification
to begin development.

Elicitation can be performed in several ways. Time-tested techniques include surveys,

questionnaires, and interviews. Interviews and follow-up meetings will be prevalent during later
iterations.

Be sure to listen actively during interviews. Ask probing questions and take copious
notes. Afterward, organize your notes and follow up as necessary. Document
each exercise or encounter thoroughly.

Document the Requirements

As soon as requirements begin to emerge from your elicitation process, start documenting them.

Write them down and collect them in whatever format your organization has agreed upon. That
could be a product requirements document (PRD) of your company’s design, a government-
mandated system requirements specification, a vendor-supplied requirements
management (RM) tool like Jama Connect, a spreadsheet, a database, or any
other appropriate repository your entire team can access.

What’s most important is that the requirements documentation…

  Can be easily navigated and understood by your team
 Is available for review by all stakeholders
 Provides a facility for traceability to other documentation.

Templates are extremely useful, both for the specification as a whole and for individual
requirements. Solid, battle-tested templates and standardized formats help provide clarity and aid
navigation.

Confirm the Requirements

Review the requirements with all stakeholders. Make sure the requirements clearly capture what
was intended and that all parties have a common understanding of each of them. If you find any
ambiguity in a requirement, revise it.

You should also validate your requirements through prototyping and testing, where
possible. Modern prototyping tools make it fast and easy to create a working model of your
specification. You can then use that model to perform feasibility, usability, and product concept
testing.

Get stakeholder sign-off on individual requirements as you get them nailed down. Do the same
for the specification as a whole during a final review.

Prioritize the Requirements

Most engineering development programs run into unexpected challenges along the
way. Unanticipated obstacles are encountered. Schedules slip. Priorities change. It’s important to
be able to adapt to those challenges and changes.

That’s why it is crucial to prioritize your requirements based on how each will impact your goals
and objectives for your release.

Many product managers prioritize features by tagging them with labels, such as “must have,”
“high want,” and “nice to have.” But it’s also important to rank order each requirement within
those categories. There are two reasons for this.

The first is time to market. Schedules often slip. When they do, you may need to trim features
and requirements to meet your release date. You don’t want your team implementing the easiest
requirements first only to find that there’s not enough time to complete all your must-haves.

The second reason is that requirements evolve. During implementation, you’re likely to discover
new needs. Some may be critically important and supersede existing requirements in terms of
priority. You need to know where those new requirements fit in your pecking order. If you don’t,
less important factors will determine what gets implemented first, which may have an
adverse impact on your product’s success.
Common Requirements Gathering Pitfalls

Beware of simple, broad requirements. Don’t assume you know exactly what they mean. Above
all, don’t assume all your stakeholders interpret those requirements in the same way.

Broad statements like, “The site shall have a blog” can mask a host of underlying assumptions.
Scrutinize such requirements. Ask lots of questions. How will posts be displayed? How should
authors be managed? How about comments, categories, tagging? Should there be an RSS feed?
… and so forth.

Cross-check the answers you receive. Then come up with a set of more specific, verifiable
requirements that everyone can agree upon.

Focusing on HOW Instead of WHAT

Requirements address two things. The first is WHAT the product must do (the functional
requirements). The second is the necessary constraints on how the product does what it
does (the non-functional requirements).

Requirements should not address HOW the product does what it has to do. In other words, your
specification should be as implementation-agnostic as possible, within the constraints of the non-
functional requirements.

During requirements elicitation, try not to think about how you’re going to implement the
product. Forget about the latest technology your engineering department is obsessed with, your
software team’s tool du jour, the features you feel are missing from the product baseline. Focus
instead on your stakeholders’ needs.

Listen to what your stakeholders are saying first. Then gather, review and refine your
requirements. Finally, once you’ve done all that, find the gaps in your baseline, and determine
which technologies will deliver what your customers and stakeholders really want.

Insufficient Consultation With Stakeholders

Perhaps the biggest mistake systems engineers and product managers make in
gathering requirements is failing to adequately consult with their stakeholders. Stakeholder
consultation has several facets.

First, it is critically important that you drill down (and follow up) with each stakeholder group to
fully understand their needs. Failure to do so is one of the leading causes of requirements
failures.

A second important facet is transparency. Clean up your notes and share them after every
interview, meeting, and survey. The easiest way to do this is through a modern RM tool to which
all team members have access. Tools like Jama Connect allow you to attach notes to the
requirements themselves for traceability purposes. This greatly increases the speed of the process
and simplifies the review task.
The third potential pitfall in this area is insufficient review. Be sure to hold reviews where
stakeholders can review the requirements, provide feedback, voice objections, and defend their
positions. Open discussions involving all concerned stakeholders can help uncover and correct
requirements flaws and achieve consensus.

Dimensions of Requirement Gathering

The requirement gathering is process of requirements discovery or generating list of requirements or collecting
many requirements as possible by stakeholders. It is also called as requirements elicitation or requirement
capture.
Various Dimensions of requirements gathering are:
1. Stakeholders –
The stakeholder means person with interest or concern in outcome of project who is affected by system.
For example- end-user, system maintenance engineer or administrator, software developer, direct user,
indirect user, senior manager, etc. By collecting requirements from these stakeholders, understanding
system requirements can be very easy.
2. Interviewing –
Interviewing is important and very effective method of requirement gathering. Different questions are
being asked about system and its uses to stakeholders by team of requirement engineering so that
identification of requirements can be done using these answers. There are two types of interviewers:
Shrinkwrap Software means third party software sold in a standard configuration and readily
available to the public on standard terms and conditions; Sample 1 Sample 2 Sample 3 Based on 9 documents Save
Copy Remove Advertising Shrinkwrap Software means generally commercially available “off the shelf” software that
may be obtained on generally commercially available terms and conditions at prices that do not exceed $10,000.
Shrinkwrap Software does not include freeware, open source and shareware software generally available over the
Internet at no cost to the user. Sample 1 Sample 2 Sample 3 Based on 5 documents Save Copy Shrinkwrap
Software means "off-the-shelf" computer software applications, other than Company Owned IP, that are generally
available to all interested purchasers and licensees on standard terms and conditions. Section 2.15(b) of the Company
Disclosure Schedule accurately (i) identifies all Company Licensed IP (A) that is incorporated in Company's products
provided to customers or provided to customers in connection with products or services of the Company; (B) is
"resold" or sublicensed to customers by the Company; (C) that is used by the Company as a development tool,
excluding Shrinkwrap Software, or (D) is material to the Company's business and is not covered under (A), (B) or (C),
and is not Shrinkwrap Software; (ii) identifies the license or other agreement or understanding pursuant to which such
Company Licensed IP is being licensed to or used by the Company or any Subsidiary (each, a "LICENSE-IN
AGREEMENT"); and (iii) sets forth a complete and accurate list of the amount of any remaining unused prepaid
royalty and identifies those License-In Agreements under which royalty or license fee (excluding fees for maintenance
and support), may become payable by the Company or such Subsidiary, as applicable, thereunder by reason of the
passage of time, use or exploitation of the Intellectual Property licensed thereunder. The rights licensed under each
License-In Agreement shall be exercisable by the Surviving Corporation on and after the Closing to the same extent
and at the same cost as the Company or such Subsidiary, as applicable, prior to the Closing and no party granting such
rights has given formal written notice to the Company or, to the Company's knowledge, threatened that it intends to
terminate such License-In Agreement prior to the expiration thereof in accordance with its terms.

The term” Shrinkwrap Software “ initially used to describe an unsigned software license agreement
that is deemed accepted when the user breaks a shrink-wrapped seal or opens an enclosed sealed envelope
in the package containing the software media, such as a floppy disk or CD.
Top 5 Challenges in Requirement
Management
Whether you are doing Project Management or Business Analysis, the foundation of Success
or Failure of the exercise is REQUIREMENT. Get it right, and you are on your way to
achieving success in the Business Analysis or Project Management assignment. I sampled
results of research studies conducted by several organizations and institutions between 2010
and 2016 on reasons for project failure, and one common factor reported by over 95% of
these studies is inadequate/poor requirements definition and management. Also, after being
involved in several projects and initiatives both in Project Management and Business
Analysis capacities across many industries, I have realized the importance of Requirement
Management.
I have outlined the top 5 challenges faced in Requirement Management. This list is as a
result of personal experience, discussions with Business Analysis and Project Management
practitioners and a mini-survey conducted across a community of practitioners.
Note: Requirement Management, in this context, covers the whole spectrum ranging from
Elicitation, Analysis, Verification, Documentation, and Validation.
1. Conflicting Requirements: No matter the scope and context of your project or business
analysis exercise, you are certain to have more than 3 stakeholders or stakeholder groups
whose requirements and needs must be managed (starting right from elicitation). And
because these stakeholders or stakeholder groups have different needs and represent different
interests within the business, there are always issues aligning their requirements. From my
experience, this is the topmost challenge I have faced in managing requirements. I recall
having this major challenge on one of the projects I managed for a top stockbroking firm in
Africa. The project involved deploying a self-service, interactive and transactional trading
portal for the firm’s clients where the clients can trade on stocks and shares directly from the
portal without recourse to the company. One of the major requirements on the project was
“User Idle Timeout (a maximum time for the user to stay logged in and not perform any
activity on the portal). The business wanted to have the clients perpetually logged on (set at
infinity), except if they decide to log out solely because the clients need to do some research
before taking a position on a particular stock, while the IT Security Executive, another
stakeholder on the project, recommended an idle timeout of 2 minutes. This conflicting
requirement took us about 4 additional days of back and forth before agreeing to a 5-minute
idle timeout. This happens on almost every project I have handled until I started using
Facilitated Workshop technique for Requirement Elicitation.
2. Customers don’t know what they want: Let’s be factual, more often than not,
customers don’t know exactly what they want. This is a huge challenge for the Business
Analyst and Project Manager during Requirement Gathering. How do you elicit, analyse or
document what is not knows? This challenge often leads to the technique called IKIWISI
(I’ll know It When I See It). But a downside of IKIWISI is that it can easily lead to Scope
Creep, which is an ingredient to Project Failure in itself.
3. Unavailability of Stakeholders: Irrespective of the technique you have chosen to use in
your requirement elicitation, be it interview, observation/shadowing, focus group,
requirement workshop, prototyping, name it. You need to meet with Stakeholders. These are
the guys with needs and expectations for the change or project you are working on, but
scheduling a meeting or session with these stakeholders has always been a challenge. They
are just not available, either due to their busy schedule or they are not interested in the
CHANGE or project (hopefully, this is not the case). I had a key stakeholder, a representative
from the user community on one project I worked on in the past who took over 2 weeks to
track and get him to sit with me for 30 minutes to elicit their requirements. Unfortunately, no
one could take his place. Imagine 2 weeks added to a 3 months change project.
4. Changing Priorities: For a lack of better word, I have used the word “Changing
Priorities”, but more bluntly said, it would be “Customers keep changing their minds”. This
is a VERY common, rampant, and tiring challenge I and couple of other practitioners have
experienced on BA and PM engagements. I can authoritatively say I have experienced this
challenge in 7 out of every 10 projects I worked on in the past. The customer comes with one
set of requirements, the next hour, they are changing the requirements, irrespective of
whether the Business Requirement Document has been signed-off. A typical example of this
challenge was while working on an initiative for a stock broking firm to develop a self-
service trading portal for their investors, same project I referenced above. During
requirement elicitation, the business owner was very emphatic about online chat integration
as a Must-Have requirement/feature. During implementation, the stakeholder called a
meeting and decided to expunge that requirement, and replace with google map integration in
the contact us page. The next review process, she was thinking and having another idea,
hence a completely new requirement, different from what was elicited earlier. I find this
challenge quite common when doing Requirement Management.
5. Unsupportive Stakeholders: Well, maybe this is not as rampant on projects as the other
four, but I have faced lots of challenges on requirement management when the stakeholders
do not buy into the change. This could be as a result of a segregation between senior
management and the user community or sheer lack of enthusiasm towards the change being
implemented. A while ago, I was working on an automation initiative as part of a firm’s
digital transformation program, and part of the process included understanding the current
(manual) process (AS-IS), identifying bottlenecks and improvements, to be able to develop
the future (TO BE) process. Unfortunately, the key stakeholders felt this automation would
render them redundant and threaten their jobs. So, we faced a lot of restriction and challenges
while meeting with them to elicit requirements of the current process or identify
improvement opportunities.
Whilst I believe some of the highlighted challenges can be addressed by implementing the
Agile method, there are still some residual challenges.
What is Estimations
Estimation of all kinds are entrenched in our day-to-day life. When we plan a trip, we
usually estimate expenses for accommodation, meals, and transportation. We also calculate
how much time we need to get to the hotel and the airport, figuring out the shortest route. We
also set our priorities and do our best to stick to them.
In software development, accurate estimating is far more vital since the success of your
effort is at stake. As a project manager or business owner, your top priority is to meet
deliverables' time-frames and optimize the budget.
The biggest challenge with project estimation is that there's also a great deal of ambiguity
when it comes to software development. It can be hard to assume how much it'll cost on the
first try, as a lot of factors are at play. It can even take hours of preliminary research and
coming up with unconventional methods how to tackle it. However, you can try to use the
standard approaches we have described below and see if they work.
what is project estimation ,when and why it is
done?
Generally speaking, it's the process of analyzing available data to predict the time, cost, and
resources needed to complete a project. Typically, project estimation includes scope, time-
frames, budget, and risks.
Key Components of Project Estimation
Scope
project scope as a detailed outline of all aspects of a project, including all related activities,
resources, timelines, and deliverables, as well as the project's boundaries. The project scope
also outlines key stakeholders, processes, assumptions, and constraints, as well as what the
project is about, what is included, and what isn't. All of this essential information is
documented in a scope statement.
The project statement of work (SoW) details all aspects of the project, from the software
development life cycle to key meetings and status updates. Accurately estimating the
project's scope means you can have a more precise understanding of the cost, time-frames,
and potential bottlenecks.
Time-frame
With a scope of work on hand, it's easier to estimate how long it’s going to take to achieve
each milestone. Make sure the time-frame allows time for management and administration.
Also, make sure you prioritize tasks, identifying those that need to be completed before
others. Some factors might also slow things down, like meetings, holidays, interruptions of
all sorts, and rejections from Quality Assurance.
A proper timeline estimation covering all elements of the project will show you how much
time will go into completing different parts, inter dependable deliverables, and when each
major milestone will be achieved.
Resources
Defining the scope of work and timeline makes it easier to understand what resources the
project needs. Resources are staff, vendors, contractors as well as equipment. You should
allocate resources for the tasks in the scope of work. Before you do that, you need to know
their availability and schedule in advance. This way, you increase the reliability of a project.
Cost
Cost is an essential part of a project. Everyone wants to know how much it will cost to
develop a project before delving into it. To predict the project cost, you need to consider the
scope, timeline, and resources. With these aspects mapped out, you can have a rough
estimate of your project.
You can base your estimation on past project costs. If you don't have your own historical
data, it's best to ask someone who has already developed a similar project to advise budget-
wise. The more accurate information you have, the closer project estimates will be.
Risks
Every project comes with risks. However, it's possible to identify them and devise strategies
to handle them. An ideal project estimation document includes potential risks as a sort of
insurance against threats in the project. After the risks are identified, you need to prioritize
them and recognize their probability and impact.
How to Estimate a Project?
Here're common techniques you can use to estimate your project.
Top-Down estimating
It's a technique whereby the overall project is estimated as a whole, and then it's broken
down into individual phases. You can use this approach based on your historical data, adding
estimation for each project element. Top-down assessment isn't detailed, so it's only suitable
for rough budget estimation to see if it's viable.
Bottom-Up estimating
This method uses a detailed scope of work and suits projects you've decided to go with. The
bottom-up approach suggests estimating each task and adding the estimates to get a high-
level assessment. This way, you make a big picture from small pieces, which is more time-
consuming but guarantees more accurate results than the Top-Down Estimate.
Expert estimation
This kind of estimation is the quickest way to estimate a project. It involves an expert with
relevant experience who applies their knowledge and historical data to estimate a project. So,
if you've already executed a similar project, you can use a top-down or bottom-up estimation
by an expert.
If it's not your typical project, you need to gather a tech and domain experts team to do the
assessment. This team of experts isn't necessarily a part of the project team. However, it's
highly recommended to engage an architect, tech lead, or systems analyst.
Analogous estimation
 You can use it when the information about a project is limited and you've executed a similar
one in the past. Comparing a project with the previous one and leaning on historical data can
give you insight into a project you have on the anvil. For more precise estimation, you
should choose a project that's a likeness of your current one. Then, you'll be able to сompare
the two projects to get an estimation. The more similarities the projects have, the more
precise estimation will be.
Parametric estimation
If you're looking for accurate estimation, a parametric approach is a good solution. It relies
on historical data to ca lculate estimation coupled with statistical data. Namely, it uses
variables from similar projects and applies them to a current one. The variables can be
human resources, materials, equipment, and more.

Analogous vs. Parametric Estimation

So, where to start?
As your first step, we'd recommend defining the scope of a project, including the following:
 Stakeholders and Product Owners;
 Business needs;
 Functionality that goes back to business needs;
 How the functionality should be implemented;
 Time-frames for each element of functionality;
 Cost of the project;
Cost estimation is a vital step that requires knowledge and experience. Even experienced
managers make mistakes, affecting the project's scope, and leading to delays and overworked
teams. That’s why it's best to start with a Discovery Phase, and based on its results, you'll get
an architecture of the software and the necessary document with the project scope.
 6 Successful Project Estimation Techniques
There are many different types of project estimation techniques used in Project Management with various streams
like Engineering, IT, Construction, Agriculture, Accounting, etc. A Project manager is often challenged to align
mainly six project constraints - Scope, Time, Cost, Quality, Resources, and Risk in order to accurately estimate
the project. The common questions that come into the mind of a project manager at the start of the project are–

 How much work is to be estimated (scope).

 How to estimate the project (techniques).

 How much time it will require to complete the project (Schedule).

 Who will be doing the project (resources)?

 What is the budget required to deliver the project (cost)?

 Any intermediary dependencies that may delay or impact the project (Risks).

What are Project Estimation Techniques?

Project estimation techniques refer to the procedures and tools used to develop rough
calculations of various aspects of any project. An excellent example of this is a project cost
estimate that provides an overview of the anticipated expenses associated with the project.

Whenever stakeholders or clients require information on any project aspect, these techniques
help project managers evaluate realistic numbers essential to plan a project successfully.

Why is Project Estimates Important?

Accurate estimates are critical to plan and execute a project successfully. Without precise
estimates, it becomes tough to determine how long a project will take or the number of resources
required.

Project managers use these estimates to ensure the team has the right people, materials, and tools
available whenever needed. These estimates also help managers set realistic goals and
expectations for the team members and the stakeholders.
 Who Estimates Projects?
Estimating a project is typically done by the project team. Although the project manager may be
in charge of the database or documents used to record estimates, the whole team and subject
matter experts need to participate in creating and refining the estimates.

Engaging more knowledgeable individuals in the estimation process increases the chances of
generating realistic figures. The project manager ensures the estimates are complete and updated
whenever necessary.

The 3 Major Parts to Project Estimation

 Effort estimation
 Cost estimation
 Resource estimate
While accurate estimates are the basis of sound project planning, there are many techniques used
as project management best practices in estimation as - Analogous estimation, Parametric
estimation, Delphi method, 3 Point Estimate, Expert Judgment, Published Data Estimates,
Vendor Bid Analysis, Reserve Analysis, Bottom-Up Analysis, and Simulation. Usually, during
the early stages of a project life cycle, the project requirements are feebly known and less
information is available to estimate the project. The initial estimate is drawn merely by
assumptions knowing the scope at a high level, this is known as ‘Ball-park estimates’, a term
very often used by project managers.

Project Estimation Techniques

1. Top-Down Estimate

Once more detail is learned on the scope of the project, this technique is usually followed where
high-level chunks at the feature or design level are estimated and are decomposed progressively
into smaller chunks or work-packets as information is detailed.

2. Bottom-Up Estimate

This technique is used when the requirements are known at a discrete level where the smaller
workpieces are then aggregated to estimate the entire project. This is usually used when the
information is only known in smaller pieces.

3. Analogous Estimating

This project estimation technique is used when there is a reference to a similar project executed
and it is easy to correlate with other projects. Expert judgment and historical information of
similar activities in a referenced project are gathered to arrive at an estimate of the project.

4. Parametric Estimate

This technique uses independent measurable variables from the project work. For example, the
cost for construction of a building is calculated based on the smallest variable as the cost to build
a square feet area, the effort required to build a work packet is calculated from the variable as
lines of codes in a software development project. This technique gives more accuracy in project
estimation.

5. Three-point Estimating

This technique uses a mathematical approach as the weighted average of an optimistic, most
likely and pessimistic estimate of the work package. This is often known as the PERT (Program
Evaluation and Review Technique).

6. What-If Analysis

This project estimation technique uses assumptions based on varying factors like scope, time,
cost, resources, etc., to evaluate the possible outcomes of the project by doing impact analysis. In
a usual scenario, the project estimate is done by conducting estimation workshops with
the stakeholders of the project, senior team members who could give valuable inputs to the
estimation exercise. The high-level scope is broken down into smaller work packages,
components, and activities, each work package is estimated by effort and resources needed to
complete the work package. The project may be detailed into the smallest chunk that can be
measured.
 The following activities are done during the workshop:

 Break down the scope into smallest work package, components or activities (WBS)
 Sequence the activities in the order in which they will be performed
 Identify the effort required to complete each activity
 Identify the resource estimate to complete each task or activity
 Identify the dependencies to complete each activity
 Identify the possible risks and assumptions
 Define the resource and cost estimate to the completion of each activity, component and work
package

When Should Estimates Take Place?

In a Waterfall project that follows a traditional approach, the planning phase occurs after project
initiation. During this phase, estimates are made and recorded for different aspects such as scope,
cost, time, resources, quality, and risks. These estimates may be subject to adjustments
throughout the project as and when new information arises. For example, if new risks are
identified, project risk estimates must be updated accordingly.

Agile projects, on the other hand, adopt a more iterative planning approach. Such projects are
usually divided into sprints or iterations in most Agile frameworks. During the initial stage,
estimates are created when compiling the overall project backlog - a list of features and
requirements. During each sprint, estimates are updated either in the sprint retrospective or the
sprint planning session for each new sprint.

Conclusion

Project estimation techniques are essential to accurately estimate several project aspects such as
cost, time, scope, and more. An accurate estimate helps project managers plan and execute
projects effectively while ensuring the right resources are available when necessary.

Suppose you want to learn more about the different types of project estimation techniques or
gain an in-depth understanding of project management. In that case, a PMP® Certification
Training course can help you learn, get certified, and apply these estimation techniques
effectively. The course highlights the role of project managers while focusing on new
technologies, emerging trends, and core competencies that a project manager should possess.
 Three Phases of Project Estimation

Project work estimation has three components: the initial first cut, commonly known as a SWAG
(scientific wild-ass guess), tracking the estimate against the actual numbers, and using the
schedule to see what's happening in your project.
If you've been assigned project estimates, or if your project estimates aren't particularly close to
reality, don't fret. Try these techniques to make and learn about your estimates.
Part 1: Create an Initial Estimate
If you're a project manager, you probably try to estimate the work at the beginning of the project,
even if you're assigned a project end date. Sometimes senior managers have trouble hearing what
you've said in your estimate. I use one of these three alternatives to creating estimates for the
entire project:

1. Provide a date range for the estimate: "We'll be able to release between May 1 and June 15."
Some senior managers can't hear the second half of that statement; they only hear May 1. If you
work for a manager like that, try either of these other two suggestions.
2. Use the word about to describe the precision of the estimate: "Five people for about nine months
or 10 people for about six months." You haven't described an end date, but you have explained
the resources you'll require.
3. Provide a confidence level to describe the range of dates: "I have 90% confidence in June 1, and
100% confidence in Aug. 1." In my experience, even the managers who can't hear the "between"
estimate can hear my confidence levels.

Once you have a gross estimate at the beginning of the project, you can drill down and create
estimates for each of the project components. Whether you try to create precise estimates or
choose to use slack buffers to deal with incomplete estimates, you will have some project
estimate total.
The problem with estimates is that they are guesses. They're the best guesses we can make, but
they're still guesses. As the project unfolds, you 'll be able to acquire feedback on how well you
estimated using the second part of estimation, the EQF, or estimation quality factor.
Part 2: Track EQF to Understand the Project Estimate
As you continue to manage the project, track your initial completion date estimate. Each month
(or in a short project, each week), take five minutes out of your project team meeting and ask,
"When do you think we will finish the project?" Track that estimate on a chart set up with the
release dates on the Y axis, and the date that you asked the question on the X axis.
There are two good reasons for asking this question. First, you continue to focus your project
staff on completing the project. People tend to work on what you, the project manager, focus on.
Second, by asking your project staff, you can discover the various confidences they have in the
release date. When you look at the EQF chart, you can see if people are concerned that the
project won't meet its release date, or if they're feeling confident about meeting or beating the
release date. Then you can deal with their concerns or your own.
When you track EQF with your project team, you're learning more about the project and using
EQF to learn how good your initial estimate was.
Part 3: Use EQF to Manage Project Concerns
I use the slope of the EQF to make queries like, "Tell me what's happened in the project to make
you think we will meet/beat/miss the date." When people become more optimistic or pessimistic,
I want to know why. The EQF not only gives me feedback on my initial estimate; it also gives
me another technique to discuss the project state with the project team.
And once I understand the project team's concerns, I can deal with them or elevate those
concerns to my management.
If you're using only one of these techniques to estimate and manage your projects, consider
adding the other two. Every project worth completing has some uncertainty. EQF is a great
technique for displaying project uncertainty and for understanding why the team is uncertain
about the project.
The better everyone understands the project, the better your project management will be, and the
more likely you are to meet your SWAG. At least you'll know how far off your SWAG was and
why. And that knowledge can help you on your next project.

Cost Estimation Models

Cost estimation simply means a technique that is used to find out the cost estimates.
The cost estimate is the financial spend that is done on the efforts to develop and test
software in Software Engineering. Cost estimation models are some mathematical
algorithms or parametric equations that are used to estimate the cost of a product or a
project.
Various techniques or models are available for cost estimation, also known as Cost
Estimation Models as shown below :

1. Empirical Estimation Technique –

Empirical estimation is a technique or model in which empirically derived formulas
are used for predicting the data that are a required and essential part of the software
 project planning step. These techniques are usually based on the data that is
collected previously from a project and also based on some guesses, prior
experience with the development of similar types of projects, and assumptions. It
uses the size of the software to estimate the effort.
In this technique, an educated guess of project parameters is made. Hence, these
models are based on common sense. However, as there are many activities involved
in empirical estimation techniques, this technique is formalized. For example Delphi
technique and Expert Judgement technique.
2. Heuristic Technique –
Heuristic word is derived from a Greek word that means “to discover”. The heuristic
technique is a technique or model that is used for solving problems, learning, or
discovery in the practical methods which are used for achieving immediate goals.
These techniques are flexible and simple for taking quick decisions through shortcuts
and good enough calculations, most probably when working with complex data. But
the decisions that are made using this technique are necessary to be optimal.
In this technique, the relationship among different project parameters is expressed
using mathematical equations. The popular heuristic technique is given
by Constructive Cost Model (COCOMO). This technique is also used to increase or
speed up the analysis and investment decisions.
3. Analytical Estimation Technique –
Analytical estimation is a type of technique that is used to measure work. In this
technique, firstly the task is divided or broken down into its basic component
operations or elements for analyzing. Second, if the standard time is available from
some other source, then these sources are applied to each element or component of
work.
Third, if there is no such time available, then the work is estimated based on the
experience of the work. In this technique, results are derived by making certain basic
assumptions about the project. Hence, the analytical estimation technique has some
scientific basis. Halstead’s software science is based on an analytical estimation
model.

Models for Size Estimation-

Project size estimation is a crucial aspect of software engineering, as it helps in planning
and allocating resources for the project. Here are some of the popular project size
estimation techniques used in software engineering:
Expert Judgment: In this technique, a group of experts in the relevant field estimates the
project size based on their experience and expertise. This technique is often used when there is
limited information available about the project.
Analogous Estimation: This technique involves estimating the project size based on the
similarities between the current project and previously completed projects. This technique is
useful when historical data is available for similar projects.
Bottom-up Estimation: In this technique, the project is divided into smaller modules or tasks,
and each task is estimated separately. The estimates are then aggregated to arrive at the overall
project estimate.
Three-point Estimation: This technique involves estimating the project size using three
values: optimistic, pessimistic, and most likely. These values are then used to calculate the
expected project size using a formula such as the PERT formula.
Function Points: This technique involves estimating the project size based on the functionality
provided by the software. Function points consider factors such as inputs, outputs, inquiries,
and files to arrive at the project size estimate.
Use Case Points: This technique involves estimating the project size based on the number of
use cases that the software must support. Use case points consider factors such as the
complexity of each use case, the number of actors involved, and the number of use cases.
Each of these techniques has its strengths and weaknesses, and the choice of technique
depends on various factors such as the project’s complexity, available data, and the expertise
of the team.
Estimation of the size of the software is an essential part of Software Project Management. It
helps the project manager to further predict the effort and time which will be needed to build
the project. Various measures are used in project size estimation. Some of these are:
 Lines of Code
 Number of entities in ER diagram
 Total number of processes in detailed data flow diagram
 Function points
1. Lines of Code (LOC): As the name suggests, LOC count the total number of lines of source
code in a project. The units of LOC are:
 KLOC- Thousand lines of code
 NLOC- Non-comment lines of code
 KDSI- Thousands of delivered source instruction
The size is estimated by comparing it with the existing systems of the same kind. The experts
use it to predict the required size of various components of software and then add them to get
the total size.
It’s tough to estimate LOC by analyzing the problem definition. Only after the whole code has
been developed can accurate LOC be estimated. This statistic is of little utility to project
managers because project planning must be completed before development activity can begin.
Two separate source files having a similar number of lines may not require the same effort. A
file with complicated logic would take longer to create than one with simple logic. Proper
estimation may not be attainable based on LOC.
The length of time it takes to solve an issue is measured in LOC. This statistic will differ
greatly from one programmer to the next. A seasoned programmer can write the same logic in
fewer lines than a newbie coder.
Advantages:
 Universally accepted and is used in many models like COCOMO.
 Estimation is closer to the developer’s perspective.
 Simple to use.
Disadvantages:
 Different programming languages contain a different number of lines.
 No proper industry standard exists for this technique.
 It is difficult to estimate the size using this technique in the early stages of the project.
2. Number of entities in ER diagram: ER model provides a static view of the project. It
describes the entities and their relationships. The number of entities in ER model can be used
to measure the estimation of the size of the project. The number of entities depends on the size
of the project. This is because more entities needed more classes/structures thus leading to
more coding.
Advantages:

 Size estimation can be done during the initial stages of planning.

 The number of entities is independent of the programming technologies used.
Disadvantages:
 No fixed standards exist. Some entities contribute more project size than others.
 Just like FPA, it is less used in the cost estimation model. Hence, it must be converted to
LOC.
3. Total number of processes in detailed data flow diagram: Data Flow Diagram(DFD)
represents the functional view of software. The model depicts the main processes/functions
involved in software and the flow of data between them. Utilization of the number of functions
in DFD to predict software size. Already existing processes of similar type are studied and
used to estimate the size of the process. Sum of the estimated size of each process gives the
final estimated size.
Advantages:
 It is independent of the programming language.
 Each major process can be decomposed into smaller processes. This will increase the
accuracy of estimation
Disadvantages:
 Studying similar kinds of processes to estimate size takes additional time and effort.
 All software projects are not required for the construction of DFD.
4. Function Point Analysis: In this method, the number and type of functions supported by
the software are utilized to find FPC(function point count). The steps in function point analysis
are:
 Count the number of functions of each proposed type.
 Compute the Unadjusted Function Points(UFP).
 Find Total Degree of Influence(TDI).
 Compute Value Adjustment Factor(VAF).
 Find the Function Point Count(FPC).
The explanation of the above points is given below:
 Count the number of functions of each proposed type: Find the number of functions
belonging to the following types:
 External Inputs: Functions related to data entering the system.
 External outputs: Functions related to data exiting the system.
 External Inquiries: They lead to data retrieval from the system but don’t change
the system.
 Internal Files: Logical files maintained within the system. Log files are not
included here.
 External interface Files: These are logical files for other applications which are
used by our system.
 Compute the Unadjusted Function Points(UFP): Categorise each of the five function
types like simple, average, or complex based on their complexity. Multiply the count of
each function type with its weighting factor and find the weighted sum. The weighting
factors for each type based on their complexity are as follows:
 Function type Simple AverageComplex

External Inputs 3 4 6

External Output 4 5 7

External Inquiries 3 4 6

Internal Logical Files 7 10 15

External Interface Files 5 7 10

 Find Total Degree of Influence: Use the ’14 general characteristics’ of a system to find the
degree of influence of each of them. The sum of all 14 degrees of influence will give the
TDI. The range of TDI is 0 to 70. The 14 general characteristics are: Data Communications,
Distributed Data Processing, Performance, Heavily Used Configuration, Transaction Rate,
On-Line Data Entry, End-user Efficiency, Online Update, Complex Processing Reusability,
Installation Ease, Operational Ease, Multiple Sites and Facilitate Change.
Each of the above characteristics is evaluated on a scale of 0-5.
 Compute Value Adjustment Factor(VAF): Use the following formula to calculate VAF
VAF = (TDI * 0.01) + 0.65

 Find the Function Point Count: Use the following formula to calculate FPC
FPC = UFP * VAF
Advantages:
 It can be easily used in the early stages of project planning.
 It is independent of the programming language.
 It can be used to compare different projects even if they use different technologies(database,
language, etc).
Disadvantages:
 It is not good for real-time systems and embedded systems.
 Many cost estimation models like COCOMO uses LOC and hence FPC must be converted
to LOC.