UNIT 1

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

• Software Creation
• Software Project Management

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

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

• Every project may has a unique and distinct goal.

• Project is not routine activity or day-to-day operations.
• Project comes with a start time and end time.
• Project ends when its goal is achieved hence it is a temporary phase in the lifetime of an
organization.
• Project needs adequate resources in terms of time, manpower, finance, material and
knowledge-bank.

Software Project

A Software Project is the complete procedure of software development from requirement

gathering to testing and maintenance, carried out according to the execution methodologies, in a
specified period of time to achieve intended software product.

Need of software project management

Software is said to be an intangible product. Software development is a kind of all new stream in
world business and there’s very little experience in building software products. Most software
products are tailor made to fit client’s requirements. The most important is that the underlying
technology changes and advances so frequently and rapidly that experience of one product may
not be applied to the other one. All such business and environmental constraints bring risk in
software development hence it is essential to manage software projects efficiently.

The image above shows triple constraints for software projects. It is an essential part of software
organization to deliver quality product, keeping the cost within client’s budget constrain and
deliver the project as per scheduled. There are several factors, both internal and external, which
may impact this triple constrain triangle. Any of three factor can severely impact the other two.

Therefore, software project management is essential to incorporate user requirements along with
budget and time constraints.

Software Project Manager

A software project manager is a person who undertakes the responsibility of executing the
software project. Software project manager is thoroughly aware of all the phases of SDLC that
the software would go through. Project manager may never directly involve in producing the end
product but he controls and manages the activities involved in production.

A project manager closely monitors the development process, prepares and executes various
plans, arranges necessary and adequate resources, maintains communication among all team
members in order to address issues of cost, budget, resources, time, quality and customer
satisfaction.

Let us see few responsibilities that a project manager shoulders -

Managing People

• Act as project leader

• Liaison with stakeholders
• Managing human resources
• Setting up reporting hierarchy etc.

Managing Project

• Defining and setting up project scope

• Managing project management activities
• Monitoring progress and performance
• Risk analysis at every phase
• Take necessary step to avoid or come out of problems
• Act as project spokesperson

Software Management Activities

Software project management comprises of a number of activities, which contains planning of

project, deciding scope of software product, estimation of cost in various terms, scheduling of
tasks and events, and resource management. Project management activities may include:

• Project Planning
• Scope Management
• Project Estimation
Project Planning

Software project planning is task, which is performed before the production of software actually
starts. It is there for the software production but involves no concrete activity that has any
direction connection with software production; rather it is a set of multiple processes, which
facilitates software production. Project planning may include the following:

Scope Management

It defines the scope of project; this includes all the activities, process need to be done in order to
make a deliverable software product. Scope management is essential because it creates
boundaries of the project by clearly defining what would be done in the project and what would
not be done. This makes project to contain limited and quantifiable tasks, which can easily be
documented and in turn avoids cost and time overrun.

During Project Scope management, it is necessary to -

• Define the scope

• Decide its verification and control
• Divide the project into various smaller parts for ease of management.
• Verify the scope
• Control the scope by incorporating changes to the scope

Project Estimation

For an effective management accurate estimation of various measures is a must. With correct
estimation managers can manage and control the project more efficiently and effectively.

Project estimation may involve the following:

• Software size estimation

Software size may be estimated either in terms of KLOC (Kilo Line of Code) or by
calculating number of function points in the software. Lines of code depend upon coding
practices and Function points vary according to the user or software requirement.

• Effort estimation

The managers estimate efforts in terms of personnel requirement and man-hour required
to produce the software. For effort estimation software size should be known. This can
either be derived by managers’ experience, organization’s historical data or software size
can be converted into efforts by using some standard formulae.

• Time estimation
 Once size and efforts are estimated, the time required to produce the software can be
estimated. Efforts required is segregated into sub categories as per the requirement
specifications and interdependency of various components of software. Software tasks
are divided into smaller tasks, activities or events by Work Breakthrough Structure
(WBS). The tasks are scheduled on day-to-day basis or in calendar months.

The sum of time required to complete all tasks in hours or days is the total time invested
to complete the project.

• Cost estimation

This might be considered as the most difficult of all because it depends on more elements
than any of the previous ones. For estimating project cost, it is required to consider -

o Size of software
o Software quality
o Hardware
o Additional software or tools, licenses etc.
o Skilled personnel with task-specific skills
o Travel involved
o Communication
o Training and support

Project Estimation Techniques

We discussed various parameters involving project estimation such as size, effort, time and cost.

Project manager can estimate the listed factors using two broadly recognized techniques –

Decomposition Technique

This technique assumes the software as a product of various compositions.

There are two main models -

• Line of Code Estimation is done on behalf of number of line of codes in the software
product.
• Function Points Estimation is done on behalf of number of function points in the
software product.

Empirical Estimation Technique

This technique uses empirically derived formulae to make estimation.These formulae are based
on LOC or FPs.

• Putnam Model
 This model is made by Lawrence H. Putnam, which is based on Norden’s frequency
distribution (Rayleigh curve). Putnam model maps time and efforts required with
software size.

• COCOMO

COCOMO stands for COnstructive COst MOdel, developed by Barry W. Boehm. It

divides the software product into three categories of software: organic, semi-detached and
embedded.

Project Scheduling

Project Scheduling in a project refers to roadmap of all activities to be done with specified order
and within time slot allotted to each activity. Project managers tend to define various tasks, and
project milestones and arrange them keeping various factors in mind. They look for tasks lie in
critical path in the schedule, which are necessary to complete in specific manner (because of task
interdependency) and strictly within the time allocated. Arrangement of tasks which lies out of
critical path are less likely to impact over all schedule of the project.

For scheduling a project, it is necessary to -

• Break down the project tasks into smaller, manageable form

• Find out various tasks and correlate them
• Estimate time frame required for each task
• Divide time into work-units
• Assign adequate number of work-units for each task
• Calculate total time required for the project from start to finish

Resource management

All elements used to develop a software product may be assumed as resource for that project.
This may include human resource, productive tools and software libraries.

The resources are available in limited quantity and stay in the organization as a pool of assets.
The shortage of resources hampers the development of project and it can lag behind the schedule.
Allocating extra resources increases development cost in the end. It is therefore necessary to
estimate and allocate adequate resources for the project.

Resource management includes -

• Defining proper organization project by creating a project team and allocating

responsibilities to each team member
• Determining resources required at a particular stage and their availability
• Manage Resources by generating resource request when they are required and de-
allocating them when they are no more needed.
Project Risk Management

Risk management involves all activities pertaining to identification, analyzing and making
provision for predictable and non-predictable risks in the project. Risk may include the
following:

• Experienced staff leaving the project and new staff coming in.
• Change in organizational management.
• Requirement change or misinterpreting requirement.
• Under-estimation of required time and resources.
• Technological changes, environmental changes, business competition.

Risk Management Process

There are following activities involved in risk management process:

• Identification - Make note of all possible risks, which may occur in the project.
• Categorize - Categorize known risks into high, medium and low risk intensity as per
their possible impact on the project.
• Manage - Analyze the probability of occurrence of risks at various phases. Make plan to
avoid or face risks. Attempt to minimize their side-effects.
• Monitor - Closely monitor the potential risks and their early symptoms. Also monitor the
effects of steps taken to mitigate or avoid them.

Project Execution & Monitoring

In this phase, the tasks described in project plans are executed according to their schedules.

Execution needs monitoring in order to check whether everything is going according to the plan.
Monitoring is observing to check the probability of risk and taking measures to address the risk
or report the status of various tasks.

These measures include -

• Activity Monitoring - All activities scheduled within some task can be monitored on
day-to-day basis. When all activities in a task are completed, it is considered as complete.
• Status Reports - The reports contain status of activities and tasks completed within a
given time frame, generally a week. Status can be marked as finished, pending or work-
in-progress etc.
• Milestones Checklist - Every project is divided into multiple phases where major tasks
are performed (milestones) based on the phases of SDLC. This milestone checklist is
prepared once every few weeks and reports the status of milestones.
Project Communication Management

Effective communication plays vital role in the success of a project. It bridges gaps between
client and the organization, among the team members as well as other stake holders in the project
such as hardware suppliers.

Communication can be oral or written. Communication management process may have the
following steps:

• Planning - This step includes the identifications of all the stakeholders in the project and
the mode of communication among them. It also considers if any additional
communication facilities are required.
• Sharing - After determining various aspects of planning, manager focuses on sharing
correct information with the correct person on correct time. This keeps every one
involved the project up to date with project progress and its status.
• Feedback - Project managers use various measures and feedback mechanism and create
status and performance reports. This mechanism ensures that input from various
stakeholders is coming to the project manager as their feedback.
• Closure - At the end of each major event, end of a phase of SDLC or end of the project
itself, administrative closure is formally announced to update every stakeholder by
sending email, by distributing a hardcopy of document or by other mean of effective
communication.

After closure, the team moves to next phase or project.

Configuration Management

Configuration management is a process of tracking and controlling the changes in software in

terms of the requirements, design, functions and development of the product.

IEEE defines it as “the process of identifying and defining the items in the system, controlling
the change of these items throughout their life cycle, recording and reporting the status of items
and change requests, and verifying the completeness and correctness of items”.

Generally, once the SRS is finalized there is less chance of requirement of changes from user. If
they occur, the changes are addressed only with prior approval of higher management, as there is
a possibility of cost and time overrun.

Baseline

A phase of SDLC is assumed over if it baselined, i.e. baseline is a measurement that defines
completeness of a phase. A phase is baselined when all activities pertaining to it are finished and
well documented. If it was not the final phase, its output would be used in next immediate phase.
Configuration management is a discipline of organization administration, which takes care of
occurrence of any change (process, requirement, technological, strategical etc.) after a phase is
baselined. CM keeps check on any changes done in software.

Change Control

Change control is function of configuration management, which ensures that all changes made to
software system are consistent and made as per organizational rules and regulations.

A change in the configuration of product goes through following steps -

• Identification - A change request arrives from either internal or external source. When
change request is identified formally, it is properly documented.
• Validation - Validity of the change request is checked and its handling procedure is
confirmed.
• Analysis - The impact of change request is analyzed in terms of schedule, cost and
required efforts. Overall impact of the prospective change on system is analyzed.
• Control - If the prospective change either impacts too many entities in the system or it is
unavoidable, it is mandatory to take approval of high authorities before change is
incorporated into the system. It is decided if the change is worth incorporation or not. If it
is not, change request is refused formally.
• Execution - If the previous phase determines to execute the change request, this phase
take appropriate actions to execute the change, does a thorough revision if necessary.
• Close request - The change is verified for correct implementation and merging with the
rest of the system. This newly incorporated change in the software is documented
properly and the request is formally is closed.

Project Management Tools

The risk and uncertainty rises multifold with respect to the size of the project, even when the
project is developed according to set methodologies.

There are tools available, which aid for effective project management. A few are described -

Gantt Chart

Gantt charts was devised by Henry Gantt (1917). It represents project schedule with respect to
time periods. It is a horizontal bar chart with bars representing activities and time scheduled for
the project activities.
PERT Chart

PERT (Program Evaluation & Review Technique) chart is a tool that depicts project as network
diagram. It is capable of graphically representing main events of project in both parallel and
consecutive way. Events, which occur one after another, show dependency of the later event over
the previous one.

Events are shown as numbered nodes. They are connected by labeled arrows depicting sequence
of tasks in the project.

Resource Histogram

This is a graphical tool that contains bar or chart representing number of resources (usually
skilled staff) required over time for a project event (or phase). Resource Histogram is an
effective tool for staff planning and coordination.
Critical Path Analysis

This tools is useful in recognizing interdependent tasks in the project. It also helps to find out the
shortest path or critical path to complete the project successfully. Like PERT diagram, each
event is allotted a specific time frame. This tool shows dependency of event assuming an event
can proceed to next only if the previous one is completed.

The events are arranged according to their earliest possible start time. Path between start and end
node is critical path which cannot be further reduced and all events require to be executed in
same order.

INFRASTRUCTURE:

AN INFRASTRUCTURE IS THE BASIC, underlying framework or features of an organization

or system. Project management requires a framework made up of product, people, processes, and
(organizational) platforms within an enterprise.

The project management process according to A Guide to the Project Management Body of
Knowledge (PMBOK® Guide) includes four phases: Initiation and Definition; Planning;
Execution and Control; and Closeout. What the business community needs to visualize is that the
inputs into this project management process are business needs. These business needs include
meeting mandated government or legal regulations, creating products or services to stay
competitive in the marketplace, upgrading systems and technology to become more efficient and
effective. The deliverable out of each and every project will be a solution to a business problem
or opportunity; thus a business result that provides added value to our internal and/or our
external customers. And that deliverable cannot be created without a sound business
infrastructure that supports project management.

A Project Management Infrastructure

A project management infrastructure, for the most part, consists of systems of policies,
standards, procedures and guidelines that define how project management work is to be
performed. I suggest that there are four key components that are part of a project management
framework or infrastructure—a Portfolio Management System (product), a Process Management
System (process), an Organizational Management System (platform), and a Performance
Management System (people)—and that there are various ways to help the business community
become aware of and embrace a project management infrastructure.

A Portfolio Management System ensures that the initiation of the project management process
is grounded in sound strategic business decisions. A Portfolio Management System has five
subsystems: a Solicitation Process (doing the right projects), a Selection Process (stopping the
wrong ones), a Prioritization Process (doing them in the right order), a Registration Process
(codifying them in a central repository), and an Enterprise Resource Planning Process (staffing
them with the right people).

First, a Solicitation Process provides a consistent model for all proponents to follow; in other
words, requestors of projects to follow. This model defines how a proponent prepares a business
case that will be evaluated by the organization's business decision-makers. Then comes the
Selection Process during which time the decision-makers approve those projects that add value
to the organization and reject those projects that do not. After certain projects are approved, this
same group of decision-makers prioritizes these projects relative to predefined business criteria,
thus signifying those projects that will be given higher visibility and support and those that will
not. Pertinent information such as project client, project scope, and team members is entered into
a centralized database for all to access. In addition, these approved and prioritized projects are
staffed (or resourced) relative to all the projects within the portfolio mix and relative to where the
project sits within the prioritization ranking.

This part of the infrastructure allows the enterprise to manage the inventory of projects within
the enterprise.

A Process Management System takes the approved and prioritized project through the
Definition, Planning, Execution/Control, and Closeout phases.

The approved project from the Portfolio Management System goes into the Definition phase,
which creates a project charter. The project charter becomes the input to the Planning phase,
which creates a work plan; that is, schedule, staffing plan, project budget, and so on. The charter
and the work plan then become the baseline in the Execution/Control phase of the project
process. During this phase, the project team creates status reports and product deliverables. Once
the project is over, these outputs from the execution/control phase are the input into the Closeout
phase from which lessons learned are documented and archived for reference when starting the
project management process all over again.

Various auxiliary processes such as a risk management process, a change management process, a
quality assurance and control process, and a vendor/ contractor management process augment the
above “core” process.

This component of the infrastructure ensures that the discipline of project management is
performed in a consistent and professional manner throughout the entire organization.

An Organizational Management System is the governance structure defining roles,

responsibilities, and authorities and reporting relationships.
From almost the beginning of project management, the applied organization structure that
supported a project environment was a matrix structure. A matrix structure consists of
representatives from various functional areas working together in an ad hoc team to accomplish
certain business objectives producing specified deliverables. These cross-functioning teams work
within the constraints of multiple bosses and often multiple priorities; however, they create a
better and more “acceptable” product because of everyone's involvement in the project effort.

Reader Service Number 030

Today the “Project Office” is the newest version of the matrix project organizational structure.
This autonomous department, staffed by project management subject matter experts, becomes
the focal point for the project management discipline. As time evolves, the project office gains
credibility, builds expertise, grows in self-confidence, and simultaneously increases its
responsibility within the organization.

The organization platform of the infrastructure indicates the political interactions among
departments and among people within the project community.

A Performance Management System supports the three systems described above. This process
sets project management performance objectives for project managers and for project team
members and sees that these folks are rewarded for their successes and given development plans
to improve their areas of deficiencies. The Performance Management System consists of a
performance improvement process in which performance expectations and personal
developmental plans are established and agreed upon.

During the appraisal review cycle, typically of 12 months, project managers have interim
dialogues with their functional managers, with input from the project client. At the same time,
project team members are having interim dialogues with their functional managers, with input
from their project managers. The interim dialogues focus on whether or not project players are
attaining their performance objectives and whether they are working toward their developmental
plan. If they are not, the objectives or the plans need to be changed or the project players need to
readdress themselves to these commitments.

As the performance improvement process comes to a close, the performance appraisal review
process takes over. In this process, the functional manager of the project player prepares an
official review document, with final input from the appropriate project client or project manager.
The functional manager then executes the performance appraisal, and the cycle begins all over
again.

This piece of the infrastructure sees that the people are guided, directed and rewarded.

PROJECT PRODUCT:

The Project Product Description is normally a 1-3 page description of the main product that will
be produced by the project. The structure of this document is covered in both the quality and
plans themes. The Project Manager will extract this information from the Senior User role which
can be one or more people and will also involve subject matter experts who give feedback on
what is and what is not possible to do. Project Product Description defines what the project must
deliver in order to gain acceptance and it is used to:

• Gain agreement from the user on the what they want (project’s scope)
• Define the customer’s quality expectations so the project can deliver a fit for purpose
product
• Define the acceptance criteria, method and responsibilities for the project.

Timeline Highlight Report

• The Project Product Description (PPD) is created in the Starting up a Project process and
is part of the Project Brief
• It is then refined during the Initiating a Project process when creating the Project Plan, so
it is still used during the project.
• The Project Product Description should be checked at stage boundaries (during Managing
a Stage Boundary ) to see if the scope of the project has changed and if any changes are
required.
• At the end of the project ( Closing a Project process) it is used to verify that the project
has delivered what was expected of it, and that the acceptance criteria have been met.

Source data for the Project Product Description

• Discussions with the Senior User using facilitated workshops

• Discussions with the Executive
 • Request for proposal which includes an overview of requirements (customer/supplier
environment)
• Subject Matter Experts (future Team Managers)

Format Project Product Description

• Word / PDF document.

• Presentation slides
• Entry in a project management tool: see the Trello example above

Quality Criteria

• Clear purpose of the main product

• Complete scope of the project and perhaps what is not included
• Clear (not vague) and realistic acceptance criteria that will be used to assess the project
• Acceptance criteria should cover stakeholder requirements
• Define how the main project product will be assessed
o All criteria are measurable
o Each criterion is individually realistic
o All criteria can be proven within the project life (see the above examples)

Tips from Frank

• You do not have to write a massive Project Product Description.

• Remind of users of the type of Project Product Description you wish to create with them
and show them an example of PC or house (1 page that gives a very good idea of the
product).
• Start with a clear purpose and get buy in on this purpose.
• For each feature discussed as the question: How can we prove we have meet your
expectations.
o E.g., Fast search results ==> Search results in < 2 seconds
o E.g., Big SSD Drive ==> SSD Drive 500 GB
• Review the Project Product Description if a change request is accepted and see if it needs
to be updated.

CHARACTERISTICS

A project is a combination of interrelated activities to achieve a specific objective within a

schedule, budget, and quality. It involves the coordination of group activity, wherein the manager
plans, organizes, staffs directs, and controls to achieve an objective, with constraints on time, cost,
and performance of the end product. Project management is the combination of project and
management.
Planning is the strong keys to make the project more effective and well utilization of resources to
achieve the goal. In this, we will focus on characteristics of the project like how objectives are
important for achieving the goal, the total time duration of the project, calculated risk, and
uncertainty of the project, the total estimated cost of the project, etc. are essential characteristics
of the project and will discuss some other characteristics of the project like team spirit, require
funds, directions, uniqueness, flexibility, and sub-contracting, etc. Let’s discuss it one by one.

Characteristics of a Project :
Projects are not homogeneous. Each project is different in itself. The distinctive characteristics of
a project are as follows.

1. Objectives –
Every project is started with some objective or goal viz. time, budget, quality, and quantity,
when objectives are fulfilled project cause existing. You can initially define the objectives
of the project what actually need to achieve. Objectives are the key characteristics of the
project where you will see the progress of the project and time to time analysis will show
you the result of how much you have achieved.

2. Single entity –
A project is one whole thing. This means that in a project although different people
contribute still is recognized as a single entity. The teams are often specifically assembled
for a single project.

3. Life Span –
No project can be ceaseless and indefinite. It must have one and beyond which it cannot
proceed. Every project is invariably time-bound. At the time of planning, you will see the
time phase of the project where the team can work independently on the project modules.
Let’s consider an example project that is divided into three modules let’s say A, B, and C.
If the total time span of a project is 5 months then you can set the time span for modules
independently like A can complete in 2 months and also B can complete in 2 months and
 C can complete in 1 month as per requirement.

4. Require funds –
Every project needs funds to reach the endpoint. Without adequate funds, no project can
be successfully implemented. Cost estimation is one of the essential factors for any
organization. So, calculating in advance the required funds for the project will be very
impactful.

5. Life Cycle –
Each project has a life cycle with different stages like start, growth, maturity, and decay.
A project has to pass through different stages to get itself completed. Let’s consider an
example where the project is related to software development then you can say SDLC
(Software Development lifecycle) will be the life cycle of the project where you will see
many stages like planning, defining, designing, building, testing, and deployment, etc.

6. Team Spirit –
Team spirit is required to get the project completed because the project constitutes different
members having different characteristics and from various disciplines. But to achieve
common goal harmony, missionary zeal, team spirit is necessary.

7. Risk and Uncertainty –

The project is generally based on forecasting. So risk and uncertainty are always associated
with projects. There will be a high degree of risk in those project which are not properly
defined. Only the degree of control over risk and uncertainty varies with the project being
conceived based on information available.

8. Directions –
Project is always performed according to the directions given by the customers with regard
to time, quality and quantity, etc. The convenience of the supply sides of economics such
as labor availability ore resources and managerial talent etc. are all secondary concerns,
primary being the customer requirement.

9. Uniqueness –
Each project is unique in itself, and it’s having own features. No two projects are similar
even if the type of organization is the same. The uniqueness of the project can measure by
considering the many factors like objectives, features of the project, application of the
project, etc.

10. Flexibility –
Change and project are synonymous. A project sees many changes throughout its life span.
These changes can make projects more dynamic and flexible.

11. Sub-Contracting –
Sub-contracting is a subset of every project and without which no project can be completed
unless it is a proprietary firm or tiny in nature. The more complexity of a project the more
will be the extent of contracting. Every project needs the help of an outsider consultant,
 engineer, or expert in that field.

12. Cost –
If the quality of the project is to be changed there could be an impact on the cost of the
project. The cost could increase if more resources are required to complete the project
quicker.

What Is Effort Estimation?

Simply put, effort estimation is the process of estimating how much effort your project will take
to bring to life. It is expressed in terms of person-hours or money.

A realistic effort estimate requires you to have a clear understanding of certain elements of the
project:

• The purpose and scope of the project (If working with a client, what are their
expectations?)
• What needs to be done to achieve it
• What resources should be allocated
• Timeline

Major project estimation techniques

1. Top-down Estimate

Once more detail is learned on the project's scope, a top-down estimating technique assigns an
overall time for the project and divides the project into parts according to the work breakdown
structure.

For example, let’s imagine a project that must be finalized in one year. By fitting the scope of the
project on the timeline, you can estimate how much time is available for each activity that needs
to be performed. The top-down method is best applied to projects similar to those you have
completed previously. If details are sketchy or unpredictable, the top-down approach is likely to
be inefficient and cause backlogs.

2. Bottom-up Estimate
The bottom-up method is the opposite of top-down. It approaches the project as a combination of
small workpieces. By making a detailed estimate for each task and combining them together,
you can build an overall project estimate.

Creating a bottom-up estimate usually takes more time than the top-down method but has a
higher accuracy rate. However, for the bottom-up method to be truly efficient, the project must
be separated at the level of work packages.

3. Expert judgement

The expert judgment technique requires consulting the expert who will perform the task to ask
how long it will take to complete. This method relies on your trust in the expert's insights and
experience.

While it may seem like the most accurate estimation method, there are two points to consider:

• The expert's estimates need to be objective. Estimates that are carried out very positively
and overlook possible disruptions can create difficulties in meeting deadlines.
• You can only get an accurate answer to specific questions. Detailing the task description,
framing it, and clarifying the requirements will allow the expert to understand the task
fully and provide an accurate estimate.

4. Analogous Estimating

Analogous estimating is a technique for estimating based on similar projects completed in the
past. If the whole project has no analogs, it can be applied by blending it with the bottom-up
technique. In this case, you compare the tasks with their counterparts, then combine them to
estimate the overall project.

5. Three-point Estimating

Three-point estimating is very straightforward. It involves three different estimates that

are usually obtained from subject matter experts:
 • Optimistic estimate
• Pessimistic estimate
• Most likely estimate

The optimistic estimate gives the amount of work and time that would be required if everything
went smoothly. A pessimistic estimate provides the worst-case scenario. The result will be most
realistic when the two are averaged with the most likely estimate.

Although it is similar to the expert judgment technique, the negative effect of the subjective point
of view is prevented by not relying on just one estimate.

Conclusion

Effort estimates are just estimates and you cannot expect them to be entirely consistent with
reality. Developing your estimating skills and technique takes place over the long term, and
requires you to understand and use data efficiently. An analytics tool will help track and analyse
projects and assist in making more accurate effort estimations.
MaestroCR enables you to connect with your customers, stakeholders and team to simplify
project management processes. Divide projects into tasks, add developers, partners and
contributors, and assign deadlines. This allows you to manage your project transparently and
efficiently. You can access past estimations that have been met or are overdue in just a few
clicks and use data to speed up your process and make more accurate effort estimations.

IDENTIFY ACTIVITY RISK

Risk in business helps detail any financial, practical or social challenges a business may face.
Risk identification can help businesses build better products and processes and improve their
profit margins by identifying and reducing the potential impact of risks. Learning to identify
risks can be a critical skill for managers and business owners. In this article, we discuss what risk
identification is, how to identify risk, why identifying risk is important and provide eight tips on
identifying risks.

What is risk identification?

Risk identification is identifying potential business risks and analyzing them to learn about their
effects on the business. Risks come in many forms for businesses and different industries may
have different risks. For example, a software development company and a construction company
may share the risk of losing revenue if they don't upgrade their tools for modern processes.
However, they can carry their own industry-specific risks like the potential for injury on the job
or intellectual property risks.

Risk identification allows a business's leadership team to learn more about the risks the company
may face and create solutions to the challenges behind the risk. It also can help provide a clear
picture of a business's risk factors for bank loans or investor funds.

Why is risk identification important?

Risk identification is important at all stages of your business's lifespan because it helps identify
your biggest challenges and helps create a clearer picture of the business's overall health. Here
are a few reasons businesses focus on risk identification:

• Identifying industry challenges: Sometimes, risks are industry-related and can be safety
risks or volatility because of the industry itself. Identifying industry challenges or
specialized risks helps a business plan for future costs or obstacles and helps leadership
know if they're allocating resources to the right places.
• Meeting legal standards: Risk identification helps a business understand if it needs to
meet certain legal requirements. For example, a business that serves food may have
different legal risks than a company that makes shoes. Food must adhere to certain
sanitation practices and food production requires certain state and local licenses.
• Appealing to investors: Investors typically look for low-risk, high-yield investments.
These investments produce the greatest reward for the smallest risk and risk identification
helps them understand the full potential of a business's risks. Knowing the risks they face,
investors can make a more informed choice on the businesses they want to support.
 • Making projects more efficient: Businesses also use risk identification on a smaller scale
for individual projects or practices. Identifying risks early during the project planning
phase can help the team navigate the challenges more effectively by planning.

8 ways to identify risk

Here are eight ways to identify risk in business:

1. Brainstorming

Brainstorming is the act of gathering team members to think about and discuss a subject and to
form solutions to any identified problems. This kind of meeting allows a team to speculate on
ideas, discuss facts and look at a project's future. You can use brainstorming to identify, analyze
and address potential risks by hearing from people who work at the front end of the business.
Team members may have a better understanding of how the business operates from the ground
level and can share their own perspectives of the company's risks.

Brainstorming is an effective method because it allows everyone to speak and practice their
critical thinking skills. You can host a brainstorming session each month to determine what your
team thinks are the project's biggest risks, allowing everyone to communicate and helping to
bridge the gap between leadership and staff.

2. Stakeholder interviews

Stakeholders are the people who have an interest in your project or business, and interviewing
them may help you better understand what they believe are the biggest risks. Stakeholders often
have invested significant resources, whether it be time, money, labor or all three, into your
business. They understand risk from an outsider's perspective as an investor, not a laborer or
leader. This viewpoint can help you learn what concerns your investors and how to address it.

3. NGT technique

The NGT, or nominal group technique, is another method of brainstorming that offers a more in-
depth approach to the subject. Participants write their own ideas about the challenge without
discussing it directly with other group members. Then, a senior member of the team asks each
participant for their thoughts, which are written on a chart or whiteboard with overlapping items
removed.

The team discusses each item to ensure everyone understands them, and then you can work to
prioritize each one. The team can explore the top three items further, analyzing them and
creating solutions. The NGT technique depends on honesty and teamwork and provides a more
comprehensive approach than brainstorming.

