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

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
‘Silos’ operating without realizing potential economies of scale with common suppliers, customers

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 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:
Remember resource material and notes are at bus362.com