CLIENT
PROBLEM ANALYSIS AND DEFINITION
PROCESS
D E C E MB E R 2009
December 2009
i
1.0
INTRODUCTION ............................................................................................. 1
1.1
B A C K GR OU N D & O B J E C T IV E ...................................................................................... 1
1.2
T E R MS
AND
D E F IN IT ION S ......................................................................................... 1
1.2.1
Glossary ----------------------------------------------------------------------------------------------- 1
1.3 A U D IE N C E ............................................................................................................. 3
1.4
H OW
1.5
D OC U ME N T M A IN T E N A N C E ........................................................................................ 3
2.0
TO
U SE T H IS D OC U ME N T .................................................................................. 3
P R O B L E M A N AL Y S I S A N D D E F I N I T I O N P R O C E S S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1
O B J E C T IV E S .......................................................................................................... 4
2.2
P R IN C IP LE S
AND
C ON C E P T S ..................................................................................... 4
2.2.1
Process Segmentation ----------------------------------------------------------------------------- 5
2.2.2
Roles, Responsibilities and Communication -------------------------------------------------- 5
2.3 M E T H OD ............................................................................................................... 6
2.3.1
Goals -------------------------------------------------------------------------------------------------- 6
2.3.2
Facts --------------------------------------------------------------------------------------------------- 7
2.3.3
Concepts ---------------------------------------------------------------------------------------------- 8
2.3.4
Structure and Framework ------------------------------------------------------------------------- 8
2.3.5
Needs, Balance, and Decision-making --------------------------------------------------------- 9
2.3.6
Stating the Problem--------------------------------------------------------------------------------10
2.3.7
Leadership, Communications and Teaming --------------------------------------------------10
2.4 D E LIV E R A B LE S ...................................................................................................... 11
2.5
E XA MP LE S ........................................................................................................... 12
2.6
S U GGE S T ION S ...................................................................................................... 12
December 2009
ii
1.0
INTRODUCTION
1.1
B a c k g r o u n d & O b j ec t iv e
Problem and Analysis Definition is the first phase of a three-phase process
designed for architectures and enterprise level programs or projects.
It also may be applied to smaller projects where the client is unclear or has not set
objectives. Problem Analysis establishes the Problem Definition that sets
requirements and success criteria for the design of a solution (Design Phase). The
output of the Design Phase is the architecture or project / program design (the “blue
print”). The delivery phase executes / implements the architecture, project or
program.
This process was created to assist the client in working with a consultant, to define
roles and to assure that client decisions control the design and delivery of the
architecture, program or project.
1.2
T er ms a n d De f i n it i ons
Problem Statement – A succinct document that describes the problem that the
designer must solve.

Sets the success criteria for the architecture, project or program

Assures project executors or designers operate effectively and do not have
to reanalyze high level needs

Is a deliverable and defines the separation between analysis and synthesis
(design activities)
Analysis – A process leading to a Pr oblem Definition and/or the high-level
requirements to for a design. It includes systems, business analysis, and other
analysis disciplines.
1.2.1
Glossary
Although these definitions conform to comm on usage, specifics have been added to
conform with this process.
December 2009
1
Concept – Something conceived in the mind an idea or notion. Concepts may be
general or specific and to be of most use they must identify the acceptable ways
that goals can be achieved without being so specific that they constrain the solution
or “tie the developer’s hands”.
Economy – The cost and value of implementation and operation, the impact of
schedule, initial budget, operating and lifecycle costs. In security architecture or
programs, this includes the costs associated with risk. The process is designed to
use qualitative information when quantitative is not available.
Fact – Pertinent knowledge presented as representing reality or truth. Facts may be
qualitative or quantitative, empir ical or objective. Some types of facts are:

Information – Knowledge obtained from investigation, study, or instruction

Data – Factual material used as the basis for reasoning, discussion or
decision

Assumption – A statement accepted or supposed to be true without hard
proof or demonstration. An assumption may used as a “what if” to investigate
options or sensitivity.
Form – W hat the solution is or appears to be - the look and feel. Form includes the
environment that the s olution must fit. For software form may include processing
environment and whether it is centralized or distributed.
Function – W hat the solution does and how it will work. Typically features,
relationships and operational interfaces, capacity, performance, reliability /
availability, and security. For security driven architectures or programs, the function
should also address the impact on the other functions and operations.
Goal - End toward which the effort is directed. Goal is synonymous with objective,
aim, mission, purpose, reason, philosophy, aspiration and policy. Goals stand -alone
/ have value unto themselves.

Motherhood Goal – Goal that is too high level for analysis and may
inspire or set direction.

