330 likes | 699 Views
Feasibility Analysis. Nupul Kukreja Supannika Koolmanojwong 24 th September 2012. 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 24th September 2012
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 and 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
Augmenting The Program Model 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 2013 for 2 semester projects - Early 2013 for 1 semester projects
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 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
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
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™)