Feasibility Analysis
Nupul Kukreja
Supannika Koolmanojwong
24th September 2012
1
Agenda
• Possibility vs. Feasibility
• Feasibility Analysis (What/Why?)
• Types of Feasibility Analysis (How?)
– Business Feasibility
– Technology Feasibility
– Operational/Process Feasibility
• Risk Assessment and Feasibility Analysis
• Various Levels of Feasibility Analysis
2
Possibility vs. Feasibility
“Everything is possible given enough
time and money”
• Usually not enough time or enough money 
• Businesses exist for making a profit – along
with creating jobs, fun, social responsibility
etc. Primary purpose – profit $$
• Time and money are precious and businesses
must decide if they are “worth spending” on
something before actually spending it!
3
Feasibility Analysis – Why?
• Must know what is doable within given
constraints – best bang for the buck
• Not everything is “feasible” with respect to the
constraints
Feasible
Region
Region of
Possibility
Constraints
• Must know “how much”, “when” and “where” to
spend time and/or money (optimum not always
possible. Thousands of unknowns!)
4
Feasibility Analysis – Why? (Cont’d)
• A commercial customer specified a natural language interface for an
otherwise simple query system. The project was cancelled after the
natural language interface caused a factor-of-5 overrun in project
budget and schedule
• A commercial customer specified a project to fully digitize a set of
corporate records via scanning and optical character recognition. The
resulting cost escalated by a factor of 10 after if was discovered that
the records included many hard-to-capture tables, charts, and graphs.
• A government customer specified a 1-second response time for an
extremely large transaction processing system. Meeting this
requirement involved a custom architecture and a $100M project. The
customer authorized a prototyping activity, which determined that 90%
of the transactions needed only 4-second response time. With this
performance requirement, a commercial-technology-based solution
was achieved for $30M
5
Feasibility Analysis/Study* – What?
• Feasibility studies aim to objectively and
rationally uncover:
– The strengths and weaknesses of an existing
business or proposed venture
– Opportunities and threats as presented by the
environment
– The resources required to carry through
– And ultimately the prospects for success
• Cost vs. Benefits – simplest criteria to gauge
feasibility
*Taken from: http://en.wikipedia.org/wiki/Feasibility_study
6
Feasibility Analysis – When?
• Generally done before initiating project or
technical development (usually continues
towards end of SDLC)
• Need to look at various aspects of the “problem”
to ascertain feasibility
• Common Factors to look at: TELOS*
–
–
–
–
–
Technology Feasibility – is it technically possible?
Economic Feasibility – can we afford it? Profitable?
Legal Feasibility – is it legal? 
Operational Feasibility – how well is problem solved?
Schedule Feasibility – is it doable in given time?
*Taken from: http://en.wikipedia.org/wiki/TELOS_(project_management)
7
Feasibility Analysis – Other Factors
• Depending on the type/scope of feasibility
analysis various other factors may be analyzed
– Industry & Market Feasibility
– Management Team (is the team capable of
executing the project)
– Cultural Feasibility
– Resource Feasibility
– Financial Feasibility
– Real Estate Feasibility etc.
8
Feasibility Analysis – Output
• Usually a “Yes/No” decision backed by
evidence/rationale for decision
• Provides “level of confidence” in executing the
project and not a guarantee of success
• Feasibility Analysis is based on “estimates”
which in turn should be based on prior
available data or through prototyping
• Project may be declared “infeasible” after
uncovering details and a prior “feasible”
decision
9
Feasibility Analysis in 577
• Provide Feasibility Evidence Description ascertaining:
– Business Feasibility: Perform Cost vs. Benefits analysis to
gauge viability of concept
– Technology Feasibility
• Architectural Feasibility:
– Level of Service Feasibility – how does the design satisfy LOS
requirements?
– Capability Feasibility – how does design satisfy/cover capability
requirements?
– Evolutionary Feasibility – (how) is the design capable of satisfying
evolutionary requirements?
• NDI/NCS Interoperability – how well do the NDIs/NCSes
interoperate?
– Process Feasibility: Why follow a particular process and
how does it help with execution?
– Schedule Feasibility: Is the project sufficiently scoped to be
doable within 1-2 semesters? (COCOMO, WinWin,
prototyping)
10
Feasibility Analysis – How?
11
Business Feasibility
• Perform Return on Investment (ROI) Analysis
based on costs/benefits of project (i.e.
program )
• ROI = f(cost, benefits*)
– Analyze ‘cost’ factors
– Analyze ‘benefits’
– Conceptually if: Benefits/Cost > 1  Feasible
• But where do the costs/benefits come from?
*benefits ≡ revenue
12
Augmenting The Program Model
Assumptions: Under what assumptions is this model true?
Stakeholders
(Who)
Initiatives
(What)
Value Propositions
(Why)
Beneficiaries
(For Whom)
• Who/what resources • What are the key
are required for
activities that
‘executing’ the
must be done to
initiatives
for delivering/
• Do you need to
realizing the
‘partner’ with
value
another department
propositions/
or organization?
benefits?
• Do you need to hire
anyone?
• Why undertake
this project/
program?
• What are the
value propositions
you seek to
satisfy/serve?
• What are the
goals?
• Who derives
value from the
project/program
? (Usually the
customers or
end users; can
also be project
sponsors)
Costs (How much)
Revenue (i.e. Benefits) (How well)
• What are the costs involved in executing
this program? Eg.: Personnel Costs,
Hardware/Software Costs, Office Rental,
Equipment/infrastructure etc.
• Against what metrics will you track the
benefits delivered? (Derived as a result
of MEDIC-ated value propositions)
13
Assumptions
• Growing needs of volunteers
• Continuously growing volunteer pool
• Increasing activities requiring more volunteers
Stakeholders
(Who)
 Developers
 Maintainer
 IIV & V
 Volunteer
 Volunteer