4. Affinity diagram
An affinity diagram is a diagram that organizes data into categories based on their similarities.
Ask each team member to write what they believe are potential project or company risks and file
each response under a few categories. For example, you can have financial, practical or safety
risks as categories. This helps separate the risks into categories for individual review and helps
organize the feedback you receive. From there, the team can prioritize each risk and address it.

5. Requirements review

A requirements review is a review of a project's labor, material or financial requirements, and

allows the team to analyze requirements often and identify potential risks quickly. The team can
complete a requirements review throughout the project timeline to understand risks and
requirements at each stage of production. During production, requirements can change, which
also may change the risk involved. For example, if a process requires twice as much material as
originally speculated, the financial risk of the project rises because of additional costs.

6. Project plans

A project plan is a basic outline of the project and its needs. This includes things like material
and labor needs, the timeline for the project and any risks that come with it. A detailed project
plan may help the team understand the nature of the project and what it takes to reach the
project's goal. It also allows investors and stakeholders to understand what they're investing in
and how the team progresses and offers a return on the initial investment.

7. Root cause analysis

A root cause analysis is an investigation of previous project risks and how they relate to one
another and the current project. The root cause can be anything from financial challenges to
outdated equipment or poor-quality materials. Finding the root cause can allow the team to
identify common challenges in the project or business and minimize them for greater project
efficiency.

8. SWOT analysis

A SWOT, or strengths, weaknesses, opportunities and threats analysis, is a great way to

understand a project's or business's risks alongside other important factors. A thorough SWOT
analysis can show investors why a business or project is worthy of investment and helps the team
better understand their efficacy in reaching goals. A SWOT analysis examines four factors:

• Strengths: Areas where the team excels and how they relate to projects.
• Weaknesses: Areas where the team can improve to increase productivity and efficiency.
• Opportunities: Areas where the team or business can improve or expand.
• Threats: Areas of risk for the project or business and how the team can minimize those
risks.
Allocate Resources:

To assign the available resources in an economic way is known as resource allocation. The
planning of the activities and the resource required by these activities while taking into
consideration both resources availability and project time is termed as resource allocation in
project management.

There are 2 parts of resource allocation: Strategic Planning, and Resource Leveling. These are
explained as following below.

1. Strategic planning –
In strategic planning resource allocation is a plan for using available resources, for
example human resources, specially in the near term, to achieve goals for the future. It is
the process of allocating resources among various projects or business units. The strategic
planning has 2 parts.
1. There is the basic allocation decision.
2. There is the contingency mechanism.

The basic allocation decision is the choice of which items to fund in the plan and what
level of fund in it should receive and which to leave unfunded; the resources are located
to some items and not to others.

There may be contingency mechanism such as priority ranking of items excluded from
the plan, showing which items are to be sacrificed to reduce total funding.

2. Resource Leveling –
The main objective is to smooth resource requirement by shifting slack jobs beyond
periods of peak requirement. Some of the methods essentially replicate what a human
scheduler do if he has enough time, procedures design especially for the computer. They
of course depend for their success on the speed and capabilities of electronic compilers.

Approach for resource allocation :

There are number of approaches to solve resource allocation problems:

1. Manual Approach
2. Algorithmic Approach
3. Combination of both

In algorithmic approach resource is allocated by using some computer program which is defined
for a specific domain, this will automatically and dynamically distribute resources to the user.
Electronic devices dedicated to routing and communication is commonly use this method. For
example: channel allocation in wireless communication may be decided by base transceiver
using an appropriate algorithm.
Six Sigma

Six Sigma is a business methodology that aims to improve processes, reduce waste and errors,
and increase customer satisfaction throughout an organization. Driven by data and statistical
analysis, Six Sigma provides a way to minimize mistakes and maximize value in any business
process, from manufacturing to management.

There are lots of different ways to improve your processes, and you’ve likely heard of Six Sigma
methodology as one possibility, particularly for large manufacturing businesses, like GE and
Motorola, looking to reduce defects and improve the quality of their products. But Six Sigma is
more than just quality improvement for manufacturing––it’s also a project management
methodology.

Regardless of the industry, companies need to develop efficient processes to complete projects
and stay relevant. As a project manager, you might feel like your goals don’t fit within a Six
Sigma framework. However, you and your team stand to benefit from the boost in efficiency a
Six Sigma mindset can create. Read on to find out how.

What is Six Sigma methodology?

In case your business school notes on Six Sigma have (understandably) blurred over the years,
Six Sigma is a methodology used to find and address the weak points in a process that hinder
efficiency or that result in more errors than is ideal.
Six Sigma specifically refers to the goal of reducing the number of manufacturing defects to less
than 3.4 per 1 million units.

Over the years, however, Six Sigma’s usefulness has expanded far beyond the world of
manufacturing to help a diverse assortment of companies like Amazon, Xerox, and Bank of
America save money by improving efficiency.

By visualizing how your product or service goes from its initial conception to your customer's
hands, you can start identifying ways to increase efficiency and quality, which is what the Six
Sigma methodology is all about.

When to use this project management methodology

First, it's important to see if Six Sigma methodology is a good fit for your project. Bernardo
Tirado, a Six Sigma expert, starts by asking himself a few key questions:

"What is the objective of this project? Is it to introduce new technology? Is it going to result in
changing a job more than 50%? Is this project going to lead to efficiency gains? I found Six
Sigma to be most effective on operations initiatives. In part, operations have processes that could
be complemented with newer technology or repeatable processes that could be centralized
elsewhere, allowing the current employees room to do advanced type of activities."
In addition to this operational focus, here’s a few more considerations for when to use Six
Sigma:

• To eliminate waste, whether that’s wasted time, materials, or other resources

• To reduce defects or variations in your product or service
• To define what’s causing problems
• To use data more effectively to increase efficiency and productivity
• To increase customer and employee satisfaction
• To design a new process or redesign an ineffective one

Benefits of the Six Sigma methodology

Nobody likes change, but if you decide to go with Six Sigma for project management, you’ll find
that it touches every area of your business––and in the best of ways.

• Informed decision-making: Six Sigma methodology rests on a bedrock of statistics.

Without accurate measurements and data on what’s actually going on in your processes,
you’re operating on gut feeling and assumptions. Data empowers you to make objective
decisions and find the best solution or idea. Six Sigma aims to back your performance or
production initiatives with quantitative data and be better equipped to meet them.
• Increase communication and collaboration in your team: Six Sigma is meant to be an
organization-wide effort, encouraging everyone to see problems as opportunities and
truth as the most important goal. As a result, employees won’t feel afraid to voice
concerns and will see other teams and departments as partners in improvement rather
than competitors in performance.
• Improved quality and customer satisfaction: As we’ve mentioned before, Six Sigma is
all about reducing defects and variations in customer experience. It doesn’t matter if it’s
for something made in a factory, like a box of cookies, or something more intangible, like
a web app. Once you begin measuring and quantifying your processes, you’ll be able to
make the changes necessary to improve the experience for your customers.
• Reduced costs: Poor quality and inefficiencies in process cause a lot more expenses than
we think––missed deadlines, lost customer loyalty, design changes, managerial changes,
engineering changes, and so on. Whether due to poor planning or to fix mistakes as they
occur, they add up. Six Sigma takes a ruthless approach to cutting those out with
structured teams of experts, a rigorous review of processes, and a strict adherence to data.
• Better productivity and time management: With better team structure, project
planning, data collection and analysis, and business strategy, your entire organization will
be more efficient. And if you aren’t spending time fixing problems that should have been
avoided or mitigated, then you can spend more time on the things that matter.

Six Sigma certification

While anyone can apply Six Sigma principles, Six Sigma certification guarantees that you have a
certain set of skills and that you have a standard level of knowledge about Six Sigma
methodology. You can get your Six Sigma certification online or through a business school.
The advantages of Six Sigma certification to a company include compliance, improved
performance, and reducing errors and waste, of course. For employees, it might mean a higher
salary, more job opportunities, improved leadership skills, and a portable set of competences that
can easily transfer from job to job.

Depending on your previous education (e.g., if you already have a business degree), your
expertise, or your employer’s requirements, though, you might choose not to get certified since it
can be expensive.

Six Sigma belts

The different levels of Six Sigma certifications are organized by belt color, like in karate, to
show the varying levels of expertise and training that a Six Sigma practitioner may have
received.

Here are the different Six Sigma certification levels:

• Champion: Though not technically a belt, champions are an important part of the Six
Sigma deployment strategy. They act as the Six Sigma team guide, aligning projects with
organizational goals, keeping the team focused, and removing roadblocks.
• Master Black Belt: The in-house authorities and teachers for Six Sigma, they train
lower-level belts. They also manage Six Sigma program strategy.
• Black Belt: The most highly trained experts in Six Sigma, they lead, mentor, and coach
Six Sigma teams.
• Green Belt: Trained to solve most process problems, they assist Black Belt projects by
collecting and analyzing data. They sometimes lead less complex projects themselves.
• Yellow Belt: Trained in basic Six Sigma methodology, they participate in Green and
Black Belt projects as team members.
• White Belt: With only an introductory overview of Six Sigma concepts, they are the
recruiting base for future Yellow and Green belts. They assist in simple tasks for Six
Sigma projects.

Six Sigma relies on strong leadership to push a project forward. Additionally, every single
person in the organization must be committed to and understand the effort, especially top-tier
management.

As project manager, you can decide whether this kind of structure would make sense within your
organization and for your project’s goals.

Six Sigma methodologies

Once you have chosen Six Sigma as the best approach for your project, there are two main sub-
methodologies that diverge slightly to allow businesses to tailor the Six Sigma approach to their
project and industry. They share the same ultimate goal of improving processes, but each offers a
more specialized approach.
DMAIC

DMAIC works best for an existing business process, for example, when looking to improve the
manufacturing or production aspect of a business.

• Define: Identify the need.

• Measure: Assess the current process and its effectiveness.
• Analyze: Use data to evaluate current processes to find where the defects occur or where
the areas of improvement are.
• Improve: Make changes and improve the process so it helps you meet your goals.
• Control: Design a system to keep the improved process in place, anticipating potential
future roadblocks.

DMADV

DMADV works best for planning a process that doesn’t yet exist, for example, when creating a
new product or improving customer relations.

• Define: Establish the client’s or customer’s need.

• Measure: Use data to assess customer needs, response to a product or service, and the
product or service’s capabilities.
• Analyze: Review data and use that information to create new goals or designs to meet
customer or client needs.
• Design: Create a product, service, or process that will better address customer needs
based on findings.
• Verify: Test the design and either deliver it to the client or put a plan in place to monitor
its success and efficacy at addressing customer needs.

Applying Six Sigma to project management

As a project manager, you likely have your own way of setting up a project and seeing it through
its various stages, and you might not be willing to fix something that isn’t broken. Even if you
borrow or adapt just some of the elements from the methodology, Six Sigma’s rigorous approach
can improve your chances of success.

• Structure your team for success: One reason Six Sigma methodology is so effective is
that it places an emphasis on clear organization from the start. Many projects fail not
because of poor goals or contributor errors but because of organizational issues that can
be traced back to the project’s inception. While you may not have a Black Belt leader or
Green and Yellow Belt team members, you can still apply the same concept of having
strong, experienced leadership and clearly defined team roles to avoid conflict or lacking
the proper skills to get the project completed.
• Use DMAIC and DMADV as your project process: Project management in itself is a
process. The steps you take to ensure a project’s success are all part of a larger process
that could always be improved. If you take the time to do a DMAIC-style assessment of
the way you and your team manage projects, you could uncover weak spots and areas for
 improvement you weren’t aware of before. Even if your plan deviates from DMAIC or
DMADV, you’ll benefit from Six Sigma’s emphasis on clearly defined steps and its
concrete, empirical approach.
• Measure and analyze to find gaps: Six Sigma methodology may have roots in
manufacturing, but don’t let that deter you from using its approach to finding and
reducing mistakes. If your team is struggling to understand failures or unexpected results,
don’t make assumptions about what you think might be the cause. Taking a Six Sigma-
inspired, scientific approach will help you comb through your process effectively to find
any gaps.
• Rely on data for a more accurate picture: Even if your team has already been
successful at achieving its goals, Six Sigma’s approachable steps could help you better
use data to measure your wins and areas for improvement.

By taking pieces of this proven methodology and adapting it to your existing workflow, you’ll be
better equipped to maintain consistency, streamline your processes, and achieve success across
your projects.

SOFTWARE QUALITY

The relevancy of Software quality in modern times is increasing like anything. Nowadays
software development companies are more focussed on deploying new codes into production
even on an hourly basis without any proper software testing. That’s creating a chaotic
environment in the market.
People often fail to understand that speed has minimal value if there is no quality. let’s learn how
to ensure software quality in every build
What is software quality?
The quality of software can be defined as the ability of the software to function as per user
requirement. When it comes to software products it must satisfy all the functionalities written
down in the SRS document.
Key aspects that conclude software quality include,

• Good design – It’s always important to have a good and aesthetic design to please users
• Reliability – Be it any software it should be able to perform the functionality impeccably
without issues
• Durability- Durability is a confusing term, In this context, durability means the ability of
the software to work without any issue for a long period of time.
• Consistency – Software should be able to perform consistently over platform and devices
• Maintainability – Bugs associated with any software should be able to capture and fix
quickly and news tasks and enhancement must be added without any trouble
• Value for money – customer and companies who make this app should feel that the
money spent on this app has not fone to waste.

ISO/IEC 25010:2011 Software Quality Model

ISO/IEC 25010:2011 Software Quality Model

What is Software Quality Model?

Software quality models were proposed to measure the quality of any software model.
There are three widely accepted models when it comes to measuring software quality

• McCall’s Quality Model

• Boehm quality model
• Dromey’s quality model

Mc call’s Model
Mc Call’s model was first introduced in the US Airforce in the year 1977. The main intention of
this model was to maintain harmony between users and developers.
 McCall Model

Boehm Quality Model

Boehm model was introduced in the year 1978. It was a kind of hierarchical model that’s
structured around high-level characteristics. Boehm model measures software quality on the
basis of certain characteristics.

Boehm Model

Dromey’s quality model

Dromey’s model is mainly focussed on the attributes and sub-attributes to connect properties of
the software to the quality attributes
There are three principal elements to this model
 • Product properties that affect the quality
• High-level quality attributes
• Linking the properties with quality attributes

Dromeys software quality model

How can software engineers acquire software quality?

• Management plan – Have a clear idea about how the quality assurance process will be
carried out through the project. Quality engineering activities required should also be set
at the beginning along with team skill check.
• Proper checkpoints – Checkpoints at required intervals should be set

How do we achieve Software quality?

Achieving quality will ensure maximum profit for your software business. But the biggest hurdle
is to achieve quality and here are some of the ways.

• Define characteristics that define quality for a product

• Decide how to measure each of that quality characteristic
• Set standards for each quality characteristic
• Do quality control with respect to the standards
• Find out the reasons that are hindering quality
• Make necessary improvements

What are software quality metrics?

In any software project, you can go on building the code but at some point, you need to take a
break and check if the work you are doing is right, if the process you followed is correct and so
on. Metrics help you in exactly that.
Metrics are pointers or numbers which help you understand the attributes of a product, (like its
complexity, its size, it’s quality, etc.), the attributes of the process (which can be used to improve
the quality and speed of development) and the attributes of the project (which includes the
number of resources, costs, productivity and timeline among others), popularly known as the
three P’s.
Why are software quality metrics important?
Software quality metrics are an indicator of the health of the product, process, and project. Good
metrics with accurate data can help in
 • Developing a strategy and giving the right direction to the process/project
• Recognizing the areas of focus
• Making strategic decisions
• Driving Performance and many others.

Important Software Quality Metrics

For any metrics to truly serve the purpose, there are 2 parts. One is the data accuracy and the
second is metrics selection.
All metrics will not be suitable for all processes and projects. So the selection of the metrics
needs to be done carefully.
Let us now look at some very important and most commonly used Software Quality Metrics and
how they are helpful in driving a better code

1. Defect Density

The first measure of the quality of any products is the number of defects found and fixed.
Though there a many “conditions apply” cases this is the first ballpark estimate of the quality of
the software.
The more the number of defects found, would be the quality of development is poor. So the
management should strive hard to improve development and do an RCA (Root Cause Analysis)
to find why the quality is taking the hit.
Defect Density = No. of Defects Found / Size of AUT or module

2. Defect Removal Efficiency (DRE)

This is an important metric for assessing the effectiveness of a testing team. DRE is an indicator
of the number of defects the tester or the testing team was able to remove from going into a
production environment. Every quality team wants to ensure a 100% DRE.
DRE = A/(A+B) x 100
A – number of defects found before production
B – Number of defects found in production

3. Meantime between failures (MTBF)

As the name suggests it is the average time between two failures in a system. Based on the AUT
and expectation of business the definition of failure may vary.
For any online website or mobile application crash or disconnection with the database could be
the expected failure. No team can produce software that never breaks or fails, so the onus is
always to increase the MTBF as much as possible, which means that in a time frame the number
of times the applications fail should be reduced to an acceptable number.

4. Meantime to recover (MTTR)

This again is quite self-explanatory. The mean time to recover is basically the time it takes for
the developers to find a critical issue with the system, fix it and push the fix patch to production.
Hence the average time which the team needs to fix an issue in production. It is more of
maintenance contract metrics, where an MTTR of 24 hours would be preferred over an MTTR of
2 days for obvious reasons.

5. Application Crash Rate

Important metrics especially for mobile apps and online websites. It is a measure of how often
the mobile app or website crashes in any environment. It is an indicator of the quality of the
code. The better the code, the longer it will be able to sustain without crashing.
In recent times where the speed of delivery has taken utmost importance, the traditional methods
life the SDLC and waterfall models have taken a backseat, giving way for more dynamic and
fast-paced agile, scrum and lean methodologies.
This section on software quality metrics would be obsolete and incomplete if we do not look at
some very important metrics in agile. These are the metrics that are more important and relevant
in today’s scenario.

6. Lead Time:

Lead time is defined as the time it takes from the time of project or sprint kick-off to the
completion. In an agile process, we normally pick up user stories that will be delivered at the end
of the sprint.
The lead time is thus defined as the time it takes to complete and deliver these user stories.

7. Cycle Time

Cycle time is similar to the lead time with a difference that leads time is measured per user story,
while cycle time is measured per task. For eg, if database creation is part of the user story related
to client data.
Then time taken to create the database would be the cycle time, while the time taken to have the
complete database ready would be the lead time. The cycle time data is used to arrive at delivery
estimation timelines for future sprints.

8. Team Velocity

Team Velocity is a very important metric for Agile/Scrum. It is an indicator of the number of
tasks or user stories a team is able to complete during a single sprint. This does not include the
items moved to the backlog and incomplete items. Only fully completed user stories are included
for velocity calculations. This is an important metric because based on the team velocity, the
management would decide on the number of stories they can pick up for the next sprint.

9. First Time Pass Rate

These metrics are in line with the agile principle of dynamic, fast and quality delivery. It is an
indicator of the number of test cases that pass in the first run itself. It is also an indicator of the
quality of development. In simpler terms, it means that no defects were found in the developed
code when it went through testing for the first time

10. Defect Count Per Sprint

As the same suggests, these metrics take the count of defects found in each sprint. This is a very
simple yet useful metrics for assessing the quality of the user stories delivered during any sprint.
Conclusion
Attaining software quality is indeed a tedious process. But through a systematic process, it’s
indeed achievable. Remember, software quality is the only resort you can rely on in achieving
profit for your business.

ISO 9126 Software Quality

The ISO 9126 software is an international standard software quality model that helps in
creating a solid framework for assessing software. This standard way of assessing software can
be segregated in four different ways. These are used to address subjects of different nature. This
software is profoundly used in a widespread way to embrace various models and metrics. The
recommended features describe externally when software is found to be a result of attributes of
internal attributes of software.

The following ways by which a standard software quality model can be calculated are as follows:

1. Quality Model.
2. External Metrics.
3. Internal Metrics.
4. Quality in use Metrics.

The part one of this software quality model is an extension to the previously work done by the
other quality enhancing models. The other defined set of software quality models are as follows:

1. Mc Call 1977.
2. Boehm 1978.
3. FURPS.

This model is used to represent the cutting-edge research. It moves into figuring software
characteristics for the few main purpose of checking software quality control, software quality
assurance and software performance improvement. The model can be acquired by purchasing the
model from official ISO 926 documentation. With the SQA.NET, this model can be only
obtained by the basic structure along with structures, commentary, or guidance.

Like every software, ISO 926 software model has distinct qualities. These are laid on following
basis:
1. Functionality: It is a key aspect of any product or service. It is due to this the software is
able to fulfill a task and keep to its purpose. It is defined as a software product that helps
to meet the needs of the clients. A functionality of software is dependent on its
complexity. For example: an ATM machine. This is further divided in other categories
are as follows:
o Suitability.
o Accuracy.
o Interoperability.
o Security.
o Functional compliance.
2. Reliability

Reliability: This characteristic determines the capability of software to sustain its use
when put under different circumstances.

3. Usability: The usability of software is highly dependent on the functional uses of

software. For example: ATM machine is used to withdraw cash. According to the
usability of an ATM; the ATM is not affected or influenced by any amounts entered by
the user. This is further divided into other sub-categories and these are as follows:
o Maturity.
o Fault Tolerance.
o Recoverability.
o Reliability Compliance.
4. Efficiency: This feature of the model is more concerned by resources of the system when
used for providing a desired functionality. This type of feature is defined by amount of
disk space, memory and network. This is further divided into other sub-categories and
these are as follows:
o Understandability.
o Learner ability.
o Operability.
o Attractiveness.
o Usability Compliance.
5. Maintainability: This property of maintainability of the software model is used to
recognize and fix a defect accordingly. The model is inspected for the faults and these
can be identified easily. In accordance to this the cause and effect of maintainability of
software is a concern. This is further divided into other sub-categories and these are as
follows:
o Analyzability.
o Resource Utilization.
o Stability.
o Testability.
o Changeability.
6. Portability: According to this feature, capable software should easily adapt to the
environmental changes frequently as possible. The designing of an object and the
practices of its implementation are highly dependent on this feature. This standard
method is further divided in few categories:
 o Adaptability.
o Install ability.
o Co-existence.
o Replaceability.
o Portability compliance.

EXTERNAL STANDARDS:

The British standard for Quality Management systems was previously called BS 5750.

Remember that these standards were originally designed for all kinds of production - not just
software development.

BS EN ISO 9001

At IOE, a decision might have been made to use an outside contractor to produce the
maintenance group accounts subsystem rather than develop the software in-house. As a client
using the services of an outside contractor, IOE would be concerned that the contractor is
following the best quality practices. It is now common to include in contracts terms covering the
types of technique that a contractor will use. Various national and international standards bodies,
including the British Standards Institution (BSI) in the United Kingdom, have inevitably become
involved in the creation of standards for quality management systems. The British standard is
now called BS EN ISO 9001:1994, which is identical to the international standard, ISO
9001:1994. Standards such as the ISO 9000 series aim to ensure that a monitoring and control
system to check quality is in place. They are concerned with the certification of the development
process, not of the end product, as in the case of crash helmets and electrical appliances with
their familiar CE labels. The ISO 9000 series govern quality systems in general terms and not
just those in the software development environment.

There has been some controversy over the value of these standards. Stephen Halliday, writing in
The Observer, had misgivings that these standards are taken by many customers to imply that the
final product is of a certified standard although as Halliday says 'It has nothing to do with the
quality of the product going out of the gate. You set down your own specifications and just have
to maintain them, however low they may be'. It has also been suggested that obtaining
certification can be an expensive and time-consuming process that can put smaller, but still well-
run, businesses at a disadvantage. Finally, there has been a concern that a preoccupation with
certification might distract attention from the real problems of producing quality products.

Putting aside these reservations, let us examine how the standard works. A primary task is to
identify those things that are to be the subject of quality requirements. Having defined the
requirements, a system must be put in place to check that the requirements are being fulfilled and
that corrective action is being taken where necessary.

An overview of BS EN ISO 9001 QMS requirements

In order for a quality management system (QMS) to meet the standard it has to conform to
certain requirements which are summarized below.

(a) The management must define and document the policy concerning quality and must ensure
that this policy is communicated to all levels of the organization.

(b) All quality control procedures must be documented.

(c) All contracts to supply goods or services must contain mutually agreed requirements that the
developer is capable of delivering.

(d) There must be procedures to control and verify the design of the system to be supplied so that
it meets the requirements agreed with the customer.

(e) There must be procedures to approve design and other documentation.

(f) Where components of the system to be supplied to the client are obtained from third parties
there must be procedures to ensure, check and maintain the quality of these components.

(g) Individual products must be identifiable as should their components.

(h) The process by which the final product is created must be planned and monitored.

(i) Inspection and testing must take place during the development phase, at its completion and
before delivery. Tests and inspections must also be carried out on components obtained from
third parties.

(j) The equipment used in the production process itself must be properly controlled with respect
to quality.

(k) The testing status of all components and systems must be clearly recorded at all times.

(1) Care must be taken to ensure that items that are known to be defective are not inadvertently
used.

(m) When a defect is detected, measures must be undertaken to remove the defective part and to
ensure that the defect does not occur again.

(n) Satisfactory procedures must be in place to deal with correct handling, storage, packaging
and delivery of the product.

(o) Sufficient records must be maintained to demonstrate that the quality system is working
satisfactorily.

(p) The software quality management system must be audited on a regular basis.
(q) Servicing and support activities must be subject to the quality management system.

(r) The developer must establish appropriate statistical techniques to verify the acceptability of
the final product.

Identify specific instances in a software development environment where the requirements about
the control of equipment (j), the recording of the testing status of all components (k), and the
correct handling, storage, packaging and delivery of the product (m) would be relevant. What
procedures would apply in a software environment in relation to these requirements?

Bearing in mind the criticisms of BS EN ISO 9001 that have been mentioned, what
precautionary steps could a project manger take where some work of which the quality is
important is to be contracted out?

TickIT

However, some parts do The ISO 9000 standards refer to quality management systems in general
but in the refer to software, for United Kingdom, the Department of Trade and Industry (DTI)
have formulated

example, ISO 9000-3. the TickIT standards which give an interpretation of these standards,
which

applies specifically to software development. This includes such requirements as:

• a detailed development plan is required before development is embarked upon;

• change control procedures should be used at all stages of development;

• design reviews must take place;

• the suitability of the design methodology must be reviewed;

• progress must be reviewed on a systematic basis;

• it must be possible to trace back the features of software design to specifications and
requirements;

• designs must be properly documented;

• suitable test plans, specifications and records must be produced;

• a code of practice must be in place which governs the way the software is developed.

The code of practice must include the requirements that:

• the design must be broken down into levels, each with identifiable inputs and outputs;

• software must be organized into modules;

• a module must normally perform a single function or a set of related functions;

• a plain language description must exist for each module.

 Unit -II
Strategic assessment
Project evaluation is a systematic method for collecting, analyzing, and using
information to answer questions about projects, policies and programs, particularly about
their effectiveness and efficiency.
✓ Project evaluation is a high level assessment of the project
❖ to see whether it is worthwhile to proceed with the project
❖ to see whether the project will fit in the strategic planning of the whole
organization

• Project evaluation is normally carried out in step 0 of stepwise

