UNIT I PROJECT MANAGEMENT & COSTING 9

Software Project Management approaches – Project Acquisition – Initiation – Planning – PERTExecution and
Control – CPM – Change Management – Project Closure – Agile SPM Problems in Software Estimation –
Algorithmic Cost Estimation Process, Function Points, COCOMO II (Constructive Cost Model) – Estimating
Web Application Development – Concepts of Finance, Activity Based Costing and Economic Value Added
(EVA) – Balanced Score Card.

What is a project management methodology?

A project management methodology is a set of principles and practices that guide you in organizing your
projects to ensure their optimum performance.
Huh?
Basically, it’s a framework that helps you to manage your project in the best way possible.
Project management is so important to organizations and teams, but in order for it to be really effective, you
need to make sure you’re correctly mapping your project management methodology to your team type, project,
organization, and goals.

Why are there so many different project management methodologies?

No two projects are exactly the same (even when you’re using handy features like project templates to replicate
your past successes).
And when you factor in the different goals, KPIs and production methods of not only different types of teams
but also different types of industries, it makes sense that there’s no one-size-fits-all approach to managing a
project.
What works best for one type of team could be an absolute nightmare for another.
For example, many software developers started to find that traditional project management methods were
hindering — rather than helping — their workflows and negatively affecting their performance and results.
As a result, software teams began to develop a new type of project management methodology, which was
designed to address their particular concerns.
Before long, other teams and industries started to adapt those new project management methods to
fit their unique needs and concerns. And on and on, with different project management methodologies being
repurposed and adapted for different industries and tweaked to fit specific use cases.
What we’re left with is a ton of different project management methodologies to choose from. So how do you
know which project management method (or methods, plural) is right for you and your team?

How do you choose the right project management methodology?

There are lots of factors that will impact which project management methodology is right for your project, team,
and organization. Here’s a quick breakdown of some of the key considerations that can help you decide:
 Cost and budget: On a scale of $ to $$$, what sort of budget are you working with? Is there room for
that to change if necessary, or is it essential that it stays within these predetermined limits?
 Team size: How many people are involved? How many stakeholders? Is your team relatively compact
and self-organizing, or more sprawling, with a need for more rigorous delegation?
 Ability to take risks: Is this a huge project with a big impact that needs to be carefully managed in
order to deliver Very Serious Results? Or is it a smaller-scale project with a bit more room to play
around?
 Flexibility: Is there room for the scope of the project to change during the process? What about the
finished product?
 Timeline: How much time is allotted to deliver on the brief? Do you need a quick turnaround, or is it
more important that you have a beautifully finished result, no matter how long it takes?
 Client/stakeholder collaboration: How involved does the client/stakeholder need — or want — to be
in the process? How involved do you need — or want — them to be?
The project management methodologies list
We’ve compiled this list of project management methodologies to help you get to grips with the basics.
While it’s not completely comprehensive, our aim is to provide you with an overview of some of the different
methodologies out there, so you can see what’s out there and figure out which one might be a good fit for your
particular projects.

1. Waterfall methodology
The Waterfall method is a traditional approach to project management. In it, tasks and phases are completed in a
linear, sequential manner, and each stage of the project must be completed before the next begins.
The stages of Waterfall project management generally follow this sequence:
 Requirements
 Analysis
 Design
 Construction
 Testing
 Deployment & maintenance
Progress flows in one direction, like a real waterfall.
Also like a real waterfall, though, this can quickly get dangerous. Since everything is mapped out at the
beginning, there’s a lot of room for error if expectations don’t match up with reality. And there’s no going back
to a previous stage once it’s completed (just imagine trying to swim against a waterfall — not fun).
Try this project management methodology if:
 The end goal of your project is clearly defined — and isn’t going to change.
 The stakeholders know exactly what they want (and it isn’t going to change).
 Your project is consistent and predictable (i.e. isn’t going to change).
 You’re working in a regulated industry that needs extensive project tracking or documentation.
 You might need to bring new people into the project midway through and get them up to speed quickly.
This project management methodology might not be for you if:
 Your project is liable to change.
 You don’t have a full picture of all the requirements before you start.
 You need to do continuous testing or adapt to feedback during the process.

2. Agile methodology
The agile project management methodology came from a growing dissatisfaction with the linear approach of
traditional project management methodologies.
Frustrated with the limitations of project management methods that couldn’t adapt with a project as it
progressed, the focus began to shift to more iterative models that allowed teams to revise their project as needed
during the process instead of having to wait until the end to review and amend.
The concept of agile project management has gone on to spark several specific sub-frameworks and
methodologies, such as scrum, kanban, and lean. But what do they all have in common? The key principles of
agile project management methodologies are:
 It’s collaborative.
 It’s quick.
 It’s open to data-driven change.
As such, agile project management methodologies usually involve short phases of work with frequent testing,
reassessment, and adaptation throughout.
In many agile methods, all of the work to be done is added to a backlog that teams can work through in each
phase or cycle, with project managers or product owners prioritizing the backlog so teams know what to focus
on first.
Try this project management methodology if:
 Your project is liable to change.
  You’re not sure at the outset what the solution will look like.
 You need to work quickly, and it’s more important that you see speedy progress than perfect results.
 Your stakeholders or client needs (or wants) to be involved at every stage.
This project management methodology isn’t for you if:
 You need a lot of documentation (for example, if you’ll be bringing new people on-board during the
project).
 You need a predictable deliverable, and you need to be crystal clear about what that looks like from the
outset.
 Your project can’t afford to change during its course.
 You don’t have self-motivated people.
 You have strict deadlines or deliverables that you need to stay on top of.

3. Scrum methodology
Scrum is a form of agile project management. You can think of it more like a framework than as a project
management methodology in itself.
With Scrum, work is split into short cycles known as “sprints”, which usually last about 1-2 weeks. Work is
taken from the backlog (see: Agile project management, above) for each sprint iteration,
Small teams are led by a Scrum Master (who is not the same as the project manager) for the duration of the
sprint, after which they review their performance in a “sprint retrospective” and make any necessary changes
before starting the next sprint.
Try this project management methodology if:
 You’re striving for continuous improvement.
This project management methodology might not be for you if:
 You don’t have the full commitment from the team needed to make it work.

4. Kanban methodology
Kanban is another method within agile project management.
Originating from the manufacturing industry, the term “kanban” has evolved to denote a framework in which
tasks are visually represented as they progress through columns on a kanban board. Work is pulled from the
predefined backlog on a continuous basis as the team has capacity and moved through the columns on the
board, with each column representing a stage of the process.
Kanban is great for giving everyone an immediate visual overview of where each piece of work stands at any
given time. (You can use kanban boards for everything from your content marketing process to hiring and
recruitment.)
It also helps you to see where bottlenecks are at risk of forming — if you notice one of your columns getting
clogged, for example, you’ll know that that’s a stage of your process that needs to be examined.
When used as part of an agile project management methodology, it’s also common to implement work in
progress (WIP) limits. Work in progress limits restrict the amount of tasks in play at any given time, meaning
that you can only have a certain number of tasks in each column (or on the board overall).
This prevents your team from spreading their energy across too many tasks, and instead ensures that they can
work more productively by focusing on each task individually.
Try this project management methodology if:
 You’re looking for a visual representation of your project’s progress.
 You want at-a-glance status updates.
 You want to encourage using WIP limits so your team can stay focused.
 You prefer to work on a continuous “pull” basis.
This project management methodology might not be for you if:
 Your process is super complex or has tons of stages.
  You want a push system instead of a pull system.

5. Scrumban methodology
It’s the answer to the age-old question: what if scrum and kanban had a baby?
Scrumban is a hybrid agile project management methodology that has scrum’s nose and kanban’s eyes.
The main benefit of scrumban as a method is that instead of deciding which task from the backlog to work on in
each sprint at the outset (like you would in a “traditional” scrum framework), scrumban allows teams to
continuously “pull” from the backlog based on their capacity (like they would in a kanban framework).
And using work in progress limits (from kanban) during your sprint cycle (from scrum), you can keep a
continuous flow while still incorporating project planning, reviews and retrospectives as needed.
Try this project management methodology if:
 You’ve ever looked at scrum and kanban and thought “I wish those two crazy kids would get together”.
This project management methodology might not be for you if:
 You’ve ever looked wistfully out the window and thought, “Oh, scrum is scrum, and kanban is kanban,
and never the twain shall meet”.

6. eXtreme programming (XP) methodology

The eXtreme Programming (XP) methodology is another form of agile project management that was designed
for software development.
It emphasizes teamwork and collaboration across managers, customers, and developers, with teams self-
organizing. It has a defined set of rules that teams should follow, which are based on its five values: simplicity,
communication (face to face is preferred), feedback, respect, and courage.
Try this project management methodology if:
 You want to foster teamwork and collaboration.
 You have a small, co-located team.
This project management methodology might not be for you if:
 You’re a rulebreaker.
 Your team is spread across different places and time zones.

7. Adaptive project framework (APF) methodology

8. Lean methodology

9. Critical path method

10. Critical chain project management

Acquisition

Resources are very important to deliver projects and they include types of machinery, people, technology,
property and other materials that are necessary to deliver work—which can also imply the cost of resources but
not automatically in financial terms. The resources may be acquired from both internal and external sources.

The project management term, Acquisition, is part of resource management and together with deployment, it is
necessary to deliver the final outcome of the project. It is crucial for the owner of the project to identify the
different resources that are needed to deliver work as well as the scheduling of the acquisition of the resources.
Acquisition is all about setting up a project management infrastructure that can mobilize the resources.
This infrastructure is also necessary to create policies for the acquisition as well as the deployment of
resources so that the projects will proceed as planned.
What is PERT in Project Management?
Program Evaluation Review Technique (PERT) is a project management planning tool used to calculate the
amount of time it will take to realistically finish a project. PERT charts are used to plan tasks within a project —
making it easier to schedule and coordinate team members.

PERT charts were created in the 1950s to manage the creation of weapons and defense projects for the US
Navy. While PERT was being introduced in the Navy, the private sector simultaneously gave rise to a similar
method called critical path. PERT is similar to critical path in that they are both used to visualize the timeline
and the work that must be done for a project. However with PERT, you create three different time estimates for
the project:

 The shortest possible amount of time each task will take

 The most probable amount of time
 The longest amount of time tasks might take if things don't go as planned
PERT is calculated backward from a fixed end date since contractor deadlines typically cannot be moved.
Executing & Control Processes Activities
 Procure or secure any required resources (hardware, services, software, etc.)
 Make project progress information available to stakeholders
 Work results (deliverables) are created
 Conduct status review meetings and disseminate status reports
 Change management (original project scope, cost, schedule, and technical strategies)
 Direct and lead the project team
 Ensure project progresses according to the plan
 Manage any project issues and risks
 Track lessons learned through the project duration.

Corporate Performance Management (CPM)

Corporate performance management (CPM) is an umbrella term that describes the methodologies,
metrics, processes and systems used to monitor and manage the business performance of an enterprise.
Applications that enable CPM translate strategically focused information to operational plans and send
aggregated results. These applications are also integrated into many elements of the planning and control cycle,
or they address BAM or customer relationship optimization needs.
CPM must be supported by a suite of analytical applications that provide the functionality to support these
processes, methodologies and metrics.
WHAT IS CHANGE MANAGEMENT?

