Systems Analysis I Feasibility & Project Management

Systems Analysis IFeasibility & Project Management ISYS 200 Glenn Booker Week #8

Feasibility • Every organization which performs system development, or has it done for them, needs a way to choose which projects are worth the effort • Feasibility study is a common approach to make such decisions thoughtfully • Basis for feasibility study is generally the problems and opportunities analysis Week #8

Problems & Opportunities • We can look for problems and opportunities in many parts of our organization, and the existing systems which are supported • Track maintenance costs for existing systems • Measure existing processes to determine their cost, and compare to industry standards • Monitor availability of support for existing system components • Look for signs of unhappy employees Week #8

Problems & Opportunities • Check quality of work products (outputs) • Listen to customers, vendors, and suppliers • Both complaints and suggestions • Measure customer satisfaction • Monitor competitor’s offerings and plans • Monitor changes in technology which could help • Don’t forget obvious measures of success, like sales, profit, or number of contracts awarded Week #8

Project Selection • Selection of projects is based on many factors – cost, urgency, the systems affected, etc. • From the organization’s perspective, choosing projects is kind of like shopping • There’s generally a limited amount of funds and people available to work on the possible projects, and management needs to choose which projects to support Week #8

Project Selection • There are five typical requirements for a project to be supported • Management support for the project • Appropriate timing of commitment to the project • Relevance to helping meet organizational goals • Project must be practical and feasible • Project must be worthwhile compared to other possible expenditures • Are we getting enough ‘bang for our buck?’ Week #8

Project Objectives • Based on the problems and opportunities identified for a project, we can set objectives for the project • These not only help the feasibility study which follows, but set goals against which we can later test the system • Objectives should not only address the type of improvement sought, but set a desired level of improvement Week #8

Project Objectives • Examples of objectives might include • Improve customer satisfaction 10% within 1 year • Reduce the response time for customer complaints by 15% • Get a new feature to market before competitors • Reduce error rate for data entry from 2% to 0.5% • Improve sales to new customers by 5% • Reduce voluntary employee turnover by 10% Week #8

Feasibility Analysis • Feasibility consists of several types we want to assess for each candidate project • Technical feasibility • Can the project be done with existing technology? • Are people available to use the technologies needed? • Economic feasibility • How much does the system cost to develop? Maintain? How long will it be usable? • Some add schedule feasibility – how long will it take to create the system? Week #8

Feasibility Analysis • Operational feasibility • What impact will the new system have on how we do business? Will there be changes to where or how processes are performed? • Will there be changes to employee skills needed? Changes to employee training? • Are existing users amenable to a new system? • These types of feasibility can be measured for each project, and compared to determine which is most feasible Week #8

Feasibility Analysis • Like voting or buying a car, feasibility analysis is rarely completely logical or quantifiable • Many other issues can also affect it • Political climate • State of the US and/or global economy • Preferences of the decision makers – favored vendors, technologies, types of projects, etc. Week #8

Planning Activities • Once a project has been selected for funding, its detailed planning generally begins • Key project management perspective is to look at a project in terms of a set of tasks to be accomplished, and managing the resources (people, tools) needed to perform those tasks • Management focuses on effort (by people), (calendar) schedule, cost, and resources Week #8

Planning Activities • Cost for software-related system development is mostly due to the labor effort of the people needed to create it • Other costs, such as hardware, software, training, etc. are relatively small for most systems • The start of planning for a project is to identify the time needed for various activities needed to create the system Week #8

Planning Activities • To help structure development activities, we use a life cycle model to identify the major sets of activities, called life cycle phases • There are many kinds of life cycle models • The Waterfall model is the oldest, and uses phases like Requirements Analysis, High Level Design, Low Level Design, Coding, and Testing • The Rational Unified Process has Inception, Elaboration, Construction, and Transition phases Week #8

Planning Activities • The life cycle used here has three phases • The Analysis phase includes data gathering, data flow and decision analysis, and proposal preparation activities • The Design phase includes data organization, and design of data entry, inputs, and outputs • The Implementation phase includes creating the system (implementation) and evaluation (testing) Week #8

Planning Activities • Each life cycle phase is broken down into more and more specific activities, until the time needed for each activity can be reliably estimated • Then the tasks are put into a Gantt chart or Pert chart to show when they occur relative to each other • Tasks might occur sequentially, have to start or end together, or wait for some other tasks to be completed Week #8

