1. Yale Braunstein School of Information Management & Systems UC Berkeley
Systems & Projects
Yale Braunstein
School of Information Management & Systems UC Berkeley

2. IS 208
29-Apr-19
Dilbert, Sunday, Jan. 28, 2001
Systems & Projects

3. We shall focus on the outputs and output measures, but not entirely …
IS 208
29-Apr-19
“Black-box” models
INPUTS
OUTPUTS
Requests for service
Items to process
Something to be transformed
Products
Services
Information
Other outcomes
External Environment
We shall focus on the outputs and output measures, but not entirely …
Systems & Projects

4. Another view Focus on inputs, outputs, forms, files & reports (IOFF)
Used to organize inputs
Eliminate any that are unnecessary
Files
Storage
Can be input, intermediate, output
Reports
Special type of output: information about the system

5. More on inputs
Identify them – variety, number, characteristics, format, contents, etc.
May be outputs from preceding phase
Control issues:
You may have little control over inputs
Can you work with provider to modify format?
Often there are institutional constraints
You must request …
You must obtain approval
Procedures fixed

6. MGO Mission, Goals, Objectives form a hierarchy
Terminology is NOT used consistently elsewhere, but we shall be VERY precise in our definitions and usage
Your role: To identify existing MGO for your system
But, they do not always exist
Or they may not be explicit
Or there may be a mismatch with reality
Importance of MGO varies across organizations, even with types (examples: universities, governmental agencies, non-profit organizations, IT departments)

7. Mission statement
Short statement of the overall purpose of the system, what it is and does.
Can focus on services or outputs, and on clients
Samples:
Reserve system at library: provide users with materials that would often would be otherwise unavailable.
Bookfinder.com: “provide fellow readers unbiased real-time information about books available online”
(Anirvan calls this their “goal”—as I mentioned, usage is not consistent)

8. Goals Specific statement(s) of what the system intends to accomplish
As a group, the goals encompass all the major functions of a system
Examples:
My HMO’s primary goals are (in order?):
To save my employer money
To aggravate both me and the healthcare providers who serve me
To improve the delivery of health care to me

9. Objectives Subsidiary to goals Can ALWAYS be measured
Specify date by which it will be accomplished
Examples from national policy (there are only a very few in U.S. history):
“A man on the moon by the end of the decade” – J.F.Kennedy, 196?
“U.S. troops out of Bosnia by the end of the year” – Bill Clinton, 199?

10. The Model for Well-Stated Objectives
Well-stated objectives should have four points:
To (action/verb)
(single measurable result)
by (target date/time span)
at (cost in time or energy)
Examples:
To submit a high-quality final project by May 8 without completely burning out
To complete my income tax return by April 15 while spending less than 10 hours preparation time

11. Output measures
There is an obvious link between objectives and output measures—we should measure the “correct” things to determine whether the objectives have been met
Output measures can be:
Objective or subjective (but NOT arbitrary)
Quantitative or non-quantitative
Discrete (yes/no, etc.) or scalar (#, rank)
Related to quantity or quality
Surrogates for quality may be used
(The TOGO’s example)

12. General propositions on output measures
Some measures are better than none
Use measures from outside sources
Use measures that are timely
Develop different measures for different purposes
Focus on the important measures
Don’t report more information than will be used
Tie output measures to expense measures
Don’t give more credence to surrogates than they are due
(Don’t confuse inputs with outputs)

13. Problem / Project definition
One way to develop a project is to think in terms of the problem to be solved
Define the problem in terms of:
its subject
its scope
its objectives
Start to focus on determining the appropriate level of detail, which can be:
overview of the problem
details of decision points (with documentation)
extensive detail

14. Problem definition - examples
Why does our organization take so long to pay its bills?
Why can’t students find materials in the library?
Why do people leave the web site before completing a transaction?
Why is our customer support so poor/slow? (Do we care?)
How can we get taxpayers the proper forms?
How can we use certain internal resources more efficiently?

15. Project initiation - I
Projects begin when someone sees an opportunity to create business value from using information technology.
Focus on “techniques for success”
Internal: What has worked previously in this organization?
External: Where have similar projects been successful?

16. Project initiation - II
Constrain area under study to keep project manageable
But don’t forget the goals
This is a key question of balance: not so big that the project can’t be done, not so small that it loses importance
Develop tentative timetables (for use in GANTT charts)
Design simple progress reports

17. Project feasibility
Feasibility analysis is used to aid in the decision of whether or not to proceed with the IS project.
Consider:
Technical feasibility
Operational feasibility
Economic feasibility
Look briefly at the feasibility sections in Chapter 2 (cost and cost analysis covered in detail later in semester)

18. Software requirements document
Written statement of what the software will do
Does NOT state HOW the software will do it
The main purpose of a requirements document is to serve as an agreement between the developers and the customers (who may be internal) on what the software will do.
General rule: You MUST have a requirements document for the application if:
the project will take more than one month
more than one person will work on it, or
more than one workgroup will use it
See the Berezin document on our web site