Change management is defined as the methods and manners in which a company describes and implements
change within both its internal and external processes. This includes preparing and supporting employees,
establishing the necessary steps for change, and monitoring pre- and post-change activities to ensure successful
implementation.

Significant organizational change can be challenging. It often requires many levels of cooperation and may
involve different independent entities within an organization. Developing a structured approach to change is
critical to help ensure a beneficial transition while mitigating disruption.

Changes usually fail for human reasons: the promoters of the change did not attend to the healthy, real and
predictable reactions of normal people to disturbance of their routines. Effective communication is one of the
most important success factors for effective change management. All involved individuals must understand the
progress through the various stages and see results as the change cascades.
HOW TO IMPLEMENT CHANGE MANAGEMENT

1. Define the change.

2. Select the change management team.
3. Identify management sponsorship and secure commitment.
4. Develop implementation plan including metrics.
5. Implement the change—in stages, if possible.
6. Collect and analyze data.
7. Quantify gaps and understand resistance.
8. Modify the plan as needed and loop back to the implementation step.

TUTORIAL FOR OVERCOMING RESISTANCE TO CHANGE

Resistance to change can be defined as any obstacle that becomes an impediment to implementing change. The
source of resistance is often individuals or groups, but it can also be systems or processes that are outdated or
that fail to fit current business conditions.

Figure 1 depicts the elements of a change management model and the sequence in which they occur.

Figure 1 Change management model for making change work

In the center of the change management model figure, all changes move from the current state, through a
transition phase, and into the desired improvement state.

 In the beginning, it is important to create, or affirm, a broadly understood need for the change (creating a
shared need).
 It is equally important to create and share an idea of what the outcome will look like (shaping a vision).
 Throughout the change effort, there must always be sufficient resources dedicated to it (mobilizing
commitment).
 There must be a way to track the change efforts (monitoring progress).
 A person or team must ensure that the change reaches completion (finishing the job).
 From the very beginning until the end, the change effort must have the backing of management, and
leadership from an accountable person or people (leading change)
 Figure 2 Elements of the change management model
Project Closing Phase
Overview
 Concludes all project activities
 Administratively closes the project
 Turns the delivered product or service over to customer or a support group
 Assesses project outcomes and team performance
 Documents best practices and lessons learned
 Celebrates project success
Description
The purpose of the closing phase in the project management lifecycle is to confirm completion of project
deliverables to the satisfaction of the project sponsor, and to communicate final project disposition and status to
all participants and stakeholders.
The PMO Director can provide Project Managers various levels of service in the Closing Phase including:
 Consult with appropriate teams to transition the project to operations
 Facilitate Project Closure/Lessons Learned Meetings
 Consult on completing the Project Closure Report
 Brainstorm team celebration ideas
 Critical Success Factors
 Pre-defined user acceptance criteria
 Business objectives and anticipated benefits are achieved
 Project objectives are achieved
 Knowledge transfer is achieved
 Project materials are archived
Closing Processes Activities
 Obtain acceptance of the project deliverables.
 Hand off operations and support responsibilities.
 Document the lessons learned over the course of the project.
 Formalize closure. Obtain sign-off from project sponsor and project manager.
Duties of the Project Manager in the Closing Phase
 For a completed project, the Project Manager is responsible to:
 Schedule and conduct a Project Closure/Lessons Learned Meeting
 Complete the Project Closure Report with input from the project team. The report will confirm in
writing from the project sponsor and/or customers that the project is complete
 Complete the Project Closeout Checklist
 Complete a Service Transition Report (if applicable)
 Conduct the Project Satisfaction Survey (Appendix F) and review results.
 Close and deactivate the project in ServiceNow (Required)
 Arrange for an appropriate celebration of the work completed. Remember to have fun! (Optional ,
but recommended)

Project Closure Report

After the Project Closure Meeting the Project Manager must produce a Project Closure Report using the Project
Closure Report template contained in Appendix D.
The purposes of the Project Closure Report are:
 Measures how closely the project met customer needs
 Identifies what worked well on the project and what needs improvement
 Documents any deviations from the original plan and identify causes
 Articulates methods for improvement
 Formulates lessons learned and best practices from feedback
The Project Closure Report should document Lessons Learned during the project lifecycle. Examples of lesson
learned could include but not limited to the following:
 Project Change Management Process
 Project Estimation
 Project Resources (scope, schedule, budget, resources)

What is Estimation in Agile?

Agile estimation is the process for estimating the effort required to complete a prioritized task in the product
backlog. This effort is usually measured with respect to the time it will take to complete that task, which, in
turn, leads to accurate sprint planning.
What is a Sprint? A sprint is a time-boxed interval that defines the time allocated to complete a task.
Note: No matter how accurately a business estimates the effort required to complete a user story in Agile, an
estimate is still an estimate. Do not strive to achieve perfect accuracy because requirements can change at any
time. There are also agile anti-patterns and other emerging realities that change the course of development.
Agile teams also make estimations with reference to story points. A story point is used in Agile Development
projects to estimate the difficulty of implementing a given user story. This is measured in relative units assigned
to different user stories that require estimation.
In a nutshell, a story point is a number that helps estimate the difficulty of building a user story successfully.
This difficulty could be anything related to the complexities, risks, and efforts involved.
Agile project estimation also helps to build strong coordination. If project X is dependent on project Y, agile
project estimation provides an overview of the wait time.
Why Run Agile Estimations?
Agile estimations are essential for:
 Making teams accountable for deliverables
 Inducing discipline across the Agile team
 Predicting the approximate time it will take to finish a project
 Enabling better sprint management
  Improving team productivity
Why do Teams Estimate in Agile?
Overestimating and underestimating are both common for Agile development teams which leads to varying
development and launch times. Though the process is complicated, considering Agile estimation in the initial
stages can assist with accurate user story estimations and helps the team stick to the timely deliverables.
Some of the to-the-point benefits of Agile Estimation techniques include:
1. Improved Decision-Making
With accurate, agile estimation, the development team will be able to conduct effective backlog grooming
sessions, which will further help in precise sprint planning. When they make informed decisions and plan well,
their user story delivery time will improve.
2. Better Coordination
Let’s say that the estimated effort for user story A is two weeks. On the other hand, the estimation effort for
user story B is four weeks. Now, suppose both the user stories depend on each other and are connected. In that
case, the team needs to prioritize work so that both user stories get completed simultaneously, thus leading to
better coordination among teams.
3. Better Risk Management
Software projects often suffer from exceeding budgets and timelines. To lessen this risk, Agile project
estimation is an ideal solution. Agile product estimation helps estimate story points and stick to budgets,
estimates, and the project’s scope. The more accurate the estimates, the better the chances of on-time, quality
delivery.
Stages of Agile Estimation: The Short Discovery Phase
When a project starts, the horizon is limited. Thus, it is wise to implement a short product discovery phase to
tide over this problem. The discovery phase establishes the essential tenet of Agile methodology, which consists
of breaking down the requirements into small batch sizes.
This is an exercise that typically takes two to four weeks, depending upon the project’s complexity.
The in-detail process includes:
1. Conduct Stakeholder Interviews
The Business Analyst (BA) assigned to the discovery team revisits any existing documentation shared initially
and extracts the gaps and queries. The BA then conducts regular workshops with the stakeholders to discuss the
gaps and clarify doubts in the system workflow.
Based on these workshops, the BA comes up with the business and functional requirements:
 Business Requirements Document (BRD): defines the end-goal of the project
 Functional Requirements Document (FRD): defines the features required to achieve the end-goal
These workshops can be conducted over a call with the client or when they visit the premises to have one-on-
one sessions.
2. Define High-Level Product Backlog
The next step of Agile Estimation involves the BA and the Technical Architect. They frame an initial outcome
that the stakeholders are looking for with a feasible solution or product.
A high-level product backlog is defined in terms of epics and story titles, which describe the bare bones of the
application. They then validate if the backlog addresses the scope of the project for the client.
3. Understand the Client and its Potential Customers
Depending upon the complexity of the problem that the application is intended to solve, a UX design anchor is
taken on board along with the BA for the discovery phase. The UX analyst’s prime deliverable is to understand
not just the client but also their potential customers.
The UX analyst works on personas of the possible user group who might use the application, the ecosystem in
which the personas will be using it, and the touchpoints of the user personas within the system. The deliverables
here would be ecosystem maps, personas, user journeys, and storyboards.
4. Prioritize Requirements
The discovery team becomes involved in the agile cost estimation project and works on the high-level backlog
after it has been validated by the stakeholder.
The analysis is employed with the prioritization method to decide which requirements to complete first, which
ones can come later, and which ones to exclude. The backlog items are divided on the basis of the MoSCoW
method, which segments features based on must-haves, should-haves, could-haves & won’t-haves.

5. Prepare the Minimum Viable Product (MVP) Backlog

Based on the prioritization activity, the BA assembles the requirements as ‘must-haves’ to the backlog and
sections them as the requirements for the MVP Development.
The MVP backlog might also contain a few items from the ‘should haves’ list, ensuring that the product is
sufficiently competitive in the market.
6. Estimate the Project Cost and Timeline
The discovery team estimates the MVP backlog to define the estimated cost and timeline for the first release.
This is followed by build, rinse, and repeat until they arrive at an estimate that fits the business needs. This also
allows flexibility to load and off-load features as product development starts.
Software Engineering | COCOMO II Model
COCOMO-II is the revised version of the original Cocomo (Constructive Cost Model) and is developed at
University of Southern California. It is the model that allows one to estimate the cost, effort and schedule when
planning a new software development activity.
It consists of three sub-models:

1. End User Programming:

Application generators are used in this sub-model. End user write the code by using these application
generators.
Example – Spreadsheets, report generator, etc.
2. Intermediate Sector:
  (a). Application Generators and Composition Aids –
This category will create largely prepackaged capabilities for user programming. Their product will
have many reusable components. Typical firms operating in this sector are Microsoft, Lotus,
Oracle, IBM, Borland, Novell.
 (b). Application Composition Sector –
This category is too diversified and to be handled by prepackaged solutions. It includes GUI,
Databases, domain specific components such as financial, medical or industrial process control
packages.
 (c). System Integration –
This category deals with large scale and highly embedded systems.
3. Infrastructure Sector:
This category provides infrastructure for the software development like Operating System, Database
Management System, User Interface Management System, Networking System, etc.
Stages of COCOMO II:

1. Stage-I:
It supports estimation of prototyping. For this it uses Application Composition Estimation Model.
This model is used for the prototyping stage of application generator and system integration.
2. Stage-II:
It supports estimation in the early design stage of the project, when we less know about it. For this it
uses Early Design Estimation Model. This model is used in early design stage of application
generators, infrastructure, system integration.
3. Stage-III:
It supports estimation in the post architecture stage of a project. For this it uses Post Architecture
Estimation Model. This model is used after the completion of the detailed architecture of application
generator, infrastructure, system integration.

Cost Estimation Models in Software Engineering

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

1. Empirical Estimation Technique –

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

