1

Systems & Projects

Yale Braunstein

School of Information Management & Systems

UC Berkeley

2

3

“Black-box” modelsINPUTS OUTPUTS

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

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

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

(Anirvan calls this their “goal”—as I mentioned, usage is not consistent)

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

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

Objectives - 1

Subsidiary to goalsCan ALWAYS be measuredSpecify date by which it will

be accomplished

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

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

“100 Mbps broadband to 50% of US households and small businesses by end of 2004” – TechNet policy statement, 15 Jan. 2002

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 outTo complete my income tax return by April 15 while spending less than 10 hours preparation time

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

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

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

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

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

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

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

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

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