• Project evaluation is a step by step process of collecting, recording and organizing
information about
– Project results
– short - term outputs (immediate results of activities or project deliverables)
– Long – term outputs (changes in behaviour , practice or policy resulting from
the result.
Why is project evaluation important:
Project evaluation is important for answering the following questions-
- what progress has been made?
- were the desired outcomes achieved? Why?
- whether the project can be refined to achieve better outcomes?
- do the project results justify the project inputs?

Project evaluation is used to

❖ Want to decide whether a project can proceed before it is too late
❖ Want to decide which of the several alternative projects has a better success
rate, a higher turnover, a higher ...
❖ Is it desirable to carry out the development and operation of the software
system?
Project evaluation is done by
❖ Senior management
❖ Project manager/coordinator
❖ Team leader
Project evaluation
❖ Strategic assessment
❖ Technical assessment
❖ Economic assessment
STRATEGIC PLANNING
Strategic planning is defined as an organization’s process of defining its strategy , or
direction and making decisions on allocating its resources to pursue this strategy, including
its capital and people
it deals with:
- what do we do?
- for whom do we do it?
- how do we excel?

STRATEGIC ASSESSMENT
Strategic assessment is the first criteria for project evaluation
– For evaluating and managing the projects, the individual projects should be
seen as components of a programme. Hence need to do programme
management.
Programme management:
• D.C. Ferns defined “a programme as a group of projects that are managed in a co-
ordinated way to gain benefits that would not be possible were the projects to be
managed independently”.
• A programme in this context is a “collection of projects that all contribute to the same
overall organization goals”.
• Effective programme management requires that there is a well defined programme
goal and that all the organization’s projects are selected and tuned to contribure to this
goal”
Evaluating of project is depends on:
• How it contributes to programme goal.
• It is viability [capability of developing or useful].
• Timing.
• Resourcing.
For successful strategic assessment, there should be a strategic plan which defines:
• Organization’s objectives.
• Provides context for defining programme .
• Provides context for defining programme goals.
• Provide context for accessing individual project.
In large organization, programme management is taken care by programme director
and programme executive, rather than, project manager, who will be responsible for the
strategic assessment of project. Any potential software system will form part of the user
organization’s overall information system and must be evaluated within the context of
existing information system and the organization’s information strategy. If a well – defined
information system does not exist then the system development and the assessment of project
proposals will be based on a more “piece meal approach”. Piece meal approach is one in
which each project being individually early in its life cycle.
Typical issues and questions to be considered during strategic assessment

• Issue – 1: objectives:
– How will the proposed system contribute to the organization’s stated
objectives? How, for example, might it contribute to an increase in market
share?
• Issue – 2: is plan
How does the proposed system fit in to the IS plan? Which existing system (s) will
it replace/interface with? How will it interact with systems proposed for the later
development?
• Issue – 3: organization structure:
– What effect will the new system have on the existing departmental and
organization structure?
– For example, a new sales order processing system overlap existing sales and
stock control functions?
• Issue – 4: MIS:
– What information will the system provide and at what levels in the
organization? In what ways will it complement or enhance existing
management information system?
• Issue – 5: personnel:
– In what way will the system proposed system affect manning levels and the
existing employee skill base? What are the implications for the organization’s
overall policy on staff development.
• Issue – 6: image:
– What, if any, will be the effect on customer’s attitudes towards the
organization? Will the adoption of, say, automated system conflict with the
objectives of providing a friendly service?

Portfolio management
Project Portfolio management provides an overview of all the projects that an
organization is undertaking or is considering. It prioritizes the allocation of resources to
projects and decides which projects should be accepted and which existing ones should be
dropped.
The concerns of Project Portfolio management include:
• Identifying which project proposals are worth implementation;
• Assessing the amount of risk of failure that a potential project has;
• Deciding how to share limited resources, including staff time and finance, between
projects;
• Being aware of the dependencies between projects;
• Ensuring that projects do not duplicate benefits;
• Ensuring that necessary developments have been inadvertently been missed.
The three key aspects of Project Portfolio management are:
 1. Portfolio definition
2. Portfolio management
3. Portfolio optimization

Technical Assessment

Technical assessment is the second criteria for evaluating the project.Technical assessment
of a proposed system evaluates functionality against available:
• Hardware
• Software
• Limitations
– Nature of solutions produced by strategic information systems plan
– Cost of solution. Hence undergoes cost-benefit analysis.
It is also referred as Technology Evaluation. The Technology Assessment is a write up
on the technical aspects of the project sector and planned technical purchases. Technology
is defined broadly here to include: equipment, tools, products, processes, raw materials,
skills, and ways of organizing production.

Assessing Technology Planning:

- Analyze Technology Needs

- Planning for Change and Technology
- Assessing a Technology Plan Before and After Implementation

Why it is important:

➢ It’s a tool to Identify the Problem

▪ At the core of any project is a series of big and small problems that need to be
addressed (ex: not enough production capacity, staff lacks required skills, overly
expensive transportation, etc.)
▪ Reviewing the production process including the systems and equipment in place
provides transparency into what some of the constraints are. Some will be obvious,
but others may be hidden until you take a closer look.
▪ Not all constraints will be technical, so this is just one investigative tool needed.
➢ It’s a tool to Identify the Best Solution

o Once you know what the technical problems are, you can start to look for solutions.

o The Technology Assessment provides the opportunity to explore potential solutions

(ex: new equipment choices, new crop varieties, new fertilizers, changes in process,
etc.)

o The grantee often has a solution in mind when they propose the project, but further
analysis can lead to more creative, better fitting, and more cost effective solutions.
 o The grant budget is limited, so looking at the options in a systematic way helps the
grantee understand the tradeoffs with implementing one technical solution or another.
Knowing this, they can make more informed decisions about using scarce budget
resources.

➢ It’s a tool for Communication

o The write-up documents the background work and thinking on technical issues that
has gone into the project design and budget.

(1) The more people understand the logic of the proposal, the more they can
help brainstorm on solutions or help catch problems that might not have
been fully addressed.
(2) A clear presentation will reduce questions from ADFW on the project
proposal and will help them better understand the design choices despite
not being present for all of the partner discussions with the grantee.

o It serves as a record and resource for the grantee in case they need to go back and
reconsider the options at a later date.

Purpose:
- Technology assessment provides an organization with information about the
profitability of current technology as well as the benefits of implementing new
technology.
- Ineffective technology needs to be upgraded or replaced for businesses to produce
quality products or services.

Types of Assessments:
Technology assessment can happen on several levels: flexibility, longevity and upgrade and
scale-assessments. To assure that an organization can remain competitive, every aspect of its
technology system must be in excellent operating condition. Assessment on all four levels improves
the chances of this happening.
- Flexibility/Longevity
Flexibility assessment examines how technology will adapt to new levels of
applications and other technology systems.
Longevity assessment provides information on how long the technology will
last.
- Upgrade/Scale Assessments
An upgrade assessment determines the ability of the technology to function
with the addition of new, advanced features and equipment.
Scale assessment considers how well the technology can operate in a larger,
ever-growing network of systems. The growth of an organization means developing a
 larger technology system. New technology must be able to be incorporated into new,
expanding networks.

Evaluate the technology options on the following factors:

➢ Fixed capital costs

➢ Source of equipment

➢ Operation, maintenance, and replacement costs

➢ Scale of production and expected capacity use rate

➢ Reliability

➢ Labor intensiveness (labor costs, productivity, and employment generation)

➢ Types and amounts of inputs required

➢ Raw material availability, sustainability, and cost

➢ Effects on product quality, cost and marketability

➢ Foreign exchange requirements and availability

➢ Natural resource requirements and sustainability

➢ Compatibility with existing technology in use

➢ Human resource requirement (training and technical assistance costs, management and
supervision costs, etc)

Cost Benefit Analysis

Economic Assessment:
➢ Consider whether the project is the best among other options
➢ Prioritise the projects so that the resources can be allocated effectively if several projects are
underway
➢ The economic assessment can be done by the following ways:
✓ Cost-benefit analysis
✓ Cash flow forecasting
✓ Various cost-benefit evaluation techniques

Cost benefit analysis:

• It is one of the important and common way of carrying “economic assessment” of a proposed
information system.
• This is done by comparing the expected costs of development and operation of the system
with its benefits.
• Any project aiming at return on investment must provide a greater benefit than putting that
investment in a bank.
• So it takes an account:
• Expected cost of development of system
• Expected cost of operation of system
• Benefits obtained
• Assessment is based on:
• Whether the estimated costs are executed by the estimated income.
• And by other benefits
• For achieving benefit where there is a scarce resource, projects will be prioritized and
resources are allocated effectively.
• The standard way of evaluating economic benefits of any project is done by “cost benefit
analysis”
• Cost benefit analysis comprises of two steps:
Step-1: identifying and estimating all of the costs and benefits of carrying out the
project.
Step-2: expressing these costs and benefits in common units.
Step-1:
It includes
• Development cost of system.
• Operating cost of system.
• Benefits obtained by system.
When new system is developed by the proposed system, then new system should reflect
the above three as same as proposed system.
Example: sales order processing system which gives benefit due to use of new system.

Step-2:
– Calculates net benefit.
– Net benefit = total benefit = total cost.
– cost should be expressed in monetary terms.

Three types of cost

1. Development costs: includes salary and other employment cost of staff involved.
2. Setup costs: includes the cost of implementation of system such as hardware, and
also file conversion, recruitment and staff training.
3. Operational cost: cost require to operate system, after it is installed.

Three categories of benefits:

1. Direct benefits: directly obtained benefit by making use of/operating the system.
Example: reduction of salary bills, through the introduction of a new , computerized
system.
2. Assessable indirect benefits: these benefits are obtained due to updation / upgrading the
performance of current system. It is also referred as “secondary benefits”.
Example: “use of user – friendly screen”, which promotes reduction in errors, thus
 increases the benefit
3. Intangible benefits: these benefits are longer term, difficult to quantify. It is also
referred as “indirect benefits”.
Example: enhanced job interest leads reduction of staff turnover, inturn leads lower
recruitment costs.

Benefits management:

Benefit management encompasses the identification, optimization and tracking of the expected
benefits from a business change in order to ensure that they are actually achieved. To do this, we
must:
• Define the expected benefits from the programme;
• Analyze the balance between costs and benefits;
• Plan how the benefits will be achieved and measured;
• Allocate responsibilities for the successful delivery of the benefits;
• Monitor the realization of the of the benefits.

Benefits can be of many different types, including

❖ Mandatory compliance
❖ Quality of service
❖ Productivity
❖ More motivated work force
❖ Internal management benefits
❖ Risk reduction
❖ Economy
❖ Revenue enhancement/acceleration
❖ Strategic fit

A change could have more than one of these types of benefit. In fact, benefits are often inter-
liked. An example of this is an insurance company which introduced a facility whereby when
settling claims for damage to property, they directly arranged for constructors to carry out the
remedial work. This improved quality of service for customers as it saved them the trouble of
locating a reputable contractor, reduced costs to the insurance company because they could take
advantage of the bulk purchase of services and improved staff morale because of the goodwill
generated between the insurance company’s front-line staff and the customer.

Quantifying benefits

We have already seen that benefits can be:

o Quantified and valued – that is, a direct financial benefit is experienced
o Quantified but not valued – for example, a decrease in the number of customer
complaints
o Identified but not easily quantified – for example, public approval of the
organization in the locality where it is based.
 A particular activity might also have disbenefits. For example, increased sales might
mean that more money has to be spent on expensive overtime working. The need for
benefit profiles is that estimate when and how benefits will be experienced. Specific
staff have to be allocated responsibility for ensuring that the planned benefits actually
materialize.
Benefit cannot normally be monitored in a purely project environment because the
project will almost certainly have been officially closed before the benefits start to filter
through. Benefit management brings to the fore the powerful idea that developers and
users are jointly responsible for ensuring the delivery of the benefits of projects.

Cash Flow Forecasting

Economic Assessment:

➢ Consider whether the project is the best among other options

➢ Prioritise the projects so that the resources can be allocated effectively if several projects are
underway
➢ The economic assessment can be done by the following ways:
✓ Cost-benefit analysis
✓ Cash flow forecasting
✓ Various cost-benefit evaluation techniques
We have already discussed about the cost benefit analysis. In this session, we are going to
discuss about the Cash flow forecasting.
Cash flow forecasting
As important as estimating the overall costs and benefits of a project is producing a cash flow
forecast which indicates when expenditure and income will take place. It estimate overall cost and
benefits of a product with respect to time.
• Negative cash flow during development stage.
• Positive cash flow during operating life.
During development stage
• Staff wages
• Borrowing money from bank
• Paying interest to bank
• Payment of salaries
• Amount spent for installation, buying hardware and software
Income is expected by 2 ways.
• Payment on completion
• Stage payment
The difficulty and importance of cash flow forecasting is evidenced by the number of
companies that suffer bankruptcy because, although they are developing profitable products
or services, they cannot sustain an unplanned negative cash flow.
 When estimating future cash flows, it is usual to ignore the effects of inflation.
Forecasts of inflation rates tend to be uncertain. Moreover, if expenditure is increased due to
inflation it is likely that income will increase proportionately.
Example:
The following table illustrates cash flow forecasts for three projects. In each case it is
assumed that that the cash flows take place at the end of each year. Here negative values represent
expenditure and positive values represent income.

Year Project1 Project2 project3

0 -100000 -1,000,000 -120000

1 10,000 2,00000 30,000

2 10,000 2,00000 30,000

3 10,000 2,00000 30,000

4 20,000 2,00000 30,000

5 100000 3,00000 75,000

Cash flow forecasting or cash flow management is a key aspect of financial management
of a business, planning its future cash requirements to avoid a crisis of liquidity.

Cash flow forecasting is important because if a business runs out of cash and is not able to obtain
new finance, it will become insolvent. It is no excuse for management to claim that they didn't see a
cash flow crisis coming. So in business, "cash is king". Cash flow is the life-blood of all businesses—
particularly start-ups and small enterprises. As a result, it is essential that management forecast
(predict) what is going to happen to cash flow to make sure the business has enough to survive. How
often management should forecast cash flow is dependent on the financial security of the business. If
the business is struggling, or is keeping a watchful eye on its finances, the business
owner should be forecasting and revising his or her cash flow on a daily basis. However, if the finances
of the business are more stable and 'safe', then forecasting and revising cash flow weekly or monthly
is enough. Here are the key reasons why a cash flow forecast is so important:

• Identify potential shortfalls in cash balances in advance—think of the cash flow forecast as
an "early warning system". This is, by far, the most important reason for a cash flow forecast.
• Make sure that the business can afford to pay suppliers and employees. Suppliers who don't
get paid will soon stop supplying the business; it is even worse if employees are not paid on
time.
• Spot problems with customer payments—preparing the forecast encourages the business to
look at how quickly customers are paying their debts. Note—this is not really a problem for
businesses (like retailers) that take most of their sales in cash/credit cards at the point of sale.
• As an important discipline of financial planning—the cash flow forecast is an important
management process, similar to preparing business budgets.
• External stakeholders such as banks may require a regular forecast. Certainly, if the business
has a bank loan, the bank will want to look at the cash flow forecast at regular intervals.

Components that Should be Considered when Developing a Cash Flow Forecast

Development of Cash Forecasting Procedures

Cash forecasting procedures should be developed so that the most current information (such as
accounts payable and accounts receivable) is reflected in the forecasts and that the forecasts are as
accurate as possible. One component that should be considered is a cheque-clearing system that can
derive statistics from the accounts payable system, and the bank clearing data.

Computerized Forecasting System

Information systems should be in place to ensure the current information can be gathered and
updated promptly for accurate cash forecasts. Cash management systems and procedures should make
use of appropriate and modern administrative practices. Staff involved in these positionsshould
have the ability to work and maintain these systems.

Long-Term Cash Flows

Both short and long-term cash forecasts should be prepared to support short and long term
investment decisions. It is important for those purchasing and selling investments to know when to
match the maturity dates with the dates of cash requirements or surpluses. The cash forecasting system
should provide at least a one-year rolling cash forecast that should be constantly updated for changes.
The annual cash flow forecast will be changed to include all cash inflows in addition to outflows.

Variance Reporting of Cash Forecasts

Significant variances between actual and forecasted cash flows should be measured,
monitored, and reported on an on-going basis to management. The performance indicators should be
included in the appropriate program overview. The variances should be recorded and explained – what
caused the variance to happen, along with solutions if required to correct the variance, and establish
actions to avoid a recurrence if required.
Steps to Preparing a Cash Flow Forecast

1. Examine previous years monthly financial data

• For an accurate prediction, previous monthly financial data should be examined when
forecasting the succeeding year’s potential receipts and disbursements.
2. Design a cash flow work sheet
• Helps organize cash flows through projected receipts and accounts receivable.

3. Consider cash flow receipts

• For new operations (i.e. programs), the average monthly revenues of a similar size
municipality or operation in Nova Scotia can be compared as a benchmark.

• For existing operations, receipts from the same month in a previous year, adjusting for
any current circumstances for that month in the succeeding year.

• Cash receipts can be predicted by taking into consideration tax bill due dates, tax sale
dates, and expected payment dates of transfers from other governments.

4. Consider cash flow disbursements

• Municipalities should only show the cash you expect to pay out each month.

o Cash disbursements can be predicted by using past year’s payroll information and pay dates
for the coming year, information on transfers to other governments and their due dates, and
information on other contractual payments (for example: debt charges or rentalcharges).

• For example, if the municipality is paying the supplier in 30 days, the cash payouts for
January’s purchases will be shown in February. If you can obtain trade credit for longer
terms, then cash outlays will appear two or even three months after thepurchase has
been received and invoiced.

5. Reconciliation of the cash receipts to cash disbursements

• The reconciliation section of the cash flow worksheet begins by showing the balance
carried over from the previous months’ operations.

• The total of the current months’ receipts are added and the total of the current month’s
disbursements are subtracted. This adjusted balance will be carried forward to the
next months’ disbursements. This adjusted balance will be carried forward to the first
line of the reconciliation portion of the next month to become the base where the next
month’s cash flow activity will be added and/or subtracted.

• Cash flows should be managed to maintain minimum balance requirements.

6. Cash flow maintenance

• Cash flow forecasts should be revised on an ongoing basis and should be constantly
modified to current circumstances and new conditions.

• At the end of each month, actual cash flow figures should be compared to the planned
figures to determine if there is a great discrepancy between the two sets of figures.

• If significant variances exist, they should be analyzed, and assumptions should be

adjusted to reflect the actual figures more closely.

cost-benefit evaluation techniques

Economic Assessment:
➢ Consider whether the project is the best among other options
➢ Prioritise the projects so that the resources can be allocated effectively if several projects are
underway
➢ The economic assessment can be done by the following ways:
✓ Cost-benefit analysis
✓ Cash flow forecasting
✓ Various cost-benefit evaluation techniques
We have already discussed about the cost benefit analysis and Cash flow forecasting. In this
session, we are going to discuss about the various cost-benefit evaluation techniques.

Cost-benefit evaluation techniques:

It consider
• the timing of the costs and benefits
• the benefits relative to the size of the investment

Common method for comparing projects on the basic of their cash flow forecasting.
1) Net profit
2) Payback Period
3) Return on investment
4) Net present Value
5) Internal rate of return

Net profit
❖ Net profit is calculated by subtracting a company's total expenses from total income.
❖ Showing what the company has earned (or lost) in a given period of time (usually one year).
also called net income or net earnings.

Net profit= total incomes - total costs

Example:
The following table illustrates cash flow forecasts for three projects. In each case it is
assumed that that the cash flows take place at the end of each year. Here negative values represent
expenditure and positive values represent income.

Year Project1 Project2 project3

0 -100000 -1,000,000 -120000

1 10,000 2,00000 30,000

2 10,000 2,00000 30,000

3 10,000 2,00000 30,000

4 20,000 2,00000 30,000

5 100000 3,00000 75,000

Calculate net profit.(-ive total cost or total investment)

Net profit= total incomes - total costs

• For project1, total income = 10,000+10,000+10,000+20,000+1,00000=1,50000

Total cost = 1,00000
Net profit = 1,50000-1,00000=Rs.50000
• For project2, total income = 2,00000+2,00000+2,00000+2,00000+3,00000=1,100,000
Total cost = 1,000,000
Net profit = 1,100,000-1,000,000=Rs.100000
• For project2, total income = 30,000+30,000+30,000+30,000+30,000+75,000=1,95000
Total cost = 1,20000
Net profit = 1,95000-1,20000=Rs.75,000

Year Project1 Project2 project3

0 -100000 -1,000,000 -120000

1 10,000 2,00000 30,000

2 10,000 2,00000 30,000

3 10,000 2,00000 30,000

4 20,000 2,00000 30,000

5 100000 3,00000 75,000

 Net profit 50,000 1,00,000 75,000

Payback Period

• The payback period is the time taken to recover the initial investment or it is the length of
time required for cumulative incoming returns to equal the cumulative costs of an investment
Advantages
• simple and easy to calculate.
• It is also a seriously flawed method of evaluating investments
Disadvantages
• It attaches no value to cash flows after the end of the payback period.
• It makes no adjustments for risk.
• It is not directly related to wealth maximisation as NPV is.
• It ignores the time value of money.
• The "cut off" period is arbitrary.

Example:

The following table illustrates cash flow forecasts for three projects. In each case it is
assumed that that the cash flows take place at the end of each year. Here negative values
represent expenditure and positive values represent income.

Year Project1 Project2 project3

0 -100000 -1,000,000 -120000

1 10,000 2,00000 30,000

2 10,000 2,00000 30,000

3 10,000 2,00000 30,000

4 20,000 2,00000 30,000

5 100000 3,00000 75,000

Calculate Payback Period

Project1 =10,000+10,000+10,000+20,000+1,00,000=1,50,000
Project 2= 2,00,000+2,00,000+2,00,000+2,00,000+3,00,000=11,000,00
Project 3= 30,000+30,000+30,000+30,000 + 75,000 =1,95,000

It ignores any benefits that occur after the payback period and, therefore, does not
measure profitability. And it ignores the time value of money.
RETURN ON INVESTMENT or ACCOUNTING RATE OF RETURN

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

Or
• A performance measure used to evaluate the efficiency of an investment or to compare the
efficiency of a number of different investments
Disadvantages
• It takes no account of the timing of the cash flows.
• Rate of returns bears no relationship to the interest rates offered or changed by bank.

ROI = average annual profit * 100

total investment

Average annual profit = net profit

total no. of years
Example:

The following table illustrates cash flow forecasts for three projects. In each case it is
assumed that that the cash flows take place at the end of each year. Here negative values
represent expenditure and positive values represent income.

Year Project1 Project2 project3

0 -100000 -1,000,000 -120000

1 10,000 2,00000 30,000

2 10,000 2,00000 30,000

3 10,000 2,00000 30,000

4 20,000 2,00000 30,000

5 100000 3,00000 75,000

• Calculate ROI for project 1.

Total investment =1,00,000
Net profit = 50,000
Total no. of year = 5
Average annual profit=50,000/5=10,000rs
ROI= (10,000/1,00,000) *100 = 10%

• Calculate ROI for project 2.

Total investment =1,000,000
 Net profit = 1,00,000
Total no. of year = 5
Average annual profit=1,00,000/5=20,000rs
ROI= (20,000/1,000,000) *100 = 2%

• Calculate ROI for project 3.

Total investment =1,20,000
Net profit = 75,000
Total no. of year = 5
Average annual profit=75,000/5=15,000rs
ROI= (15,000/1,20,000) *100 = 12.5%

2.1 Net present value and internal rate of return

Cost-benefit evaluation techniques:

It consider
• the timing of the costs and benefits
• the benefits relative to the size of the investment
Common method for comparing projects on the basic of their cash flow forecasting.
1) Net profit
2) Payback Period
3) Return on investment
4) Net present Value
5) Internal rate of return

Net present value (NPV)

• It is the sum of the present values of all future amounts.
• Present value is the value which a future amount is worth at present
• It takes into account the profitability of a project and the timing of the cash
flows
• Discounted Cash Flow (DCF) is a cash flow summary adjusted to reflect the
time value of money. DCF can be an important factor when evaluating or
comparing investments, proposed actions, or purchases. Other things being equal,
the action or investment with the larger DCF is the better decision. When
discounted cash flow events in a cash flow stream are added together, the result
is called the Net Present Value (NPV).
• When the analysis concerns a series of cash inflows or outflows coming at
different future times, the series is called a cash flow stream. Each future cash
flow has its own value today (its own present value). The sum of these present
values is the Net Present Value for the cash flow stream.
• The size of the discounting effect depends on two things: the amount of time
between now and each future payment (the number of discounting periods) and
an interest rate called the Discount Rate. Discount rate is the annual rate by
which we discount future earning

• The example shows that:

• As the number of discounting periods between now and the cash arrival
increases, the present value decreases.
• As the discount rate (interest rate) in the present value calculations increases,
the present value decreases.

Issues in NPV
➢ Choosing an appropriate discount rate is difficult
➢ Ensuring that the rankings of projects are not sensitive to small changes in discount
rate
 Guidelines:
➢ Use the standard rate prescribed by the organization
➢ Use interest rate + premium rate
➢ Use a target rate of return
➢ Rank the projects using various discount rates

Applying discount factors

NPV is the sum of the discounted cash flows for all the years of the ‘project’ (note that
in NPV terms the lifetime of the completed application is included in the ‘project’)
The figure of RM618 means that RM618 more would be made than if the money were simply invested
at 10%. An NPV of RM0 would be the same amount of profit would be generated as investing at 10%.

Discount factor(discount
Year Cash-flow Discounted cash flow
rate 10%)

0 -100,000 1.0000 -100,000

1 10,000 0.9091 9,091

2 10,000 0.8264 8,264

3 10,000 0.7513 7,513

4 20,000 0.6830 13,660

5 100,000 0.6209 62,090

NPV 618

The figure of RM618 means that RM618 more would be made than if the money were
simply invested at 10%. An NPV of RM0 would be the same amount of profit would be generated as
investing at 10%.

Example: Comparing Competing Investments with NPV.

Consider two competing investments in computer equipment. Each calls for an initial cash
outlay of $100, and each returns a total a $200 over the next 5 years making net gain of $100. But
the timing of the returns is different, as shown in the table below (Case A and Case B), and therefore
the present value of each years return is different. The sum of each investments present values is
called the Discounted Cash flow (DCF) or Net Present Value (NPV). Using a 10% discount rate

CASE A CASE B
Discount
Timing Rate(10%) Present
Net Cash Flow Net Cash Flow Present Value
Value
Now 0 1 – $100.00 – $100.00 – $100.00 – $100.00

Year 1 0.9091 $60.00 $54.54 $20.00 $18.18

Year 2 0.8264 $60.00 $49.59 $20.00 $16.52

Year 3 0.7513 $40.00 $30.05 $40.00 $30.05

Year 4 0.6830 $20.00 $13.70 $60.00 $41.10

Year 5 0.6209 $20.00 $12.42 $60.00 $37.27

NPVA =
Total Net CFA = $100.00 Net CFB = $100.00 NPVB = $43.12
$60.30
Disadvantage
◼ May not be directly comparable with earnings from other investments or the costs of
borrowing capital

Internal Rate of Return (IRR)

❖ The percentage discount rate that would produce a NPV of zero
❖ A relative measure. Use Excel to demonstrate the calculation of NPV and IRR
❖ The IRR being a relative measure does not indicate the absolute size of the return.

The IRR compares returns to costs by asking: "What is the discount rate that
would give the cash flow stream a net present value of 0?"

CASE A CASE B
Discount
Present Present
Timing Rate(10%) Net Cash Flow Net Cash Flow
Value Value

Now 0 1 – $100.00 – $100.00 – $100.00 – $100.00

Year 1 0.9091 $60.00 $54.54 $20.00 $18.18

Year 2 0.8264 $60.00 $49.59 $20.00 $16.52

Year 3 0.7513 $40.00 $30.05 $40.00 $30.05

Year 4 0.6830 $20.00 $13.70 $60.00 $41.10

Year 5 0.6209 $20.00 $12.42 $60.00 $37.27

NPVA =
Total Net CFA = $100.00 Net CFB = $100.00 NPVB = $43.12
$60.30

IRR asks a different question of the same two cash flow streams. Instead of proposing
a discount rate and finding the NPV of each stream (as with NPV), IRR starts with the net cash
flow streams and finds the interest rate (discount rate) that produces an NPV of zero for each.
The easiest way to see how this solution is found is with a graphical summary:

• These curves are based on the Case A and Case B cash flow figures in the table above. Here,
however, we have used nine different interest rates, including 0.0 and 0.10, on up through 0.80.
• As you would expect, as the interest rate used for calculating NPV of the cash flow stream
increases, the resulting NPV decreases.
• For Case A, an interest rate of 0.38 produces NPV = 0, whereas
• Case B NPV arrives at 0 with an interest rate of 0.22.
• Case A therefore has an IRR of 38%, Case B an IRR of 22%.
• IRR as the decision criterion, the one with the higher IRR is the better choice.
 Risk Evaluation

Every project involves risk. Risk is “an uncertain event or condition that, if it occurs has a
positive or negative effect on a project objectives”, include transferring the risk to another party,
avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the
consequences of a particular risk.There are two types of risks.
1. Project risk – which prevent the project from being completed successfully.
2. Business risk – delivered products are not profitable.
• Risk evaluation is meant to decide whether to proceed with the project or not, and whether
the project is meeting its objectives.

Risk Occurs:
• When the project exceed its original specification
• Deviations from achieving it objectives and so on.

Risk evaluation describe the following

1. Risk Identification and ranking
2. Risk and Net Present Value
3. Cost benefit Analysis
4. Risk profile analysis
5. Decision trees

Risk Identification and ranking

• Identify the risk and give priority.
• Could draw up draw a project risk matrix for each project to assess risks
• Project risk matrix used to identify and rank the risk of the project
Example of a project risk matrix

In the table ‘Importance’ relates to the cost of the damage if the risk were to materialize and
‘likelihood’ to the probability that the risk will actual occur. ‘H’ indicates ‘High’, ‘M’ indicates
‘medium’ and ‘L’ indicates ‘low’. The issues of risk analysis are explored in much more depth in
lecture/chapter 7.
Risk and Net Present Value
• For riskier projects could use higher discount rates
• Ex: Can add 2% for a Safe project or 5 % for a fairly risky one.
Cost benefit Analysis
It is one of the important and common way of carrying “economic assessment” of a proposed
information system. This is done by comparing the expected costs of development and operation of
the system with its benefits.

Risk profile analysis

• This make use of “risk profiles” using sensitivity analysis.
• It compares the sensitivity of each factor of project profiles by varying parameters which
affect the project cost benefits.
• Eg:
• Vary the original estimates of risk plus or minus 5% and re-calculate the expected cost
benefits.

• P1 depart far from p2,have large variation

• P3 have much profitable than expected
• All three projects have the same expected profit
• Compare to p2 , p1 is less risky.

Decision trees
• Identify over risky projects
• Choose best from risk
• Take suitable course of action
Decision tree of analysis risks helps us to
1. Extend the existing system
➢ increase sales
➢ improve the management information
2. Replace the existing system
➢ Not replacing system leads in loss
➢ Replace it immediately will be expensive.
 • The expected value of Extending system=