Planning Activities • Tasks for a project often include the acts of creating specific documents or work products, approving things or making decisions; such as • ‘Prepare system test plan’ • ‘Approve system release’ • ‘Conduct user satisfaction survey’ • ‘Approve system requirements specification’ • So the life cycle model provides guidance on the types of activities needed, but the tasks provide authority for people to do them Week #8

Gantt Chart • The Gantt chart shows tasks graphically • Time moves forward from left to right • Each task is a bar, whose length is the task duration, and position shows when it starts and stops • Above the bars are 1-3 timelines, which can show actual time (e.g. calendar weeks and months) or relative time (weeks or months since the start of the project) Week #8

Gantt Chart • Decisions are shown by a milestone diamond – they are tasks of zero duration • Tasks and decisions are grouped together into activities and life cycle phases • The higher level tasks are shown as summary tasks – a different style of bar • Once the project starts, another style of bar can be used to show progress toward completing tasks Week #8

Notice that tasks 3-5 are sequential, tasks 7 and 8 end together, tasks 1, 2, 6, and 9 are summary tasks, and tasks 12 and 15 are decisions.Detailed activities of design and implementation phases are not shown.Each level of indenting task names indicates a new level of detail. Gantt Chart Excerpt Week #8

PERT Diagrams • PERT diagrams, or PERT charts, are primarily used to help identify the critical path for a project • The critical path is the sequence of tasks which, if any tasks were changed, would also change the completion date of the project • Tasks on the critical path tend to get preferential treatment for getting resources Week #8

PERT Diagrams • A PERT diagram consists of labeled circles, connected by lines (other formats exist) • The circles are points in time on the project schedule (not tasks); the labels are sequential tens (10, 20, 30, etc.) • Each line is a task, labeled with the task identifier and its duration in some consistent units (weeks in the text, days here) Week #8

PERT Diagrams • A split in tasks after some circle means that two or more tasks start at the same time • Conversely, two or more lines entering a circle means that ALL of those tasks have to finish before the project can move forward • ‘Dummy’ lines can be added to connect tasks which have no previous or following task Week #8

6, 20d 13, 20d 14, 50d 20 40 50 60 2, 10d 10 Dummy 9, 8d 30 This is the Gantt example on slide 20, omitting the lowest level tasks. Tasks 13 and 14 are, for example, the design and implementation phases. Sample PERT Diagram Week #8

PERT Diagrams • PERT is therefore useful for • Identifying the order in which tasks take place • Finding the critical path • Finding slack time (open areas in the schedule) Week #8

Timeboxing • Timeboxing refers to creating short, well defined iterations in which to perform project tasks • Each time box has clearly stated objectives and deliverables (work products due) • Used to avoid long, ill-defined tasks which don’t produce anything • The Rational Unified Process uses timeboxing throughout the life cycle Week #8

Teamwork • Teams are groups of people who • 1) are working to achieve a common goal, and • 2) whose activities are interdependent • Teams need to have clear objectives • Teams need a way to resolve conflicts • Teams may have specifically defined roles, and one or more leaders • Teams should set their own goals Week #8

E-Commerce Management • Management of e-commerce projects are frequently similar to any other development effort • Might have greater geographic range of locations • Typically need diverse skill sets • May be very politically driven projects with tight schedule • And obvious security concerns Week #8

Systems Proposals • Many organizations obtain new work by bidding on projects using some kind of proposal document • Proposals could be used internally within your organization, or sent to an external customer • A proposal outlines their proposed solution to the customer’s problem, and gives estimates of the cost, schedule, and risks associated with the project Week #8