Coordinator
 Supervisor
Initiatives
(What)
Develop new volunteer
management system
Create web application outreach
Develop improved volunteer
management process outreach
Provide training for new job
management process
Deploy job management process
Setup work stations for volunteer
use
Cost
Development Costs,
Maintenance Costs, Maintainer (admin hire),
Web Server (hardware), Web Hosting,
Oracle License etc.
Value Propositions
Beneficiaries
(Why)
(For Whom)
 Improved
 Volunteers
Productivity
 Volunteer
 Faster volunteer
coordinator
management and  Supervisor
less person-toperson time
 Improved
volunteer
management
process
Benefits
Decreased:
Application Data Entry
Time sheet data entry
Job request time
Job assignment time
Increased volunteer applications
Ascertaining Feasibility of Program
• Use Costs, Benefits of the Program Model to
perform an ROI Analysis
• The costs are estimated on the items listed in
the ‘cost box’
• Benefits are estimated based on those listed
in the ‘benefits’ box
• Compute ROI…
15
Computing ROI
• In 577 ROI computation is w.r.t. Effort
expended (cost) vs. Effort saved (Benefits)
• Capture Costs (C) as ‘Time Spent’ (except
where things were purchased/hired)
• Capture Benefits (B) as ‘Time Saved’
• Time can always be converted to money (and
vice versa )
• Compute ROI = Net Benefits/Cost
ROI = (B – C)/C
16
Visualizing ROI
Saved
Effort
(or Cost)
Time
Breakeven point
Total Cost = Total Benefits
Spent
17
Computing Costs
18
Computing Benefits
19
Computing ROI
Year
Cost
(hours)#
Benefit
(hours)+
Cumulative
Cost
Cumulative
Benefit
ROI*
2012
425
0
425
0
-1
2013
156
762
581
762
0.31
2014
172
762
753
1,524
1.02
2015
190
762
943
2,286
1.42
2016
210
762
1,153
3,048
1.64
# : Assuming 10% per yr increase in cost. Rounded up
+ : Benefits rounded up to nearest integer
* : ROI = (Cumulative Benefit – Cumulative Cost) / (Cumulative Cost)
It’s okay to round off decimals – these are just estimates and 23.54 hours of
effort is not better than 23 or 24 or 25 hours
20
Plotting ROI
2
1.5
ROI
1
0.5
0
-0.5
2012
2013
2014
2015
2016
-1
-1.5
Year
Benefit Realization only after transition:
- Mid 2013 for 2 semester projects
- Early 2013 for 1 semester projects
21
Technology Feasibility
1. Architecture Feasibility
– LOS Feasibility Techniques:
•
•
•
•
Analysis
Detailed references to prototypes
Models
Simulations
– Capability Feasibility: Explicitly state/show how
design satisfies capability requirements
– Evolutionary Feasibility: Explicitly state/show how
design satisfies evolutionary requirements (if any)
25
Technology Feasibility
2. NDI/NCS Interoperability
• Various different NDI/NCSes may be used
to satisfy the operational concept
• Need to check if they can seamlessly
interoperate
– Plug and Play instead of Plug and Pray
• Usually a manual effort by going through
documentations and architecture and by
prototyping to see if glue code required
26
Process Feasibility
• ICSM for 577 typically has 4 ‘sub process models’
– Architected Agile (develop from scratch)
– NDI Process (Shrink-wrapped software; minor
customization possible; may have missing
functionality)
– NDI Intensive ( 3̴ 0% of features provided by NDI;
remaining effort in appraising features)
– Net-Centric Services (Almost all functionality provided
by online services with some customization)
• Need to provide rationale stating which process
was chosen and why
• (How) Will the process help deliver the
operational concept within budget/schedule?
27
Risk Assessment and its relation to
Feasibility Analysis
28
Risk Assessment
• Feasibility analysis only helps put estimates on
the costs/benefits to ascertain expected ROI
• Various environmental factors can jeopardize
project execution and delivery
– Risks: Things that have a possibility of occurring in
the future and may negatively impact outcome of
project
– Problem: Risk which has occurred or something
that will happen with 100% probability
• Necessary to identify, analyze, prioritize and
come up with mitigation plans if risk occurs
29
Risk Management/Documentation
Risk Exposure
Risks
Need to synchronize
with another team for
delivering capability.
High communication
overhead.
Probability Magnitude
Risk
of Loss*
of Loss* Exposure
8
9
72
Risk Mitigations
-Setup a fixed schedule
of meeting frequently
and try to raise all the
problems that most
likely to occur.
- Fixed meetings for
synchronizing and
finalizing architectural
interfaces
* Scale: 1 – 9 (1: lowest, 9:highest)
Risk Exposure (RE) = Probability of Loss x Magnitude of Loss
(Risks prioritized using RE score)
30
Continual Feasibility Analysis
31
Various Stages of Feasibility Analysis
• Feasibility Analysis is NOT a one time activity
• The granularity of the analysis changes when
progressing through the project
• Continually conducted as more details are
uncovered during execution
• A previous “feasible” decision might as well
become “infeasible” later down the road
• Feasibility Evidence required at every at every
anchor-point milestone in ICSM
32
The Incremental Commitment Spiral Model (ICSM)
33
Trivia: All Estimates Are Wrong 
• If all estimates are wrong they why bother doing
feasibility analysis?
• Estimates must be based on experience,
judgment and past data (if possible) to be of any
value. You’ll still be wrong 
• It’s the thought process that counts to help
ascertain the odds of success
• Increases confidence in the solution being
provided (or outcome of project/program)
• Shows if the team has thought through the
potential pitfalls and their readiness in dealing
with them
34
Conclusion
• Feasibility Evidence is an absolute must to verify
optimistic claims made by developers (and other
business people too )
• Always get into the habit of asking “prove it” rather
than saying “believe me”
• No “idea” can come to fruition unless its feasibility has
been ascertained to prove with sufficient confidence
that it’s indeed worthwhile (ROI)
• There is NOT enough time/money to do everything and
hence it’s necessary to know what’s feasible
• Out of the ‘multiple’ feasible options choose the one(s)
that are feasible and have the best bang for the buck
35
Online Resources
• Tools/Documents available on class website:
Greenbay.usc.edu
– Course Readings
• Electronic Papers
1.
2.
Business Case Analysis Guidelines (MS Word™)
Business Case Analysis Workbook (MS Excel™)
36