(0.8*75,000)-(0.2*100,000)=40,000 Rs.
• The expected value of Replacing system=
(0.2*250,000)-(0.8*50,000)=10,000 Rs.
Therefore, organization should choose the option of extending the existing system.

The diagram here is figure 3.8 in the text.

This illustrates a scenario relating to the IOE case study. Amanda is responsible for extending
the invoicing system. An alternative would be to replace the whole of the system. The decision is
influenced by the likelihood of IOE expanding their market. There is a strong rumour that they could
benefit from their main competitor going out of business: in this case they could pick up ahuge amount
of new business, but the invoicing system could not cope. However replacing the system immediately
would mean other important projects would have to be delayed.
The NPV of extending the invoicing system is assessed as £75,000 if there is no sudden
expansion. If there were a sudden expansion then there would be a loss of £100,000. If the whole
system were replaced and there was a large expansion there would be a NPV of £250,000 due to the
benefits of being able to handle increased sales. If sales did not increase then the NPV would be -
£50,000.
The decision tree shows these possible outcomes and also shows the estimated probability of each
outcome.
The value of each outcome is the NPV multiplied by the probability of its occurring. The
value of a path that springs from a particular decision is the sum of the values of the possible outcomes
from that decision. If it is decided to extend the system the sum of the values of the outcomes is
£40,000 (75,000 x 0.8 – 100,000 x 0.2) while for replacement it would be £10,000 (250,000 x 0.2 –
50,000 x 0.80). Extending the system therefore seems to be the best bet.
 SELECTION OF AN APPROPRIATE PROJECT APPROACH

BUILD OR
BUY?

1. Software development involves developing the software either from

the developers or that of the client or users.
2. In in-house development the developers and the users are in the same
organization whereas if the development is outsourced they are in different
organization.
3. Developing a new IT application in-house:
➢ Time is needed to develop the software.
➢ Would often require the recruitment of new technical staff to do the job.
➢ Usually, the new staff won’t be needed after the project is completed.
➢ Sometimes due to the novelty of the project there may be lack of
executives tolead the effort.
4. Advantages of off -the -shelf (OTS) software are:
➢ Cheaper as supplier can spread development costs over a large
number ofcustomers.
➢ Software already exists.
✓ Can be trialed by potential customer.
✓ No delay while software being developed.
➢ Where there have been existing users, bugs are likely to have been
found anderadicated.
5. Disadvantages of off -the -shelf (OTS) software are:
➢ Customer will have same application as everyone else: no competitive
advantage, but competitive advantage may come from the way
application isused.
➢ Customer may need to change the way they work in order to fit in with
OTSapplication.
➢ Customer does not own the code and cannot change it.
➢ Danger of over-reliance on a single supplier.
4.2 CHOOSING METHODOLOGIES AND TECHNOLOGIES
1. Methodologies describe a collection of methods which is a general way of
carrying out a specific task that could be applicable to any project needing to
that task.
2. Techniques tend to involve the application of scientific, mathematical or
logical principles to resolve a particular kind of problem.
3. Methods involve the creation of models.
4. A model is a representation of a system which abstracts certain features but
oftenignores others.
5. Project analysis should select the most appropriate
methodologies andtechnologies for a project.
6. Methodologies include approaches like the Unified Software
Development Process (USDP), Structured Systems Analysis and Design
Method (SSADM) andHuman- Centered Design.
7. The analysis identifies the methodology, but also selects the methods
within themethodology that are to be deployed.
8. As well as the products and activities.
9. The chosen methods and technologies will affect:
➢ The training requirements for development staff.
➢ The types of staff to be recruited.
➢ The development environment - both hardware and software.
➢ System maintenance arrangements.
10. Steps of project analysis are given below:
4.3 SOFTWARE PROCESSES AND PROCESS MODELS
1. The expression of need for the product is called product inception.
2. From the inception stage product undergoes a series of transformations through a
few identifiable stages until it is fully developed and released to the customer.
3. After release, the product is used by the customer and during this time the product
needs to be maintained for fixing bugs and enchaining functionalities. This
stage is called maintenance stage.
4. When the product is no longer useful to the customer, it is retired. This set of
identifiable stages through which a product transits from inception to retirement
form the life of the product.
5. The software life cycle is commonly referred to as Software Development Life
Cycle SDLC and software process.
6. A life cycle model (also called a process model) of software product is a graphical
representation of its life cycle.
7. A process model may describe the details of various types of act out during the
different phases and the documents produced.
4.4 CHOICE OF PROCESS MODELS
1. The word 'process' emphasizes the idea of a system in action.
2. In order to achieve an outcome, the system will have to execute one or more
activities: this is its process.
3. This applies to the development of computer based applications.
4. A number of interrelated activities have to be undertaken to create a final
product.
5. These activities can be organized in different ways and these are called as
process models.
6. The planner selects methods and specifies how they are to be applied.
4.5 STRUCTURE VERSUS SPEED OF DELIVERY
1. Structured approach is also called as ‘heavyweight’ approaches.
2. Step-by-step methods where each step and intermediate product is carefully
defined.
3. Emphasis on getting quality right first time. Example: use of UML (Unified
Modelling Language).
4. Future vision: Model-Driven Architecture (MDA). UML supplemented with
Object Constraint Language, press the button and application code generated from
the UML/OCL model Agile methods.
5. Emphasis on speed of delivery rather than documentation.
6. Rapid Application Development (RAD) emphasized use of quickly developed
prototypes.
7. Requirements are identified and agreed in intensive workshops with users in
Joint Application Development (JAD).
8. System development using MDA involves creating a platform independent
model (PIM) which specifies system functionality using UML diagrams
supplemented by additional information recorded in the Object Constraint
Language (OCL).
9. PIM is the logical structure that should apply regardless of the software and
hardware environment in which the system is to be implemented.
10. PIM can be transformed into platform-specific model (PSM) and PSM can
then be transformed into executable code to implement working system.
11. The goal is that once a PIM had been created the creation of PSMs and
executable code will be automated.
4.6 THE WATERFALL MODEL
1. Waterfall model is sometimes called as linear sequential model or classic life
cycle model or the one-shot or one- through model.
2. This model suggests a systematic sequential approach for software development
that begins at system level & progress through analysis, design, coding, testing and
maintenance.
a) System Information Engineering:
➢ Because software is always a part of large system, work begins by establishing
the requirements for all system elements & then allocating subset of the sequence
to the software.
b) Software Requirement Analysis
➢ The requirement gathering process is intensified by focusing on software.
Software Engineer/ Analyst must understand the information as well as required
function, behavior, performance and interface so as to build the software.
➢ Requirements for both the systems and software are documented and are given
to the customer.
c) Design
➢ Software design is actually multistep process that focuses on four distinct
attributes of a program i.e. Data Structure, Software Architecture, Interface
Representation and Procedural Details.
➢ The design process translates the requirements into representation of the system
software.
d) Code Generation
➢ The design must be translated into machine readable form.
e) Testing
➢ Once coding has been generated testing begins.
➢ The test process focuses on the logical into software ensuing that all
statements have been tested.
f) Support/ Maintenance
➢ Software will undergo change before it is delivered to the customer.
(External Environment)
ADVANTAGES OF WATERFALL MODEL:
a) Simple and easy to understand and use.
b) Phases are processed and completed one at a time.
c) Works well for smaller projects where requirements are very well understood.
DISADVANTAGES OF WATERFALL MODEL:
a) Once an application is in the testing stage, it is very difficult to go back and change
something that was not well-thought out in the concept stage.
b) High amounts of risk and uncertainty.
c) Poor model for long and ongoing projects.
d) Not suitable for the projects where requirements are at a moderate to high risk of
changing.
WHEN TO USE THE WATERFALL MODEL:
a) Requirements are very well known, clear and fixed.
b) Ample resources with required expertise are available freely.
c) The project is short.

4.7 WHAT IS THE SPIRAL MODEL?

1. The spiral model combines the idea of iterative development with the systematic,
controlled aspects of the waterfall model.
2. This Spiral model is a combination of iterative development process model and
sequential linear development model i.e. the waterfall model with a very high
emphasis on risk analysis.
3. It allows incremental releases of the product or incremental refinement through
each iteration around the spiral.
4. The spiral model has four phases. A software project repeatedly passes through
these phases in iterations called Spirals.
a) Identification:
➢ This phase starts with gathering the business requirements in the baseline spiral.
➢ In this identification of system requirements, subsystem requirements and unit
requirements are all done in this phase.
➢ This phase also includes understanding the system requirements by
continuous communication between the customer and the system analyst.
b) Design:
➢ The Design phase starts with the conceptual design in the baseline spiral and
involves architectural design, logical design of modules, physical product design
and the final design in the subsequent spirals.
c) Construct or Build:
➢ The Construct phase refers to production of the actual software product at
every spiral.
d) Evaluation and Risk Analysis:
➢ Risk Analysis includes identifying, estimating and monitoring the technical
feasibility and management risks.
5. ADVANTAGES OF SPIRAL MODEL:
a) High amount of risk analysis hence, avoidance of Risk is enhanced.
b) Good for large and mission-critical projects.
c) Strong approval and documentation control.
d) Additional Functionality can be added at a later date.
e) Software is produced early in the software life cycle.
6. DISADVANTAGES OF SPIRAL MODEL:
a) Can be a costly model to use.
b) Risk analysis requires highly specific expertise.
c) Project’s success is highly dependent on the risk analysis phase.
d) Doesn’t work well for smaller projects.
7. WHEN TO USE SPIRAL MODEL:
➢ When deliverance is required to be frequent.
➢ When the project is large.
➢ When requirements are unclear and complex
➢ When changes may require at any time
➢ Large and high budget projects
➢ Users are unsure of their needs.
4.8 SOFTWARE PROTOTYPING
1. A prototype is a working model of one or more aspects of the projected system.
2. It is constructed and tested quickly and inexpensively in order to test
out assumptions.
3. Prototypes can be classified as throw-away or evolutionary.
a) Throw away prototypes:
➢ The prototype tests out some ideas and is then discarded when the
true development of the operational system is commenced.
➢ The prototype could be developed using a different hardware or software
is environment.
➢ A procedural programming language is then used for the final system
where machine-efficiency is important.
b) Evolutionary prototypes:
➢ The prototype is developed and modified until it is finally in a state where it
can become the operational system.
4. BENEFITS OF PROTOTYPING:
a) Learning by doing: One can usually look back on a task and see where mistakes
have been made mistakes.
b) Improved communication: Users do not get a feel for how the system is likely
to work in practice from a specification.
c) Improved user involvement: The users can be more actively involved in design
decisions.
d) Clarification of partially known requirements: Where there is no existing system,
users can often get a better idea of what might be useful to them by trying out
prototypes.
e) Demonstration of the consistency and completeness of a specification: Any
mechanism that attempts to implement a specification on a computer is likely to
uncover ambiguities and omissions.
f) Reduced need for documentation: Because a working prototype can be examined
there is less need for detailed documentation of requirements.
g) Reduced maintenance costs: If the user is unable to suggest modifications at the
prototyping stage they are more likely to ask for changes to the operational system.
This reduction of maintenance costs is the core of the financial case for prototypes.
h) Feature constraint: If an application building tool is used, then the prototype will
tend to have features that are easily implemented by that tool.
i) Production of expected results: The problem with creating test cases is generally
not the creation of the test input but the accurate calculation of the expected results.
5. DRAWBACKS OF PROTOTYPING:
a) Users can misunderstand the role of the prototype.
b) Lack of project standards possible.
c) Lack of control: It can be difficult to control the prototyping cycle if the driving
force is the users’ have a tendency to try out new things.
d) Additional expenses: Building and exercising a prototype will incur additional
expenses.
e) Machine efficiency: A system built through prototyping while sensitive to the
users’ needs, might not be as efficient in machine terms as one developed using more
conventional methods.
4.10 WHAT IS INCREMENTAL DELIVERY?
1. Incremental delivery involves breaking the system down into small components
which are then implemented and delivered in sequence.
2. Each component that is delivered must give some benefit to the user.

3. ADVANTAGES OF INCREMENTAL DELIVERY:

a) The feedback from early increments can influence the later stages.
b) The possibility of changes in requirements is reduced.
c) Users get benefits earlier than with a conventional approach.
d) Smaller sub-projects are easier to control and manage.
e) Job satisfaction is increased for developers.
4. DISADVANTAGES OF INCREMENTAL DELIVERY:
a) ‘Software breakage’, that is, later increments might require modifications to the
earlier increments.
b) Developers might be more productive working on one large system than on a
series of smaller ones.
 Dynamic Systems Development Method (DSDM)

➢ Dynamic System Development Method(DSDM) is another approach to system

development, which, as the name suggests, develops will develop the system
dynamically.
➢ This methodology is independent of tools, in that it can be used with both
structured analysis and design approach or object-oriented approach.
➢ The Dynamic System Development Method (DSDM) is dynamic as it is a Rapid
Application Development (RAD)method that uses incremental prototyping.
➢ This method is particularly useful for the systems to be developed in short time
span and where the requirements cannot be frozen at the start of the application
building.
➢ Whatever requirements are known at a time, design for them is prepared and
design is developed and incorporated into system.
➢ In Dynamic System Development Method (DSDM), analysis, design and
development phase can overlap.
➢ In Dynamic System Development Method (DSDM), requirements evolve with
time.
 Feasibility study:
➢ In this phase the problem is defined and the technical feasibility of the desired
application is verified.
Business study
➢ In this phase the overall business study of the desired system is done.
➢ The business requirements are specified at a high level and the information
requirements out of the system are identified.
Functional Model Iteration
➢ The main focus in this phase is on building the prototype iteratively and getting
it reviewed from the users to bring out the requirements of the desired system.
➢ The end product of this phase is a functional model consisting of analysis model
and some software components containing the major functionality.
Design and Build Iteration
➢ The software components designed during the functional modeling are further
refined till they achieve a satisfactory standard.
➢ The product of this phase is a tested system ready for implementation.

Implementation
➢ Implementation is the last and final development stage in this methodology.
➢ In this phase the users are trained and the system is actually put into the
operational environment.
➢ Everything was delivered as per the user demand, so no further development
required.

What is RAD Model?

➢ RAD Model or Rapid Application Development model is a software
development process based on prototyping without any specific planning.
➢ In RAD model, there is less attention paid to the planning and more priority
is given to the development tasks.
➢ It targets at developing software in a short span of time.
SDLC RAD modeling has following phases: -
1. Business Modeling
2. Data Modeling
3. Process Modeling
4. Application Generation
5. Testing and Turnover
 RAD Model Activities performed in RAD Modeling
Phases

Business On basis of the flow of information and distribution betweenvarious business

Modeling channels, the product is designed.

Data The information collected from business modeling is refined into a

Modeling set of data objects that are significant for the business.
Process The data object that is declared in the data modeling phase is
Modeling transformed to achieve the information flow necessary to
implement a business function.

Application Automated tools are used for the construction of the software, to
Generation convert process and data models into prototypes.
Testing and As prototypes are individually tested during every iteration, theoverall testing
Turnover time is reduced in RAD.
 WHAT IS AGILE?
➢ Agile software development refers to a group of software development
methodologies based on iterative development.
➢ Where requirements and solutions evolve through collaboration between self-
organizing cross-functional teams.
➢ Agile methods or Agile processes generally promote a disciplined project
management process that encourages frequent inspection and adaptation.
➢ A leadership philosophy that encourages teamwork, self-organization and
accountability.
➢ A set of engineering best practices intended to allow for rapid delivery of high-
quality software, and a business approach that aligns development with customer
needs and company goals.
➢ Agile development refers to any development process that is aligned with the
concepts of the Agile Manifesto.
➢ The Manifesto was developed by a group fourteen leading figures in the software
industry, and reflects their experience of what approaches do and do not work for
software development.
 Phases of Agile Model:
Following are the phases in the Agile model are as follows:

1. Requirements gathering
2. Design the requirements
3. Construction/ iteration
4. Testing/ Quality assurance
5. Deployment
6. Feedback

1. Requirements gathering: In this phase, you must define the requirements.

2. Design the requirements: You can use the user flow diagram or the high-level
UML diagram to show the work of new features and show how it will apply to your
existing system.

3. Construction/ iteration: When the team defines the requirements, the work
begins. Designers and developers start working on their project, which aims to
deploy a working product.

4. Testing: In this phase, the Quality Assurance team examines the product's
performance and looks for the bug.

5. Deployment: In this phase, the team issues a product for the user's work
environment.

6. Feedback: After releasing the product, the last step is feedback. In this, the team
receives feedback about the product and works through the feedback.
 4.14 EXTREME PROGRAMMING (XP)
1. Extreme programming (XP) is a software development methodology, which is
intended to improve software quality and responsiveness to changing customer
requirements.
2. It advocates frequent "releases" in short development cycles, to improve
productivity and introduce checkpoints at which new customer requirements can be
adopted.
3. XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun
way to develop a software.
4. Extreme Programming (XP) is based on the four values:
a) Communication and feedback:
➢ Face-to-Face communication is preferred and is achieved with pair programming
and a customer representative is always onsite.
b) Simplicity:
➢ The simpler your system is, the less you have to communicate about the fewer
developers that you require.
➢ This leads to better communication.
c) Responsibility:
Developers are the ones who are ultimately responsible for the quality of thesoftware.
d) Courage:
Provides courage to the developers in the following way:
✓ To focus on only what is required.
✓ To communicate and accept feedback.
✓ To tell the truth about progress and estimates.
✓ To adapt to changes whenever they happen.
5. XP is organized into four framework activities:
a) Planning
b) Design
c) Coding
d) Testing
6. Programmers work in pair and develop tests for each task before writing the
code.
7. All tests must be successfully executed when new code is integrated in to the
system.
8. There is a short gap between releases of the system.
4.15 WHAT IS SCRUM?
1. Scrum is one of the agile development models.
2. In the Scrum model, A project is divided into small work parts that can
incrementally be developed and delivered over time boxes that are called sprints.
3. Scrum is an Agile process to focus on delivering the business value in the shortest
time.
4. Scrum collaboration is achieved in daily stand up meetings.
5. At the end of each sprint the team members meet to assess the developed
software increment.
6. The stakeholders may suggest any changes and improvements to completed
thedeveloped software that they might feel necessary.
7. Daily sprint meeting is conducted to review and feedback to decide future progress
of the project.
8. Key roles and responsibilities:
In the Scrum model, the team members assume three basic roles: product owner,
scrum master and team member.
a) Product owner:
➢ The product owner represents the customer's perspective and guides the team
towards building the right software.
➢ The product owner takes the responsibility of communicating the customer's
views to the development team.
b) Scrum master: The scrum master acts as the project manager for the project.
c) Team Member: A scrum team usually consists of cross-functional team members
with expertise in areas such as quality assurance, programming, user interface design
and testing.
 LEAN SOFTWARE DEVELOPMENT
➢ Lean Software Development (LSD) is an agile framework which is used to
streamline & optimize the software development process.
➢ It may also have referred as Minimum Viable Product (MVP) strategy as these
ways of thinking are very much alike since both intend to speed up development
by focusing in new deliverables.
➢ The main purpose of Lean is to achieve overall process efficiency through
eliminating various aspects that cause waste of work and introduce delays.
➢ Lean Software Development is one of the proactive approach that drives your
body through productivity and cleanliness.
➢ It closely connects to Agile methodology, knowledge-sharing experience, fast
product delivery.
➢ All processes and stages of development are accurately built to deliver the end
product at minimum cost in a timely manner.
Key Principles of Lean Software Development :
There are 7 established lean principles Software Development:-
1. Eliminating the waste
2. Fast Delivery
3. Amplify Learning
4. Builds Quality
5. Respect Teamwork
6. Delay the commitment.
7. Optimizing the whole system
Eliminating the Waste: To identify and eliminate wastes e.g. unnecessary code, delay in
processes, inefficient communication, issue with quality.
Fast Delivery: So they came up with (Minimum Viable Product) MVP strategy
which resulted them to build products quickly that included with a little
functionality.
Amplify Learning: Learning is improved through ample code reviewing, meeting that are cross
team applicable.
Builds Quality: The quality can also be gained to get constant feedback from teammembers and
project manager.
Respect Teamwork: Setting up a collaborative atmosphere, keep perfect balance when there is
short deadlines and immense workload.
Delay the Commitment: This methodology always constructs software as flexible, so the new
knowledge is available and engineers can make improvement. Optimizing the whole system:
lean’s principle allows managers to break an issue to small constituent parts to optimize team’s
workflow.
 MANAGING ITERATIVE PROCESSES
1. Brooch suggests that there are two levels of development: the macro process and
the micro process.
2. The macro process is closely related to the waterfall process model.
3. Dates have to know prior so that when we will need to bring in staff to work on
subsequent activities.
4. Within this macro process there will be micro process activities which might
involve iterative working. Example: Systems testing
5. Figure 2.7 illustrates how a sequential macro process can be imposed on a number
of iterative sub-processes.
SELECTING THE MOST APPROPRIATE PROCESS MODEL
1. Construction of an application can be distinguished from its installation.
2. It is possible to use different approaches for these two stages.
3. Whenever uncertainty is high, an evolutionary approach needs to be favored.
4. Where the requirements are relatively certain but there are many complexities, aswith a
large embedded system needing a large amount of code, then an incremental approach is
favored.
5. Where deadlines are tight, then either an evolutionary or an incremental approach is
favored.
6. Selection of an appropriate process model for a project can depend on several issues such
as the characteristics of the software to be developed.
7. For development of simple and well-understood applications, the waterfall modelshould be
sufficient.
8. An incremental delivery model is usually suitable for object-oriented
development projects.
9. The spiral model would be appropriate, if the project is large and it is not possibleto
anticipate the project risks at the start of the project.
10. The user interface part is usually developed using the prototyping model.
 UNIT-3

SOFTWARE EFFORT ESTIMATION

Understanding the size and effort of a software project early on is a difficult problem. Several
different methods exist, but no method is perfect. In this article we present an overview of the
four methods most mentioned in literature: 1) expert opinion-based, 2) top-down estimation, 3)
bottom-up estimation and 4) estimation using a parametric or algorithmic model.

Expert estimation
Expert estimation means that an expert estimates how much effort a project requires. The
advantages of asking somebody else than the project manager to estimate a project, is that some
experts have deep knowledge about the problem at hand. Many experts will use intuition and/or
previous experience to estimate the project, which is usually more time-efficient than any of the
other methods. The problem with expert estimates is that their reliability is typically unknown
(unless the organization tracks the performance of their estimators) and that their estimates are
not objective. This last aspect is important when discussions arise.

Note that there is big difference in asking an independent expert for an estimate, or asking the
person that has to perform the task for an estimate for that task. Asking the person that has to do
it probably yields more information, because the person has an incentive to estimate accurately.

Top down estimation

Top-down, analogy-driven estimation methods use experience from the past to make estimates
for the future. Analogy-driven estimation methods require examples of completed IT projects to
base the new estimates upon. Note that one can do top down estimations in multiple ways. The
easiest way is finding three previous projects, and takes the average of these projects. A better,
more advanced way is to use more information for selecting the most similar projects. One
should start with a database of completed projects. For each completed project, the effort that
was required to complete it is listed together with information about the aspects that had an
influence on the costs of that project. These aspects are also known as effort drivers. An estimate
for a new project is derived by comparing the new project to all old projects and selecting the
(effort of the) project that is most similar. The advantage of using analogy-driven estimation
methods is that their basis is more objective and repeatable than expert estimation.

Bottom-up estimation

Bottom-up estimation methods take a project definition and examine what activities or
deliverables need to be completed in order to achieve the project’s objective. One keeps breaking
up the project activities or deliverables into smaller sub activities or partial deliverables until
each sub activity of partial deliverable requires less than two weeks of effort. After this project
decomposition, in which the project is broken into smaller bits, each individual part (be it
activity or deliverable) is estimated. This estimate is then combined into an overall estimate. The
advantage of using bottom-up estimation methods is that their estimates are more open to
inspection (and more understandable) than an expert’s holistic estimate. Also, since estimation
errors tend to cancel each other out, the bottom-up estimate is typically more reliable than an
expert’s single estimate of an entire project. Unfortunately the method has as a disadvantage that
it generally is less objective than a parametric estimation method, since the decomposition
contains subjective assessments of what needs to be done for the project. Also it can take a lot of
work to produce a good bottom-up estimate.

Parametric estimation methods

Parametric estimation methods use a model or algorithm that takes as input some aspects of the
project (such as the required functionality and the quality that is expected). The model (a
formula) or algorithm (computational steps) then produce an estimate based on those inputs
alone. The advantage of using parametric estimation methods is that they tend to be more
objective as their counterparts. When properly used and with sufficient calibration these methods
can produce highly reliable estimates. Unfortunately their use is more complex and often more
time-consuming than the other estimation methods. Function Point Analysis is one of the most
commonly used methods. Cocomo is another. We discussed both methods in our course on
software project management, and many students found these methods difficult to apply. The
reason is that one needs to have fairly detailed requirements/specifications in order to apply these
methods. In our lectures we explained how to do Function Point Analysis per user story, using
this academic paper (PLANNING AGILE SOFTWARE PROJECTS WITH REDUCED GUESS
ESTIMATION, Buğra KOCATÜRK, Jean-Marc Desharnais). In our view, this is a very agile
wa
y to
do
FP
A.
Problems with over and underestimates

Parkinson's law was originally expounded in C. Northcote Parkinson's tongue-in-cheek book

Parkinson's Law, John Murray, 1957.

A project leader such as Amanda will need to be aware that the estimate itself, if known to the
development team, will influence the time required to implement the system. An over-estimate
might cause the project to take longer than it would otherwise. This can be explained by the
application of two 'laws'.

Parkinson's Law 'Work expands to fill the time available', which implies that given an easy target
staff will work less hard.

Brooks' Law The effort required to implement a project will go up disproportionately with the
number of staff assigned to the project. As the project team grows in size so will the effort that
has to go into management, co-ordination and communication. This has given rise, in extreme
cases, to the notion of Brooks'

Law: 'putting more people on a late job makes it later'. If there is an over-estimate of the effort
required then this might lead to more staff being allocated than are needed and managerial
overheads will be increased. This is more likely to be of significance with large projects.

Some have suggested that while the under-estimated project might not be completed on time or
to cost, it might still be implemented in a shorter time than a project with a more generous
estimate. There must, however, be limits to this phenomenon where all the slack in the project is
taken up.

The danger with the under-estimate is the effect on quality. Staff, particularly those with less
experience, might respond to pressing deadlines by producing work which is sub-standard. Since
we are into laws, this might be seen as a manifestation of Weinberg's zeroth law of reliability: 'if
a system does not have to

Brooks' law comes from The Mythical Man-month that has been referred to already.

See T. K. Hamid and S. E. Madnick 'Lessons learnt from modeling the dynamics of software
development' in C. F. Kemerer (ed.) Software Project Management, Irwin, 1997.

Barry Boehm devised the COCOMO estimating models, which are described later in this
chapter.

be reliable, it can meet any other objective'. In other words, if there is no need for the program
actually to work, you can meet any programming deadline that might be set! Sub-standard work
might only become visible at the later, testing, phases of a project, which are particularly difficult
to control and where extensive rework can have catastrophic consequences for the project
completion date.

Because of the possible effects on the behaviour of development staff caused by the size of
estimates, they might be artificially reduced by their managers to increase pressure on staff. This
will work only where staff are unaware that this has been done. Research has found that
motivation and morale are enhanced where targets are achievable. If, over a period of time, staff
become aware that the targets set are unattainable and that projects are routinely not meeting
their published targets, then this will help to destroy motivation. Furthermore, people like to
think of themselves as winners and there is a general tendency to put success down to our own
efforts, while failure is blamed on the organization.

In the end, an estimate is not really a prediction, it is a management goal. Barry Boehm has
suggested that if a software development cost is within 20% of the estimated cost estimate for the
job then a good manager can turn it into a self-fulfilling prophecy. A project leader like Amanda
will work hard to make the actual performance conform to the estimate.

Basis of software Estimation

“If you fail to plan, you’re planning to fail” – Benjamin Franklin might not have known
about software project estimation when he said that, but this saying couldn’t be more accurate.
Even before the planning stage, it’s wise to have a good forecast of the time and effort you will
put into application development, how much your project will cost, and what you can expect
from the development process.

Let’s familiarize ourselves with the software development project estimation concept, see why
it’s essential, and how to avoid a planning fallacy that could ruin the end result.
 1. What is software project estimation?
2. Why is software project estimation important?
3. What are the types of estimation?
4. Agile vs Traditional estimation
5. What are the four basic steps in software project estimation?
6. Why is software estimation so hard?

1. What is software project estimation?

Long story short, software development estimation is a crucial process that revolves around
predicting the project’s time and effort, cost, and scope; all this information is necessary for the
planning stage and to ensure the project’s success. Additionally, it also takes into consideration,
in terms of custom software development, the experience of the company you’re working with,
their tech stack, and their own process they need to follow to finish the project (also known as
the software development life cycle).