Candidate Solutions • Key to a good feasibility analysis is to choose an appropriate set of candidate solutions • Each candidate solution is one way to approach structuring the solution • They might differ in the • Type of network architecture (# of tiers), • Extent of automation (which processes are automated vs. stay manual), • Use of push vs. pull technologies Week #8

Candidate Solutions • Brand of commercial components (UNIX vs VMS operating system), • Types of hardware technology (e.g. typed vs. RFI vs. barcode input devices), • Use of custom vs. commercial vs. outsourced software components • For each candidate solution, need to • Identify the hardware and software needs to implement it • Estimate the labor effort to implement it Week #8

Candidate Solutions • Estimate the maintenance costs • Select appropriate options for buying vs leasing equipment, and options for commercial software maintenance contracts • Determine facility needs for each solution • Then you can choose the tool for making the choice among the candidate solutions Week #8

Decision Tools • Tools for making decisions include • The spreadsheet approach – assign a value to each aspect of feasibility, and rate each solution on those aspects • More formal tools can use analytical hierarchy processing (AHP), neural nets, expert systems, or other techniques Week #8

Cost-Benefit Analysis • As part of the cost feasibility, a formal cost-benefit analysis can be performed • This is weighing the costs of developing and maintaining a new system, against the benefits that system should provide • This is why quantifying system objectives was important • The tangible benefits of the new system can be the value of improvements Week #8

Cost-Benefit Analysis • For example, the benefit from saving four minutes on generating a form that’s used 50,000 times per year might be • (4 min/form)/(60 min/hr)*(50000 form/yr)*$40/hr • Equals $100,000 per year, assuming the cost of an employee, with benefits, is $30/hr • Similar approaches can be used to estimate benefits of bringing in new customers, increasing sales, reducing errors, etc. Week #8

Cost-Benefit Analysis • Analytical approaches for predicting trends from past behavior can use several methods • Regression analysis (statistical curve fitting) • Moving averages • Graphic judgment (visual curve fitting) • Intangible benefits are also important – improved employee morale, good company reputation, customer satisfaction Week #8

Cost-Benefit Analysis • Costs associated with creating a system are also tangible or intangible • Tangible costs include the development and maintenance costs of the new system • Intangible costs are hard to measure, e.g. the cost of making poor decisions • All costs over the life of the system should first be converted to their present value Week #8

Time Value of Money • All cost benefit analyses assume that money is worth more over time, since it can be invested As a result, these analyses depend VERY STRONGLYon the interestrate which could be obtained from saved money – a critical assumption Week #8

Present Value • The present value of money, some time in the future, is • $1 of money today = $(1+i)-n • Where ‘i’ is the interest rate, and ‘n’ is the number of time periods over which that rate was collected • The interest rate is how much you could earn on investing that money some way other than this system • The number of time periods is generally in years, but the formula still works if you divide the interest rate accordingly Week #8

Present Value • So the present value of $30,000 five years from now at an 8% interest rate is$30,000 * (1 + 0.08)-5 = $20,417 • That means if we invest $20,417 at 8% interest for five years, we’d have $30,000 • The same problem with months used instead of years gives us a slightly different answer • PV = $30,000*(1 + 0.08/12)-60 = $20,136 • How often the interest is obtained is a small factor Week #8

Present Value • Notice that the present value of $1.00 is always less than or equal to $1.00 • If you invest 50 cents now, at some point in the future it will be worth $1.00 • When that happens depends on how well that 50 cents could be invested (the interest rate) • Very short term projects don’t need to use present value analysis, but most information systems are long term investments Week #8

Break Even Analysis • One way to analyze cost effectiveness is to determine how much business volume is needed for the new system to pay for itself • Determine the costs and benefits as a function of system output • Look for when benefits exceed costs – that’s the breakeven point • A good method if cost is the main concern, not benefits Week #8

Return On Investment (ROI) • Lifetime ROI is a percentage comparing the total costs and benefits from a project: Lifetime ROI=(total benefit - total cost)/(total cost) • Lifetime ROI may be divided by project duration to get a ROI per year (annual ROI) • Want high ROI (lifetime and annual) • A low ROI (~ under 10%/yr) might indicate the benefits are too little to be worthwhile Week #8

Cash Flow Analysis • Look at the costs and benefits from the system over time (e.g. each year) • Convert costs and benefits to present value • Add up the total costs and total benefits • When the total benefits are greater than total costs, you have reached the breakeven point (“out of the red”) • Good for projects that are a substantial investment for the organization Week #8

The Systems Proposal • Based on all the nifty stuff we’ve covered, we can now put together a systems proposal • Executive summary (execs don’t read much) • Describe the methods used to study the existing system and the business environment • Describe the candidate solutions and the feasibility analysis results for each • Provide a recommendation on the preferred solution Week #8

The Systems Proposal • Most people who receive a systems proposal are looking at many of them and need to choose the ones to receive funding • Hence there’s a noticeable amount of sales pitch in many proposals • Consider appropriate graphics to make the data more interesting Week #8

Types of Graphs • Pie chart • Bar or column graph • Bars can be stacked, or clustered next to each other • Line graph • Scatter plot • Histogram • A bar chart with ranges of X values, like ages 15-24, 25-39, 40-54, etc. Week #8

The Systems Proposal • An oral presentation may be needed for the systems proposal • Make sure your voice is loud enough to be heard • Look at your audience – they won’t bite! • Keep visual aids large enough to be read • Avoid filler words: errr, um, y’know • A little silence can be a good pause between topics, and give you time to think Week #8

Systems Analysis I Feasibility & Project Management