How to Estimate Web App Development Project | Web App Development Cost Calculator
Share
Reading time about 12 minutes
The importance of web applications cannot be denied even when we are staying in a mobile dominant world. Web
applications have a significant impact on the user’s mind and act as an integral part of a business’s presence
online. It turns out to be an online brochure or marketing forefront of any company.
Hundreds of web applications are launched every month. Surprisingly, the enigma no longer exists whether you
need a web application for your business or not. But the question is that the cost to build a web application fits
your company’s budget and meets business requirements.
Many businesses hire web & app development companies to create intuitive web apps that help them to reach
their goals faster. The cost of developing web apps depends on various factors that we’ll discuss in this blog.
Which Factors are affecting the Development Cost to Create a Web App?
How Much Does It Cost To Build a Web Application? It is the most common question that comes to your mind
before building a web app for your business. Many factors impact the development cost of the app. Hiring a cheap
development team can hamper not just the quality of the app but also lead to poor customer experiences.
To help in planning your budget better with a brief idea of estimated cost, we have listed some of the hand-picked
factors that hugely affect the web application development cost.
1. Functionality
Another factor that may raise the cost of the web app is the number of functionalities and the complexity of each
feature. Some features can be developed quickly without effort, while others may take time to build.
One of the simplest websites is the one that is developed without any support of integrations or payments and is
usually managed by a single person for any content update/change. A basic informational website takes lesser
time to build & needs a lower budget.
2. Complexity of App
One aspect that can impact the web development estimation is the complexity of the web app. The more complex
your app is, the more expensive it will take to develop it. We should be aware that the total cost is calculated as
per the number of working hours spent and the hourly rates of each web developer involved in the process. Web
apps with more complex features will take more working hours to build. Additionally, the number of custom
features you want in your app also defines its complexity.
Evaluating Costs by Project Complexity
Basic Web Apps
The simplest version of a web application with basic functionality is called basic web apps. It generally includes
simple landing webpages or informational websites.
 Development Time – Around 3 to 4 weeks
 Approximate Development Cost $5000 to $17,000
 Built with predefined template layouts
 Small online catalogs
 Calculator pages
 Widgets or additional features to the existing web apps
Custom Web Apps
Professionally designed with interactive UI/UX are custom web apps. It is one of the most suitable options for
mid-scale business or e-commerce sites with moderate complexity.
 Development Time – Around 12 weeks
 Approximate Development Cost $17,000 – $55,000
 E-commerce stores
 Marketplace-based web apps
 Modules or additional parts for existing web apps
Complex Web Apps
Complex web apps have a high complexity level with exclusive CMS features. It includes various features like
payment gateways, social media integration, checkout carts, and much more.
 Development Time – Around 24 weeks
 Approximate Development Cost $55,000 – $2,50,000
 Automated billing systems
 Payment processing apps
Enterprise-grade Web Apps
 Development Time – Around 24 weeks
 Approximate Development Cost around $2,50,000 or More
The companies that need large software system platform designed to operate effortlessly in a corporate
environment use enterprise-level web apps. It includes various functionalities like automated billing systems,
ERP, e-mail marketing systems, CMS, business intelligence, and much more. It can cost around $2,50,000 and
more, depending on the list of features that needs to be integrated into the platform.
3. Custom Designs
A web app with standard design is what we suggest if you are a startup or a budget-company, as it comes with
several pre-built themes & templates. The more custom designs you want in your app, the more additional charges
you need to spend on the development cost. Go for an advanced web app with a fully customized user interface
design when you have good money to spend. A number of screens are also a factor that can impact the website
development cost.
4. Location of Developers
Development costs may indeed differ location wise. One of the most significant factors that can impact the
development cost is the physical location of the development company. It is because the wages of web app
developers may vary from one country to another. Developers in software companies based in advanced
countries with a higher cost of living usually have higher earnings.
5. Strict Deadlines
Maintaining the quality of the project and handling strict deadlines can be difficult. Also, it will cost you more
since you need a higher number of resources working dedicatedly for the fast development process. It is always
advisable to plan the project because a tight schedule task involves higher risks that may increase the
developmental cost.
6. Hourly Rates
In today’s global IT market, there is an enormous number of web application designers that work as per diverse
business models, and the value ranges are related to each type. The hourly developmental rates will be distributed
to different types of professionals involved in the whole development cycle i.e. manager, developer, and QA team.
Talking about high-profile clients with budgets starting at six figures will prefer to work with enterprise-level
developers while startups would go for mid-level developers.
7. Maintenance Charges
We know that the cost involved in making a successful web app doesn’t end with its development cost, as post-
release expenses will be there to fix the bugs and maintain the infrastructure. Even if you are working with the
top developers in the town, bugs can pop up after the launch of the website.
We advise you to have a clear discussion with the development team to make sure that the cost involves the
maintenance and bug fixing charges. Save a part of your budget and be ready to fix the issues that may arise after
the development phase and keep the app updated to engage customers with evolving trends.

Main Web App Categorizations

Web apps are divided into six broad categories. The classification is based on the content required to showcase
on a website.
Static Web Dynamic Web E-commerce Web Web Portal CMS Web Application
Application Application Application Development Development Services
Development
$500 – $10,000 $2500 – $5000 $10,000 – $50,000 $3,000 – $6,000 $5,000 – $50,000
1. Static Web Application
A static website is easily and quickly developed in HTML and CSS languages. They are cost-effective but are
preferable to showcase portfolios or static information. As, even if you want to update certain information on the
website, you need a developer to perform the needful task. The main advantages of developing a static website
are inexpensive hosting, easy indexing, and quickly transferred from server to client without much processing
time.
2. Dynamic Web Application
Dynamic websites are more powerful than static websites. From the ease of maintenance to greater usability,
dynamic web apps give you an opportunity to display different content to different users according to the location.
It is developed with a combination of HTML and coding.
Unlike static websites, it holds an entire database of content thus you can effortlessly alter, edit, or update content,
without the need of a web developer. By enabling its features like recently viewed items, personalized product
suggestions, and location-based offers, you can deliver amazing customer experience. It increases customer
engagement and improves retention.
3. E-commerce Web Application Development
Every E-commerce web app is different from another. Incorporation of different features like content management
system, payment gateways, search engine optimized layout, reporting tools, email integration, push notifications,
chatbots, and much more can affect the total development cost. With the right features on your e-store website,
you can reach a global audience with ease.
4. Web Portal Development
There are several web portals including B2C, B2B, learning, community, vendor, and much more. Each portal
can be differentiated from other from its features. For information management, you can use features like multisite
support, document management, and advanced search.
To make a platform socially-active, you can integrate media galleries, polls & rating functionality, and activity
streams. If you want to enhance collaboration then you can include workflows, forums, and blogs.
5. Animation Web Development
With the continuously changing technology environment, you need to give something “extra” to keep your
customers engaged. The best solution for animation can be accomplished by using HTML5, CSS3, and JavaScript.
While animation web development, you need to consider cross-platform support.
Devices come with different aspect ratios, orientations, and pixel densities, thus you need to test on all platforms
and devices to better performance and improved response times. The development can cost around $10,000 per
minute for a simple video with no characters.
6. CMS Web Application Development Services
For quick management of website content, you can use the right CMS for your business. It gives complete control
over your website including design and content. You can edit, delete, add, or update webpages when and where
required, without hiring a web developer.
However, the cost depends on which CMS you use for your business. With emerging trends, there are different
CMS options that you can use and upgrade your company’s website, effortlessly.
6.1 Kentico
Kentico is a licensed CMS that enables you to manage online stores and provides a unified view of your marketing
activities and consumer data. It is an all-in-one solution with out-of-the-box functionality thus a preferable option
for the enterprise-grade website. The standard cost with a custom design for a corporate website starts
from $50,000.
6.2 WordPress
WordPress is an open source yet powerful CMS that offers extensive features to build intuitive business websites.
It is a reliable web development solution for professional websites and e-commerce stores. The platform offers
smart customization, responsive design, easy-to-install functionality, multiple theme options, flexibility, and
much more. A custom WordPress theme will cost around $3000 and a custom WordPress website will cost
around $15,000.
6.3 Drupal
One of the most comprehensive CMS systems available in the market is Drupal. You can use the platform to
manage content as per your changing business strategies with ease. If done right, you can make your websites
highly responsive, secure, and easy to integrate & market.
A standard Drupal project can cost you around $30,000 to $40,000. However, the cost may rise in case of
complicated workflows and many content types.
6.4 Magento
An open source platform, Magento is mainly used for e-commerce development. It is a feature-rich CMS that
empowers store owners to makes the efficient use of in-built features to manage the overall store functionality.
Some of the in-built features include search engine optimization, catalog management, payment integration tools,
and much more. The cost of a Magento website starts from $20,000 to $40,000.
Key Takeaway: The choice of web application development company has a crucial impact on the development
costs. Whether you choose freelancers in expensive location or a megastar company in a cheap location may cost
you an arm and a leg. Choose a renowned web development company with a proven-track record to enjoy
immense benefits in the future.
Top 5 Computer Science Concepts for Finance and Financial Engineering
Algorithms
Probability and Statistics
Artificial intelligence (AI)
Distributed ledger technology (DLT)
Cloud computing

What Is Activity-Based Costing (ABC)?

Activity-based costing (ABC) is a costing method that assigns overhead and indirect costs to related products
and services. This accounting method of costing recognizes the relationship between costs, overhead activities,
and manufactured products, assigning indirect costs to products less arbitrarily than traditional costing
methods. However, some indirect costs, such as management and office staff salaries, are difficult to assign to
a product.

Activity-Based Costing (ABC)

How Activity-Based Costing (ABC) Works

Activity-based costing (ABC) is mostly used in the manufacturing industry since it enhances the reliability of
cost data, hence producing nearly true costs and better classifying the costs incurred by the company during its
production process.
KEY TAKEAWAYS

 Activity-based costing (ABC) is a method of assigning overhead and indirect costs—such as salaries
and utilities—to products and services.
 The ABC system of cost accounting is based on activities, which are considered any event, unit of
work, or task with a specific goal.
 An activity is a cost driver, such as purchase orders or machine setups.
 The cost driver rate, which is the cost pool total divided by cost driver, is used to calculate the amount
of overhead and indirect costs related to a particular activity.
ABC is used to get a better grasp on costs, allowing companies to form a more appropriate pricing strategy.
This costing system is used in target costing, product costing, product line profitability analysis, customer
profitability analysis, and service pricing. Activity-based costing is used to get a better grasp on costs,
allowing companies to form a more appropriate pricing strategy.
The formula for activity-based costing is the cost pool total divided by cost driver, which yields the cost driver
rate. The cost driver rate is used in activity-based costing to calculate the amount of overhead and indirect
costs related to a particular activity.
The ABC calculation is as follows:

1. Identify all the activities required to create the product.