Even though an estimation is not the final software cost but just a ballpark range of the project –
it’s essential to be as accurate as possible. To be transparent and fair, an estimate should take into
consideration the following points but doesn’t have to be limited to them:

 Tasks – the details of what needs to be done

 Resources – what human resources are available
 Rate – cost to time ratio, the payment currency, and discounts
 Duration – how long will the project take to complete
 Third-party services – what additional services are necessary for completing the project

2. Why is software project estimation important?

The estimation accuracy is crucial because the client needs to feel confident that they can fund
the project before committing to it. Also, there are many side effects of poor project estimates,
like:

 Going over budget

 Cutting corners to avoid going over an unrealistic budget
 Running out of funds
 The developing team has low morale due to unrealistic expectations

… and those are just some examples. But you get the idea – the more accurate the software
project estimations, the better the chances of successfully finishing the project. So, as a
recommendation, the error margin should be anywhere in the range of 5 to 10 percent.

We’ve seen the effects of poor project estimates, but what about the benefits of estimation?

 They are usually a pre-requisite, so they must be done anyway

 They provide a common language and a bridge between the team and the organization the project
is for.
 Estimates provide alignment across the project team, providing transparency and validating or
questioning assumptions.
So what do you need to estimate a software project? Here is a list of inputs that you will need
to be able to create a meaningful result:

1. Scope of work

a. User requirements – this is needed to understand the system’s complexity.

b. Non-functional requirements – an app that must remain available at all times will be built
differently than an app that will only be used during office hours.
c. External factors – summarized as PESTLE (Political, Economic, Social, Technological,
Legal, Environmental).

2. Project risks

A risk is something that has the potential to happen and, if it materializes, will cause a
measurable impact on the project. Each risk can be prevented, reduced, accepted, or transferred.

3. Tech stack

a. Is there a requirement to write something of a legacy nature?

b. Are any items from the tech stack going to end of life during the project?
c. Is the tech stack aligned with the present competencies in the organization?

3. What are the types of estimation?

No matter the type of development estimation, there are a couple of questions that any software
project manager should ask that aim at the most critical six constraints before starting the
software project estimation process, such as:

 Scope of the project – How much work is to be estimated?

 Estimation technique – How to estimate the project?
 Schedule – How much time will it take to finish the project?
 Resources – Who will be working on the project?
 Cost – What is the required budget?
 Risks – What blocking points might appear?

Estimating software projects should have three major parts at the center: effort, cost, and
resource predictions. There is more than one estimation technique. However, during the early
stages of a project life cycle, when the product requirements are still fuzzy, and there isn’t much
data to base the project estimation on, an initial estimate is made, all known as a “ballpark
estimate.” Let’s see what types of estimation techniques you can use:

1. Parametric estimation

This type of estimation uses independent measurable variables from the actual project work. For
instance, the effort needed to build a work packet will be calculated using the variable
representing the lines of code in the project. The parametric model gives more accuracy to the
estimation since it uses more of a statistical or mathematical approach.

 Step 1 – establish the factors of development (business or functional requirements, non-

functional requirements, project complexity, tech stack, etc.)
 Step 2 – obtain information about the required work to complete one unit from similar projects
completed in the past.
 Step 3 – the cost is predicted by using an empirical relationship between the factors from step 1
and the total units from the project.

2. Topdown estimation

This method is more beneficial for initial estimations. The project’s scope is reviewed at a high
level and divided into features or estimated deliverables. However, this doesn’t include breaking
down the project scope into smaller pieces of work.

Mainly used for projects in the initial stages, where there isn’t much information available. Less
time-consuming than the bottom-up method, but it provides high-level estimations.

3. Bottomup estimation

This estimation model is useful when the requirements are known at a discrete level, where the
smaller work pieces are aggregated into the whole project. As the name implies, this is the
reverse method of topdown estimation.

The scope of the project needs to be described at a low level with all the details, and those
components of work are estimated. The work breakdown structure can be used to present the
detailed project scope.

The bottomup estimation is usually precise; however, it might not provide a buffer in case of
scope changes. Therefore, it is recommended to use this type of estimation technique for more
mature projects; it’s more time-consuming but provides a more precise estimation.

4. Threepoint estimating

This one uses a mathematical approach, the result being a weighted average or an optimistic,
most likely, and pessimistic estimation of the work package. This is also known as Program
Evaluation and Review Technique, or PERT.

Three ranges of estimates from three different data points are provided. Those three data points
are “best scenario,” “worst scenario,” and “most likely scenario.” The pessimistic estimation
considers negative risks that can happen, while the optimistic analysis includes positive risks.
The final result is the weighted average of the estimates.

There are two methods of calculating the final estimate:

 1. Beta distribution – includes weight in the estimation formula

Estimation = (p + 4m +o) / 6, where

P= pessimistic, O= optimistic, M= most likely

1. Triangular distribution

Estimation = (p + m + o) / 3, where

P= pessimistic, O- optimistic, M= most likely

This three-point estimate reduces the chance of having an inflated estimate. Additionally, it’s
one of the most straightforward yet accurate project estimating techniques.

5. Planning poker

Mostly used in agile software development, the planning poker estimation approach is used to
estimate project backlog. The name comes from the fact that the team uses cards while
estimating.

Team members estimate all items in the backlog using cards; after the product owner describes
the items, each team member thinks about the estimation and prepares the card. Simultaneously,
everyone shows their cards, and the session ends when the team reaches a consensus.

Agile estimations are also used to estimate story points, even for virtual teams. This estimation
technique’s apparent benefit is that all team members think about the estimation simultaneously.
This way, nobody is being influenced.

6. Expert judgment

As the name suggests, this method involves experts in the project estimation process since they
have experience with similar projects and can provide more accurate cost estimates.
Additionally, experts will be integrating risk into their calculations.

4. Agile vs Traditional estimation

“Responding to change over following a plan” is one of the critical principles of the agile
manifesto. This implies that agile estimation techniques will focus on what can be delivered
over a short-term period rather than a long-term one, with the waterfall model.

Agile software estimations are often lightweight, vs traditional ones that require pages and
pages of documentation before being submitted, therefore being less time-consuming.
It’s interesting to note that some development teams argue that estimations are unnecessary,
wasting time that would be better spent on delivery. Their approach is to split all deliverables
into similarly-sized subtasks and keep a constant delivery flow. #NoEstimates

5. What are the four basic steps in software project estimation?

Generally, there are four basic steps in software project estimation:

1. Estimating the project size

This will usually end up either in Lines of Code (LOC) or Function Points (FP). The sources of
information for this step should start with formal descriptions of the requirements. This step can
be completed either by analogy or by counting product features and using an algorithmic
approach to convert the count into an estimate of size.

2. Estimating the effort in person-months or person-hours

You can convert the software project size estimation to the total project effort only if you
have a defined software development life cycle and a development process that you must
follow. This effort estimation requires you to identify and predict all the necessary activities to
build the product. You can do this either by using historical data or with an algorithmic
approach, such as the COCOMO model or the Putnam Methodology.

3. Estimate the schedule in calendar months

This can be determined by using the effort estimate. It involves predicting the number of people
working on the project, what they will work on, when they will start working on it, and when
they will finish. Again, like before, historical data help lay this information out in a calendar
format.

4. Estimate the project cost

There are a lot of factors that can influence the cost estimate. For example, to determine the labor
cost, the easiest method is multiplying the project’s effort estimate in hours by a general labor
rate. However, you can get a more accurate estimate by using specific labor rates for each staff
position in your team.

6. Why is software estimation so hard?

Until recently (around 2011), most development teams used the Waterfall model to plan
projects. This implies that all the software requirements had to be defined upfront. However, the
shift has been made towards Agile development. This means that the product is shaped through
constant stakeholder conversations. What is finally delivered might not be precisely what was
discussed in the initial concept. While Agile proved to be valuable when it comes to
development, it has complicated things when it comes to estimations.
To make things easier, we’ve put together a guide that helps you with one stage of the software
project estimation process: how much app development costs. We’ve used our own experience
and comprehensive research and put together a guide with a working sheet that you can use.

Software Estimation Techniques

Estimation is the process of finding an estimate, or approximation, which is a value that can be
used for some purpose even if input data may be incomplete, uncertain, or unstable.

Estimation determines how much money, effort, resources, and time it will take to build a
specific system or product. Estimation is based on −

 Past Data/Past Experience

 Available Documents/Knowledge
 Assumptions
 Identified Risks

The four basic steps in Software Project Estimation are −

 Estimate the size of the development product.

 Estimate the effort in person-months or person-hours.
 Estimate the schedule in calendar months.
 Estimate the project cost in agreed currency.

Observations on Estimation

 Estimation need not be a one-time task in a project. It can take place during −
o Acquiring a Project.
o Planning the Project.
o Execution of the Project as the need arises.
 Project scope must be understood before the estimation process begins. It will be helpful
to have historical Project Data.
 Project metrics can provide a historical perspective and valuable input for generation of
quantitative estimates.
 Planning requires technical managers and the software team to make an initial
commitment as it leads to responsibility and accountability.
 Past experience can aid greatly.
 Use at least two estimation techniques to arrive at the estimates and reconcile the
resulting values. Refer Decomposition Techniques in the next section to learn about
reconciling estimates.
 Plans should be iterative and allow adjustments as time passes and more details are
known.

General Project Estimation Approach

The Project Estimation Approach that is widely used is Decomposition Technique.
Decomposition techniques take a divide and conquer approach. Size, Effort and Cost estimation
are performed in a stepwise manner by breaking down a Project into major Functions or related
Software Engineering Activities.

Step 1 − Understand the scope of the software to be built.

Step 2 − Generate an estimate of the software size.

 Start with the statement of scope.

 Decompose the software into functions that can each be estimated individually.
 Calculate the size of each function.
 Derive effort and cost estimates by applying the size values to your baseline productivity
metrics.
 Combine function estimates to produce an overall estimate for the entire project.

Step 3 − Generate an estimate of the effort and cost. You can arrive at the effort and cost
estimates by breaking down a project into related software engineering activities.

 Identify the sequence of activities that need to be performed for the project to be
completed.
 Divide activities into tasks that can be measured.
 Estimate the effort (in person hours/days) required to complete each task.
 Combine effort estimates of tasks of activity to produce an estimate for the activity.
 Obtain cost units (i.e., cost/unit effort) for each activity from the database.
 Compute the total effort and cost for each activity.
 Combine effort and cost estimates for each activity to produce an overall effort and cost
estimate for the entire project.

Step 4 − Reconcile estimates: Compare the resulting values from Step 3 to those obtained from
Step 2. If both sets of estimates agree, then your numbers are highly reliable. Otherwise, if
widely divergent estimates occur conduct further investigation concerning whether −

 The scope of the project is not adequately understood or has been misinterpreted.
 The function and/or activity breakdown is not accurate.
 Historical data used for the estimation techniques is inappropriate for the application, or
obsolete, or has been misapplied.

Step 5 − Determine the cause of divergence and then reconcile the estimates.

Estimation Accuracy

Accuracy is an indication of how close something is to reality. Whenever you generate an

estimate, everyone wants to know how close the numbers are to reality. You will want every
estimate to be as accurate as possible, given the data you have at the time you generate it. And of
course you don’t want to present an estimate in a way that inspires a false sense of confidence in
the numbers.

Important factors that affect the accuracy of estimates are −

 The accuracy of all the estimate’s input data.

 The accuracy of any estimate calculation.
 How closely the historical data or industry data used to calibrate the model matches the
project you are estimating.
 The predictability of your organization’s software development process.
 The stability of both the product requirements and the environment that supports the
software engineering effort.
 Whether or not the actual project was carefully planned, monitored and controlled, and
no major surprises occurred that caused unexpected delays.

Following are some guidelines for achieving reliable estimates −

 Base estimates on similar projects that have already been completed.

 Use relatively simple decomposition techniques to generate project cost and effort
estimates.
 Use one or more empirical estimation models for software cost and effort estimation.

Refer to the section on Estimation Guidelines in this chapter.

To ensure accuracy, you are always advised to estimate using at least two techniques and
compare the results.

Estimation Issues

Often, project managers resort to estimating schedules skipping to estimate size. This may be
because of the timelines set by the top management or the marketing team. However, whatever
the reason, if this is done, then at a later stage it would be difficult to estimate the schedules to
accommodate the scope changes.

While estimating, certain assumptions may be made. It is important to note all these assumptions
in the estimation sheet, as some still do not document assumptions in estimation sheets.

Even good estimates have inherent assumptions, risks, and uncertainty, and yet they are often
treated as though they are accurate.

The best way of expressing estimates is as a range of possible outcomes by saying, for example,
that the project will take 5 to 7 months instead of stating it will be complete on a particular date
or it will be complete in a fixed no. of months. Beware of committing to a range that is too
narrow as that is equivalent to committing to a definite date.
  You could also include uncertainty as an accompanying probability value. For example,
there is a 90% probability that the project will complete on or before a definite date.
 Organizations do not collect accurate project data. Since the accuracy of the estimates
depend on the historical data, it would be an issue.
 For any project, there is a shortest possible schedule that will allow you to include the
required functionality and produce quality output. If there is a schedule constraint by
management and/or client, you could negotiate on the scope and functionality to be
delivered.
 Agree with the client on handling scope creeps to avoid schedule overruns.
 Failure in accommodating contingency in the final estimate causes issues. For e.g.,
meetings, organizational events.
 Resource utilization should be considered as less than 80%. This is because the resources
would be productive only for 80% of their time. If you assign resources at more than 80%
utilization, there is bound to be slippages.

Estimation Guidelines
One should keep the following guidelines in mind while estimating a project −

 During estimation, ask other people's experiences. Also, put your own experiences at
task.
 Assume resources will be productive for only 80 percent of their time. Hence, during
estimation take the resource utilization as less than 80%.
 Resources working on multiple projects take longer to complete tasks because of the time
lost switching between them.
 Include management time in any estimate.
 Always build in contingency for problem solving, meetings and other unexpected events.
 Allow enough time to do a proper project estimate. Rushed estimates are inaccurate,
high-risk estimates. For large development projects, the estimation step should really be
regarded as a mini project.
 Where possible, use documented data from your organization’s similar past projects. It
will result in the most accurate estimate. If your organization has not kept historical data,
now is a good time to start collecting it.
 Use developer-based estimates, as the estimates prepared by people other than those who
will do the work will be less accurate.
 Use several different people to estimate and use several different estimation techniques.
 Reconcile the estimates. Observe the convergence or spread among the estimates.
Convergence means that you have got a good estimate. Wideband-Delphi technique can
be used to gather and discuss estimates using a group of people, the intention being to
produce an accurate, unbiased estimate.
 Re-estimate the project several times throughout its life cycle.

Summary

Expert judgment is when you call in an expert with a specific area of expertise to get a skilled
opinion. These experts can be external consultants or internal team members, so long as they
have the required knowledge base. Learn how and when to use expert judgment in project
management.

When working on any project, you run into topics, challenges, or questions you simply don’t
know how to resolve. That’s when you need an expert. Project managers use expert judgment to
solve complex problems during high-impact projects. These experts are uniquely qualified to
make decisions based on their years of experience. Learn how expert judgment works and when
to use it in your work.

What is expert judgment in project management?

Expert judgment is when you call in an expert to get a skilled opinion. It’s an estimation
methodology for project planning that relies on the expert’s opinion to estimate quantitative
project details, such as timelines and potential resources.

According to the Project Management Institute (PMI), expert judgement is one of the most
common project management planning tools. Expert judgment as a potential tool in every single
one of their six processes. Specialized knowledge is expensive, so hiring a skilled full-time
employee to give expert judgement is not always cost-effective. Instead, many companies hire
external experts to complete assessments, using them to monitor and control project work in
specific areas.

When and how to use expert judgment

One of the reasons expert judgement is so common is because it can be applied to a variety of
situations. It’s a useful way to get external insight into your work, but it’s subjective and needs
guidelines. Often, you’ll use expert judgment to assist with resource management. For example,
an expert can help you determine how many resources you need to launch a new product,
feature, or even a new company if you’re in the startup stages.

You can also use expert judgment:

 When the stakes are high. If you have a high-impact project coming up, it helps to get
validation from experts before you move forward.
 Before project planning. If you’re developing a project charter before you create a
project plan, you might want to bring in an expert to review it and confirm that your
project is viable.
 For cost management. When you’re determining cost estimates for product pricing or
even hiring, having an expert on hand will help you get as close as possible to a realistic
number.
 During decision-making. You can use expert judgment in a decision-making
framework, such as RACI, or during routine decisions. If you use RAPID, having an
expert as the decision-maker role helps you get full use of expert opinions.
  With forecasting. Experts can help you weigh factors such as the current macro
environment or market fit during forecasting, to help you get an accurate estimate on
potential sales.
 For risk management. An expert can review and analyze your risk assessment, risk
analysis, and risk responses to determine how high-risk different scenarios are, so you
can be prepared for any likely outcome.

Types of expert judgment:

Delphi technique: Running through the expert judgment process once will leave you with one
expert’s opinion, but these can be biased. The Delphi technique continues the expert judgment
process repeatedly in an effort to remove those cognitive biases.

Expert elicitation: When a group of experts in a specific knowledge area form one, cohesive
opinion. Usually used when there’s less data or resources available.

Who are the experts?

Your experts will vary depending on your needs—they could be anyone, from a team member to
a consultant you fly in for a unique situation. Your experts can be:

 Internal project team members. Your team is likely already made up of experts. This is
the easiest place (and often the first place) to look for experts.
 Subject matter experts. These are experts with a deep knowledge base of a specific
subject. For example, if you manage a manufacturing company, you’d likely bring in a
procurement expert when you’re looking for new potential suppliers. Subject matter
experts can be external consultants or in-house experts. The benefits of using someone
outside of your organization is that they come without biases and can be more objective.
 Project managers. Project managers often have a deep understanding of their subject
matter. When using project managers as your experts, watch for biases that come from
working in the same field as you.
 Project stakeholders. Stakeholders can come from different backgrounds and perform a
variety of different roles. As a result, many of them are experts. Don’t be afraid to lean on
them for their valuable judgment.

The 7 steps to get expert judgment

It's not enough to just talk to an expert—you need to clarify what you want and expect from
them in order for the relationship to be successful. By clearly defining the inputs, outputs, and
expectations of the project, you and your expert can benefit from a structured expert judgment
process that satisfies everyone.
1. Research the problem

Before you can engage your expert, you must have a thorough understanding of your problem.
Make sure you know exactly what’s already been completed, where the issue stands, and what
you need from your expert.

2. Write out your questions

Be as specific as possible here. The more targeted your questions, the better your expert’s
answers will be. Using your research from the previous step, develop clear questions. The
questions you ask can be complex, but should be clear enough for the expert to understand and
answer.

3. Select your experts

Choose the experts that best fit the needs of this specific problem or project. For example, if
you’re working on product distributions, you’ll want to involve experts who understand your
industry’s supply chain and the target market. Then explain the problem to them, sharing all
resources and project documents so they have the knowledge they need to pass effective
judgment.

4. Submit your questions

Send your questions off to your selected experts. If you’re using project management software,
you can attach relevant analyses and documents directly to the questions. Then when your
experts respond, you can see their answers in real-time.

5. Review and analyze their judgements

Once you have answers from your experts, it’s up to you to review them and determine how
you’re going to use the information. To further mitigate bias, you might want to use a peer
review process made up of multiple experts to ensure you’re getting the most accurate data.

6. Aggregate judgements in a report

Create a report of all the judgements you receive. Save it as one central source of truth, so you
can easily share the results with stakeholders.

7. Communicate results

Once you have your results neat and tidy, send them out to all stakeholders for review. At this
stage, you’ll also start to discuss if you need another round of expert judgment. Mostly, you
repeat the process if stakeholders spot errors or have additional questions.

Expert judgment cuts back on guesswork

When you’re estimating key project, product, or company initiatives, you’re never going to be
100 percent sure—but using experts can help you get as close as possible to the results you
need.

Estimating by Analogy
Analogous Estimation uses a similar past project information to estimate the duration or cost of
your current project, hence the word, "analogy". You can use analogous estimation when there is
limited information regarding your current project.

Quite often, there will be situations when project managers will be asked to give cost and
duration estimates for a new project as the executives need decision-making data to decide
whether the project is worth doing. Usually, neither the project manager nor anyone else in the
organization has ever done a project like the new one but the executives still want accurate cost
and duration estimates.

In such cases, analogous estimation is the best solution. It may not be perfect but is accurate as it
is based on past data. Analogous estimation is an easy-to-implement technique. The project
success rate can be up to 60% as compared to the initial estimates.

Analogous Estimation – Definition

Analogous estimation is a technique which uses the values of parameters from historical data as
the basis for estimating similar parameter for a future activity. Parameters examples: Scope, cost,
and duration. Measures of scale examples − Size, weight, and complexity.

Because the project manager’s, and possibly the team’s experience and judgment are applied to
the estimating process, it is considered a combination of historical information and expert
judgment.

Analogous Estimation Requirements

For analogous estimation following is the requirement −

 Data from previous and on-going projects

o Work hours per week of each team member
o Costs involved to get the project completed
 Project close to the current project
 In case the current Project is new, and no past project is similar
o Modules from past projects that are similar to those in current project
o Activities from past projects that are similar to those in current project
o Data from these selected ones
 Participation of the project manager and estimation team to ensure experienced judgment
on the estimates.
Analogous Estimation Steps
The project manager and team have to collectively do analogous estimation.

 Step 1 − Identify the domain of the current project.

 Step 2 − Identify the technology of the current project.
 Step 3 − Look in the organization database if a similar project data is available. If
available, go to Step (4). Otherwise go to Step (6).
 Step 4 − Compare the current project with the identified past project data.
 Step 5 − Arrive at the duration and cost estimates of the current project. This ends
analogous estimation of the project.
 Step 6 − Look in the organization database if any past projects have similar modules as
those in the current project.
 Step 7 − Look in the organization database if any past projects have similar activities as
those in the current project.
 Step 8 − Collect all those and use expert judgment to arrive at the duration and cost
estimates of the current project.

Advantages of Analogous Estimation

 Analogous estimation is a better way of estimation in the initial stages of the project
when very few details are known.
 The technique is simple and time taken for estimation is very less.
 Organization’s success rate can be expected to be high since the technique is based on the
organization’s past project data.
 Analogous estimation can be used to estimate the effort and duration of individual tasks
too. Hence, in WBS when you estimate the tasks, you can use Analogy.

The objectives of activity planning

We looked at methods for forecasting the effort required for a project - both for the project as a
whole and for individual activities. A detailed plan for the project, however, must also include a
schedule indicating the start and completion times for each activity. This will enable us to:

 ensure that the appropriate resources will be available precisely when required;
 avoid different activities competing for the same resources at the same time;
 produce a detailed schedule showing which staff carry out each activity;
 produce a detailed plan against which actual achievement may be measured;
 produce a timed cash flow forecast;
 replan the project during its life to correct drift from the target.

To be effective, a plan must be stated as a set of targets, the achievement or non- Project
monitoring is achievement of which can be unambiguously measured. The activity plan does
discussed in more detail in this by providing a target start and completion date for each activity.
within which each activity may be carried out). The starts and completions of activities must be
clearly visible and this is one of the reasons why it is advisable to ensure that each and every
project activity produces some tangible product or 'deliverable'. Monitoring the project's progress
is then, at least in part, a case of ensuring that the products of each activity are delivered on time.

As a project progresses it is unlikely that everything will go according to plan. Much of the job
of project management concerns recognizing when something has gone wrong, identifying its
causes and revising the plan to mitigate its effects. The activity plan should provide a means of
evaluating the consequences of not meeting any of the activity target dates and guidance as to
how the plan might most effectively be modified to bring the project back to target. We shall see
that the activity plan may well also offer guidance as to which components of a project should be
most closely monitored.

This co-ordination will normally form part of Programme Management.

In addition to providing project and resource schedules, activity planning aims to achieve a
number of other objectives which may be summarized as follows.

 Feasibility assessment Is the project possible within required timescales and resource constraints?
It is not until we have constructed a detailed plan that we can forecast a completion date with any
reasonable knowledge of its achievability. The fact that a project may have been estimated as
requiring two work-years effort might not mean that it would be feasible to complete it within,
say, three months were eight people to work on it - that will depend upon the availability of staff
and the degree to which activities may be undertaken in parallel.
 Resource allocation What are the most effective ways of allocating resources to the project and
when should they be available? The project plan allows us to investigate the relationship between
timescales and resource availability (in general, allocating additional resources to a project
shortens its duration) and the efficacy of additional spending on resource procurement.
 Detailed costing How much will the project cost and when is that expenditure likely to take
place? After producing an activity plan and allocating specific resources, we can obtain more
detailed estimates of costs and their timing.
 Motivation Providing targets and being seen to monitor achievement against targets is an
effective way of motivating staff, particularly where they have been involved in setting those
targets in the first place.
 Co-ordination When do the staff in different departments need to be available to work on a
particular project and when do staff need to be transferred between projects? The project plan,
particularly with large projects involving more than a single project team, provides an effective
vehicle for communication and co-ordination among teams. In situations where staff may need to
be transferred between project teams (or work concurrently on more than one project), a set of
integrated project schedules should ensure that such staff are available when required and do not
suffer periods of enforced idleness.

Activity planning and scheduling techniques place an emphasis on completing the project in a
minimum time at an acceptable cost or, alternatively, meeting an arbitrarily set target date at
minimum cost. These are not, in themselves, concerned with meeting quality targets, which
generally impose constraints on the scheduling process.

One effective way of shortening project durations is to carry out activities in parallel. Clearly we
cannot undertake all the activities at the same time - some require the completion of others
before they can start and there are likely to be resource constraints limiting how much may be
done simultaneously. Activity scheduling will, however, give us an indication of the cost of these
constraints in terms of lengthening timescales and provide us with an indication of how
timescales may be shortened by relaxing those constraints. It is up to us, if we try relaxing
precedence constraints by, for example, allowing a program coding task to commence before the
design has been completed, to ensure that we are clear about the potential effects on product
quality.

When to plan

Planning is an ongoing process of refinement, each iteration becoming more detailed and more
accurate than the last. Over successive iterations, the emphasis and purpose of planning will
shift.

During the feasibility study and project start-up, the main purpose of planning will be to estimate
timescales and the risks of not achieving target completion dates or keeping within budget. As
the project proceeds beyond the feasibility study, the emphasis will be placed upon the
production of activity plans for ensuring resource availability and cash flow control.

Throughout the project, until the final deliverable has reached the customer, monitoring and
replanning must continue to correct any drift that might prevent meeting time or cost targets.

Project schedules
Before work commences on a project or, possibly, a stage of a larger project, the project plan
must be developed to the level of showing dates when each activity should start and finish and
when and how much of each resource will be required. Once the plan has been refined to this
level of detail we call it a project schedule. Creating a project schedule comprises four main
stages.

The first step in producing the plan is to decide what activities need to be carried out and in what
order they are to be done. From this we can construct an ideal activity plan - that is, a plan of
when each activity would ideally be undertaken were resources not a constraint. It is the creation
of the ideal activity plan that we shall discuss in this chapter. This activity plan is generated by
Steps 4 and 5 of Step Wise.

On a large project, detailed plans for the later stages will be delayed until information about the
work required has emerged from the earlier stages.

Activity planning is carried out in Steps 4 and 5

The ideal activity plan will then be the subject of an activity risk analysis, aimed at identifying
potential problems. This might suggest alterations to the ideal activity plan and will almost
certainly have implications for resource allocation.

The third step is resource allocation. The expected availability of resources might place
constraints on when certain activities can be carried out, and our ideal plan might need to be
adapted to take account of this.

The final step is schedule production. Once resources have been allocated to each activity, we
will be in a position to draw up and publish a project schedule, which indicates planned start and
completion dates and a resource requirements statement for each activity.

Projects and activities

Defining activities

Before we try to identify the activities that make up a project it is worth reviewing what we mean
by a project and its activities and adding some assumptions that will be relevant when we start to
produce an activity plan.

• a project is composed of a number of inter-related activities;

• a project may start when at least one of its activities is ready to start;

• a project will be completed when all of the activities it encompasses have been completed;

• an activity must have a clearly defined start and a clearly defined end-point, normally marked
by the production of a tangible deliverable;

• if an activity requires a resource (as most do) then that resource requirement must be
forecastable and is assumed to be required at a constant level throughout the duration of the
activity;
• the duration of an activity must be forecastable - assuming normal circumstances, and the
reasonable availability of resources;

• some activities might require that others are completed before they can begin (these are known
as precedence requirements).

Identifying activities

Essentially there are three approaches to identifying the activities or tasks that make up a project
- we shall call them the activity-based approach, the product-based approach and the hybrid
approach.

The activity-based approach The activity-based approach consists of creating a list of all the
activities that the project is thought to involve. This might involve a brainstorming session
involving the whole project team or it might stem from an analysis of similar past projects. When
listing activities, particularly for a large project, it might be helpful to subdivide the project into
the main life style stages and consider each of these separately.

Rather than doing this in an ad hoc manner, with the obvious risks of omitting or double-
counting tasks, a much favoured way of generating a task list is to create a Work Breakdown
Structure (WBS). This involves identifying the main (or high-level) tasks required to complete a
project and then breaking each of these down into a set of lower-level tasks. Figure 6.2 shows a
fragment of a WBS where the design task has been broken down into three tasks and one of these
has been further decomposed into two tasks.

