Objectives for Class 2

1. 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

2. ‘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.

3. 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 • ‘U-Brew’ wine or beer store • movie theatre • video rental outlet • insurance brokerage firm • on-campus stuff is okay, but much has been done • could do a club or some student organization

4. 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

5. 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

6. 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’

7. 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

8. Economics Problems • Costs • unknown, untraceable to source, too high • Profits • New markets available, current marketing can be improved, orders can be increased

9. 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

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

11. 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

12. 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

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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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)

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

23. 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.

24. 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?

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