SADM 5/ed – CASE STUDY 4 – Milestone 2: Problem Analysis
Page: 2-1
MILESTONE 2 – PROBLEM ANALYSIS
 Synopsis
here’s an old saying that suggests, “Don't try to fix it unless you understand
it.” With those words of wisdom, the next milestone of our project is to study
and analyze the existing system. There is always an existing system, whether
computerized or manual or some of both. The problem analysis phase
provides the project team with a more thorough understanding of the problems,
opportunities, and/or directives that triggered the project. Indeed, the analyst
frequently uncovers new problems and opportunities. The problem analysis phase
may answer the questions, “Are the problems worth solving?” and “Is a new system
worth building?”
T
The purpose of the problem analysis phase is threefold. First and foremost, the
project team must gain an appropriate understanding of the business problem
domain. Second, you need to answer the question, “Are these problems
(opportunities, and directives) worth solving?” Finally, you need to determine if the
system is worth developing. The problem analysis phase provides the systems analyst
and project team with a more thorough understanding of the problems, opportunities,
and/or directives that triggered the project. In the process, they frequently uncover
new problems and opportunities.
In this milestone you will perform Cause-Effect Analysis and document your findings
using the Problems, Opportunities, Objectives, and Constraints Matrix. The PIECES
framework, originally developed by James Wetherbe, and then adapted by the
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 5ed
by J. L. Whitten, L. D. Bentley, & K. C. Dittman
Copyright Irwin/McGraw-Hill 2001
SADM 5/ed – CASE STUDY 4 – Milestone 2: Problem Analysis
Page: 2-2
authors, can serve as a useful tool to classify the various problems, opportunities, and
directives identified in Milestone 1.
 Objectives
After completing this milestone, you should be able to:
 Perform Cause-Effect Analysis to be able to thoroughly understand a system’s
problems, opportunities, and/or directives that triggered the project.
 Use and understand the PIECES framework for classifying problems,
opportunities, and directives.
 Complete the Problems, Opportunities, Objectives, and Constraints Matrix.
 Prerequisites
Before starting this milestone the following topics should be covered:
1.
2.
3.
4.
The problem analysis phase – Chapters 3 and 5
Problem analysis techniques – Chapter 6
PIECES Framework – Chapters 3 and 5
Milestone 1 Solution
 Assignment
Now that you have completed the survey of the system, and gained approval to
proceed, you can now attempt to gain a better understanding of the current system. In
this assignment you will use your results of Milestone 1, plus the case background
information and the user interview, to perform cause-effect analysis. The results of
this activity will provide you a better understanding of the problems, opportunities,
and constraints of the current system.
 Activities