Activities are added to a branch in the structure if they directly contribute to the task immediately
above - if they do not contribute to the parent task, then they should not be added to that branch.
The tasks at each level in any branch should

Activities must be defined so that they meet these criteria. Any activity that does not meet these
criteria must be redefined.

WBSs are advocated by BS 6079, which is discussed in Appendix B.

Figure 6.2 A fragment of an activity-based Work Breakdown Structure.

A complete task catalogue will normally include task definitions along with task input and output
products and other task-related information.

include everything that is required to complete the task at the higher level - if they are not a
comprehensive definition of the parent task, then something is missing.

When preparing a WBS, consideration must be given to the final level of detail or depth of the
structure. Too great a depth will result in a large number of small tasks that will be difficult to
manage, whereas a too shallow structure will provide insufficient detail for project control. Each
branch should, however, be broken down at least to a level where each leaf may be assigned to
an individual or responsible section within the organization.

Advantages claimed for the WBS approach include the belief that it is much more likely to result
in a task catalogue that is complete and is composed of non-overlapping activities. Note that it is
only the leaves of the structure that comprise the list of activities comprising the project - higher-
level nodes merely represent collections of activities.

The WBS also represents a structure that may be refined as the project proceeds. In the early part
of a project we might use a relatively high-level or shallow WBS, which can be developed as
information becomes available, typically during the project's analysis and specification phases.

Once the project's activities have been identified (whether or not by using a WBS) they need to
be sequenced in the sense of deciding which activities need to be completed before others can
start.

The product-based approach, used in PRINCE 2. It consists of producing a Product Breakdown

Structure and a Product Flow Diagram. The PFD indicates, for each product, which other
products are required as inputs. The PFD can therefore be easily transformed into an ordered list
of activities by identifying the transformations that turn some products into others. Proponents of
this approach claim that it is less likely that a product will be left out of a PBS than that an
activity might be omitted from an unstructured activity list.

This approach is particularly appropriate if using a methodology such as SSADM, which clearly
specifies, for each step or task, each of the products required and the activities required to
produce it. The SSADM Reference Manual provides a set of generic PBSs for each stage in
SSADM (such as that shown in Figure 6.3), which can be used as a basis for generating a
project-specific PBS.

Most good texts on SSADM will explain the tailoring of the generic PBSs and Activity
Networks. The illustrations here are taken from M. Goodland and C. Slater, SSADM Version 4:
A Practical Approach, McGraw-Hill, 1995.

The SSADM Reference Manual also supplies generic activity networks and, using the project-
specific PBS and derived PFD, these may be used as a basis for developing a project-specific
activity network. Figure 6.4 illustrates an activity network for the activities required to create the
products in Figure 6.3.
Notice how the development of a PFD leads directly to an activity network that indicates the
sequencing of activities - in Figure 6.4, activity 340 (Enhance required data model) requires
products from activity 330 and activity 360 needs products from both activities 330 and 340.

The hybrid approach The WBS is based entirely on a structuring of activities. Alternatively, and
perhaps more commonly, a WBS may be based upon the project's products, which is in turn
based on a simple list of final deliverables and, for each deliverable, a set of activities required to
produce that product. A flat WBS and it is likely that, in a project of any size, it would be
beneficial to introduce additional levels - structuring both products and activities. The degree to
which the structuring is product-based or activity-based might be influenced by the nature of the
project and the particular development method adopted. As with a purely activity-based WBS,
having identified the activities we are then left with the task of sequencing them.

The activity numbers in Figure 6.4 are the step numbers used by SSADM version 4.

BS 6079 states that WBSs may be product-based, cost-centre-based, task-based or function-

based but states that product-based WBSs are preferred.

Not all of the products in this activity structuring will be final products. Some will be further
refined in subsequent steps.

The current version of the SSADM reference manual provides generic PBSs and generic activity
networks, but not generic PFDs. Stress is placed on the fact that these are generic structures and
it is important that project-specific versions are created. A project-specific PFD would be
produced as part of this process.

Data Catalogue Logical Data Flow Model Logical Data Store/Entity Xref User Catalogue
Requirements Catalogue Selected Business System Option

Current Environment LDM Requirements Catalogue Selected Business System Catalogue

Data Catalogue

Define Required System Processing

Required System DFM

Required System DFM

Develop Required Data Model

 Required System LDM Data Catalogue

 EffiSXT teoeumeentS Guide ' Catal°9ue
 Develop, Specification, Prototypes, User Role/Function Matrix I/O Structures, Derive
System Functions, I/O Structures, Enhance Required Data Model, Menu & Command
Structures Prototyping Report
 Requirements Catalogue, Function Definitions Requirements Catalogue User
Role/Function Matrix I/O Structures
 Requirements Catalogue Required System LDM Function Definitions
 Confirm System Objectives
 Function Definitions Required System LDM Requirements Catalogue
 I/O Structures Function Definitions Requirements Catalogue
 Data Catalogue Required System LDM
 Develop Processing Specification
 Data Catalogue
 Effect Correspondence Diagram Enquiry Access Paths Entity Life Histories
 Assemble
 Requirements Specification
 Specification stage (from Goodland and Slater).

A framework dictating the number of levels and the nature of each level in the structure may be
imposed on a WBS. For example, in their MITP methodology, IBM recommend that the
following five levels should be used in a WBS:

• Level 2: Deliverables such as software, manuals and training courses.

Installed system
Software components

Project

User manuals
Training course

Figure 6.5 A Work Breakdown Structure based on deliverables.

• Level 3: Components which are the key work items needed to produce deliverables, such as the
modules and tests required to produce the system software.

• Level 4: Work-packages which are major work items, or collections of related tasks, required to
produce a component.

• Level 5: Tasks which are tasks that will normally be the responsibility of a single person.
Sequencing and scheduling activities

Throughout a project, we will require a schedule that clearly indicates when each of the project's
activities is planned to occur and what resources it will need.

The chart shown has been drawn up taking account of the nature of the development process
(that is, certain tasks must be completed before others may start) and the resources that are
available (for example, activity C follows activity B because Andy cannot work on both tasks at
the same time). In drawing up the chart, we have therefore done two things - we have sequenced
the tasks (that is, identified the dependencies among activities dictated by the development
process) and scheduled them (that is, specified when they should take place). The

Separating the logical sequencing from the scheduling may be likened to the principle used in
SSADM of separating the logical system from its physical implementation.

The bar chart does not show why certain decisions have been made. It is not clear, for example,
why activity H is not scheduled to start until week 9. It could be that it cannot start until activity
F has been completed or it might be because Charlie is going to be on holiday during week 8.

Task: Person

Activity key: A: Overall design

B: Specify module 1 C: Specify module 2 D: Specify module 3 E: Code module 1

Figure 6.6 A project plan as a bar chart.

F: Code module 3 G: Code module 2 H: Integration testing I: System testing scheduling has had
to take account of the availability of staff and the ways in which the activities have been
allocated to them. The schedule might look quite different were there a different number of staff
or were we to allocate the activities differently.

In the case of small projects, this combined sequencing-scheduling approach might be quite
suitable, particularly where we wish to allocate individuals to particular tasks at an early
planning stage. However, on larger projects it is better to separate out these two activities: to
sequence the task according to their logical relationships and then to schedule them taking into
account resources and other factors.

Sequencing and Scheduling

Sequencing is the order of tasks to be done in chain. Hence the next task is started once the
previous one is completed.

Scheduling, on the other hand is the process in which people are assigned to time to accomplish
different tasks.

It improves the delivery performance and reduces the manufacturing time and cost.

Scheduling

• Scheduling: The allocation of resources over time to accomplish specific tasks.

• Demand scheduling: A type of scheduling whereby customers are assigned to a definite time
for order fulfillment.
• Workforce scheduling: A type of scheduling that determines when employees work.
• Operations scheduling: A type of scheduling in which jobs are assigned to workstations or
employees are assigned to jobs for specified time periods.

Operations scheduling is critical to the success of an organization; however, it can be a very

complicated task. Effective schedules are needed to meet promised customer delivery dates or
inventory targets.
It covers the following areas in particular:

 assign job to a particular work center/ machine

 time of assignment of job and completion
 allocation of resources like manpower and materials
 time sequence of operations
 feedback and control function to take care of deviations

Objectives of Operations Scheduling

• Making efficient use of the labour.

• Making best possible use of the equipments that are available for the use.
• Increasing the profit.
• Increasing the output.
• Improving the service level.

Objectives of Operations Scheduling

• Maximizing the delivery performance i.e. meeting the delivery dates.
• Minimizing the inventory.
• Reducing the manufacturing time.
• Minimizing the production costs.
• Minimizing the worker costs.

Functions of Operations Scheduling

• Allocation of the resources.

• Shop floor control.
• Making maximum use of the plant at minimum possible cost.
• Ensure that the needs of the manpower are optimum.
• Determination of the sequence of the jobs.

Functions of Operations Scheduling

• Specifying the start and the end time for each job (actively scheduled).
• Getting quick feedback from the shops regarding the delays and the various interruptions.
• Possess up – to – date information for the availability of the materials, expected delivery dates
etc.
• Possess up – to – date data on the machine regarding its breakdown, servicing etc.

Types of Scheduling

Types of Operations Scheduling are as follows:

1. Forward operations scheduling –

• Classified on the basis of the time.
• All the activities are scheduled from the date of the planned order release.
• First task of the job is scheduled.
• Its subsequent task is scheduled on the scheduled completion of the first task.
• Like this, accordingly all the tasks of the job are scheduled.
2. Backward operations scheduling –
• Also classified on the basis of the time.
• Activities are scheduled from the date or the planned receipt date.
• The last activity is scheduled first.
• Time of the start of the last task is considered as the time for the start of the previous activity.

Sequencing
• Prioritize jobs assigned to a resource
• If no order specified use first-come first-served (FCFS)
• Other Sequencing Rules
• FCFS – first-come, first-served
• LCFS – last come, first served • DDATE – earliest due date
• CUSTPR – highest customer priority • SETUP – similar required setups
• SLACK – smallest slack • CR – smallest critical ratio
• SPT – shortest processing time • LPT – longest processing time

Sequencing Jobs

• Operations schedules are short-term plans designed to implement the sales and operations plan
• An operation with divergent flows is often called a job shop
– Low-to medium-volume production
– Utilizes job or batch processes
– The front office would be the equivalent for a service provider
– Difficult to schedule because of the variability in job routings and the continual introduction of
new jobs to be processed
• An operation with line flow is often called a flow shop
– Medium- to high-volume production
– Utilizes line or continuous flow processes
– The back office would be the equivalent for a service provider
– Tasks are easier to schedule because the jobs have a common flow pattern through the system

Priority Sequencing Rules

• First-come, first-served (FCFS)

• Earliest due date (EDD)
• Critical ratio (CR)
CR = [(Due date) – (Today’s date)]/Total shop time remaining
 A ratio of less than 1.0 implies that the job is behind schedule
 A ratio greater than 1.0 implies the job is ahead of schedule
 The job with the lowest CR is scheduled next

• Shortest processing time (SPT)

• Slack per remaining operations (S/RO)

 The job with the lowest S/RO is scheduled next

S/RO = [(Due date –Today’s date)–Total shop time remaining] / Number of operations
remaining
Johnson’s Rule

Johnson’s Rules a technique that

can be used to minimize the completion time for a group of jobs
that are to be processed on two machines or at two successive work centers.

Objectives of Johnson’s Rule

The Objectives of Johnson’s Rule are:

To minimize the processing time for sequencing a group of jobs through two work centers.

To minimize the total idle times on the machines.

To minimize the flow time from the beginning of the first job until the finish of the last job.

Conditions for Johnson’s Rule

In order for the technique to be used, several conditions must be satisfied:
Job time(including setup and processing) must be known and constant for each job at each work center.

Job times must be independent of the job sequence.

All jobs must follow the same two-setup work sequence.

Job priorities cannot be used.

Steps Involved In Johnson’s Rule

Minimizes makespan when scheduling a group of jobs on two workstations

Step 1: Scan the processing time at each workstation and find the shortest processing time among the jobs
not yet scheduled. If two or more jobs are tied, choose one job arbitrarily.
Step 2: If the shortest processing time is on workstation 1, schedule the corresponding job as early as
possible. If the shortest processing time is on workstation 2, schedule the corresponding job as late as
possible.
Step 3: Eliminate the last job scheduled for further consideration. Repeat steps 1 and 2 until all jobs have
been scheduled

Network Planning Models:

 Scheduling techniques model the project’s activities and their relationships as a

“Network”.In network time flows from left to right.
 There are two best techniques:
o CRM(Critical Path Method)
o PERT(Program Evaluation Review Technique)
 Both use the “Activity on Arrow” approach to visualize the project as a network where
activities are drawn as arrows joining circles,or nodes which represent the possible start
or completion of an activity or set of activities.
  Sequencing the tasks according to their logical relationship,and then scheduling them
taking into account resources and other factors.

 Both of these techniques used an activity-on-arrow approach to visualizing the

project as a network where activities are drawn as arrows joining circles, or nodes,which
represent the possible start and/or completion activities.

More recently a variation on these techniques, called precedence networks,has become

popular.This method uses activity-on-node networks where activities are Represented as
nodes and the links between nodes represent precedence or

sequencing requirements.It is this method that is adopted in the

majority of computer applications currently available.

Formulating Network Model

The first stage in creating a network model is to represent the activities and their

interrelationships as a graph. In activity-on-nodes we do this by representing activities as links

(arrowed lines) in the graph - the nodes (circles) representing the events of activities starting and
finishing.

 Constructing precedence networks

Before we look at how networks are used, it is worth spending a few moments

considering some rules for their construction.

 A project network should have only one start node

Although it is logically possible to draw a network with more than one starting node it is
undesirable to do so as it is a potential source of confusion. In such cases. (for example, where
more than one activity can start immediately the project starts) it is normal to invent a start
activity which has zero duration but may have, for example, an actual start date.
  A project network should have only one end node

The end node designates the completion of the project and a project may only finish once.
Although it is possible to draw a network with more than one end node it will almost certainly
lead to confusion if this is done. Where the completion of a project depends upon more than one
'final' activity it is normal to invent a 'finish' activity.

 A node has duration

A node represents an activity and, in general, activities take time to execute.This network
drawing merely represents the logic of the project and the rules governing the order in which
activities are to be carried out.

 Links normally have no duration

Links represent the relationships between activities.Program testing cannot start until both
coding and data take-on have been completed.

 Precedents are the immediate preceding activities

The activity Program test cannot start until both Code and Data take-on have been completed and
activity Install cannot start until the Program test has finished. Code and Data take-on can
therefore be said to be precedents of Program test, and Program test is a precedent of Install.
Note that we do not speak of Code and Data take-on as precedents of Instal - that relationship is
implicit in the previous statement.
 Fragment of a Precedence Network

 Time moves from left to right

If at all possible, networks are drawn so that time moves from left to right. It is rare that this
convention needs to be flouted, but some people add arrows to the lines to give a stronger visual
indication of the time flow of the project.

A loop represents an impossible sequence

 A network may not contain loops

It demonstrates a loop in a network.A loop is an error in that it represents a situation that cannot
occur in practice.While loops, in the sense of iteration, may occur in practice, they cannot be
directly represented in a project network.
 SPM

UNIT 4

Risk Management
A risk is a probable problem- it might happen or it might not. There are main two characteristics
of risk

Uncertainty- the risk may or may not happen that means there are no 100% risks.
loss – If the risk occurs in reality , undesirable result or losses will occur.

Risk management is a sequence of steps that help a software team to understand , analyze and
manage uncertainty. Risk management consists of

 Risk Identification
 Risk analysis
 Risk Planning
 Risk Monitoring

A computer code project may be laid low with an outsized sort of risk. so as to be
ready to consistently establish the necessary risks which could have an effect on a
computer code project, it’s necessary to reason risks into completely different categories.
The project manager will then examine the risks from every category square measure
relevant to the project.

There are mainly 3 classes of risks that may have an effect on a computer code project:

1. Project Risks:
Project risks concern various sorts of monetary funds, schedules, personnel, resource, and
customer-related issues. a vital project risk is schedule slippage. Since computer code is
intangible, it’s terribly tough to observe and manage a computer code project. it’s terribly
tough to manage one thing that can not be seen. For any producing project, like
producing cars, the project manager will see the merchandise taking form.

For example, see that the engine is fitted, at the moment the area of the door unit fitted,
the automotive is obtaining painted, etc. so he will simply assess the progress of the work
and manage it. The physical property of the merchandise being developed is a vital
reason why several computer codes come to suffer from the danger of schedule
slippage.

2. Technical Risks:
Technical risks concern potential style, implementation, interfacing, testing, and
maintenance issues. Technical risks conjointly embody ambiguous specifications,
 incomplete specification, dynamic specification, technical uncertainty, and technical
degeneration. Most technical risks occur thanks to the event team’s lean information
concerning the project.

3. Business Risks:
This type of risk embodies the risks of building a superb product that nobody needs,
losing monetary funds or personal commitments, etc.

Classification of Risk in a project:

Example: Let us consider a satellite based mobile communication project. The project manager
can identify several risks in this project. Let us classify them appropriately.

 What if the project cost escalates and overshoots what was estimated? – Project Risk
 What if the mobile phones that are developed become too bulky in size to conveniently
carry? Business Risk
 What if call hand-off between satellites becomes too difficult to implement? Technical
Risk

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

Problem Priority
No of problem problem exposure
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

The nature of risk

For the purpose of identifying and managing those risks that may cause a project to overrun its
time-scale or budget, it is convenient to identify three types of risk:
Figure 7.1 Risk analysis is carried out in Steps 3 and 6.

Improved quality control should make it easier to predict the time required for program and
system testing.

• those caused by the inherent difficulties of estimation;

• those due to assumptions made during the planning process;

• those of unforeseen (or at least unplanned) events occurring.

Estimation errors

Some tasks are harder to estimate than others because of the lack of experience of similar tasks
or because of the nature of a task. Producing a set of user manuals is reasonably straightforward
and, given that we have carried out similar tasks previously, we should be able to estimate with
some degree of accuracy how long it will take and how much it will cost. On the other hand, the
time required for program testing and debugging, might be difficult to predict with a similar
degree of accuracy - even if we have written similar programs in the past.
Estimation can be improved by analysing historic data for similar activities and See Chapter 5
for similar systems. Keeping records comparing our original estimates with the final methods of
estimation, outcome will reveal the type of tasks that are difficult to estimate correctly.

Planning assumptions

At every stage during planning, assumptions are made which, if not valid, may put the plan at
risk. Our activity network, for example, is likely to be built on the assumption of using a
particular design methodology - which may be subsequently changed. We generally assume that,
following coding, a module will be tested and then integrated with others - we might not plan for
module testing showing up the need for changes in the original design but, in the event, it might
happen.

At each stage in the planning process, it is important to list explicitly all of the assumptions that
have been made and identify what effects they might have on the plan if they are inappropriate.

Eventualities

Some eventualities might never be foreseen and we can only resign ourselves to the fact that
unimaginable things do, sometimes, happen. They are, however, very rare. The majority of
unexpected events can, in fact, be identified - the requirements specification might be altered
after some of the modules have been coded, the senior programmer might take maternity leave,
the required hardware might not be delivered on time. Such events do happen from time to time
and, although the likelihood of any one of them happening during a particular project may be
relatively low, they must be considered and planned for.

Managing risk
The objective of risk management is to avoid or minimize the adverse effects of unforeseen
events by avoiding the risks or drawing up contingency plans for dealing with them.

There are a number of models for risk management, but most are similar, in that they identify
two main components - risk identification and risk management. An example of an often-used
model is that in Figure 7.2, which shows a task breakdown structure for what Barry Boehm calls
risk engineering.

• Risk identification consists of listing all of the risks that can adversely affect the successful
execution of the project.

• Risk estimation consists of assessing the likelihood and impact of each hazard.

This is based on the breakdown presented by Barry Boehm in his Tutorial on Software Risk
Management, IEEE Computer Society, 1989.
 Risk analysis
Risk identification Risk estimation Risk evaluation

Risk Risk Risk Risk Risk

planning control Monitoring directing staffing

Figure 7.2 Boehm \s risk engineering task breakdown.

Dwayne Phillips, The Project Manager's Handbook, IEEE Computer Society, 1998.

• Risk evaluation consists of ranking the risks and determining risk aversion strategies.

• Risk planning consists of drawing up contingency plans and, where appropriate, adding these to
the project's task structure. With small projects, risk planning is likely to be the responsibility of
the project manager but medium or large projects will benefit from the appointment of a full-
time risk manager.

• Risk control concerns the main functions of the risk manager in minimising and reacting to
problems throughout the project. This function will include aspects of quality control in addition
to dealing with problems as they occur.

• Risk monitoring must be an ongoing activity, as the importance and likelihood of particular
risks can change as the project proceeds. Risk monitoring is discussed in Chapter 9.

• Risk directing and risk staffing are concerned with the day-to-day management of risk. Risk
aversion and problem solving strategies frequently involve the use of additional staff and this
must be planned for and directed.

Whatever task model or whichever techniques are used, risk management will not be effective
unless all project staff are risk-oriented and are provided with an environment where they can
freely discuss the risks that might affect a project. All too often, team members who identify
potential risks at an early stage are seen as having a negative attitude.

Writing about attitudes to risk, Dwayne Phillips remarks that 'I have seen a room get suddenly
quiet when someone brings up a "concern"' but says that 'pretending that problems will not occur
will not prevent them'. For effective risk management, it is important that the project team are
encouraged to identify and discuss risks as early as possible in the project's life.

Risk Identification

Identifying risk is one of most important or essential and initial steps in risk management
process. By chance, if failure occurs in identifying any specific or particular risk, then all other
steps that are involved in risk management will not be implemented for that particular risk. For
identifying risk, project team should review scope of program, estimate cost, schedule, technical
maturity, parameters of key performance, etc. To manage risk, project team or organization are
needed to know about what risks it faces, and then to evaluate them. Generally, identification of
risk is an iterative process. It basically includes generating or creating comprehensive list of
threats and opportunities that are based on events that can enhance, prevent, degrade, accelerate,
or might delay successful achievement of objectives. In simple words, if you don’t find or
identify risk, you won’t be able to manage it.

The organizer of project needs to expect some of the risk in the project as early as possible so
that the performance of risk may be reduced. This could be only possible by making effective
risk management planning.

A project may contain large variety of risk. To know the specific amount of risk, there may be
chance of affecting a project. So, this is necessary to make categories into different class of risk.

There are many different types of risks which affects the software project:

1. Technology risks
2. Tools risks
3. Estimation risks
4. People risks
5. Requirement risks
6. Organizational risks

Methods for Identifying Risks : Earlier, there were no easy methods available that will surely
identify all risks. But nowadays, there are some additional approaches available for identifying
risks. Some of approaches for risk identification are given below:

1. Checklist Analysis – Checklist Analysis is type of technique generally used to identify or find
risks and manage it. The checklist is basically developed by listing items, steps, or even tasks
and is then further analyzed against criteria to just identify and determine if procedure is
completed correctly or not. It is list of risk that is just found to occur regularly in development of
software project. Below is the list of software development risk by Barry Boehm- modified
version.

Risk Risk Reduction Technique

Various techniques include training and career development,
Personnel Shortfalls
job-matching, teambuilding, etc.
Various techniques include incremental development,
Unrealistic time and cost
standardization of methods, recording, and analysis of the past
estimates
project, etc.
Development of wrong Various techniques include formal specification methods, user
software functions surveys, etc.
Development of the
Various techniques include user involvement, prototyping, etc.
wrong user interface

2. Brainstorming – This technique provides and gives free and open approach that usually
encourages each and everyone on project team to participate. It also results in greater sense of
ownership of project risk, and team generally committed to managing risk for given time period
of project. It is creative and unique technique to gather risks spontaneously by team members.
The team members identify and determine risks in ‘no wrong answer’ environment. This
technique also provides opportunity for team members to always develop on each other’s ideas.
This technique is also used to determine best possible solution to problems and issue that arises
and emerge.

3. Casual Mapping – Causal mapping is method that builds or develops on reflection and
review of failure factors in cause and effect of the diagrams. It is very useful for facilitating
learning with an organization or system simply as method of project-post evaluation. It is also
key tool for risk assessment.

4. SWOT Analysis – Strengths-Weaknesses-Opportunities-Threat (SWOT) is very technique

and helpful for identifying risks within greater organization context. It is generally used as
planning tool for analyzing business, its resources, and also its environment simply by looking at
internal strengths and weaknesses and opportunities and threats in external environment. It is
technique often used in formulation of strategy. The appropriate time and effort should be spent
on thinking seriously about weaknesses and threats of organization for SWOT analysis to more
effective and successful in risk identification.

5. Flowchart Method – This method allows for dynamic process to be diagrammatically

represented in paper. This method is generally used to represent activities of process graphically
and sequentially to simply identify the risk.

Risk Analysis

a risk is represented by one or more potential negative events which an individual or

organization seeks to avoid – at all costs – to achieve their intended objectives. It is therefore
important that these potential negative events are identified as well as their impact on the overall
project.

In project management, a risk is described as a combination of the following elements:

Risk = Potential Negative Event + Impact + Probability of Occurrence

The probability of risk occurrence ranges from 0% to 100%. It is important to note that risk
probabilities are not fixed and can change at any time throughout the project life-cycle.

Factors that affect the probability of occurrence include:

 The experience and skills of the project team

 The complexity of the task
 The existence of similar tasks in the past
 Change control procedures
 External variables

Risks that are analyzed, recorded and monitored for changes in probability are known as ‘active’
risks; those that are not are ‘inactive’ risks.

Remember, a risk is an event with an uncertain outcome. In most cases, the degree or extent that
a given risk affects a project varies from one project to another. This is where risk analysis
comes into play.

What is Risk Analysis in Project Management?

Risk analysis in project management refers to an important aspect of the feasibility study
wherein various risks and uncertainties are identified in order to evaluate them, rank them in
terms of priority and identify the areas where they are most likely to occur.

Risk Analysis is a series of activities to quantify the impact of uncertainty on a project. These
activities are risk identification, probability assessment, and impact estimation. Risk analysis
creates the foundation for running the risk management process throughout the project lifecycle.

There are three types of risk analysis in project management as follows below:

1. Qualitative Risk Analysis. It is a subjective analysis by the project team where risks are
identified and assessed based on their probability of occurrence. The risk analysis table lists the
risks in terms of their probability of occurrence, impact and its control strategies.
2. Quantitative Risk Analysis. It is an objective analysis wherein risks are classified according to
their probability of occurrence, using the standard deviation to determine its level. This technique
is useful for determining the impact of risk events to project objectives and for identifying the
possible courses of action and methods for controlling and mitigating risks.
PERT.
3. Technical Risk Analysis. it is a dynamic analysis that requires the project manager to use various
tools and techniques in order to identify, rank and evaluate risks. For example, the Delphi method
 requires the project manager to present the risks to a group of experts in the field and ask them to
rate or rank each risk in terms of its probability.

Risk Analysis Management

The goal of risk analysis management is to identify and estimate the value of potential threats
and then choose what approaches to apply to respond to identified risks. Risk analysis
management consists of three coherent activities: 1) Identify threats, 2) Assess probability of
their occurrence, and 3) Estimate their impact on the project in terms of working hours.

For this purpose, it is convenient to develop a risk analysis checklist that describes a range of
tasks to complete each of the activities. Let’s review items (tasks) of the checklist (see below).

1. Threats Identification. This activity is about identifying all potential events that seem to be risky
for the project. The next tasks characterize this activity:
o Conduct workshops and use brainstorming to determine types of the risks surrounding
your project. There could be Strategic risks, Operational risks, Compliance risks, Staff
management risks, Financial risks, Knowledge risks, etc.
o List all the types of risks affecting the project (create a project risks list sorted by types).
2. Probability Assessment. Once the potential threats have been identified, the next activity is to
measure the probability of those threats for occurrence. The goal is to estimate the probability of
each event happening during the project.
o Investigate each of the identified risks to create a detailed description of the risks.
o Use the project risk description to make an evaluation on how the risks may cause a
project failure considering Budget, Completion Dates, and Performance Objectives.
o Apply analysis methods and techniques (e.g. PERT – Program Evaluation and Review
Technique) to identify the probability of risk occurrence and assess potential deviations
of project characteristics from the baseline.
3. Impact Estimation. One of the best approaches to estimating risk impact is to multiply the
probability of risk occurrence by the amount of costs required for setting things right if risks
happen. The result will give a value for the identified risks. Following this concept, the next tasks
should be completed:
o Use the formula ∑ (Events * Probability * Consequences) to estimate the impact of the
risks affecting your project.
o Develop a risk analysis table that includes such columns as Risk Event, Probability,
Impact, Score, and Risk Mitigation Plan. The table demonstrates results of the risk
analysis management process with details on risk characteristics and mitigation plans. An
example of the risk analysis table is shown below.
Risk Analysis Table Example

Note that the sample risk analysis table gives the impact in working hours, yet it can be estimated
in other units, for example in dollars.

Once the value of project risks has been identified and estimated, the analysis management
process should be targeted at finding ways to managing the risks. This is made by using cost-
effective approaches because such approaches allow comparing risk elimination expenses with
the cost of the risk event if it happen. Cost effective approaches for project risk analysis
management will help determine the necessity for either mitigating a risk or accepting it, because
there can be cases when it’s better to access a risk rather than invest excessive resources to
eliminate it.