2. Divide the activities into cost pools, which includes all the individual costs related to an activity—such
as manufacturing. Calculate the total overhead of each cost pool.
3. Assign each cost pool activity cost drivers, such as hours or units.
4. Calculate the cost driver rate by dividing the total overhead in each cost pool by the total cost drivers.
5. Divide the total overhead of each cost pool by the total cost drivers to get the cost driver rate.
6. Multiply the cost driver rate by the number of cost drivers.
As an activity-based costing example, consider Company ABC that has a $50,000 per year electricity bill. The
number of labor hours has a direct impact on the electric bill. For the year, there were 2,500 labor hours
worked, which in this example is the cost driver. Calculating the cost driver rate is done by dividing the
$50,000 a year electric bill by the 2,500 hours, yielding a cost driver rate of $20. For Product XYZ, the
company uses electricity for 10 hours. The overhead costs for the product are $200, or $20 times 10.
What Is Economic Value Added (EVA)?
Economic value added (EVA) is a measure of a company's financial performance based on the residual wealth
calculated by deducting its cost of capital from its operating profit, adjusted for taxes on a cash basis. EVA can
also be referred to as economic profit, as it attempts to capture the true economic profit of a company. This
measure was devised by management consulting firm Stern Value Management, originally incorporated as
Stern Stewart & Co.1
KEY TAKEAWAYS

 Economic value added (EVA), also known as economic profit, aims to calculate the true economic
profit of a company.
 EVA is used to measure the value a company generates from funds invested in it.
 However, EVA relies heavily on invested capital and is best used for asset-rich companies, where
companies with intangible assets, such as technology businesses, may not be good candidates.

Understanding Economic Value Added (EVA)

EVA is the incremental difference in the rate of return (RoR) over a company's cost of capital. Essentially, it is
used to measure the value a company generates from funds invested in it. If a company's EVA is negative, it
means the company is not generating value from the funds invested into the business. Conversely, a positive
EVA shows a company is producing value from the funds invested in it.
The formula for calculating EVA is:
EVA = NOPAT - (Invested Capital * WACC)
Where:

 NOPAT = Net operating profit after taxes

 Invested capital = Debt + capital leases + shareholders' equity
 WACC = Weighted average cost of capital

Advantages and Disadvantages of EVA

EVA assesses the performance of a company and its management through the idea that a business is only
profitable when it creates wealth and returns for shareholders, thus requiring performance above a company's
cost of capital.
EVA as a performance indicator is very useful. The calculation shows how and where a company created
wealth, through the inclusion of balance sheet items. This forces managers to be aware of assets and expenses
when making managerial decisions.

What Is a Balanced Scorecard (BSC)?

The term balanced scorecard (BSC) refers to a strategic management performance metric used to identify and
improve various internal business functions and their resulting external outcomes. Used to measure and
provide feedback to organizations, balanced scorecards are common among companies in the United States,
the United Kingdom, Japan, and Europe. Data collection is crucial to providing quantitative results as
managers and executives gather and interpret the information. Company personnel can use this information to
make better decisions for the future of their organizations.

Characteristics of the Balanced Scorecard Model (BSC)

Information is collected and analyzed from four aspects of a business:

1. Learning and growth are analyzed through the investigation of training and knowledge resources.
This first leg handles how well information is captured and how effectively employees use that
information to convert it to a competitive advantage within the industry.
2. Business processes are evaluated by investigating how well products are manufactured. Operational
management is analyzed to track any gaps, delays, bottlenecks, shortages, or waste.
 3. Customer perspectives are collected to gauge customer satisfaction with the quality, price, and
availability of products or services. Customers provide feedback about their satisfaction with current
products.
4. Financial data, such as sales, expenditures, and income are used to understand financial performance.
These financial metrics may include dollar amounts, financial ratios, budget variances, or income
targets.

Benefits of a Balanced Scorecard (BSC)

There are many benefits to using a balanced scorecard. For instance, the BSC allows businesses to pool
together information and data into a single report rather than having to deal with multiple tools. This allows
management to save time, money, and resources when they need to execute reviews to improve procedures and
operations.1

Examples of a Balanced Scorecard (BSC)

Corporations can use their own, internal versions of BSCs, For example, banks often contact customers and
conduct surveys to gauge how well they do in their customer service. These surveys include rating recent
banking visits, with questions ranging from wait times, interactions with bank staff, and overall satisfaction.
They may also ask customers to make suggestions for improvement.
UNIT II PROCESS MODELS & LIFECYCLE MANAGEMENT
Software Engineering Process Models - Adaptive Software Development (ASD) - DSDM - SCRUM – Crystal -
Feature Driven Development (FDD) - ISO 9000: 2000 - SPICE – SIX SIGMA – CMMI. SLIM (Software Life
cycle Management) – PLM (Product Lifecycle Management) – PDM (Product Data Management) - PLM, PDM
Applications – Pre-PLM Environment – Change Management.
What is a Software Process Model?
 What is a Software Process Model?
 Types of Software Process Model
 Waterfall Model
 V Model
 Incremental model
 Iterative Model
 RAD model
 Spiral model
 Agile model
 Managing Software Process with Visual Paradigm
 Project Manage Guide-Through
 Just-in-Time PMBOK / Project Management Process Map
Software Processes is a coherent set of activities for specifying, designing, implementing and testing software
systems. A software process model is an abstract representation of a process that presents a description of a
process from some particular perspective. There are many different software processes but all involve:
 Specification – defining what the system should do;
 Design and implementation – defining the organization of the system and implementing the system;
 Validation – checking that it does what the customer wants;
 Evolution – changing the system in response to changing customer needs.
Types of Software Process Model
Software processes, methodologies and frameworks range from specific prescriptive steps that can be used
directly by an organization in day-to-day work, to flexible frameworks that an organization uses to generate a
custom set of steps tailored to the needs of a specific project or group. In some cases a “sponsor” or
“maintenance” organization distributes an official set of documents that describe the process.
Software Process and Software Development Lifecycle Model
One of the basic notions of the software development process is SDLC models which stands for Software
Development Life Cycle models. There are many development life cycle models that have been developed in
order to achieve different required objectives. The models specify the various stages of the process and the
order in which they are carried out. The most used, popular and important SDLC models are given below:
 Waterfall model
 V model
 Incremental model
 RAD model
 Agile model
 Iterative model
 Spiral model
 Prototype model
Waterfall Model
The waterfall model is a breakdown of project activities into linear sequential phases, where each phase
depends on the deliverables of the previous one and corresponds to a specialisation of tasks. The approach is
typical for certain areas of engineering design.

V Model
The V-model represents a development process that may be considered an extension of the waterfall model
and is an example of the more general V-model. Instead of moving down in a linear way, the process steps
are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the
relationships between each phase of the development life cycle and its associated phase of testing. The
horizontal and vertical axes represent time or project completeness (left-to-right) and level of abstraction
(coarsest-grain abstraction uppermost), respectively.
Incremental model
The incremental build model is a method of software development where the model is designed, implemented
and tested incrementally (a little more is added each time) until the product is finished. It involves both
development and maintenance. The product is defined as finished when it satisfies all of its requirements.
Each iteration passes through the requirements, design, coding and testing phases. And each subsequent
release of the system adds function to the previous release until all designed functionally has been
implemented. This model combines the elements of the waterfall model with the iterative philosophy of
prototyping.

Iterative Model
An iterative life cycle model does not attempt to start with a full specification of requirements by first
focusing on an initial, simplified set user features, which then progressively gains more complexity and a
broader set of features until the targeted system is complete. When adopting the iterative approach, the
philosophy of incremental development will also often be used liberally and interchangeably.
In other words, the iterative approach begins by specifying and implementing just part of the software, which
can then be reviewed and prioritized in order to identify further requirements. This iterative process is then
repeated by delivering a new version of the software for each iteration. In a light-weight iterative project the
code may represent the major source of documentation of the system; however, in a critical iterative project a
formal software specification may also be required.
RAD model
Rapid application development was a response to plan-driven waterfall processes, developed in the 1970s and
1980s, such as the Structured Systems Analysis and Design Method (SSADM). Rapid application
development (RAD) is often referred as the adaptive software development. RAD is an incremental
prototyping approach to software development that end users can produce better feedback when examining a
live system, as opposed to working strictly with documentation. It puts less emphasis on planning and more
emphasis on an adaptive process.
RAD may resulted in a lower level of rejection when the application is placed into production, but this
success most often comes at the expense of a dramatic overruns in project costs and schedule. RAD approach
is especially well suited for developing software that is driven by user interface requirements. Thus, some
GUI builders are often called rapid application development tools.

Spiral model
The spiral model, first described by Barry Boehm in 1986, is a risk-driven software development process
model which was introduced for dealing with the shortcomings in the traditional waterfall model. A spiral
model looks like a spiral with many loops. The exact number of loops of the spiral is unknown and can vary
from project to project. This model supports risk handling, and the project is delivered in loops. Each loop of
the spiral is called a Phase of the software development process.
The initial phase of the spiral model in the early stages of Waterfall Life Cycle that is needed to develop a
software product. The exact number of phases needed to develop the product can be varied by the project
manager depending upon the project risks. As the project manager dynamically determines the number of
phases, so the project manager has an important role to develop a product using a spiral model.
Agile model
Agile is an umbrella term for a set of methods and practices based on the values and principles expressed in
the Agile Manifesto that is a way of thinking that enables teams and businesses to innovate, quickly respond
to changing demand, while mitigating risk. Organizations can be agile using many of the available
frameworks available such as Scrum, Kanban, Lean, Extreme Programming (XP) and etc.

The Agile movement proposes alternatives to traditional project management. Agile approaches are typically
used in software development to help businesses respond to unpredictability which refer to a group of
software development methodologies based on iterative development, where requirements and solutions
evolve through collaboration between self-organizing cross-functional teams.
The primary goal of being Agile is empowered the development team the ability to create and respond to
change in order to succeed in an uncertain and turbulent environment. Agile software development approach
is typically operated in rapid and small cycles. This results in more frequent incremental releases with each
release building on previous functionality. Thorough testing is done to ensure that software quality is
maintained.
Adaptive Software Development (ASD)
Adaptive Software Development is a method to build complex software and system. ASD focuses on human
collaboration and self-organization. ASD “life cycle” incorporates three phases namely:
1. Speculation
2. Collaboration
3. Learning
These are explained as following below.

Adaptive Software Development

1. Speculation:
During this phase project is initiated and planning is conducted. The project plan uses project initiation
information like project requirements, user needs, customer mission statement, etc, to define set of release
cycles that the project wants.
2. Collaboration:
It is the difficult part of ASD as it needs the workers to be motivated. It collaborates communication and
teamwork but emphasizes individualism as individual creativity plays a major role in creative thinking. People
working together must trust each others to
 Criticize without animosity,
 Assist without resentment,
  Work as hard as possible,
 Possession of skill set,
 Communicate problems to find effective solution.
3. Learning:
The workers may have a overestimate of their own understanding of the technology which may not lead to the
desired result. Learning helps the workers to increase their level of understanding over the project.
Learning process is of 3 ways:
1. Focus groups
2. Technical reviews
3. Project postmortem
ASD’s overall emphasis on the dynamics of self-organizing teams, interpersonal collaboration, and individual
and team learning yield software project teams that have a much higher likelihood of success.

Dynamic Systems Development Method (DSDM)