Objective Goal – Goal that is achievable and measurable

Lip Service Goal – Goal that looks good in public but is not achievable
Information Matrix – the Goals, salient / analyzed Facts and Concepts and Needs
organized into a Function, Form, Economy, and Time based structure
Mission – the objective or goal of the analysis (not the overal l architecture, project
or program)
Need – Requirement, something necessary, an indispensabl e or essential thing or
quality Needs are determined by analysis to be achievable, feasible or affordable /
fit within the budget determined by the economic conside rations.
Problem Statement – Description of the critical conditions and design premises that
become the starting point for design . The criteria that are to be used to evaluate the
design and assess whether it leads to a successful outcome.
Time – Compatibility with the past or prior efforts or evolve -ability and expandability
for the future
December 2009
2
Want – Desire or something wished / something that is not determined t o be
achievable or affordable.
1.3
A u d i e nc e
This document is for use by client staff and consultants.
1.4
H o w t o Us e T h is D oc um e n t
The document contains both essentials and suggested guide lines for effective
Problem Analysis and Definition.
1.5
D oc u m en t M a in t en a nc e
Phillip Fuhrer currently maintains this document. Send suggestions or updates via
email ( phil@philfuhrer.com ).
The rationale for the Problem Analysis and Definition process has been taken from
Problem Seeking – An Architectural Programming Primer , W illiam M. Pena and
Steven A. Parshall, Fourth Edition 2001, ISBN 0-471-12620-9. Many of the words
and illustrations are taken verbatim from this book.
December 2009
3
2.0
PROBLEM ANALYSIS AND DEFINITION PROCESS
2.1
O b j ec t iv e s
Problem Analysis and Definition is of most use when applied to architectures or
projects that require a large amount of effort or have large / enterprise wide impa ct
or when applied to programs that are composed of many interrelated initiatives. This
process may also be used as a method of inquiry, on smaller undertakings.
This process reduces the overall effort over t he “just-do-it” approach.
Problem Analysis and Definition Process objectives are a combination of “product”
and “process”. The value of a Problem Definition is a function of the analysis
process that created it. This proce ss:

Is structured – composed of logical steps

Is comprehensive – assures that all considerations are addressed and are
balanced

Assures that implementation details do not cloud problem analysis – problem
analysis is separated from design / synthesis

Is designed for open team participation, effective communications and
decision-making, to promote consensus and buy-in and to use both
qualitative and quantitative information

Provides a framework for listening, questioning and recording and to
organize / structure the acquired information
The product:

Provides the designers with succinct requirements that answer their
questions, optimize their effort and assure that they do not have to reanalyze
needs

Sets the success criteria (high-level requirements) for the architecture,
project or program
2.2
P r i nc ip l es a n d C onc e pt s
The process is composed of five steps:
1. Establish Goals
2. Collect and analyze Facts
3. Uncover and test Concepts
4. Determine Needs
5. Define the Problem
Four consideration types assure that process is comprehensive.

Function
December 2009
4

Form

Economy

Time
Problem analysis and problem solving are two distinct processe s requiring different
attitudes. Trying to do both at once often causes false starts and rework, sub optimal solutions or “solution probleming” rather than problem solving. Analysis
involves decomposing the elements for understanding while problem solving is a
constructive task where elements are combined into a solution .
2.2.1
Process Segmentation
The Problem Definition should “speak to” the designers to focus their efforts and to
assure understanding. Since it is the success criteria, it should be self -contained
and state the necessary and sufficient factors.
2.2.2
Roles, Responsibilities and Communication
A consultant and staff assigned by the client team execute the Problem Analysis
and Definition process. In addition to leading the Problem Analys is and Definition
effort a consultant may provide subject matter experts to participate on the team.
Other client stakeholders may participate on the analysis team. The process allows
December 2009
5
for wide team participation and benefits from different personal styles and
preferences.
The Problem Analysis and Definition process facilitates communication between the
stakeholders, the client decision makers, and the consultant through interviews and
work sessions. Interviews for data gathering and work sessions for summaries are
clearly distinguished.
The consultant role encompasses facilitator, documenter and subject matter expert
with knowledge of the industry, st andards and other clients. As facilitator, the
consultant represents an objective party that guides the process of inquiry and
supports the open exchange of information. As an interviewer, consultant asks
questions in the spirit of guiding the process and, in most cases, not to elicit
specific answers. Specific / rigid answers when needed can be obtained by
research.
The client staff brings profound knowledge of the problem and associated issues.
They also are subject matter experts and are key in decision-making.
Problem Analysis and Definition is a participatory process requiring team effort.
Consultant coordinates the individual effort of team members, make s decisions
about the process and impels client decision-making. Consultant must also assure
effective communication within the team and with non -team management.
Additional ways of optimizing the team effort are also addressed in this document.
2.3
M e t ho d
The preliminary step is preparation and gathering background information. This
includes identifying and briefing the key team members.
Briefly, the five steps pose these questions:
1. Goals – W hat does The client want to achieve and why?
2. Facts – W hat do we know? W hat is given?
3. Concepts – How does The client want to achieve the goals?
4. Needs – How much money or other resources are needed to address the
problem and what is affordable?
5. Problem – W hat are the significant criteria for the success of the design?
W hat are the general directions of the design or implementation?
Normally the first three steps (establish goals, collect and analyze facts, and
uncover and test concepts ) are started in parallel. Determining Needs is a function
of the decision-making process and starts as soon as the data is analyzed and
ready. The Problem phase is largely wrap-up and summarization.
2.3.1
Goals
Initially Goals established by the client are not constrained to be practical,
measurable or affordable. Motherhood Goals and lip service Goals are okay.
Understanding these Goals and putting them into perspective is part of the analysis
process.
December 2009
6
It is important to distinguish Goals that have value unto themselves from Concepts.
The following questions help with this distinction.