Considering this, managing of project risk analysis can be performed by using:

 Available assets. Any project has resources available for solving risk issues. Such resources can
be used to make improvements to existing methodologies and systems, reassign roles and
responsibilities, delegate tasks, improve internal controls and supervision, etc.
 Contingency planning. This involves the development of a contingency plan. Contingency
planning assumes acceptance of a risk with further implementation of a contingency plan to
minimize or eliminate the negative impact of the risk (once it happens).
 External resources. The process of managing project analysis sometimes requires additional
resources when existing assets are not enough for solving project issues. In this case, investments
will help counter risks. Often project risk insuring is used to carry part of the risks. Project risk
insuring is an effective way to increase solvency of the performing organization.

Reduce Project Risks

Any discussion of project risks needs to recognise that all projects have risks. The very nature of
a project is not "business-as-usual" – projects tend to go beyond the status quo – and that will
always pose some measure of risk. It is important is to accept that there will be risks, but also
recognise that risks need to be managed in order to minimise them. Projects where risks are
actively managed and controlled are more likely to be successful. But how exactly can you
handle and reduce project risks as a project manager?

Effective risk management has a number of possible objectives, such as:

 to prevent risks happening, where possible, that pose a threat to delivering a successful project
outcome;
 to mitigate risks that cannot be avoided by planning the most appropriate response; and
 to act upon risks that might present positive opportunities. That is, viewing risk from a different
perspective – one that does not always assume risks are bad for a project.

Activities designed to reduce project risks are an integral part of project management. One of the
biggest hurdles to overcome in terms of risks in project management is identifying the risks in
the first place! Sometimes it is impossible to know in advance about certain types of risks. For
example, if your project involves cutting-edge innovative technology, then predicting the
possible risks is taking a shot in the dark.

But, there are also some risks that are common across many projects or risks that certain team
members may be aware of, but don't communicate to project managers or project leaders.

One way to reduce risks is to gather as much information as possible that might help you identify
possible risks. This can be done through tried and tested methods such as brain-storming, story-
boarding or interviewing individuals from all parts of operations related to a particular project.
Working through a structured project plan template will also help you to map out potential risks,
as it will encourage you to strategically approach and analyse the project each step of the
process.

Once you have documented the identifiable risks, you will be in a much better position to
prevent them or mitigate them; and if you manage those well then any unforeseen risks are likely
to have a lesser impact on the overall project. There are 4 essential steps to reducing risk:
documenting, prioritising, avoiding and mitigating.

Documenting

Document each risk in detail, including their potential impacts and possible responses to mitigate
the risk. Then, assign a team member to monitor each risk as your project progresses. Keep this
risk log updated throughout the project.

Prioritising

Prioritisation of risks should rely on a combination of how likely the risk is to occur and its effect
on the project's schedule or budget. Cleary, certain risks may be very unlikely to occur but could
have an extremely serious effect on budget, schedule or even on your ability to complete the
project. Others may be very likely to occur but require no more response than dipping into a
contingency fund to resolve the issue.

Avoiding

Once compiled, the detailed and prioritised list of all the known risks needs to be communicated
to the team members, stakeholders and anyone else involved in the project. By doing, this you
will enable your team to work towards avoiding these risks – if a team is not made aware of what
could go wrong, how can they work to avoid it?

It is impossible to avoid unknown risks, and more effective to concentrate your efforts on the
known risks associated with your project.
Mitigating

Before any potential risks have occurred it will benefit the process to consider what the best
solution to the problem would be, should it occur. You can also decide for each individual risk
whether to try and implement the solution, if resources allow, or simply accept there is a problem
but defer any solution to a later date – possibly after the final product has been delivered –
depending on the severity of the problem. If the decision is to resolve the problem then ensure
the solution is fully implemented otherwise you will have just wasted your time.

Effectively managing risk, as already mentioned, is part of a project manager's role and helps
ensure more successful projects. However, risk management should never be such an onerous
task that it takes significant resources away from the other aspects of project management.

Resource Allocation
To assign the available resources in an economic way is known as resource allocation. The
planning of the activities and the resource required by these activities while taking into
consideration both resources availability and project time is termed as resource allocation in
project management.

There are 2 parts of resource allocation: Strategic Planning, and Resource Leveling. These are
explained as following below.

1. Strategic planning –
In strategic planning resource allocation is a plan for using available resources, for
example human resources, specially in the near term, to achieve goals for the future. It is
the process of allocating resources among various projects or business units. The strategic
planning has 2 parts.
1. There is the basic allocation decision.
2. There is the contingency mechanism.

The basic allocation decision is the choice of which items to fund in the plan and what
level of fund in it should receive and which to leave unfunded; the resources are located
to some items and not to others.

There may be contingency mechanism such as priority ranking of items excluded from
the plan, showing which items are to be sacrificed to reduce total funding.

2. Resource Leveling –
The main objective is to smooth resource requirement by shifting slack jobs beyond
periods of peak requirement. Some of the methods essentially replicate what a human
scheduler do if he has enough time, procedures design especially for the computer. They
of course depend for their success on the speed and capabilities of electronic compilers.

Approach for resource allocation :

There are number of approaches to solve resource allocation problems:
 1. Manual Approach
2. Algorithmic Approach
3. Combination of both

In algorithmic approach resource is allocated by using some computer program which is defined
for a specific domain, this will automatically and dynamically distribute resources to the user.
Electronic devices dedicated to routing and communication is commonly use this method. For
example: channel allocation in wireless communication may be decided by base transceiver
using an appropriate algorithm.

Resource Scheduling in Project Management

Resources such as raw materials, human resources and machinery are needed to execute any
project. This means that resource management is one of the main hurdles that project managers
have to clear for successful project delivery.

Because resources are tied to project activities, sound resource scheduling is required to have the
resources you need when you need them.

What Is Resource Scheduling?

Resource scheduling is the process of identifying when project resources are needed and
allocating them based on factors such as capacity planning or resource availability. The main
purpose of resource scheduling is to guarantee that there’s no over or under-allocation of
resources at any point of the project.

This leads to not only getting projects done on time and within budget, but also builds morale,
fosters better relationships, helps with profitability and boosts stakeholder satisfaction

Why Is Resource Scheduling Important In Project Management?

Resource scheduling is important in project management for a variety of reasons. The main
reason that resources can have an impact on all project constraints: time, scope, cost, risk, quality
and of course, resources. In other words, resource scheduling has a direct effect on key project
planning areas any project manager must be aware of.

In most projects, poor resource scheduling delays individual tasks which cause a domino effect
that delays the whole project. These delays mean extra project costs and sometimes project
managers are obligated to reduce their project scope or compromise the project deliverables
quality to save time.
What Should You Consider Before Creating a Resource Schedule?

As stated, the resource schedule is linked to other important aspects of your project and your
organization. So, resource scheduling is a project management decision-making activity that
needs many inputs. Here are some of the things to keep in mind.

 Resource capacity planning: This consists of assessing the total amount of work that can be
done with the resources that your organization currently has.
 Resource utilization: Resource utilization is a KPI that refers to the number of resources that are
currently being used by your company.
 Resource forecasting: It’s important to estimate the future resource needs of your project. There
are different resource forecasting tools and techniques you can use to do so.
 Resource availability: Once you’ve understood your resource capacity planning and resource
utilization, you’ll be able to determine what resources are at your disposal, or what’s your
resource availability.
 Project schedule: Your resource schedule must be aligned with the project schedule and vice-
versa. You’ll need to weigh your resource capacity, utilization and availability whenever drafting
your project schedule. However, once the schedule baseline has been approved and the project
execution phase begins, the resource schedule must align with the project schedule and not the
other way around.

Now that we’ve learned about the main inputs that you’ll need for the resource scheduling
process, let’s review some methods you can apply.

Resource Scheduling Methods

There are two main approaches that are followed by project managers when scheduling
resources, time-constrained and resource-constrained resource scheduling. This decision is made
based on resource availability.

 Time-constrained resource scheduling: Time constraint is a resource scheduling approach that

prioritizes the timely delivery of projects even if that means extra project costs. For example, a
project manager using this approach would hire extra workers to make up for a project schedule
delay, so that deliverables can be produced on time.
 Resource-constrained resource scheduling: Contrary to time-constrained resource scheduling,
this method builds the resource schedule based on resource availability.

Benefits of Resource Scheduling

With resource scheduling comes superior organization for projects, teams, sites, equipment and
any other resource associated with the project. All of this sets the stage for the intelligent
distribution of resources among your project tasks.

That includes identifying resources for each task, what their availability is and then matching
those resources with capability. That is, who on your team is best suited for executing the task?
With this information, resource scheduling also makes for better time estimates, as it provides
one more metric by which to measure your project schedule. It relies on reports and analysis of
past project resource scheduling and other similar projects for information.

Planning also benefits from resource scheduling, which helps to plan for the future by figuring
out capacity and demand. The better you do this, the better your team will feel when working on
the project. That’s because smart capacity planning prevents over-allocation. They’ll trust project
managers, which leads to greater employee retention and productivity.

8 Tips for Great Resource Scheduling

1. Use Resource Management Software

Use resource management software to help you keep track of your resources and your project
schedule. A resource management software stores all your project information to help you
manage your human resources, material and equipment.

2. Use a Work Breakdown Structure (WBS)

You can’t start to schedule your resources until you know how many you’ll need and when
you’ll use them. This involves collecting every task that leads to your final deliverable. It might
seem a daunting task, but using a WBS makes sure you don’t neglect any steps. It’s a tree
diagram with your final deliverable on top and beneath that, the various branches that lead to it.
The more complete your list, the more accurate your resource schedule is.

3. Try Resource Smoothing

Once you have all the steps, there are many ways to schedule resources. One technique is
resource smoothing, which focuses on the time constraint over all others. Here, the deadline is
king. This practice is best applied when things must be done on time, even if it means delaying
some work. While it removes some flexibility in your schedule, it tends to make scheduling more
efficient and cost-effective.

4. Practice Resource Leveling

Another resource optimization technique to use is called resource-leveling. This is used when
you have enough resources on hand to complete the project. It then distributes the resources over
the work evenly.

This helps to improve morale and makes the schedule both realistic and achievable. That might
happen by shortening or loosening the schedule and the deadline might even change, but that’s
okay because you’re not adding capacity.

5. Be Aware of Constraints
There are constraints on any project, such as the triple constraint of time, cost and scope. All of
these forces are working on your resources, so the better you can define how they’ll impact the
tasks in the previous tip, the tighter your resource schedule will be.

6. Know How Many Resources You Need

Going back to your task list, make a determination as to how many resources each task will
require.

What type of resource is it? How many of each will be required to finish the task? This figure
can be numerical, as in the quantity needed, but it can also be expressed in time. You might need
the resource for an hour or weeks. This all should be noted.

7. Control Availability of Resources

You want to control the future availability of resources. To do this requires knowing how much
capacity you have and your current resource utilization. That is, for example, how much work
your team can accomplish over a specific timeframe.

Do team members have time off scheduled over that period? Are there holidays? The more data
around the availability of your resources, the more you can manage the schedule for your
resources.

8. Assign Your Resources Wisely

The final tip applies to assigning your resources after you’ve listed tasks, identified constraints
and know how many resources you’ll need and their availability. At this point, you have the
information necessary to build a resource schedule that can avoid costly bottlenecks.

Assign with care. Depending on your resources, demand and capacity, due dates might need to
change or even be delayed. A resource schedule can work better than tea leaves in divining your
project’s future.

ProjectManager Can Schedule Your Resources

ProjectManager has a wealth of features to help you better manage and control your resource
schedule. After you’ve created a task list, you can easily import the spreadsheet into our software
and create a new project. This opens up a Gantt chart with the tasks listed on the left. Add a start
and end date to create the duration of the task, and a timeline will appear on the right.

Assign Tasks & Resources with the Gantt

Assignments can be made right from the Gantt chart, and task dependencies can be linked to
reducing resource scarcity. As you create assignments, team member availability is updated in
real time, so you always know which resources are available.
You can also track resources by categorizing them as teams or equipment. By adding hourly
rates to these resources you can also track their costs. As hours are logged on tasks, those costs
are automatically updated and compared to your plan, so you can immediately see if you’re
going off-track.

The Workload Page Tracks Availability & Schedules

In terms of availability, ProjectManager lets you block out working days, holidays and planned
hours. This is especially helpful when you’re managing distributed teams in different countries,
with different time zones and holidays.

To further balance your team’s tasks, we have a workload page that gives you visibility into how
much each team member is assigned. Their workload is color-coded, so you can quickly see if
there are any imbalances. If there are, simply reassign tasks from the workload page.
Real-Time Tracking with Dashboards

Because our software is online, it updates in real time. This makes our team management feature
especially useful, which lets you track what your team is doing on a daily or weekly basis. Easily
track task progress, who’s assigned to what and on what each team is working. If something
needs to be reassigned, it only takes a few clicks.
Critical Path

Critical Path Method (CPM) is a method used in project planning, generally for project
scheduling for the on-time completion of the project. It actually helps in the determination of the
earliest time by which the whole project can be completed. There are two main concepts in this
method namely critical task and critical path. Critical task is the task/activity which can’t be
delayed otherwise the completion of the whole project will be delayed. It must be completed on-
time before starting the other dependent tasks.

Critical path is a sequence of critical tasks/activities and is the largest path in the project
network. It gives us the minimum time which is required to complete the whole project. The
activities in the critical path are known as critical activities and if these activities are delayed
then the completion of the whole project is also delayed.

Major steps of the Critical Path Method:

1. Identifying the activities

2. Construct the project network
3. Perform time estimation using forward and backward pass
4. Identify the critical path

The table given below contains the activity label, its respective duration (in weeks) and its
precedents. We will use critical path method to find the critical path and activities of this project.
 Duration (in
Activity Precedents
weeks)
A 6 –
B 4 –
C 3 A
D 4 B
E 3 B
F 10 –
G 3 E, F
H 2 C, D

Rules for designing the Activity-on-Node network diagram:

 A project network should have only one start node

 A project network should have only one end node
 A node has a duration
 Links normally have no duration
 “Precedents” are the immediate preceding activities
 Time moves from left to right in the project network
 A network should not contain loops
 A network should not contain dangles

Node Representation:

 Activity label is the name of the activity represented by that node.

 Earliest Start is the date or time at which the activity can be started at the earliest.
 Earliest Finish is the date or time at which the activity can completed at the earliest.
 Latest Start is the date or time at which the activity can be started at the latest.
 Latest Finish is the date or time at which the activity can be finished at the latest.
 Float is equal to the difference between earliest start and latest start or earliest finish and
latest finish.
Activity-On-Node diagram:

Forward Pass:
The forward pass is carried out to calculate the earliest dates on which each activity may be
started and completed.

1. Activity A may start immediately. Hence, earliest date for its start is zero i.e. ES(A) = 0.
It takes 6 weeks to complete its execution. Hence, earliest it can finish is week 6 i.e.
EF(A) = 6.
2. Activity B may start immediately. Hence, earliest date for its start is zero i.e. ES(B) = 0.
It takes 4 weeks to complete its execution. Hence, earliest it can finish is week 4 i.e.
EF(B) = 4.
3. Activity F may start immediately. Hence, earliest date for its start is zero i.e. ES(F) = 0. It
takes 10 weeks to complete its execution. Hence, earliest it can finish is week 10 i.e.
EF(F) = 10.
4. Activity C starts as soon as activity A completes its execution. Hence, earliest week it can
start its execution is week 6 i.e. ES(C) = 6. It takes 3 weeks to complete its execution.
Hence, earliest it can finish is week 9 i.e. EF(C) = 9.
5. Activity D starts as soon as activity B completes its execution. Hence, earliest week it can
start its execution is week 4 i.e. ES(D) = 4. It takes 4 weeks to complete its execution.
Hence, earliest it can finish is week 8 i.e. EF(D) = 8.
6. Activity E starts as soon as activity B completes its execution. Hence, earliest week it can
start its execution is week 4 i.e. ES(E) = 4. It takes 3 weeks to complete its execution.
Hence, earliest it can finish is week 7 i.e. EF(E) = 7.
7. Activity G starts as soon as activity E and activity F completes their execution. Since,
activity requires the completion of both for starting its execution, we would consider the
MAX(ES(E), ES(F)). Hence, earliest week it can start its execution is week 10 i.e. ES(G)
= 10. It takes 3 weeks to complete its execution. Hence, earliest it can finish is week 13
i.e. EF(G) = 13.
8. Activity H starts as soon as activity C and activity D completes their execution. Since,
activity requires the completion of both for starting its execution, we would consider the
MAX(ES(C), ES(D)). Hence, earliest week it can start its execution is week 9 i.e. ES(H)
 = 9. It takes 2 weeks to complete its execution. Hence, earliest it can finish is week 11 i.e.
EF(H) = 11.

Backward Pass:
The backward pass is carried out to calculate the latest dates on which each activity may be
started and finished without delaying the end date of the project.
Assumption: Latest finish date = Earliest Finish date (of project).

1. Activity G’s latest finish date is equal to the earliest finish date of the precedent activity
of finish according to the assumption i.e. LF(G) = 13. It takes 3 weeks to complete its
execution. Hence, latest it can start is week 10 i.e. LS(G) = 10.
2. Activity H’s latest finish date is equal to the earliest finish date of the precedent activity
of finish according to the assumption i.e. LF(H) = 13. It takes 2 weeks to complete its
execution. Hence, latest it can start is week 11 i.e. LS(H) = 11.
3. The latest end date for activity C would be the latest start date of H i.e. LF(C) = 11. It
takes 3 weeks to complete its execution. Hence, latest it can start is week 8 i.e. LS(C) = 8.
4. The latest end date for activity D would be the latest start date of H i.e. LF(D) = 11. It
takes 4 weeks to complete its execution. Hence, latest it can start is week 7 i.e. LS(D) =
7.
5. The latest end date for activity E would be the latest start date of G i.e. LF(G) = 10. It
takes 3 weeks to complete its execution. Hence, latest it can start is week 7 i.e. LS(E) = 7.
6. The latest end date for activity F would be the latest start date of G i.e. LF(G) = 10. It
takes 10 weeks to complete its execution. Hence, latest it can start is week 0 i.e. LS(F) =
0.
7. The latest end date for activity A would be the latest start date of C i.e. LF(A) = 8. It
takes 6 weeks to complete its execution. Hence, latest it can start is week 2 i.e. LS(A) =
2.
8. The latest end date for activity B would be the earliest of the latest start date of D and E
i.e. LF(B) = 7. It takes 4 weeks to complete its execution. Hence, latest it can start is
week 3 i.e. LS(B) = 3.

Identifying Critical Path:

Critical path is the path which gives us or helps us to estimate the earliest time in which
the whole project can be completed. Any delay to an activity on this critical path will lead
to a delay in the completion of the whole project. In order to identify the critical path, we
need to calculate the activity float for each activity.

Activity float is actually the difference between an activity’s Earliest start and its latest
start date or the difference between the activity’s Earliest finish and its latest finish date
and it indicates that how much the activity can be delayed without delaying the
completion of the whole project. If the float of an activity is zero, then the activity is an
critical activity and must be added to the critical path of the project network. In this
example, activity F and G have zero float and hence, are critical activities.
Cost Scheduling In Project Management

Cost scheduling in project management is the process of estimating, budgeting, and scheduling
the costs of a project. This process is used to determine the total cost of a project, as well as the
resources needed to complete it. Cost scheduling is an important part of project management, as
it allows managers to track the progress of a project and make necessary adjustments to keep it
on track.

The schedule and budget are the two major legs of the project constraint polygon. A successful
project will be delivered if it is cost effective, meets project deadlines, and has the necessary
resources. This article describes the steps, tools, and techniques involved in cost control and
project scheduling in a concise and clear manner. A project budget is a financial plan for all
project costs (costs). The budget determines how much each project element should cost, as well
as how much each level of the work breakdown schedule (WBS) should cost, and how much the
project should cost as a whole. The best project budget management practices must include the
development of a comprehensive, consistent, and dependable project budget. The Determine
Budget is the first step in Project Cost Management.

The project manager has the ability to evaluate the project’s budget performance using the level
of detail provided here. The PM can drill down until he or she discovers that a work package is
running over or that the budget is being overrun by an unusually large amount. The PMI®
Develop Schedule process is used to create a project schedule, which is the primary output. A
project schedule could be a simple chart of work elements with a corresponding set of schedule
dates in its most basic form. When a deliverable is slipping or is in danger of slipping, the project
manager can use a drill to locate the problem. When the appropriate level of detail is present,
EVM can be applied to the work element level. As an added feature, EVM can calculate a
Schedule Variance (SV) in which the difference between the value of the work completed and
the intended work is added up.

When the project manager is able to understand why certain work elements are out of date, he or
she will be able to come up with solutions. The inability to fully comprehend the complexity of
the project results in overestimating the cost and duration. The improper allocation of resources
to critical path activities. According to human nature, it is difficult to report news that is harmful.
Some policies regarding merits, bonuses, performance reviews, and other rewards may
encourage people to act in the wrong way. J. Scott has over 30 years of experience in
engineering, project management, training, and as a professional skills consultant. Receive 25%
off your next project management course. The coupon code WEB25 can be used to make a
purchase. Only online is valid from July 31st to August 31st.

The goal of cost management is to estimate, allocate, and control project costs. The cost-
management process enables businesses to predict future expenses in order to reduce the chances
of budget overruns. Before a project can begin, project costs must be approved in the planning
stage.

What Is Cost Scheduling?

A cost schedule is a table that displays the total costs of production at different production levels
as well as marginal and average costs, as well as cost curves.

A cost schedule that shows weekly or monthly costs as well as the duration of the project is in
order. This process will give you a more detailed and accurate estimate of the cost and will serve
as a monitoring mechanism for project progress. The following are some examples of costs. The
average salary of a worker is also included in costs, as is the employer’s contribution to social
security funds, the pension plan contribution, holiday pay, and sickness benefits. In some cases,
IOE recoups some overhead costs from direct staff costs. Others recover by charging a fixed
£200 per day against projects, whereas others recover by charging a fixed price per hour for
exercising. Figure 8.9 shows the weekly cost estimate that Amanda expects the project to take on
during the next 20 weeks. The cost profile is typically set up so that it gradually approaches a
peak and then falls back.

Scheduling can be difficult, but a COGM schedule can make it easier. By organizing the tasks
involved in scheduling, the Scheduler can better plan their time and maximize their resources.
The COGM schedule was developed to streamline the process. This column contains the name of
the task, the time it should take, and the person who is responsible for carrying out the task. Each
row of the schedule begins at the start of the week, followed by the end of the week. It can be
customized to meet your specific needs.
As an example, the Scheduler could develop a schedule that covers all of the days of the week. In
this case, the schedule would have one column for each day of the week, and the time for each
task would be listed in the same format as the COGM schedule, with the start and end times for
each day.
Furthermore, the Scheduler can create a schedule that covers a specific time period. In this case,
the Scheduler would be able to create a schedule that covers all of the month. The schedule in
this scenario would be based on a single column for each week of the month, with the start and
end times of each task listed in the same format as the COGM schedule.
The Scheduler can also generate a schedule that covers a specific number of days. The
Scheduler, for example, could create a schedule that covers the entire month and all of the days
in a week.
A schedule can be created that covers a specific number of hours as well as a set of hours. In this
case, the Scheduler could try to create a schedule that covers the entire day. In this case, the
schedule would include one column for each hour of the day, and the time for each task would be
listed in the same format as the COGM schedule, with the start and end times for the day listed in
the same columns.
The COGM schedule can be used to schedule events quickly and easily. COGM allows the
Scheduler to plan their time more effectively and make better use of their resources by utilizing a
schedule.

Cost Management: Four Steps To Success

The cost management process is the most important step in successfully managing any project.
Projects can be successfully completed if they are kept costs low. If costs are not managed
properly, they can spiral out of control, resulting in project failure. The cost management process
consists of four steps: creating a cost management plan, estimating and budgeting costs,
controlling costs, and reviewing expenditures. Each step must be taken to ensure that the project
is cost-managed and that the project is completed on time and within budget. A cost management
plan must be developed in order to establish the overall budget and objectives of a project.
Creating realistic goals and costs is an important step toward avoiding overexpenditure. The cost
estimation and budgeting process is the first step in determining project costs. This step must be
taken to estimate the total cost of the project and determine how much money is available to
spend. To stay within a budget, it is critical to manage costs. Cost control strategies include
limiting costs, controlling resources, and optimizing resources, among other things. The cost
review is the final step in the cost management process. It is critical to review project costs and
overall project progress in order to determine the right costs and schedule the project for
completion.

What Is Cost Schedule And Performance?

The cost/schedule performance measurement technique (also known as the earned value analysis
technique) is used to measure and give visibility to cost and schedule variances from the plan in
accordance with Cost/Schedule Performance Management Standard.

The cost/schedule performance measurement technique allows for greater visibility into cost and
schedule variances, as well as increased transparency. If the CPI decreases over time, the
situation worsens. The project is not currently on schedule; however, this indicates that work is
not being completed as planned. The value of any piece of work, whether in-house or through
third parties, is used to calculate the budget value of that work. The ability to compare actual
costs to the value of the work performed at any given point is a powerful tool that can provide
more insight into the project’s overall success and cost/schedule performance. The
TimeVariation (TV) metric indicates how late or early a project is running. The situation appears
to be worsening if the CPI falls steadily over time. The Cost Performance Indicator can be used
in conjunction with the Budgeted Cost at Completion (BCAC) and Actual Cost of Work
Performed (ACWP) to provide a better understanding of project performance.

Performance Indicators Used In Earned Value Management

CPI = earned value (EV) / actual cost (AC) is a method of calculating the efficiency and
financial effectiveness of a specific project by taking the total cost and adding the earned value.
A CPI ratio of more than one indicates that the project is performing well within its budget.
Earned Value Management uses a variety of performance indicators in addition to the Schedule
Performance Index (SPI), Cost Performance Index (CPI), Schedule Variance (SV), and Cost
Variations (CV). The use of these tools makes it easier to comprehend the health or status of our
projects. The SPI, or project schedule variation index, is a performance indicator that plots the
amount of variation in the project schedule over time. It is calculated using the planned schedule
as an example. The SV, or variation in project costs, is a performance indicator that tracks the
amount of variation in project costs when compared to the expected cost of the project. To
calculate it, simply subtract the actual costs from the planned costs. The CV is a performance
indicator that measures the amount of variation in the project’s actual value compared to its
anticipated value. This value is calculated by taking the actual value and subtracting it from the
planned value.

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.

Creating the framework

Exercising control over a project and ensuring that targets are met is a matter of regular
monitoring, finding out what is happening, and comparing it with current targets. If there is a
mismatch between the planned outcomes and the actual ones then either replanning is needed to
bring the project back on target or the target will have to be revised. Figure 9.1 illustrates a
model of the project control cycle and shows how, once the initial project plan has been
published, project control is a continual process of monitoring progress against that plan and,
where necessary, revising the plan to take account of deviations. It also illustrates the important
steps that must be taken after completion of the project so that the experienced gained in any one
project can feed into the planning stages of future projects, thus allowing us to learn from past
mistakes. See Chapter 11 for a In practice we are normally concerned with departures from the
plan in four discussion of software dimensions - delays in meeting target dates, shortfalls in
quality, inadequate quality. functionality, and costs going over target. In this chapter we are
mainly concerned with the first and last of these.
Figure 9.1 The project control cycle.

Responsibility

The overall responsibility for ensuring satisfactory progress on a project is often the role of the
project steering committee or Project Board. Day-to-day responsibility will rest with the project
manager and, in all but the smallest of projects, aspects of this can be delegated to team leaders.

Figure 9.2 illustrates the typical reporting structure found with medium and The concept of a
reporting large projects. With small projects (employing around half a dozen or fewer staff)
hierarchy was introduced individual team members usually report directly to the project
manager, but in in Chapter 1. most cases team leaders will collate reports on their section's
progress and forward summaries to the project manager. These, in turn, will be incorporated into
project-level reports for the steering committee and, via them or directly, progress reports for the
client.

Team leader

Steering committee-A

Client

Project manager A
Team leader

Team leader

Team leader t

Analysis/design Programming Quality control section section section

User documentation section

In a PRINCE 2 environment, there is a Project Assurance function reporting to the Project Board
and independent of the Project Manager.

Figure 9.2 Project reporting structures.

Reporting may be oral or written, formal or informal, or regular or ad hoc and some examples of
each type are given in Table 9.1. While any effective team leader or project manager will be in
touch with team members and available to discuss problems, any such informal reporting of
project progress must be complemented by formal reporting procedures - and it is those we are
concerned with in this chapter.

Assessing progress

Progress assessment will normally be made on the basis of information collected and collated at
regular intervals or when specific events occur. Wherever possible, this information will be
objective and tangible - whether or not a particular report has been delivered, for example.
However, such end-of-activity deliverables might

Table 9.1 Categories of reporting

Examples Comment
Report type
Oral formal weekly or monthly while reports may be oral formal written
Regular progress meetings minutes should be kept
Oral formal end-of-stage review while largely oral, likely to receive and
ad hoc meetings generate written reports
Written formal job sheets, progress normally weekly using forms
Regular reports
Written formal exception reports,
ad hoc change reports
Oral informal canteen discussion, often provides early warning; must be
ad hoc social interaction backed up by formal reporting

