Objectives for Class 2 Understand and be able to formulate the different elements of a system request: Business need Business requirements Business value Understand and be able to determine the different types of risk a project might encounter

‘Art’ versus ‘Science’ Standish Group Report _____% of projects are cancelled before completion. _____% of software projects are completed on-time and on-budget. A project costs, on average, _____% of the original cost estimate and takes _____% of the original time estimate.

Project Topics Pick an organization or application area with which you are familiar and, preferably, have access to ask questions as they arise restaurant golf course movie theatre Bike rental firm insurance brokerage firm on-campus stuff is okay, but much has been done could do a club or some student organization

Project Initiation How does an IT project begin? Someone has to recognize an opportunity for improvement. Looking for business value The challenge, most times, is identifying tangible business value. Could also come externally, such as a new business law or regulation

Identifying Business Value More or less formal process Informal: a ‘systems person’ vets ideas Formal: ‘System Request’ Project Sponsor Business Need Expected Functionality Expected Value tangible intangible

Performance Problems Throughput Amount of work performed over some period of time Response time The average delay between a transaction or request and a response to that transaction or request ‘Entropy ain’t what it used to be’

Information (and Data) Problems Outputs Lack of information, lack of relevant information, information overload, poor format, not accurate, difficult to produce, not timely Inputs data not captured, not captured in time to be useful, contains errors, difficult to capture, captured redundantly, too much is captured, illegal data is captured Stored Data Stored redundantly, not secure, not well organized, not flexible, not accessible

Economics Problems Costs unknown, untraceable to source, too high Profits New markets available, current marketing can be improved, orders can be increased ‘Silos’ operating without realizing potential economies of scale with common suppliers, customers

Control and Security Problems Too little control or security potential for fraud, information accessible by unauthorized people, privacy guidelines breachable, process errors are occurring Too much control or security bureaucratic red tape, controls inconvenience customers or employees, controls cause processing delays

Efficiency Problems People, machines or computers waste time They waste materials and supplies Effort required to perform tasks is excessive Materials requirements are excessive

Service Problems Business process produces inaccurate, inconsistent or unreliable results Business process not easy to learn or use Business process is awkward Business process is inflexible to new or exceptional situations Business process is incompatible or uncoordinated with other processes

Business requirements Define the boundaries (project scope) Specify requirements in terms of the tasks – the business processes or activities that users will be able to perform. Scope can change – the clearer your initial statement, the easier it is to document and track the impacts of suggested changes

Business requirements Scope creep is the single greatest cause of project budget and timeframe over-runs

Business value This should fall out of the way you define the business need and business requirements Ask yourself “what will be different?” Indicate how you will measure the value The details will be in the feasibility analysis, but once that is done, come back and put the summary numbers here

Risk analysis Feasibility analysis = risk analysis Don’t just ask “can we do it” – try to identify aspects of the project that either jeopardize its completion or its usefulness For each risk identified, think about its potential costs and how to mitigate negative impacts

Risk A hazard that must be minimized or eliminated An uncertainty about which path should be taken and which must be studied to reduce the variance between anticipated outcomes and actual results An opportunity for growth or improvement, which must be assessed to determine how much innovation, initiative, and entrepreneurship should be exercised

Risk management To mitigate risk: Identification Assessment of exposure (likelihood of occurrence and potential impact) Dealing with the risk (monitoring, deflecting, or reducing the risk

Types of risk Financial risk Technological risk (lack of familiarity, performance, scalability, reliability, and stability) Schedule risk Information risk (inaccurate or missing data, privacy, decision-making risk) People risk (unpredictable reactions, lack of managerial, interpersonal or technical skills, politics) Business process risk External risk

Points to remember “Familiarity with application” refers to understanding the business processes Look at familiarity from both the users’ and developers’ perspectives When you are assessing benefits, ask yourself what differences a user can expect to see – be very specific

Project Sponsor Person who is interested in seeing the project succeed a ‘Critical Success Factor’ according to Gartner Group Study (Chaos, 1995) May have several roles technical operating funding

Business Need Why build the system? often an overlooked step need CLEAR and UNDERSTANDABLE milestones for a project The #1 contributor to project failure is changing system requirements (Gartner)

Functionality Need to fully understand how the organization will benefit from the new system Techniques tend to be heuristic

Cash Flow and ROI ROI on information system projects are typically quite high often seek a payback in two years (>50%) other benchmarks include NPV, IRR This typically sets the parameters for the general ability to handle the project, and its scope. A key function is the ability to handle ‘what if’ analysis and/or scenario generation.

Systems Analysis and Design Roles System owners – sponsors, champions Provide resources, establish goals, advocate on behalf of the team – are they willing and able to do this? System users (clients) – can be internal, external, mobile Concerned with functionality – the tasks to be performed – will they use the system? Will they know how? Will they be happy about it? Project team – business analysts, systems analysts, programmers, infrastructure providers, trainers, vendors and consultants Design, construct, test and implement the system – Do they have the technical and business knowledge?

For Next Week Text Chapter 2 Tutorials start today Tutorial assignments are due the following Monday at midnight (11:59pm, actually). Russell and Ashton will give you instructions on how to submit them on Canvas at: https://canvas.sfu.ca/courses/31431 Remember resource material and notes are at bus362.com