Does this have a higher purpose?

Are there other acceptable ways of getting the result?

Is this goal important even if not productive?
Goals, Facts, Concepts, and later Needs sho uld be recorded as individual
statements that can be easily organized / re -organized as needed for presentation
and use by the analysis team. Key words should be in large or in a bold font.
Sketches and charts are often the most effective way of presenting information.
It is also helpful to organize the Goals by consideration (Function, Form, Econom y
and Time). Sometimes Goals need to be restated to fit this model.
People do not distinguish Function, Form, Economy and Time when stating Goals.
For example, “I need a new car to get to work”. The Go al may be Function
(transportation get to work ), Economic (new), or Form (car). If the Goal is
transportation bus, train, or bicycle in addition to car may be valid Concepts. If th e
Goal is Economic fixing up the old car to look and operate like new may be an
alternative. Problem Analysis and Definition is intended to help The client
understand this distinction and to open up the possibilities while assuring that their
statements are respected and their needs are met .
Often the economic Goals start as, “to spend as little as possible while achieving all
the other Goals”. This is okay if, during the analysis process, costs are estimated
and a rationale for setting priorities is determined.
2.3.2
Facts
Facts are collected by:

Research in and outside the organization

Interviews of the client and other stakeholders that may be impacted by
program
Facts are important if they are appropriate / associated with Goals and Concepts .
Facts include statistics, economic data such risk a nd other cost estimates ,
information about the current situation, base lines, benchmarks and many other
things.
Analysis concerns the processing of raw data into useful information. This means
that facts need to be combined and abstracted into salient info rmation that supports
definite conclusions and decision -making. It assures that information is complete
and organized to have a sense of clarity.
December 2009
7
2.3.3
Concepts
Often Concepts are first elicited as lower level goals (s ee Goals) or arise organically
from the collection and analysis of Facts. An example is Facts about how other
companies have solved similar problems. Concepts may also be uncovered by
analysis team brainstorming with stakeholders, or by the design team.
During the analysis, Concepts are tested to verify that they are consistent with the
goals and are not so low level that they tie the designer’s hands. Concepts that do
not meet these criteria may be treated as F acts.
In addition to guiding design, Concepts aid in estimating costs.
2.3.4
Structure and Framework
Goals, salient Facts and Concepts, and Needs are classified based the
considerations (Function, Form, Econom y, and Time) forming an Information Matrix.
The information index shows at -a-glance the inter-relationship of information and
indicates when important information is lacking.
December 2009
8
All four considerations interact at each step. For example, in the first step when
Goals are investigated, function Goals, form Goals, econom y Goals and time Goals
should emerge. Facts, Concepts, Needs, and the Problem Statement then are
organized based on the associated goals
2.3.5
Needs, Balance, and Decision-making
In any large project or program decisions are essential to narrow the scope and
focus the effort.
Effective decision-making can start as soon as information is analyzed.
The Problem Analysis and Definition Process is characterized by timely and sound
decision-making by The client. Consultant’s role is to facilitate decision -making by
making sure that the information is available for Fact based decisions.
In most cases, economic decisions se parate the W ants from the Needs. The Needs
are the Goals or part of the Goals that are highest priority or can be budgeted
immediately while the W ants are lower priority.
Balance is when all four considerations (Function, Form, Econom y and Time) are
addressed in each step and the trade -off between economic and other Goals is
understood (i.e. the budget is balanced). W hile the budget may not be fixed it
should be determined before the process is complete.
December 2009
9
Postponing decisions increases the cost of the architecture or program. Over design
and high cost is usually the result when decisions are not made during the analysis
process.
2.3.6
Stating the Problem
Since the Problem Statement drives the downstream design or implementation, it is
best when composed by the designers. It must address the Needs and be approved
by client management.
2.3.7
Leadership, Communications and Teaming
Effective communication requires careful documentation. Undocumented information
is not likely to be consider ed and evaluated by the client, designers, and
stakeholders. The Goals, Facts, Concepts, Wants and Needs are documented for
use and not just for reference. Graphics, illustrations, flow charts and other tools
make information understandable and useful.
.
To achieve effective group leadership it is important to understand and apply
multiple ways of thinking and analysis. Architecture projects and programs are
usually massive undertakings requiring the melding of many ideas and approaches.
The belief that “together the team can do a better job than separately” is a critical
maxim. Some disparate ways of thinking are:

