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
© Copyright 2024