The Dynamic Systems Development technique (DSDM) is an associate degree agile code development
approach that provides a framework for building and maintaining systems. The DSDM philosophy is borrowed
from a modified version of the sociologist principle—80 % of An application is often delivered in twenty
percent of the time it’d desire deliver the entire (100 percent) application.
DSDM is An iterative code method within which every iteration follows the 80% rule that simply enough work
is needed for every increment to facilitate movement to the following increment. The remaining detail is often
completed later once a lot of business necessities are noted or changes are requested and accommodated.
The DSDM tool (www.dsdm.org) could be a worldwide cluster of member companies that put together tackle
the role of “keeper” of the strategy. The pool has outlined AN Agile Development Model, known as the DSDM
life cycle that defines 3 different unvarying cycles, preceded by 2 further life cycle activities:
1. Feasibility Study:
It establishes the essential business necessities and constraints related to the applying to be designed
then assesses whether or not the application could be a viable candidate for the DSDM method.
2. Business Study:
It establishes the use and knowledge necessities that may permit the applying to supply business
value; additionally, it is the essential application design and identifies the maintainability necessities
for the applying.
3. Functional Model Iteration:
It produces a collection of progressive prototypes that demonstrate practicality for the client.
(Note: All DSDM prototypes are supposed to evolve into the deliverable application.) The intent
throughout this unvarying cycle is to collect further necessities by eliciting feedback from users as
they exercise the paradigm.
4. Design and Build Iteration:
It revisits prototypes designed throughout useful model iteration to make sure that everyone has been
designed during a manner that may alter it to supply operational business price for finish users. In
some cases, useful model iteration and style and build iteration occur at the same time.
5. Implementation:
It places the newest code increment (an “operationalized” prototype) into the operational
surroundings. It ought to be noted that:
 (a) the increment might not 100% complete or,
 (b) changes are also requested because the increment is placed into place. In either case,
DSDM development work continues by returning to the useful model iteration activity.
Below diagram describe the DSDM life cycle:
DSDM is often combined with XP to supply a mixed approach that defines a solid method model (the DSDM
life cycle) with the barmy and bolt practices (XP) that are needed to create code increments. additionally, the
ASD ideas of collaboration and self-organizing groups are often tailored to a combined method model.
Scrum (software development)
Scrum is the type of Agile framework. It is a framework within which people can address complex adaptive
problem while productivity and creativity of delivering product is at highest possible values. Scrum
uses Iterative process.
Silent features of Scrum are:
 Scrum is light-weighted framework
 Scrum emphasizes self-organization
 Scrum is simple to understand
 Scrum framework help the team to work together
Lifecycle of Scrum:
Sprint:
A Sprint is a time-box of one month or less. A new Sprint starts immediately after the completion of the
previous Sprint.
Release:
When the product is completed then it goes to the Release stage.
Sprint Review:
If the product still have some non-achievable features then it will be checked in this stage and then the
product is passed to the Sprint Retrospective stage.
Sprint Retrospective:
In this stage quality or status of the product is checked.
Product Backlog:
According to the prioritize features the product is organized.
Sprint Backlog:
Sprint Backlog is divided into two parts Product assigned features to sprint and Sprint planning meeting.
Advantage of using Scrum framework:
 Scrum framework is fast moving and money efficient.
 Scrum framework works by dividing the large product into small sub-products. It’s like a divide
and conquer strategy
 In Scrum customer satisfaction is very important.
 Scrum is adaptive in nature because it have short sprint.
 As Scrum framework rely on constant feedback therefore the quality of product increases in less
amount of time
Disadvantage of using Scrum framework:
 Scrum framework do not allow changes into their sprint.
 Scrum framework is not fully described model. If you wanna adopt it you need to fill in the
framework with your own details like Extreme Programming(XP), Kanban, DSDM.
 It can be difficult for the Scrum to plan, structure and organize a project that lacks a clear
definition.
 The daily Scrum meetings and frequent reviews require substantial resources.

FDD Full Form

FDD stands for Feature-Driven Development. It is an agile iterative and incremental model that focuses on
progressing the features of the developing software. The main motive os feature-driven development is to
provide timely updated and working software to the client. In FDD, reporting and progress tracking is necessary
at all levels.

History
FDD was first applied in the year 1997 on a real-world application by Jeff De Luca for large software
development with specific needs of 15-month and 50 persons and published as a discussion in book Java
Modeling in Color with UML in the year 1999.
FDD Lifecycle
 Build overall model
 Build feature list
 Plan by feature
 Design by feature
 Build by feature
Characteristics of FDD
 Short iterative: FDD lifecycle works in simple and short iterations to efficiently finish the work on
time and gives good pace for large projects.
 Customer focused: This agile practice is totally based on inspection of each feature by client and
then pushed to main build code.
 Structured and feature focused: Initial activities in lifecycle builds the domain model and features
list in the beginning of timeline and more than 70% of efforts are given to last 2 activities.
 Frequent releases: Feature-driven development provides continuous releases of features in the
software and retaining continuous success of the project.
Advantages of FDD
 Reporting at all levels leads to easier progress tracking.
 FDD provides continuous success for larger size of teams and projects.
 Reduction in risks is observed as whole model and design is build in smaller segments.
 FDD provides greater accuracy in cost estimation of the project due to feature segmentation.
Disadvantages of FDD
 This agile practice is not good for smaller projects.
 There is high dependency on lead programmers, designers and mentors.
 There is lack of documentation which can create an issue afterwards.
SPICE (Software Process Improvement and Capability Determination) in software engineering
SPICE (Software Process Improvement and Capability Determination) is an international framework for
assessment of software processes developed jointly by the ISO (International Organization for Standardization)
and the IEC (International Electrotechnical Commission). SPICE is laid out in ISO/IEC 15504. It’s a group of
technical standards documents for the pc software development process and related business management
functions.
The process is assessed to guage methods, tools, and practices, which are wont to develop and test the software.
The aim of process assessment is to spot the areas for improvement and suggest an idea for creating that
improvement. The main focus areas of process assessment are listed below
• Obtaining guidance for enhancing software development and test processes
• Obtaining an independent and impartial review of the process
• Obtaining a baseline (defined as a group of software components and documents that are formerly reviewed
and accepted; that is the idea for further development) for improving quality and productivity of processes.
The functions of SPICE (ISO/IEC 15504) are listed below
• To develop process-rating profiles rather than pass or fail criteria
• To consider the environment during which the assessed process operates
• To facilitate self assessment
 To ensure suitability for all applications and all sizes of organizations.
What is Six Sigma?
Six Sigma is a process that makes use of statistics and data analysis to analyze and reduce errors or defects. In
this process, the purpose is to improve cycle times while reducing manufacturing defects to no more than 3.4
defects per million units or events.
SIS SIGMA is a set of management tools and techniques designed to improve the capability of the business
process by reducing the likelihood of error. Six sigma is a data-driven approach that uses a statistical
methodology for eliminating defects, defect reduction and profits improvement.
The 5 Key Principles of Six Sigma
The concept of Six Sigma has a simple goal – delivering near-perfect goods and services for business
transformation for optimal customer satisfaction (CX).
Goals are achieved through a two-pronged approach:

Six Sigma has its foundations in five key principles:

1. Focus on the Customer
2.Measure the Value Stream and Find Your Problem
3.Get Rid of the Junk
4. Keep the Ball Rolling
5. Ensure a Flexible and Responsive Ecosystem

The Six Sigma Process of the DMAIC method has five phases:
Six Sigma Techniques
The Six Sigma methodology also uses a mix of statistical and data analysis tools such as process mapping and
design and proven qualitative and quantitative techniques, to achieve the desired outcome.

Capability Maturity Model Integration (CMMI)

Capability Maturity Model Integration (CMMI) is a successor of CMM and is a more evolved model that
incorporates best components of individual disciplines of CMM like Software CMM, Systems Engineering
CMM, People CMM, etc. Since CMM is a reference model of matured practices in a specific discipline, so it
becomes difficult to integrate these disciplines as per the requirements. This is why CMMI is used as it
allows the integration of multiple disciplines as and when needed.
Objectives of CMMI :
1. Fulfilling customer needs and expectations.
2. Value creation for investors/stockholders.
3. Market growth is increased.
4. Improved quality of products and services.
5. Enhanced reputation in Industry.
CMMI Representation – Staged and Continuous :
A representation allows an organization to pursue a different set of improvement objectives. There are two
representations for CMMI :
 Staged Representation :
 uses a pre-defined set of process areas to define improvement path.
 provides a sequence of improvements, where each part in the sequence serves as a
foundation for the next.
 an improved path is defined by maturity level.
 maturity level describes the maturity of processes in organization.
 Staged CMMI representation allows comparison between different organizations for
multiple maturity levels.
 Continuous Representation :
 allows selection of specific process areas.
 uses capability levels that measures improvement of an individual process area.
 Continuous CMMI representation allows comparison between different organizations
on a process-area-by-process-area basis.
 allows organizations to select processes which require more improvement.
 In this representation, order of improvement of various processes can be selected which
allows the organizations to meet their objectives and eliminate risks.
CMMI Model – Maturity Levels :
In CMMI with staged representation, there are five maturity levels described as follows :
1. Maturity level 1 : Initial
 processes are poorly managed or controlled.
 unpredictable outcomes of processes involved.
 ad hoc and chaotic approach used.
 No KPAs (Key Process Areas) defined.
 Lowest quality and highest risk.
2. Maturity level 2 : Managed
 requirements are managed.
 processes are planned and controlled.
 projects are managed and implemented according to their documented plans.
 This risk involved is lower than Initial level, but still exists.
 Quality is better than Initial level.
3. Maturity level 3 : Defined
 processes are well characterized and described using standards, proper procedures, and
methods, tools, etc.
 Medium quality and medium risk involved.
 Focus is process standardization.
4. Maturity level 4 : Quantitatively managed
 quantitative objectives for process performance and quality are set.
 quantitative objectives are based on customer requirements, organization needs, etc.
 process performance measures are analyzed quantitatively.
 higher quality of processes is achieved.
 lower risk
5. Maturity level 5 : Optimizing
 continuous improvement in processes and their performance.
 improvement has to be both incremental and innovative.
 highest quality of processes.
 lowest risk in processes and their performance.
CMMI Model – Capability Levels
A capability level includes relevant specific and generic practices for a specific process area that can improve
the organization’s processes associated with that process area. For CMMI models with continuous
representation, there are six capability levels as described below :
1. Capability level 0 : Incomplete
 incomplete process – partially or not performed.
 one or more specific goals of process area are not met.
 No generic goals are specified for this level.
 this capability level is same as maturity level 1.
2. Capability level 1 : Performed
 process performance may not be stable.
 objectives of quality, cost and schedule may not be met.
 a capability level 1 process is expected to perform all specific and generic practices for
this level.
 only a start-step for process improvement.
3. Capability level 2 : Managed
 process is planned, monitored and controlled.
 managing the process by ensuring that objectives are achieved.
 objectives are both model and other including cost, quality, schedule.
 actively managing processing with the help of metrics.
4. Capability level 3 : Defined
 a defined process is managed and meets the organization’s set of guidelines and
standards.
 focus is process standardization.
5. Capability level 4 : Quantitatively Managed
 process is controlled using statistical and quantitative techniques.
 process performance and quality is understood in statistical terms and metrics.
 quantitative objectives for process quality and performance are established.
6. Capability level 5 : Optimizing
 focuses on continually improving process performance.
 performance is improved in both ways – incremental and innovation.
 emphasizes on studying the performance results across the organization to ensure that
common causes or issues are identified and fixed.

Explain the concepts of SLIM estimating model.