Visual versus verbal – where possible charts and illustrations a re used to
document information
December 2009
10
2.4

Qualitative versus quantitative – the process is intended to deal with both
qualitative and quantitative data. Risk analysis for example may not be
complete to provide quantitative results for analysis.

Problem-oriented versus solution-oriented – some people are solution
oriented. They prefer to analyze a problem by proposing multiple solutions
and converging on the best. In Problem Analysis and Definition Process
proposed solutions are treated as Concepts to be tested and become pivotal
in the Problem Statement

Analytical thinking versus synthesis – analysis identifies the parts of a
problem while synthesis brings together pieces so that the whole is more
than the sum of the parts.

Logical versus intuitive thought – logical thinkers prefer a systematic
approach while intuitive thinkers tend to skip st eps and often obtain valuable
insights. Intuitive thinking is needed when chunks of information cannot be
obtained.

Algorithmic versus heuristic – the process is heuristic steps are not
rigorously sequential and information may not be overly precise. An
algorithmic approach is used for critical facts such as safety or absolute
security.

Abstract versus concrete – the process is designed for abstract thinking i.e.
to keep the parts malleable, jellylike and loose until dictated by the design

Feed-forward versus feedback – the process implies looking ahead to design
implications of analysis decision s or feed-forward. In stating the problem the
design team provides feedback concerning their needs

Objective versus subjective – the process rational and objective a nd as much
as possible reduce the need for subjectivity

Art versus science – artistic activities emphasize intuitive, subjective
thinking. Scientific activities emphasize logical objective thinking. The
process assures that the artistic activities are larg ely confined to design.

Comprehensive versus singular – the process tends to be comprehensive
thought – addressing the whole problem rather than components in isolation.

Holistic versus atomistic – the process team is best when it sees both the
forest and the trees

Expansion versus reduction – the process is intended to not expand or
contract the problem space

Complexity versus simplicity – some people enjoy tension, ambiguity, and
complexity. Other people enjoy the intellectual challenge of simplifying it –
boiling it down to its essence. The process is intended to simplify the
problem in face of the staggering amount of information that can be
collected.
D e l iv er ab l es
The Problem Definition composed of the Problem Statement and the Information
Matrix is the deliverable.
December 2009
11
2.5
E x a mp l es
Two of the client IT Security Programs GOALS are:
TO HAVE A
VISIBLE PROGRAM
TO ESTABLISH
THAT MOVES THE CLIENT TOWARD
ISO-27002 AND OTHER
STANDARDS AND BEST PRACTICES
BEST
ER
S
BETTER
CA
LP
GOOD
• COMPREHENSIVE
• CONSISTENT
• UNIFIED
IT SECURITY ACROSS
THE CLIENT
ORGANIZATION
FUNCTION
FORM. TIME
Two of the Concepts are:
CONSIDER
CONSIDER
INCREMENTAL
CHANGE /
EVOLUTION TO
MINIMIZE
DISRUPTION
FUNCTION
2.6
T
IEN
CL
BRINGING
PIECES INTO
PLACETO
MINIMIZE
DISRUPTION
AND PROMOTE
EFFICIENCY AND
BUY-IN
FUNCTION
S u g g es t i o ns
The distinction between goals of value unto themselves and necessary concepts is
difficult. W hen this becomes a concern, the terminology of low level goals can be
used.
Often Facts and Concepts are not easily associated with a single Goal or
Consideration. W hen this occurs, it is best to duplicate it in two or more cells of the
information index.
Illustrations are important to support visual thought. The following are examples of
security illustrations.
December 2009
12
December 2009
13