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

2. 2

3. 3 “Black-box” models INPUTSOUTPUTS External Environment We shall focus on the outputs and output measures, but not entirely … Requests for service Items to process Something to be transformed Products Services Information Other outcomes

4. 4 Another view  Focus on inputs, outputs, forms, files & reports (IOFF)  Forms  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. 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. 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. 7 Mission statement (1)  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” Bookfinder.com (Anirvan calls this their “goal”—as I mentioned, usage is not consistent)

8. 8 Mission statement (2)  Possibly more common in nonprofit sector than in for-profit sector  But, compare Coke & Pepsi (see links from course download page)  Often written using infinitives  "To boldly go …"  [Or… "to vigilantly fight the use of split infinitives"]

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

10. 10 Objectives - 1  Subsidiary to goals  Can ALWAYS be measured  Specify date by which it will be accomplished

11. 11 Objectives - 2  Examples from national policy (there are only a very few in U.S. history):  “ First, I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth.” – J.F.Kennedy, 25 May 196125 May 1961  “U.S. troops out of Bosnia within a year” – Bill Clinton, 7 Dec. 1995. (See five-year timeline at: http://www.pstripes.com/dec00/ed122000n.html ) http://www.pstripes.com/dec00/ed122000n.html  “We will cure cancer by the end of this decade” – Sam Seaborn, rejected draft for President Bartlet’s 2002 Sate of the Union address (TWW episode #55)TWW episode #55  “100 Mbps broadband to 50% of US households and small businesses by end of 2004” – TechNet policy statement, 15 Jan. 2002TechNet policy statement

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

13. 13 Additional items related to MGO  Refining objectives  Can ALWAYS be measured  Specify date by which it will be accomplished –Therefore a problem can arise when deadlines depend on each other. Example: Release Version 2.0 after completing beta testing AND complete beta tests prior to release of Version 2.0

14. 14 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)  Possible digression on educational testing goes here

15. 15 General propositions on output measures 1. Some measures are better than none 2. Use measures from outside sources 3. Use measures that are timely 4. Develop different measures for different purposes 5. Focus on the important measures 6. Don’t report more information than will be used 7. Tie output measures to expense measures 8. Use appropriate surrogates (Don’t give more credence to surrogates than they are due) 9. (Don’t confuse inputs with outputs)

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

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

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

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

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

21. 21 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 siteBerezin document