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

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

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

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

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

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)

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)

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

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?

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

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)

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)

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

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?

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?

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

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)

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