360 likes | 769 Views
Feasibility Analysis. Nupul Kukreja Supannika Koolmanojwong 23 rd September 2013. Agenda. Possibility vs. Feasibility Feasibility Analysis (What/Why?) Types of Feasibility Analysis (How?) Business Feasibility Technology Feasibility Operational/Process Feasibility
E N D
Feasibility Analysis Nupul Kukreja SupannikaKoolmanojwong 23rdSeptember 2013
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
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!
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 • Must know “how much”, “when” and “where” to spend time and/or money (optimum not always possible. Thousands of unknowns!) Region of Possibility Feasible Region Constraints
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
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
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)
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.
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 of a prior “feasible” decision
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)
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
Program Model – Costs/Benefits Assumptions: Under what assumptions is this model true?
Assumptions • Growing needs of volunteers • Continuously growing volunteer pool • Increasing activities requiring more volunteers
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…
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
Visualizing ROI Saved Effort (or Cost) Time Breakeven pointTotal Cost = Total Benefits Spent
Computing ROI # : 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
Plotting ROI Benefit Realization only after transition: - Mid 2014 for 2 semester projects - Early 2014 for 1 semester projects In reality, economic analyses are more prevalent: http://greenbay.usc.edu/csci577/fall2013/uploads/readings/ep/Economic_Analyses_-_CBA_Break-even_Paybay_and_NPV.xls
Workshop Problem Statement USC needs an online course reservation system to automate the registration process and to use the registration data to understand which courses to offer when, to improve their overall course offerings thereby increasing quality of the program • Get together in your teams and create: • Program Model with Cost/Benefits • Estimate the costs and benefits per year • Compute ROI for 3 years
Problem Statement USC needs an online course reservation system to automate the registration process and to use the registration data to understand which courses to offer when, to improve their overall course offerings thereby increasing quality of the program Assumptions: Better course offering/quality increases enrollment/funding
Technology Feasibility • 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)
Technology Feasibility • 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
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 ( ̴30% 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?
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
Risk Management/Documentation * Scale: 1 – 9 (1: lowest, 9:highest) Risk Exposure (RE) = Probability of Loss x Magnitude of Loss (Risks prioritized using RE score)
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 anchor-point milestone in ICSM
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
Key Takeaways • 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
Online Resources • Tools/Documents available on class website: Greenbay.usc.edu • Course Readings • Electronic Papers • Business Case Analysis Guidelines (MS Word™) • Business Case Analysis Workbook (MS Excel™)