It is one of the first algorithmic models for estimating software project costs. It is based on Norden-
Rayleigh function and is commonly used for large projects. SLIM also uses historical data from past
projects for estimation. It also uses and considers other project parameters, characteristics, attributes
and KLOC for its estimation calculation.

Total Life cycle effort (years) = ( LOC / ( C * t4/3 )) * 3

t is development and C is technology constant which is determined from tools, language, methods, quality
features etc. This make SLIM dependent on C which is a disadvantage.

Advantages of SLIM estimating model.

Advantages of SLIM estimating model:

1. It provides a set of software development management tools that support the entire program life cycle.
2. Offers value-added planning.
3. It simplifies strategic decision making.
4. Supports "what-if" analysis.
5. It allows report and graph generation.
6. To consider the development constraints on both the cost and effort linear programming is used.
7. It has a few parameters which are required to generate an estimate over the COCOMO'81 and
COCOMO'II.
Disadvantages:

a. Works best on large projects.

b. The software size needs ot be estimated in advance in order to use this model.
c. Estimates are extremely sensitive to the technology factor.
d. Model is also sensitive to size estimate.
e. Tool is considered to be fairly complex.
f. It works for Waterfall life cycle that doesn’t cover up spiral model.

PRODUCT LIFECYCLE MANAGEMENT

Product lifecycle management (PLM) is the process of managing a product’s lifecycle from inception, through
design and manufacturing, to sales, service, and eventually retirement.
PLM fundamentals
In an age where innovation is key to business survival and success, PLM plays a critical role in helping
manufacturers develop the next generation of products, at a lower cost, and with a faster time to market. While
PLM can also be interpreted as a business strategy, three fundamentals impact the way teams work and the
ability for organizations to grow and thrive:

 Universal, secure, managed access and use of product definition information

 Maintenance of the integrity of that product definition and related information throughout the life of the
product
 Management and maintenance of the business processes used to create, manage, disseminate, share, and
use the information
The five phases of product development
There are many different ways to describe the phases of product development and no one industry standard.
However, the phases below represent a typical development cycle.

1. Concept and design: The ideation phase, where a product’s requirements are
defined based on factors including competitor analysis, gaps in the market, or
customer needs.
2. Develop: The detailed design of the product will be created, along with any
necessary tool designs. This phase includes validation and analysis of the
planned product, as well as prototype development and piloting in the field.
This generates vital feedback on how the product is used and what further
refinements are needed.
3. Production and launch: Feedback from the pilot is used to adjust the design
and other components to produce a market-ready version. The production of
the new product is scaled – followed by launch and distribution to the market.
4. Service and support: Following the launch of the new product, the period of
time when service and support is offered.
5. Retirement: At the end of the product’s lifecycle, its withdrawal from the
market must be managed – along with any retrials or absorption into new
concept ideas.