1. To complete the Problems, Opportunities, Objectives, and Constraints Matrix,
use the interview presented in this milestone. Use the PIECES framework as a
model to classify the problems, opportunities, and directives.
Deliverable format and software to be used are according to your instructor’s
specifications. Deliverables should be neatly packaged in a binder, separated with a
tab divider labeled “Milestone 2,” and optionally accompanied with a Milestone
Evaluation Sheet.
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 5ed
by J. L. Whitten, L. D. Bentley, & K. C. Dittman
Copyright Irwin/McGraw-Hill 2001
SADM 5/ed – CASE STUDY 4 – Milestone 2: Problem Analysis
Page: 2-3
References:
Case Background
Case Study Introduction
Milestone 1 Solution
Provided by your instructor
Transcripts of IT Tracker meeting
Exhibit 2.1
Templates
See online learning center web site for the textbook.
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 5ed
by J. L. Whitten, L. D. Bentley, & K. C. Dittman
Copyright Irwin/McGraw-Hill 2001
SADM 5/ed – CASE STUDY 4 – Milestone 2: Problem Analysis
Page: 2-4
Deliverables:
Problems, Opportunities, Objectives, and Constraints Matrix:
Due: __/__/__
Time:_______
ADVANCED OPTIONS
Write a detailed study report for the phase. This deliverable was not
discussed in the narrative because students need to be exposed to modeling (data,
process, & interface) before this report can be completed. For those ambitious
individuals who are familiar with those skills and wish to be challenged, use the
detailed study report outline found in Chapter 5 of the textbook, as a guideline.
Another advanced option is to develop one or more fishbone diagrams for
problems outlined in the case. To complete this advanced option, you may need to
make some assumptions about causes and effects.
Study Report:
Due: __/__/__
Time:_______
Fishbone Diagrams
Due: __/__/__
Time:_______
Milestone’s Point Value:
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 5ed
by J. L. Whitten, L. D. Bentley, & K. C. Dittman
____
Copyright Irwin/McGraw-Hill 2001
SADM 5/ed – CASE STUDY 4 – Milestone 2: Problem Analysis
Page: 2-5
Exhibit 2.1
The following is a transcript of a meeting of Frank Baravelli (systems analyst for the
IT Tracker project), Julius Marx (IT Director), Sy Burnett of the Tech Support staff,
Sarah Bellum of the Admissions Office (to represent end-users of the proposed
system), and Max Stout of the Accounting Department (to represent the concerns of
Vice President of Finance Calvert).
Scene: The Information Technology
meeting room at Huxley College.
Frank has just finished
introductions and is explaining
the purpose of the meeting.
Frank: Each of you has received a copy
of the Request for System
Services and the Problem
Statement Matrix we have
developed in investigating the IT
Tracker system. As I continue
that investigation, each of you
has been suggested as possible
panel members to help me (1)
more fully understand the
current system and the need for
the new system and (2)
document any constraints for
designing the new system –
things that it either must do or
must not do. Mr. Marx sees the
IT Management side. Mr.
Burnett sees the tech staff side.
Ms. Bellum sees the end-user
side. Mr. Stout sees the
accounting side. I’d like to start
with problems in the current
system. What is preventing it
from working?
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 5ed
by J. L. Whitten, L. D. Bentley, & K. C. Dittman
Sy:
I think the biggest problems are
lack of automation, lack of
integration, and lack of
accessibility. We have just one
piece computerized now – the
PC Configurations. But that isn’t
integrated with purchase order
information, so it is a big pain to
look up warranty information.
The warranty information is on
paper. The service requests are
on paper. There’s no flow of
data from one part to the next.
Frank: What about the accessibility?
Sy:
Because it is on paper, I can’t
get at anything. I don’t know
what other techs have done or
any machine history. Sometimes
I go out to do something to a
computer only to find that
someone else tried that last week
and it didn’t work.
Sarah: I would like better accessibility,
too. We users feel like we’re in
the dark out there. We call in a
service request. It may be days
before anyone comes, and we
don’t know what’s going on.
Copyright Irwin/McGraw-Hill 2001
SADM 5/ed – CASE STUDY 4 – Milestone 2: Problem Analysis
Sy:
Well, we do the best we can,
Sarah. We are understaffed and
hampered by the lack of a good
tracking system.
Frank: I don’t think Sarah was trying to
point fingers. Our goal for this
meeting is to look at the
underlying causes and effects
and to set objectives and
constraints. Sarah, what could
we change in the system to
improve your satisfaction?
Sarah: Mainly I would like to know the
status of my request – who is
coming out and when will they
get here.
Frank: Our initial thinking was to
provide just that. If we give you
look-up capability, would it also
be reasonable to have you enter
your own service requests
instead of phoning them in?
Sarah: That would actually be better for
me. I’ve had cases where things
were lost in the translation, and
the tech came out expecting to
find a different problem than
what actually existed.
Sy:
I’m not saying that couldn’t or
shouldn’t be done. But I have a
few concerns, namely security
and ease-of-use. I want this
system to solve our problems,
not create more through bad or
missing data that some user
messed up or a student hacked.
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 5ed
by J. L. Whitten, L. D. Bentley, & K. C. Dittman
Page: 2-6
Julius: I think I can answer that one.
Though it is too early to talk
about implementation specifics,
let’s assume for the sake of
argument that we use a web user
interface and SQL Server on the
back-end. We can use SQL
Server security both to keep out
hackers and to prevent anyone
from doing any more than we
want them to. And how many
users couldn’t fill out a web
form to submit or query
information?
Sy:
That sounds reasonable. A web
front-end would also make sure
it could run on any computer we
have – Windows, Linux, Mac,
whatever.
Julius: But let’s not commit ourselves to
a particular solution yet. For
now we just have to note that the
proposed system has to have an
easy-to-use interface.
Sy:
And that handles updates
without us going out to every PC
and installing a new version.
Julius: Right. And that the solution
must be platform-independent
and secure.
Max:
You talk about integrating
everything. But we can’t have
purchase orders pulled out of the
mainframe accounting program.
And we sure don’t want anyone
else in our system.
Copyright Irwin/McGraw-Hill 2001
SADM 5/ed – CASE STUDY 4 – Milestone 2: Problem Analysis
Sy:
But we need that information in
the system. You don’t know how
many hours we spend combing
through printed POs looking to
verify warranty information.
Max:
I would think that if you just
record the PO number used to
purchase each item when you
install that item, you could go
right to it.
Sy:
Max, we need more than just the
PO number. We need the PO
date and the vendor.
Max:
All of which is available if you
record the PO with your data and
then look up the paper.
Sy:
We are drowning in paper as it
is. We need to automate this.
Max:
I’m just saying that Dr. Calvert
won’t go for anything that
impinges the integrity of our
accounting system.
Julius: I think there are some steps we
can take to make everyone
happy. We do need to integrate
that purchase information for
parts inventory as well as the
other reasons. But we are
sensitive to your needs, Max.
We only need purchase order
data in read-only format. If we
could just have that, it would
allow us to automate what we
need and maintain the security
you want.
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 5ed
by J. L. Whitten, L. D. Bentley, & K. C. Dittman
Page: 2-7
Max:
But if your staff is even reading
our data, won’t that slow down
performance for us?
Julius: We could make sure it doesn’t.
We could grab a copy of the data
at night, and all our work would
be with the copy.
Max:
Okay. But Dr. Calvert also wants
to make sure that you don’t start
growing some alternative
accounting system out here. Can
you promise me that this system
will never include accounting
reports?
Julius: I can promise you that your
office will be involved in all
future plans and requests to
enhance the system. As for this
present phase, the closest things
to accounting that we want to do
are an inventory of uninstalled
components and some total cost
of ownership (TCO)
calculations.
Max:
As an accountant, I can tell you
that you can’t calculate a true
total cost of ownership without
extensive accounting data.
Julius: I know that. We just want to
look at the direct costs of
components with standard
service and downtime estimates.
That would be so much more
helpful than what we have now.
That’s all I need for my
management.
Copyright Irwin/McGraw-Hill 2001
SADM 5/ed – CASE STUDY 4 – Milestone 2: Problem Analysis
Max:
Page: 2-8
I think total cost of ownership
will still worry Dr. Calvert.
Julius: Would it make him feel better if
we stipulated that TCO is a side
benefit of the system and that no
data will be included in the
system solely to calculate TCO?
Max:
Yes, it would.
Julius: Then make that a system
constraint, Frank.
Frank: Yes, sir. Is there anything else I
need to know?
Julius: Let me be more specific on total
cost of ownership. I want to look
at TCO by computer and by
department. One other thing,
have you ever heard of a digital
dashboard, Frank?
Frank: It is a way to track key
management statistics, isn’t it?
Julius: Yes. There are many service
statistics I would like to track.
That would lead to continuous
improvement in our service and
better management. I would like
the system to include a digital
dashboard for me.
Frank: Got it. Well that gives me plenty
to work on. I’d like to thank
each of you for your time. I will
be sending you a copy of my
Problems, Opportunities,
Objectives, and Constraints
Matrix. Let me know if you have
any comments or questions.
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 5ed
by J. L. Whitten, L. D. Bentley, & K. C. Dittman
Copyright Irwin/McGraw-Hill 2001