The PRINCE 2 standard described in Appendix A has its own terminology.

Short, Monday morning team progress meetings are a common way of motivating staff to meet
short term targets.

not occur sufficiently frequently throughout the life of the project. Here progress assessment will
have to rely on the judgement of the team members who are carrying out the project activities.

Setting checkpoints

It is essential to set a series of checkpoints in the initial activity plan. Checkpoints may be:

• regular (monthly, for example);

• tied to specific events such as the production of a report or other deliverable. Taking snap-shots

The frequency with which the a manager needs to receive information about progress will
depend upon the size and degree of risk of the project or that part of the project under their
control. Team leaders, for example, need to assess progress daily (particularly when employing
inexperienced staff) whereas project managers may find weekly or monthly reporting
appropriate. In general, the higher the level, the less frequent and less detailed the reporting
needs to be.

There are, however, strong arguments in favour of formal weekly collection of information from
staff carrying out activities. Collecting data at the end of each week ensures that information is
provided while memories are still relatively fresh and provides a mechanism for individuals to
review and reflect upon their progress during the past few days.

Major, or project-level, progress reviews will generally take place at particular points during the
life of a project - commonly known as review points or control points. PRINCE 2, for example,
designates a series of checkpoints where the status of work in a project or for a team is reviewed.
At the end of each project Stage, PRINCE 2 provides for an End Stage Assessment where an
assessment of the project and consideration of its future are undertaken.

Cost monitoring

Expenditure monitoring is an important component of project control. Not only in itself, but also
because it provides an indication of the effort that has gone into (or at least been charged to) a
project. A project might be on time but only because more money has been spent on activities
than originally budgeted. A cumulative expenditure chart such as that shown in Figure 9.9
provides a simple method of comparing actual and planned expenditure. By itself it is not
particularly meaningful - Figure 9.9 could, for example, illustrate a project that is running late or
one that is on time hut has shown substantial costs savings! We need to take account of the
current status of the project activities before attempting to interpret the meaning of recorded
expenditure.

Project costs may be monitored by a company's accounting system. By themselves, they provide
little information about project status.
Figure 9.9 Tracking cumulative expenditure.

Time (weeks)

Figure 9.9 Tracking cumulative expenditure.

Cost charts become much more useful if we add projected future costs calculated by adding the
estimated costs of uncompleted work to the costs already incurred. Where a computer-based
planning tool is used, revision of cost schedules is generally provided automatically once actual
expenditure has been recorded. Figure 9.10 illustrates the additional information available once
the revised cost schedule is included - in this case it is apparent that the project is behind
schedule and over budget.

9.6 Earned Value

Earned Value Analysis, also known as Budgeted Cost of Work Performed, is recommended by a
number of agencies including the US and Australian departments of defence. It is also
recommended in BS 6079.

Earned Value Analysis has gained in popularity in recent years and may be seen as a refinement
of the cost monitoring discussed in the previous section. Earned Value Analysis is based on
assigning a 'value' to each task or work package (as identified in the WBS) based on the original
expenditure forecasts. The assigned value is the original budgeted cost for the item and is known
as the baseline budget or budgeted cost of work scheduled (RC WS). A task that has not started
is assigned the value zero and when it has been completed, it. and hence the project, is credited
with the value of the task. The total value credited to a project at any point is known as the
earned value or budgeted cost of work performed (BCWP) and this can be represented as a value
or as a percentage of the BCWS.

Original total cost

Time (weeks)

Revised total cost

Revised estimate ^

Original total cost

Project costs augmented by project monitoring can be used to generate forecasts of future costs.

Figure 9.10 The cumulative expenditure chart can also show revised estimâtes of cost and
completion date.

Where tasks have been started but are not yet complete, some consistent method of assigning an
earned value must be applied. Common methods in software projects are:

• the 0/100 technique Where a task is assigned a value of zero until such time that it is completed
w hen it is given a value of I00*£ of the budgeted value;

• the 50/50 technique Where a task is assigned a value of 50% of its value as soon as it is started
and then given a value of I00# once it is complete;

• the milestone technique Where a task is given a value based on the achievement of milestones
that have been assigned values as part of the original budget plan.

Of these, we prefer the 0/100 technique. The 50/50 technique can give a false sense of security
by over-valuing the reporting of activity starts. The milestone technique might be appropriate for
activities w ith a long duration estimate but. in such cases, it is better to break that activity into a
number of smaller ones.

The baseline budget

The first stage in setting up an earned value analysis is to create the baseline budget. The
baseline budget is based on the project plan and shows the forecast grow th in earned value
through time. Earned value may be measured in monetary values but, in the case of staff-
intensive projects such as software development, it is common to measure earned value in
person-hours or workdays. Amanda's baseline budget, based on the schedule shown in Figure
8.7, is shown in Table 9.2 and diagrammatically in Figure9.11. Notice that she has based her
baseline budget on workdays and is using the 0/100 technique for crediting earned value to the
project.

Table 9.2 Amanda's bast-line budget calculation

Budgeted Scheduled Cumulative cumulative earned
Task
workdays completion workdays value
Specify overall
34 34 34 14.35
system
Specify module B 15 49 i
\ 64 27.00
Specify module D 15 49 J
Specify module A 20 54 84 35.44
Check
2 56 86 36.28
specifications
Design module D 4 60 90 37.97
Design module A 7 63 97 40.93
Design module B 6 66 103 43.46
Check module C
1 70 104 43.88
spec
Specify module C 25 74 129 54.43
Design module C 4 79 133 56.12
Code & test
25 85 158 66.67
module D
Code & test
30 93 188 79.32
module A
Code & lest
28 94 i
module B
| 231 97.47
Code & test
15 94 J
module C
System integration 6 100 237 100.00

Amanda's project is not expected to be credited with any earned value until day 34, when the
activity specify overall system is to be completed. This activity was forecast to consume 34
person-days and it will therefore be credited with 34 person-days earned value when it has been
completed. The other steps in the baseline budget chart coincide with the scheduled completion
dates of other activities.
Prioritizing Monitoring

 The process of prioritizing projects is an activity for defining what projects within a
portfolio to perform in what sequence.
 It is an attempt to make the project portfolio more effective through identifying the most
effective way of implementing the projects.
 Project Prioritization Process is a structured and consistent activity that aims to analyze
the current operational environment to identify any projects running in parallel within the
same portfolio, develop a scoring model including ranking criteria, and apply that model
to prioritizing the projects in order to determine the execution order that ensures the
highest efficiency of the overall portfolio.
 The process serves as a framework for managing the effectiveness of parallel projects.

Steps involved for prioritizing monitoring:

 Collection – you must collect and gather all the data about your projects.
 Ranking – you must develop and use a ranking model that includes criteria for
prioritizing.
 Verification – you must approve the ranked projects.
 SOFTWARE PROJECT MANAGEMENT
UNIT 5
Globalization issues in project management: Evolution of globalization- challenges in
building global teams-models for the execution of some effective management techniques
for managing global teams. Impact of the internet on project management: Introduction –
the effect of the internet on project management – managing projects for the internet –
effect on project management activities. Comparison of project management software: dot
Project, Launch pad, openProj. Case study: PRINCE2

GOBALIZATION ISSUES IN PROJECT MANAGEMENT:

Globalization has significantly impacted project management in various ways.
While it has brought numerous benefits, such as increased access to talent, resources,
and markets, it has also introduced several challenges and issues. Here are some
globalization issues in project management:
- Cultural Differences: Globalization brings together people from diverse cultural
backgrounds, which can lead to challenges in communication, decision-making, and
understanding of project objectives and requirements.
-Language Barriers: When managing global projects, language barriers can hinder
effective communication, leading to misunderstandings, errors, and delays.
-Time Zone Differences: Global projects often involve teams spread across different
time zones, making it challenging to schedule meetings, coordinate tasks, and ensure
timely collaboration.
- Legal and Regulatory Compliance: Projects operating in multiple countries must
navigate different legal and regulatory frameworks, which can vary significantly and
require careful consideration and compliance.
- Technology and Infrastructure: Varying technological capabilities and
infrastructure in different regions can impact the implementation and execution of
global projects, affecting connectivity, data sharing, and accessibility.
- Supply Chain Complexity: Global projects often involve complex supply chains
spanning multiple countries, increasing the risk of delays, disruptions, and logistical
challenges.

1
- Stakeholder Management: Managing stakeholders across different countries and
cultures requires sensitivity to their unique needs, expectations, and perspectives,
which can be challenging to navigate effectively.
- Project Control and Monitoring: Global projects demand robust control and
monitoring mechanisms to ensure that progress is tracked accurately, risks are
identified, and adjustments can be made promptly.
- Risk Management: Global projects may face additional risks due to geopolitical,
economic, or social factors that can impact the project's success, requiring a
comprehensive risk management strategy.
- Resource Allocation: Optimizing resource allocation across multiple locations,
considering factors such as cost, availability, and skill sets, can be complex and
require careful planning and coordination.

EVOLUTION OF GLOBALIZATION
The evolution of globalization in software project management has been a
significant development in the field, driven by advancements in technology,
communication, and a changing global economy. Over the years, globalization has
transformed the way software projects are managed, bringing both opportunities and
challenges. Let's explore the key stages of this evolution:

1. Localized Development: In the early days of software project management,

development was primarily conducted within local teams. Companies focused on
serving their local markets, and the project teams were typically co-located.

2. Offshoring and Outsourcing: As technology improved and communication

barriers reduced, organizations started exploring offshoring and outsourcing options.
They began to leverage talent and cost advantages in other countries, typically in
regions like India, China, and Eastern Europe. This led to the establishment of global
delivery centers and the rise of the global outsourcing industry.

2
3. Distributed Development: With the expansion of the internet and improvements
in collaboration tools, distributed development became more feasible. Companies
started forming globally dispersed teams, with team members located in different
countries or regions. This allowed organizations to tap into talent pools worldwide,
benefiting from diverse perspectives and 24/7 development cycles.

4. Agile Methodologies and Collaboration Tools: Agile methodologies, such as

Scrum and Kanban, gained popularity in software development. These
methodologies emphasized iterative development, close collaboration, and self-
organizing teams. Collaboration tools like video conferencing, project management
software, and version control systems played a vital role in enabling effective
communication and coordination among distributed teams.

5. Cloud Computing and DevOps: The advent of cloud computing and DevOps
practices further accelerated the globalization of software project management.
Cloud platforms provided scalable infrastructure, making it easier to deploy and
manage software globally. DevOps fostered collaboration between development and
operations teams, enabling faster and more efficient software delivery.

6. Virtual Teams and Remote Work: In recent years, remote work has become
increasingly prevalent, driven by technological advancements and changing work
culture. Virtual teams, comprised of individuals working from different locations,
have become the norm rather than the exception. Project managers now need to
navigate the complexities of leading and coordinating teams that span multiple time
zones and cultural backgrounds.

7. Global Talent Marketplaces: Online talent marketplaces have emerged,

connecting organizations with skilled professionals worldwide. These platforms
provide access to a vast pool of talent and facilitate remote collaboration. They
enable organizations to assemble project teams with specialized skills, regardless of
geographical boundaries.

3
8. Cultural Considerations and Adaptation: Effective software project management
in a globalized context requires an understanding of cultural nuances and the ability
to adapt to diverse work environments. Project managers must be sensitive to
cultural differences, communication styles, and business practices to foster
collaboration and achieve project success.

9. Ethical and Legal Challenges: Globalization has brought forth ethical and legal
challenges in software project management. Data protection, intellectual property
rights, compliance with local regulations, and ensuring fair and equitable treatment
of remote team members are some of the complex issues that project managers need
to address.

In summary, the evolution of globalization in software project management has

transformed the way projects are executed. It has enabled organizations to access a
global talent pool, leverage cost advantages, and adopt agile practices. However, it
has also introduced new challenges, such as managing virtual teams, navigating
cultural differences, and ensuring compliance with legal and ethical standards.
Project managers must continually adapt their strategies and practices to effectively
manage software projects in an increasingly globalized world.

CHALLENGES IN BUILDING GLOBAL TEAMS

Building global teams in software project management can present several
challenges. Here are some common ones:
Communication and Collaboration: Effective communication becomes crucial
when team members are geographically dispersed across different time zones and
cultural backgrounds. Language barriers, varying communication styles, and lack of
face-to-face interaction can hinder effective collaboration. Miscommunication and
misunderstandings may occur more frequently, leading to delays and project issues.

Cultural Differences: Global teams often consist of members from diverse cultural
backgrounds, which can lead to differences in work styles, expectations, and
approaches to problem-solving. Cultural norms, values, and communication styles

4
can vary significantly, leading to misunderstandings and conflicts. Building a
cohesive team and fostering a shared understanding of goals and processes can be
challenging.

Time Zone Differences: Global teams can span multiple time zones, making it
challenging to schedule meetings and maintain real-time collaboration. Team
members may need to adjust their working hours or participate in meetings outside
their regular work hours, leading to potential work-life balance issues and reduced
productivity.

Trust and Relationship Building: Building trust and rapport among team
members who may have never met in person can be difficult. Lack of face-to-face
interaction can make it harder to establish personal connections and develop a sense
of camaraderie. Trust is essential for effective collaboration and can take longer to
establish in a global team.

Project Coordination: Coordinating tasks and managing dependencies across

geographically dispersed teams can be complex. Project managers may face
challenges in tracking progress, identifying bottlenecks, and ensuring smooth
coordination among team members. Different time zones and communication
challenges can lead to delays and difficulties in synchronizing efforts.

Knowledge Sharing and Documentation: In global teams, knowledge sharing

becomes crucial for maintaining consistency and ensuring that team members have
access to relevant information. Documenting processes, sharing best practices, and
providing comprehensive project documentation becomes essential. Language
barriers and cultural differences can make it challenging to create effective
knowledge-sharing mechanisms.

Team Dynamics and Motivation: Maintaining team morale and motivation can
be challenging in global teams. The physical distance can lead to a lack of
camaraderie and a sense of isolation. Team members may feel disconnected from

5
the project goals and less engaged, affecting their productivity and commitment to
the project.

Addressing these challenges requires proactive measures and effective

management strategies. Some approaches include establishing clear communication
channels, promoting cultural awareness and sensitivity, leveraging collaborative
tools and technologies, fostering regular team interactions, and providing
opportunities for face-to-face meetings or virtual team-building activities.
THE ADVANTAGES
Working with international colleagues stimulates flexibility and increases
availability. When you can divide the work among people in different time zones,
your team will finish the project within e.g.
24 hours instead a few days. Working virtually is a good way to cut costs e.g.
especially travel costs.

TEAM EFFECTIVENESS MODEL

A team effectiveness model is a tool or framework to help businesses and leaders
understand how well their teams function and improve team building, management,
and training to ultimately boost performance and accomplish shared goals.

Team effectiveness models are an excellent tool for HR managers and team
managers to evaluate how effective and efficient their teams are in an unbiased way
and develop stronger solutions.

GRPI Model of team effectiveness

The GRPI (goals, roles, procedures, and interpersonal relationships) model was
introduced by Richard Beckhard in 1972 and later popularized by Irwin Rubin,

6
Mark Plovnick, and Ronald Fry. It is one of the most widely-known team
effectiveness models, consisting of the four components listed below:

 Goals – A team must have clear objectives and direction to be effective.

 Roles – Each team member must know what they are responsible for.

 Procedures – Processes must be in place so the team can operate

successfully.

 Interpersonal relationships – It’s important that every team member

develops relationships with one another and can communicate effectively
and trust each other.

The GRPI model is best suited to dysfunctional teams that aren’t hitting their goals
or have lost direction and can help identify the cause and resolve it. Understanding
the relationships among the elements helps here.

For example, if your team isn’t hitting their goals, you can see if everyone has a
clear role and is held accountable, and so on. It operates on the central belief that if
everyone has a goal, a role, a process to support them, and is kind, then you’ll have
a winning team. It’s also a great model to use when building a new team from
scratch.

The downside is that this model is static and will only show you how well a team
performs at a specific time rather than over its whole lifecycle. It also relies on

7
teams being fairly structured from the get-go instead of developing organically
over time.

The Hackman model

J. Richard Hackman, who started studying teams in the 1970s, introduced the
Hackman team effectiveness model. Through his 40 years of research, he discovered
that what is central to collaboration is not the personalities or behaviors of individual
team members but the conditions that enable a group of people to thrive.

His model comprises five factors, which are:

1. Being a Real Team – Everyone has a defined role with set tasks to complete.

2. Compelling Direction – There is a clear direction or end goal to work towards.

8
3. Enabling Structure – Workflows and processes support the team in achieving
their goals.

4. Supportive Context – Tools, resources, and training help the team reach their
goal.

5. Expert Coaching – Access to a coach or mentor when needed helps teams

perform more effectively.

The Hackman model is most helpful to managers who want to know how to best
structure their team and give them the tools they need to eventually be self-
sustaining.

9
IMPACT OF INTERNET ON PROJECT MANAGEMENT:
INTRODUCTION:
Author, speaker, and futurist Jacob Morgan wrote in a Forbes article that,
“The internet of things (IoT) is becoming an increasingly growing topic of
conversation both in the workplace and outside of it. It's a concept that not
only has the potential to impact how we live but also how we work."

The internet of things has also become one of those tech buzzwords that loses
a little more of its real meaning every time a Silicon Valley wannabe
carelessly tosses it around.

EFFORT OF THE INTERNET ON PROJECT MANAGEMENT

Project management is always changing and looking for new ways to increase
organizational efficiency. It's an important process because keeping teams under
control, especially larger ones, takes a lot of time and often results in
underperformance.Although agile project management technologies have been
available for a few decades, we are now witnessing another revolution in the form
of the Internet of Things (IoT).
The internet of things and project management
The IoT is essentially the global network of devices that can communicate with
one another and end users through the internet.
As recently as two decades ago, this network was made up of computers almost
exclusively. But in the last decade, the IoT has exploded through the proliferation of
everything from smartphones, to microwaves and refrigerators, and even toasters,
all sharing data with each other around them.
Many major technology firms are developing their own IoT platforms, such as
Amazon Web Services, Microsoft Azure, and Google Cloud.
The IoT intersects with project management on everything from team
collaboration to data collection. You can expect real-time status reporting via IoT to
usher in a new era of dynamic planning and revolutionized project execution.

10
 Data collection will happen seamlessly and constantly, allowing leaders to make
more informed decisions. Inventory and resources will be easily monitored at all
times.
Devices can automatically sense and respond to what is happening around them
or in their network, reducing the need for human intervention, lowering operating
costs, increasing response times, and minimizing errors. Moreover, customers can
expect to receive better and faster service.
In terms of project management technology, the IoT will fundamentally alter the
speed of project execution. Organizations that capitalize on the IoT will complete
projects faster than those that don't, and organizations that fail to adapt to the IoT
revolution will be left hopelessly behind.
At least six things will change, which will require project managers to adapt both
technically and systematically.

11
1. IoT enables hyperspeed reporting
IoT substantially reduces the cost of communication.
The hyperconnected devices and constant flow of data that automate systems will
speed things up considerably. No more idle times are required in between activities.
No more silos from support systems such as databases, storage, and IT operations.
IMPACT Say you're an IT project manager, and you need to run a status report
on all of your organization's desktop and laptop computers and tablets and mobile
devices. In the past, this process might take weeks. But with the IoT, a project
manager could run a report on the quantity and condition of all of those pieces in an
instant.

2. IoT allows complete monitoring and process control

IoT allows project managers, management, and stakeholders to monitor and
control activities in real time. The overall snapshot of a comprehensive system is
monitored on a single screen, which allows overseers to immediately attend to any
interruptions.
IMPACT Using equipment as an example, sensors will be used for monitoring
and predicting maintenance needs throughout a project's lifetime. The scope of
devices, activities, and conditions that need to be tested will increase exponentially
as projects become more complex. Ease of use and environments suddenly become
critical.

3. IoT creates an explosion of valuable project data

In the past, archiving historical data was a time- and labor-intensive process. With
the IoT, historical data will become available immediately, which is extremely
helpful for current and future projects.
Everything from budgeting to individual meetings with team members will be
recorded in great detail, providing a solid foundation for future decisions.
IMPACT Project management tools will need to be more responsive and scalable
to accommodate this data explosion. Organizations need to make sure that their

12
project management software package is capable of growing to accommodate this
incoming flood of data. They also need to know when it's time to upgrade—for
example, if your team is capping out on your storage allowance each month.

4. IoT allows super-deep data analytics

With the IoT comes advanced data analytics, and advanced data analytics require
advanced interpretations and management.
IMPACT Project managers must upgrade their skills related to data handling,
which could mean increasing spend and resources toward data management, hiring
experienced data analysts, and accounting for data analysis when creating the project
timeline.
In other words, the more familiar project managers are with the importance of
advanced data analysis, the better the chances for project success.

5. IoT ushers in stricter ethical and legal implications

Today's internet-connected devices send data to each other extremely fast. We're
not dealing with dial-up modems anymore. One error could create a domino effect
that could topple an entire project or, in extreme cases, an entire career before you
can say "Enron."

IMPACT Businesses of all sizes need to impose stricter ethical and legal
implications on any slight mistake or oversight. Project managers and team members
should be aware of this early on so that the project can be completed with minimal
ethical and legal risks.

6. IoT raises expectations for all stakeholders

Once companies adopt IoT, the marketplace will be transformed into a level
playing field. Only the strongest and the fittest will survive. No longer can
organizations hide behind old excuses such as, "We don't have access to that data"
or, "We need a few weeks to get that report back."

13
 IMPACT Project managers need to lead the charge when it comes to raising
standards in the IoT era. As a project manager, your job is to be aware of the most
useful technology available and enable your team to use it.

EFFECT ON PROJECT MANAGEMENT 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. 10s

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.

14
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:

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

Comparison of Project Management Software

Comparison of project management software, dot project launch pad, open
project

When comparing project management software such as DotProject, Launchpad, and

OpenProject, there are several factors to consider, including features, usability,
flexibility, and community support. Here's a brief comparison of these three tools:

DotProject:

16
Features: DotProject is an open-source project management software that offers
features like task management, resource allocation, time tracking, Gantt charts, and
document management.

Usability: DotProject has a relatively simple interface, which may be suitable for
users who prefer a straightforward project management tool. However, the user
experience can sometimes be considered less intuitive compared to more modern
alternatives.

Flexibility: DotProject can be customized to some extent to meet specific project

requirements, but the flexibility might be limited compared to other tools.

Community Support: DotProject has an active community that provides support

and contributes to its development, although the frequency of updates and new
features may vary.

Launchpad:
Features: Launchpad is primarily known as a software development platform that
includes project management features such as bug tracking, code hosting,
translations, and release management.

Usability: Launchpad has a user-friendly interface that integrates well with various
software development processes, making it suitable for teams focused on code-based
projects.

Flexibility: Launchpad is designed with software development in mind and may not
offer the same level of flexibility for non-technical project management needs.

Community Support: Launchpad has an active user community and is particularly

popular within the open-source software community. However, it's worth noting that
the development of Launchpad itself has slowed down in recent years.

OpenProject:
Features: OpenProject is a feature-rich project management software that offers
task management, Gantt charts, time tracking, issue tracking, document
collaboration, and more. It provides a wide range of functionalities suitable for
various project types.

17
Usability: OpenProject has a modern and user-friendly interface that makes it
relatively easy to navigate and use. The platform is designed to accommodate both
agile and traditional project management methodologies.

Flexibility: OpenProject allows for a high degree of customization, making it

suitable for adapting to different project requirements. It also integrates with other
popular tools such as Git, Jenkins, and Slack.

Community Support: OpenProject has an active and growing community that

provides support, regular updates, and new features. The community actively
contributes to the development and improvement of the software.

Ultimately, the choice between these project management tools depends on your
specific needs, preferences, and the nature of your projects. It's advisable to try out
demos, evaluate the features, and consider the requirements of your team before
making a decision.

DOTPROJECT:

dotProject is a web-based, multi-user, multi-language project management

application. It is free and open source software, and is maintained by an open
community of volunteer programmers. dotProject was originally developed by
Will Ezell at dotmarketing, Inc. to be an open source replacement for Microsoft
Project, using a very similar user interface but including project
management functionality.

18
LAUNCH PAD

Launchpad is a web application and website that allows users to develop and
maintain software, particularly open-source software. It is developed and maintained
by Canonical Ltd.

It has several parts:

 Answers: a community support site and knowledge base.

 Blueprints: a system for tracking new features.
 Bugs: a bug tracker that allows bugs to be tracked in multiple contexts
(e.g. in an Ubuntu package, as an upstream, or in remote bug trackers).

19
  Code: source code hosting, with support for the Bazaar and Git[5] version
control systems.
 Translations: a site for localising applications into different languages.
A significant but less visible component is Soyuz, "the distribution management
portion of Launchpad." Launchpad is currently primarily used in the development
of Ubuntu, an operating system. Launchpad uses the FOSS (free/open source) Zope
3 application server.

OPEN PROJECT
OpenProj was an open-source project management software application.
The original founders of OpenProj start to develop a complementary server for
OpenProj in 2012. Comparable to Microsoft project Server for Microsoft project.
Server projectLibre corrects many issues of OpenProj and introduces significant
features such as import/eport with Microsoft 2010, printing PDF exporting(without
any restrictions), new ribbon user interface, Full compatibility with Microsoft
project 2010.

The current version includes:

 Earned value costing

 Gantt charts
 PERT graphs
 Resource breakdown structure (RBS) charts
 Task usage reports
 Work breakdown structure (WBS) charts[5]

20
PRINCE 2:

Introduction
Effective project management is essential in absolutely any organization,
regardless of the nature of the business and the scale of the organization. From
choosing a project to right through to the end, it is important that the project is
carefully and closely managed. This is essentially the role of the project manager
and his/her team of employees.
Managing and tracking the progress of a project is no easy task. Every project
manager must know (and communicate to his/her team) all the project goals,
specifications and deadlines that need to be met in order to be cost-effective, save
time, and also to ensure that quality is maintained so that the customer is completely
satisfied.
21
 The project plan and other documents are therefore very important right through
out the project. Effective project management, however, cannot simply be achieved
without employing certain techniques and methods. One such method is the
PRINCE2.

PRINCE2 . What is it?

PRINCE stands for Projects in Controlled Environments. Dealing with a bit of
history, this method was first established by the Central Computer and
Telecommunications Agency (It is now referred to as the Office of Government
Commerce).
It has since become a very commonly used project management method in all
parts of the world and has therefore proven to be highly effective in various respects.
The method also helps you to identify and thereafter assign roles to the different
members of the team based on expertise. Over the years, there have been a number
of positive case studies of projects that have used PRINCE2 project management
methodology.
This method deals with the various aspects that need to be managed in any given
project.
The diagram below illustrates the idea.

In the above diagram:

22
  The seven principles shown in the above diagram must be applied if the
project is to be called a PRINCE2 project. These principles will show
you whether and how well the project is being carried out using this
particular project management method.
 Similarly, the themes of PRINCE2 refer to the seven principles that
need to be referred to at all times during the project, if the project is to
indeed be effective. If adherence to these principles is not carefully
tracked from the inception of the project through to the end, there is a
high chance that the project will fail entirely.
 The processes refer to the steps that need to be followed. This is why
this method is known as a 'process-based' method.
 Finally, with regard to the project environment, it's important to know
that this project management method is not rigid. Changes can be made
based on how big the project is, and the requirements and objectives of
each organization. PRINCE2 offer this flexibility for the project and this
is one of the reasons why PRINCE2 is quite popular among the project
managers.
The Pros and Cons of the Methodology
One benefit of using this method over others could be said to be the fact that it is
product-based and it also divides the project into different stages making it easy to
manage. This is sure to help the project team to remain focused and deliver a quality
outcome at the end of the day.
The most important of all benefits is that it improves communication between all
members of the team and also between the team and other external stakeholders,
thereby giving the team more control of the project.
It also gives the stakeholder a chance to have a say when it comes to decision
making as they are always kept informed by the issuance of reports at regular
intervals.
PRINCE2 also ensures that improvements can be made in the organization. This
is because you would be able to identify any flaws that you make in projects and
correct, which of course would help you to a great extent in the long run.
The flexibility of PRINCE2 allows these changes to be made run-time. Although
there can be some implications and issues to the project schedule when certain
changes are done run-time, PRINCE2 offers some of the best practices to minimize
the impact.

23
 Your team will also learn to save a lot of time and be more economical when it
comes to the use of assets and various other resources, thereby ensuring that you are
also able to cut down on costs a great deal.
When it comes to disadvantages, PRNCE2 does not offer the level of flexibility
offered by some of the modern project management methodologies. Since project
management, especially in software industry, has grown to a different level,
PRINCE2 may find difficulties in catering some of the modern project management
needs.
Conclusion
It should be kept in mind that PRINCE2 is a very complex method and cannot
be carried out without special training. Failure to understand precisely how it works
could lead to a lot of problems and difficulties whilst carrying out the project.
PRINCE2 guidelines can be selectively applied to certain projects that do not last
long. This makes the method even more flexible and thereby more appealing to
dynamic organizations and projects.

24