What is PDM?
Product data management (PDM) is a system for managing design data and engineering processes in one central
location. Engineering teams use PDM software to organise product-related information, track revisions,
collaborate, manage change orders, generate Bills of Materials (BOMs) and more. With a single source for
project data, engineers save time and avoid mistakes.
Benefits of PDM
According to a Tech-Clarity report, world-class manufacturers are 30 per cent more likely to use PDM or
product lifecycle management (PLM) to manage their design data.
Improved design workflows
Experience direct CAD integration, fast data searching, easy file replacement and reuse, and safe
simultaneous access to data. With PDM, your design workflow has never been smoother.
Enhanced collaboration
Share 2D or 3D views of your work with others (even those outside your company's firewall) and get
comments and feedback directly inside your product.
Streamlined processes
Get automated engineering change order, revision control, BOM management and more. Keep your
engineering processes under control with PDM software.
Shared knowledge
You don't have to reinvent the wheel. Instead, leverage existing design data. Easily access and configure
files you want to replace, reuse or copy to use in new designs.
Drive Engineering Efficiencies
Increase Global Collaboration
Improve Data Quality
Greater Document Control
Better IP Protection
Decrease Time Searching for Data

Key Product Data Management Capabilities

Maintain legacy information and manage new product data, providing full digital traceability. Ensure everyone
is using the right version for development, analysis, manufacturing, and procurement.
 Control CAD data: Easy HTML UI and CAD tool integrations including Creo, Creo Elements/Direct
Modeling/Drafting, CATIA V5, NX, SolidWorks, Inventor, AutoCAD
 Secure collaboration: Fast and secure role-based access to product data by disbursed teams and value
chain partners
 Role-based apps: Self-service, out-of-the-box role and task-based apps that provide contextualized
information for non-CAD users
 Release and change process: Simple workflow capabilities to route documents for approval and/or
review
 ECAD data management: Synchronize ECAD libraries with PLM Parts and MCAD models (Zuken,
Cadence, Altium and more). Provide easy and accurate enterprise access to complex electronic design
data.
 Generate viewables: Publishing of CAD to lightweight viewables for review and consumption outside
of engineering
 Multi-CAD editing: Edit product data within major CAD systems using check-in check-out,
downloads, family tables, virtual components, and save-as
 Lifecycle management: Control CAD data status from WIP (work-in-progress) to release
 Microsoft Office integration: Initiate promotion, version comparison, and link to detailed information
in GUI and web browsers
 Create new documents: Drag and drop using Windows File Explorer or browse the PDM system as a
folder structure
1. Upchain
2. Autodesk Vault
3. Solidworks PDM
4. Siemens Teamcenter
5. OpenBOM
What is change management?
Change management is a systematic approach to dealing with the transition or transformation of an
organization's goals, processes or technologies. The purpose of change management is to implement strategies
for effecting change, controlling change and helping people to adapt to change.
How does change management work?
To understand how change management works, it helps to apply its concepts and tools to specific areas of
business. Below are examples of how change management works for project management, software
development and IT infrastructure.
Change management for project management
Change management plays an important role in project management because each change request must be
evaluated for its impact on the project. Project managers, or the senior executives in charge of change control,
must examine how a change in one area of the project could affect other areas and what impact that change
could have on the project as a whole. Project areas that change control experts should pay particular attention to
include the following:
 Scope. Change requests must be evaluated to determine how they will affect the project scope.
 Schedule. Change requests must be assessed to determine how they will alter the project schedule.
 Costs. Change requests must be evaluated to determine how they will affect project costs. Labor is
typically the largest expense on a project, so overages on completing project tasks can quickly drive
changes to the project costs.
 Quality. Change requests must be evaluated to determine how they will affect the quality of the
completed project. An acceleration of the project schedule, in particular, can affect quality as defects
can occur if work is rushed.
 Human resources. Change requests must be evaluated to determine if additional or specialized
labor is required. When the project schedule changes, the project manager may lose key resources to
other assignments.
 Communications. Approved change requests must be communicated to the appropriate
stakeholders at the appropriate time.
 Risk. Change requests must be evaluated to determine what risks they pose. Even minor changes
can have a domino effect on the project and introduce logistical, financial or security risks.
Procurement. Changes to the project may affect procurement of materials and contract labor.
Change management for software development
In software development project management, change management strategies and tools help developers manage
changes to code and its associated documentation and enable chief information officers (CIOs) to keep projects
on track. Agile software development environments encourage changes that are made to satisfy requirements
and/or adjust the user interface. Change is not addressed in the middle of an iteration, however; changes are
scheduled as stories or features for future iterations.

Version control software tools assist with documentation and prevent more than one person from making
changes to code at the same time. Such tools have capabilities to track changes and back out changes when
necessary.
Change management for IT infrastructure
Change management tools are also used to track changes made to an IT department's hardware infrastructure.
As with other types of change management, standardized methods and procedures ensure every change made to
the infrastructure is assessed, approved, documented, implemented and reviewed in a systematic manner.

Changes made to hardware settings are also referred to as configuration management (CM). Technicians use
CM tools to review the entire collection of related systems and verify the effects that a change in one system has
on other systems.
Types of organizational change
Change management can be used to manage many types of organizational change. The three most common
types are the following:
1. Developmental change. Any organizational change that improves on previously established
processes and procedures.
2. Transitional change. Change that moves an organization away from its current state to a new state
to solve a problem, such as implementing a merger and acquisition or automating a task or process.
3. Transformational change. Change that radically and fundamentally alters the culture and operation
of an organization. In transformational change, the end result might not be known. For example, a
company may pursue entirely different products or markets.
Popular models for managing change
Best practice models can provide guiding principles and help managers align the scope of proposed changes
with available digital and nondigital tools. Popular models include the following:
 ADKAR. The ADKAR model, created by Prosci founder Jeff Hiatt, consists of five sequential steps:
1. Awareness of the need for change;
2. Desire to participate and support the change;
3. Knowledge on how to change;
4. Ability to implement desired skills and behaviors; and
5. Reinforcement to sustain the change.
 Bridges' Transition Model. Change consultant William Bridges' model focuses on how people
adjust to change. The model features three stages: a stage for letting go, a stage of uncertainty and
confusion and a stage for acceptance. Bridges' model is sometimes compared to the Kübler-Ross
five stages of grief -- denial, anger, bargaining, depression, and acceptance.
 IT Infrastructure Library (ITIL). The ITIL framework offers detailed guidance for managing
change in IT operations and infrastructure. It is owned by Axelos, a joint venture between Capita
and the U.K. Cabinet Office.
 Kotter's 8-Step Process for Leading Change. Harvard University professor John Kotter's model
has eight steps:
1. Create a sense of urgency.
2. Build a guiding coalition.
3. Form a strategic vision and initiatives.
4. Enlist a volunteer army.
5. Enable action by removing barriers.
 6. Generate short-term wins.
7. Sustain acceleration.
8. Institute change.
 Lewin's Change Management Model. Psychologist Kurt Lewin created a three-step framework
that is also referred to as the Unfreeze-Change-Refreeze
 McKinsey 7-S. Business consultants Robert H. Waterman Jr. and Tom Peters designed a model to
look holistically at seven factors that affect change:
1. shared values
2. strategy
3. structure
4. systems
5. style
6. staff
7. skills

What are the benefits of change management?

As laid out in other sections of this definition, taking a structured approach to change management helps
organizations mitigate disruption, reduce costs, reduce time to implementation, improve leadership skills, drive
innovation and improve morale.

In addition, here are some ways that change management can help add structure to IT and operations:
 improved documentation of enterprise systems;
 greater alignment between suggested change and what gets implemented;
 better starting point for automation initiatives;
 understanding of why systems were made;
 ability to reverse-engineer changes made to existing business processes and infrastructure; and
 better ability to identify what can be safely eliminated or updated.
What are the challenges of change management?
Companies developing a change management program from the ground up often face daunting challenges. In
addition to a thorough understanding of company culture, the change management process requires an accurate
accounting of the systems, applications and employees to be affected by a change. Additional change
management challenges include the following:
 Resource management. Managing the physical, financial, human, informational, and intangible
assets and resources that contribute to an organization's strategic plan becomes increasingly difficult
when implementing change.
 Resistance. The executives and employees who are most affected by a change may resist it. Since
change may result in unwanted extra work, ongoing resistance is common. Transparency, training,
planning and patience can help quell resistance and improve overall morale.
  Communication. Companies often fail to consistently communicate change initiatives or include
employees in the process. Change-related communication requires an adequate number of messages,
the involvement of enough stakeholders to get the message out and multiple communication
channels.
 New technology. The application of new technologies can disrupt an employee's entire workflow.
Companies can improve adoption of new technology by creating a network of early learners who
champion the new technology to colleagues.
 Multiple points of view. In any change initiative, success factors differ for people based on their
roles in the organization and incentives. Managing these various priorities is challenging.
 Scheduling issues. Deciding whether a change program will be long or short term and clearly
defining milestone deadlines are complicated. Some organizations believe that shorter change
programs are most effective. Others believe a more gradual approach to change reduces resistance
and errors.

UNIT III RISK MANAGEMENT

Perspectives of Risk Management - Risk Definition – Risk Categories – Risk Assessment: Approaches,
techniques and good practices – Risk Identification / Analysis / Prioritization – Risk Control (Planning /
Resolution / Monitoring) – Risk Retention – Risk Transfer - Failure Mode and Effects Analysis (FMEA)
– Operational Risks – Supply Chain Risk Management.

What is Risk Management?

Risk management is the process of identifying, assessing, and prioritizing the risks to minimize, monitor, and
control the probability of unfortunate events.

Risk Management Process:

Risk Management process can be easily understood with use of the following workflow:

Risk Management Practices:

 Software Risk Evaluation (SRE)
 Continuous Risk Management (CRM)
 Team Risk Management (TRM)

Risk Management

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

There are three main classifications of risks which can affect a software project:
 1. Project risks
2. Technical risks
3. Business risks

1. Project risks: Project risks concern differ forms of budgetary, schedule, personnel, resource, and customer-
related problems. A vital project risk is schedule slippage. Since the software is intangible, it is very tough to
monitor and control a software project. It is very tough to control something which cannot be identified. For any
manufacturing program, such as the manufacturing of cars, the plan executive can recognize the product taking
shape.

2. Technical risks: Technical risks concern potential method, implementation, interfacing, testing, and
maintenance issue. It also consists of an ambiguous specification, incomplete specification, changing
specification, technical uncertainty, and technical obsolescence. Most technical risks appear due to the
development team's insufficient knowledge about the project.

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

Other risk categories

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

Principle of Risk Management

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

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

Risk Assessment

The objective of risk assessment is to division the risks in the condition of their loss, causing potential. For risk
assessment, first, every risk should be rated in two methods:
o The possibility of a risk coming true (denoted as r).
o The consequence of the issues relates to that risk (denoted as s).

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

p=r*s

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

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

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

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

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

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

It is not possible to make an exact, the numerical estimate of the probability and seriousness of each risk. Instead,
you should authorize the risk to one of several bands:
1. The probability of the risk might be determined as very low (0-10%), low (10-25%), moderate (25-50%),
high (50-75%) or very high (+75%).
2. The effect of the risk might be determined as catastrophic (threaten the survival of the plan), serious
(would cause significant delays), tolerable (delays are within allowed contingency), or insignificant.

Risk Control

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

There are three main methods to plan for risk management:

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

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

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

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

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

For each of the risks, you have to think of the behavior that you may take to minimize the disruption to the plan
if the issue identified in the risk occurs.
You also should think about data that you might need to collect while monitoring the plan so that issues can be
anticipated.

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

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

Types of Project Risks

At the project level, risks can come from financial decisions, project management strategies, project
performance, or external sources. These four risk types have varying consequences based on severity. It is
important to consider all four in your risk mitigation strategy.

These are the four types of project-level risks:

 Financial Risks: Financial risks involve a project’s monetary factors. These might include the rising
costs of materials, unrealistic budgets, higher-than-expected time or labor requirements, lower-than-
expected sales numbers, or the failure to secure sufficient funding.
 Strategic Risks: Strategic risks involve the strategies chosen to complete a project. These might include
your project management methodology, project planning techniques, daily operations, company culture,
employee satisfaction and retention rates, project dependencies, or investment in technology.

“The risks you might encounter can vary greatly in the chaos of our culture and environment,” says
Donald Bloom, the CEO of Prime Retail Services, “but the greatest risks each company faces are the
actions of the people in project authority. Their training and attention to planning a project completely
and executing according to the company processes is the cornerstone for success.”

 Performance Risks: Performance risks involve the overall project performance. These might include
unclear expectations for deliverables, undefined KPIs, outdated market research, or underperforming
product lines.

“Some projects have emerging requirements, meaning there is no way to get all the requirements at the
beginning of the project because people are still figuring out what they want,” explains Angela
Druckman, Owner of The Druckman Company. Projects with clear guidelines and requirements will run
into fewer performance risks than those without them.

 External Risks: External risks come from less predictable outside sources. External risks might affect
performance and results at the project or business level, depending on their severity. These might
include employee illness, major weather events or emergencies, legal decisions, market volatility, and
supply chain risks.

REQUIREMENTS TECHNIQUES
There are five basic techniques of risk management:
 Avoidance
 Retention
 Spreading
 Loss Prevention and Reduction
 Transfer (through Insurance and Contracts)
Avoidance: Many times it is not possible to completely avoid risk but the possibility should not be
overlooked. For example, at the height of a thunderstorm, Physical Plant may not release vehicles for travel
until the weather begins to clear, thus avoiding the risk of auto accidents during severe weather. Some
buildings on campus have had repeated water problems in some areas. By not allowing storage of records or
supplies in those areas, some water damage claims may be avoided.
Retention: At times, based on the likely frequency and severity of the risks presented, retaining the risk or a
portion of the risk may be cost-effective even though other methods of handling the risk are available. For
example, the University retains the risk of loss to fences, signs, gates and light poles because of the difficulty
of enumerating and evaluating all of these types of structures. When losses occur, the cost of repairs is
absorbed by the campus maintenance budget, except for those situations involving the negligence of a third
party. Although insurance is available, the University retains the risk of loss to most University personal
property.
Spreading: It is possible to spread the risk of loss to property and persons. Duplication of records and
documents and then storing the duplicate copies in a different location is an example of spreading risk. A
small fire in a single room can destroy the entire records of a department's operations. Placing people in a
large number of buildings instead of a single facility will help spread the risk of potential loss of life or injury.
Loss Prevention and Reduction: When risk cannot be avoided, the effect of loss can often be minimized in
terms of frequency and severity. For example, Risk Management encourages the use of security devices on
certain audio visual equipment to reduce the risk of theft. The University requires the purchase of health
insurance by students who are studying abroad, so that they might avoid the risk of financial difficulty, should
they incur medical expenses in another country.
Transfer: In some cases risk can be transferred to others, usually by contract. When outside organizations use
University facilities for public events, they must provide evidence of insurance and name the University as an
additional insured under their policy, thereby transferring the risk of the event from the University to the
facility user. The purchase of insurance is also referred to as a risk transfer since the policy actually shifts the
financial risk of loss, contractually, from the insured entity to the insurance company. Insurance should be the
last option and used only after all other techniques have been evaluated.
Contracts: Often vendors and service providers will attempt through a contract to release themselves from all
liability for their actions relating to the contract. These are often referred to as "hold harmless or
indemnification" clauses. Due to the complexity of interpreting these provisions, the President has
delegated contracting authority for the University solely to staff in Contracts & Procurement. The
Office of University Risk Management reviews contracts and agreements as requested by Contracts &
Procurement to identify and assess risks, evaluate insurance standards, and review hold harmless and
indemnification provisions. The Chancellor's Office requires that the University obtain in most instances not
only a Certificate of Insurance, but also an Endorsement. Collecting these documents is often the most time
consuming aspect of the contracting process.

What Is Risk Analysis?

Risk analysis is the process that figures out how likely risk will arise in a project. It studies the uncertainty of
potential risks and how they would impact the project in terms of schedule, quality and costs if, in fact, they
were to show up. Two ways to analyze risk are quantitative and qualitative. But it’s important to know that risk
analysis is not an exact science, so it’s important to track risks throughout the project life cycle.
Types of Risk Analysis

There are two main types of risk analysis, qualitative and quantitative risk analysis. Let’s learn about these two
approaches.
Qualitative Risk Analysis
The qualitative risk analysis is a risk assessment done by experts on the project teams, who use data from past
projects and their expertise to estimate the impact and probability value for each risk on a scale or a risk matrix.

The scale used is commonly ranked from zero to one. That is, if the likelihood of the risk happening in your
project is .5, then there is a 50 percent chance it will occur. There is also an impact scale, which is measured
from one to fine, with five being the most impact on the project. The risk will then be categorized as either
source- or effect-based.

Once risks are identified and analyzed, a project team member is designated as a risk owner for each risk.
They’re responsible for planning a risk response and implementing it.

Qualitative risk analysis is the base for quantitative risk analysis, and it’s beneficial because not only do you
reduce uncertainty in the project, but you also focus mostly on high-impact risks, for which you can assign a
risk owner and plan out an appropriate risk response. Get started with qualitative risk analysis with our free risk
assessment template.
Quantitative Risk Analysis

By contrast, quantitative risk analysis is a statistical analysis of the effect of those identified risks on the overall
project. This helps project managers and team leaders to make decisions with reduced uncertainty and supports
the process of controlling risks.

Quantitative risk analysis counts the possible outcomes for the project and figures out the probability of still
meeting project objectives. This helps with decision-making, especially when there is uncertainty during the
project planning phase. It helps project managers create cost, schedule or scope targets that are realistic.

The Monte Carlo simulation is an example of a quantitative risk analysis tool. It’s a probability technique that
uses a computerized method to estimate the likelihood of a risk. It’s used as input for project
management decision-making.
Risk Analysis Methods

There are several risk analysis methods that are meant to help managers through the analysis and decision-
making process. Some of these involve the use of risk analysis tools such as charts and documents. Let’s dive
into these risk analysis methods and how they can help you.
Bow Tie Analysis

This qualitative risk analysis method is used to identify causes and consequences for all potential project risks.
The project management team must first identify risks that might affect the project and then think about causes,
consequences and more importantly, a risk mitigation strategy for them. It’s a very versatile method that can be
used in any industry.
Risk Analysis Matrix

The risk analysis matrix assesses the likelihood and the severity of risks, classifying them by order of
importance. It’s main purpose is to help managers prioritize risks and create a risk management plan that has the
right resources and strategies to properly mitigate risks. Risk likelihood is measured on a relative scale, not a
statistical one, which makes it a qualitative risk analysis tool.
Risk Register
A risk register is a crucial project management tool to document project risks. It’s a document that lists all the
potential risks that could occur during the project execution phase, as well as critical information about them.

It’s meant to be used as an input for the risk management plan, which describes who’s responsible for those
risks, the risk mitigation strategies and the resources needed. Creating a risk register usually involves several,
reliable information sources such as the project team, subject matter experts and historical data.
SWIFT Analysis

SWIFT stands for Structured What If Technique. It’s a risk analysis method that focuses on identifying
potential risks associated with changes made to a project plan. As its name suggests, team members have to
come up with any “what if” questions they can to find out all the potential risks that could arise.
Risk Analysis Templates

There are several quantitative and qualitative risk analysis methods and that can be confusing. On top of that
there are several tools that can be used for different purposes. For those reasons, we’ve prepared some free risk
analysis templates to help you through the risk analysis process.
Risk Register Template

This risk register template has everything you need to keep track of all the potential risks that might affect your
project as well as their probability, impact, status and more.

Risk Analysis Matrix Template

This risk matrix template lets you visualize all your project risks in one color-coded graph to classify them by
likelihood and severity. This will allow you to better understand what are the most critical risks for your project.

Risk Analysis Examples

So let’s look at where and when the risk analysis is done. Well, if we look at the project management process
groups, the planning process is where we start looking at the risk, and it’s done throughout the entire project. So
we develop our risk management plan, identify the risks, and those are captured in our risk register.

So as a reminder, the risk register identifies all the risks, the impacts, the risk response, and the risk level. We’re
ultimately looking at what the potential impacts to the activity resource estimates, the activity duration
estimates, possibly the schedule, the cost estimates, budgets, quality, and even the procurements.

So when we take the risk register, then we take those items and that’s where we do the detailed analysis. We do
that in two parts. In the first part, we perform a qualitative risk analysis, and there what we’re doing is that’s a
process of prioritizing the risk for further analysis or action, depending upon the probability and the impact of
those risks. The benefit of that is it helps to reduce the level of uncertainty of those risks on the project and
allows us to focus on the high priority risk.

The second piece is performing the quantitative risk analysis, and what that is, it’s a process for numerically
analyzing the effect of those risks on the project. The benefit of that is it helps support decision-making to
reduce the project uncertainty. Again, that can help us, number one, plan the risk responses and control those
risks.
Benefits of Risk Analysis

To understand risk analysis, note the importance of examining risk in methodical detail. Why? There are several
reasons.
 Avoid potential litigation
 Address regulatory issues
 Comply with new legislation
 Reduce exposure
 Minimize impact
 Risk analysis is an important input for decision-making during all the stages of the
project management cycle

Project managers who have some experience with risk management in projects are a great resource. We culled
some advice from them, such as:
 There’s no lack of information on risk
 Much of that information is complex
 Most industries have best practices
 Many companies have risk management framework
 Risk analysis is done in extremes
Risk Identification & Management

People frequently confuse risk analysis with risk identification and risk management. Let’s clear these project
management concepts up before we continue.
What Is Risk Identification?

Risk identification is also a risk management process, but in this case, it lists all the potential project risks and
their characteristics would be. If this sounds like a risk register, that’s because your findings are collected there.
This information will then be used for your risk analysis. Though this process starts at the beginning of the
project planning phase, it’s an iterative process and continues throughout the project life cycle.
What Is Risk Management?

Finally, risk management is the overall process that project managers use to minimize and manage risk. It
includes risk identification, risk assessment, risk response development and risk response control.

What Is Risk Control?

Risk control is the set of methods by which firms evaluate potential losses and take action to reduce or
eliminate such threats. It is a technique that utilizes findings from risk assessments, which involve identifying
potential risk factors in a company's operations, such as technical and non-technical aspects of the business,
financial policies and other issues that may affect the well-being of the firm.
Risk control also implements proactive changes to reduce risk in these areas. Risk control thus helps
companies limit lost assets and income. Risk control is a key component of a company's enterprise risk
management (ERM) protocol.

How Risk Control Works

Modern businesses face a diverse collection of obstacles, competitors, and potential dangers. Risk control is a
plan-based business strategy that aims to identify, assess, and prepare for any dangers, hazards, and other
potentials for disaster—both physical and figurative—that may interfere with an organization's operations and
objectives. The core concepts of risk control include:
  Avoidance is the best method of loss control. For example, after discovering that a chemical used in
manufacturing a company’s goods is dangerous for the workers, a factory owner finds a safe substitute
chemical to protect the workers’ health.
 Loss prevention accepts a risk but attempts to minimize the loss rather than eliminate it. For example,
inventory stored in a warehouse is susceptible to theft. Since there is no way to avoid it, a loss
prevention program is put in place. The program includes patrolling security guards, video cameras and
secured storage facilities. Insurance is another example of risk prevention that is outsourced to a third
party by contract.
 Loss reduction accepts the risk and seeks to limit losses when a threat occurs. For example, a company
storing flammable material in a warehouse installs state-of-the-art water sprinklers for minimizing
damage in case of fire.
 Separation involves dispersing key assets so that catastrophic events at one location affect the business
only at that location. If all assets were in the same place, the business would face more serious issues.
For example, a company utilizes a geographically diverse workforce so that production may continue
when issues arise at one warehouse.
 Duplication involves creating a backup plan, often by using technology. For example, because
information system server failure would stop a company’s operations, a backup server is readily
available in case the primary server fails.
 Diversification allocates business resources for creating multiple lines of business offering a variety of
products or services in different industries. A significant revenue loss from one line will not result in
irreparable harm to the company’s bottom line. For example, in addition to serving food, a restaurant
has grocery stores carry its line of salad dressings, marinades, and sauces.

What is Risk Transfer?

Risk transfer refers to a risk management technique in which risk is transferred to a third party. In other words,
risk transfer involves one party assuming the liabilities of another party. Purchasing insurance is a common
example of transferring risk from an individual or entity to an insurance company.

Methods of Risk Transfer

There are two common methods of transferring risk:

1. Insurance policy

As outlined above, purchasing insurance is a common method of transferring risk. When an individual or entity
is purchasing insurance, they are shifting financial risks to the insurance company. Insurance companies
typically charge a fee – an insurance premium – for accepting such risks.

2. Indemnification clause in contracts

Contracts can also be used to help an individual or entity transfer risk. Contracts can include
an indemnification clause – a clause that ensures potential losses will be compensated by the opposing party. In
simplest terms, an indemnification clause is a clause in which the parties involved in the contract commit to
compensating each other for any harm, liability, or loss arising out of the contract.

For example, consider a client that signs a contract with an indemnification clause. The indemnification clause
states that the contract writer will indemnify the client against copyright claims. As such, if the client receives a
copyright claim, the contract writer would (1) be obliged to cover the costs related to defending against the
copyright claim, and (2) be responsible for copyright claim damages if the client is found liable for copyright
infringement.
Risk Transfer by Insurance Companies

Although risk is commonly transferred from individuals and entities to insurance companies, the insurers are
also able to transfer risk. This is done through an insurance policy with reinsurance companies. Reinsurance
companies are companies that provide insurance to insurance firms.

Similar to how individuals or entities purchase insurance from insurance companies, insurance companies can
shift risk by purchasing insurance from reinsurance companies. In exchange for taking on this risk, reinsurance
companies charge the insurance companies an insurance premium.

Risk Transfer vs. Risk Shifting

Risk transfer is commonly confused with risk shifting. To reiterate, risk transfer is passing on (“transferring”)
risk to a third party. On the other hand, risk shifting involves changing (“shifting”) the distribution of risky
outcomes rather than passing on the risk to a third party.

For example, an insurance policy is a method of risk transfer. Purchasing derivative contracts is a method of
risk shifting.
What is Risk Retention?

Risk retention is the practice of setting up a self-insurance reserve fund to pay for losses as they occur,
rather than shifting the risk to an insurer or using hedging instruments. A business is more likely to engage
in risk retention when it determines that the cost of self-insurance is lower than the insurance payments or
hedging costs required to transfer the risk to a third party. A large deductible on an insurance policy is
also a form of risk retention.
Failure Modes and Effects Analysis (FMEA) Tool
Institute for Healthcare Improvement
Boston, Massachusetts, USA
Failure Modes and Effects Analysis (FMEA) is a systematic, proactive method for evaluating a process to
identify where and how it might fail and to assess the relative impact of different failures, in order to identify
the parts of the process that are most in need of change. FMEA includes review of the following:

 Steps in the process

 Failure modes (What could go wrong?)
 Failure causes (Why would the failure happen?)
 Failure effects (What would be the consequences of each failure?)
Teams use FMEA to evaluate processes for possible failures and to prevent them by correcting the processes
proactively rather than reacting to adverse events after failures have occurred. This emphasis on prevention may
reduce risk of harm to both patients and staff. FMEA is particularly useful in evaluating a new process prior to
implementation and in assessing the impact of a proposed change to an existing process.
WHEN TO USE FMEA

 When a process, product, or service is being designed or redesigned, after quality function deployment
(QFD)
 When an existing process, product, or service is being applied in a new way
 Before developing control plans for a new or modified process
 When improvement goals are planned for an existing process, product, or service
 When analyzing failures of an existing process, product, or service
 Periodically throughout the life of the process, product, or service
 What Is Operational Risk Management?

 Operational risk is the risk of loss resulting from ineffective or failed internal processes, people,
systems, or external events that can disrupt the flow of business operations. The losses can be directly or
indirectly financial. For example, a poorly trained employee may lose a sales opportunity, or indirectly a
company’s reputation can suffer from poor customer service.

Examples of operational risk include:

 Employee conduct and employee error
 Breach of private data resulting from cybersecurity attacks
 Technology risks tied to automation, robotics, and artificial intelligence
 Business processes and controls
 Physical events that can disrupt a business, such as natural catastrophes
 Internal and external fraud


SUPPLY CHAIN RISK MANAGEMENT
supply chain risk management (SCRM) is the process of identifying, assessing, and mitigating the risks of an
organization’s supply chain. Implementing global supply chain risk management strategies can help an
enterprise operate more efficiently, reduce costs, and enhance customer service.
 Supply chain management refers to how organizations manage the flow of their goods, including all the
processes involved in transforming raw materials the organization consumes into finished products or
services the organization offers. It includes planning and managing sourcing, procurement, conversion,
and logistics management functions.
Internal supply chain risks include risk events caused by:

 Disruptions of internal operations;

 Changes in management, key personnel, and business processes;
 Not putting contingencies in place in case something goes wrong;
 Not implementing proper cybersecurity policies and controls to protect against cyber-attacks and data
breaches;
 Not complying with environmental regulations or labor laws;
 Not having the goods to meet customers’ needs.
External supply chain risks include risk events caused by:

 Unpredictable or misunderstood customer demand;

 Interruptions to the flow of products, including raw materials, parts, and finished goods;
 Social, governmental, and economic factors, including the threat of terrorism;
 Supplier risk management, including concerns related to a supplier’s physical facility and regulatory
compliance;
 Natural disasters, such as earthquakes, hurricanes, and tornadoes.

Supply Chain Risk Examples

Supply chain risk includes a wide variety of problems with vendors, suppliers, shipping agents, resellers, and
other third parties. Those issues can disrupt production, operations, sales, and projects. They can also lead to
quality issues, accountability, and reputational conflicts. Here are some examples that expose supply risk:
Price Increases
Rising prices are caused by supply, demand, currency instability, and customs tariffs. Volatility in prices can
jeopardize financial projections and profitability of the business.
Shortages
These can arise from lacking a component, material, or part needed to produce a finished product. Shortages
may be short-term availability issues or long-term if the supplier has discontinued the required items.
Supplier Relationships
If litigation or some other dispute ruptures your relationship with a supplier, the scenario will lead you to
replace the supplier.
Quality Failures
Quality failures occur when shipments of certain parts do not meet the given specifications or perform as
expected.
Delivery Failures
Carrier and logistical issues can result in late deliveries, damaged packages, or lost shipments.
Supply Shocks
Sudden worldwide or industry-wide drop in supply due to events such as a pandemic, natural disaster, labor
dispute, or trade embargo.