Problem Statement - Wikipedia

Download as pdf or txt
Download as pdf or txt
You are on page 1of 12

Problem statement

A problem statement is a descript ion of an issue t o be addressed or a condit ion t o be improved


upon. It ident ifies t he gap bet ween t he current problem and goal. The problem st at ement should
be designed t o address t he Five Ws. The first condit ion of solving a problem is underst anding t he
problem, which can be done by way of a problem st at ement .[1]

Problem st at ement s are used by most businesses and organizat ions t o execut e process
improvement project s.[2]

Purpose
The main purpose of t he problem st at ement is t o ident ify and explain t he problem. This includes
describing t he exist ing environment , where t he problem occurs, and what impact s it has.[3]
Addit ionally, t he problem st at ement is used t o explain what t he expect ed environment looks
like.[4]

Anot her import ant funct ion of t he problem st at ement is t o be used as a communicat ion device.
A problem st at ement helps wit h obt aining buy-in from t hose involved in t he project .[3] Before t he
project begins, t he st akeholders verify t he problem and goals are accurat ely described in t he
problem st at ement . Once t his approval is received, t he project t eam reviews it t o ensure
everyone underst ands t he issue at hand and what t hey are t rying t o accomplish. This also helps
define t he project scope, which keeps t he project concent rat ed on t he overall goal.[5]
The problem st at ement is referenced t hroughout t he project t o est ablish focus wit hin t he
project t eam and verify t hey st ay on t rack. At t he end of t he project , it is revisit ed t o confirm t he
implement ed solut ion indeed solves t he problem. A well-defined problem st at ement can also aid
in performing root -cause analysis t o underst and why t he problem occurred and ensure measures
can be t aken t o prevent it from happening in t he fut ure.[2]

It is import ant t o not e t hat t he problem st at ement does not define t he solut ion or met hods of
reaching t he solut ion. The problem st at ement simply recognizes t he gap bet ween t he problem
and goal.[4][6]

Defining the problem


Before t he problem st at ement can be craft ed, t he problem must be defined.[7]

The process of defining t he problem is oft en a group effort . It st art s wit h meet ing wit h t he
st akeholders, cust omers, and/or users affect ed by t he issue (if possible) and learning about t heir
pain point s.[8] Since people oft en st ruggle wit h effect ively communicat ing t heir issues,
part icularly t o someone out side of t he process, it is helpful t o ask a series of "why" quest ions
unt il t he underlying reasoning is ident ified. This met hod, known as t he five whys, helps drill down
t o t he core problem as many of t he experienced frust rat ions could be mere sympt oms of t he
act ual problem.[6] Asking t hese addit ional quest ions as well as paraphrasing what t he st akeholder
had said demonst rat es a degree of empat hy and underst anding of t he problem.[5]

The informat ion collect ed from t hese init ial int erviews is only one part of problem analysis. Many
t imes t he problem ext ends t o mult iple areas or funct ions t o which t he st akeholders, cust omers,
and users are unaware. They may also be familiar wit h what is happening on t he surface but not
necessarily t he underlying cause. Therefore, it is just as essent ial t o gat her knowledge,
informat ion, and insight s from project t eam members and subject mat t er expert s concerning t he
problem.[8] Addit ional research mat erials, including work inst ruct ions, user manuals, product
specificat ions, workflow chart s, and previous project plans may also need t o be consult ed. Like
most ot her st ages in t he process improvement project , defining t he problem is oft en it erat ive as
several rounds of discussions may be needed t o get t he full pict ure.[2]

Once t he problem is underst ood and t he circumst ances driving t he project init iat ion are clear, it is
t ime t o writ e t he problem st at ement .
Writing the problem
statement
The problem st at ement will be used t o gain project support and approval from st akeholders. As
such, it must be act ion-orient ed.[3] More import ant ly, t he problem st at ement must be writ t en
clearly and accurat ely in order t o deliver successful result s. A poorly craft ed or incorrect
problem st at ement will lead t o a fault y solut ion, as well as wast ed t ime, money, and resources.[1]

There are several basic element s t hat can be built int o every problem st at ement t o decrease
t he risk of project failure. First , t he problem st at ement must focus on t he end user. A common
mist ake is focusing on how a problem will be solved rat her t han t he current gap. Second, t he
problem st at ement should not be t oo broad. A benefit of using t he five whys approach is t hat it
avoids over-simplicit y by providing t he det ails needed for underst anding t he problem and
developing an appropriat e solut ion. Finally, t he problem st at ement should not be t oo narrow.
Solut ion-bias st ifles t he creat ivit y t hat arises while brainst orming a solut ion, which may result in
less-t han-opt imal experience for t he user.[8]

It is useful t o design and follow a specific format when writ ing a problem st at ement . While t here
are several opt ions for doing t his, t he following is a simple and st raight forward t emplat e oft en
used in business analysis t o maint ain focus on defining t he problem.

1. Ideal: This section is used to describe


the desired or "to be" state of the
process or product. It identifies the
goals of the stakeholders and
customers as well as assists in
defining scope. At large, this section
should illustrate what the expected
environment would look like once the
solution is implemented.
2. Reality: This section is used to
describe the current or "as is" state of
the process or product. It explains
pain points expressed by the
stakeholders and customers. It
should also include the insights and
expertise of the project team and
subject matter experts provided
during problem analysis.
3. Consequences: This section is used
to describe the impacts on the
business if the problem is not fixed or
improved upon. This includes costs
associated with loss of money, time,
productivity, competitive advantage,
and so forth. The magnitude of these
effects will also help determine the
priority of the project.
4. Proposal: This section is used to
describe potential solutions. Once the
ideal, reality, and consequences
sections have been completed,
understood, and approved, the
project team can start offering
options for solving the problem. It
can also include suggestions by the
stakeholders and customers,
although further discussions and
research will be needed before a
specific course of action can be
determined.[7]

Example
Problem st at ement s can vary in lengt h, depending on t he complexit y of t he problem. The
following is an example of a simple problem st at ement for t he creat ion of a single sign-on
capabilit y:

Ideal:

Ideally, users would be able to sign into


their laptops and then automatically
have access to all of the applications
they need to use.
Reality:
In reality, at least three applications are
used every day to accomplish the work.
Each application is protected by a
password with different requirements
for username and password length.
Passwords also expire at different
times.
Consequences:

Users waste approximately two minutes


per day logging into multiple
applications (if there are 500 users, then
500 users * 2 minutes per day = 1000
minutes in lost productivity; 1000
minutes = 16.67 hrs per day * $75/hr =
$1250 per day).
Help desk resolves approximately 6,000
calls per year to reset forgotten
passwords and unlock accounts.
Security risk as users will continue to
write usernames and passwords on
sticky notes on their desks
Proposal:

Have a software developer, network


administration and business
stakeholders collaboration to evaluate
potential solutions for a single-sign on
capability.
References

1. Kush, Max (June 2015). "The


Statement Problem". Quality Progress.
48 (6).
2. Annamalai, Nagappan; Kamaruddin,
Shahrul; Azid, Ishak Abdul; Yeoh, TS
(September 2013). "Importance of
Problem Statement in Solving Industry
Problems". Applied Mechanics and
Materials. Zurich. 421: 857–863.
doi:10.4028/www.scientific.net/AMM.
421.857 (https://doi.org/10.4028%2F
www.scientific.net%2FAMM.421.857) .
S2CID 60791623 (https://api.semantic
scholar.org/CorpusID:60791623) .
3. Gygi, Craig; DeCarlo, Neil; Williams,
Bruce (2015). Six sigma for dummies.
Hoboken, NJ: John Wiley & Sons.
pp. 76–78.
4. Lindstrom, Chris (2011-04-24). "How
To Write A Problem Statement" (http://
www.ceptara.com/blog/how-to-write-p
roblem-statement) .
www.ceptara.com. Retrieved
2018-04-10.
5. Perry, Randy; Bacon, David (2010).
Commercializing Great Products with
Design for Six Sigma. Prentice Hall.
p. 18.
6. Shaffer, Deb (2017-07-12). "How to
Write a Problem Statement" (https://w
ww.proprojectmanager.com/problem-
statement/) . ProProject Manager.
Retrieved 2018-04-10.
7. Shaffer, David (2015-12-21). "Cooking
Up Business Analysis Success" (http
s://www.batimes.com/articles/cookin
g-up-business-analysis-success.htm
l) . BA Times. Retrieved 2018-04-10.
8. Widen, Steven (2018-04-02). "Take
These Steps To Define Your UI/UX
Problem And Avoid Haphazard
Changes" (https://www.forbes.com/sit
es/forbesagencycouncil/2018/04/02/t
ake-these-steps-to-define-your-uiux-pr
oblem-and-avoid-haphazard-changes/
#22f21cda7c6c) . Forbes. Retrieved
2018-04-10.

Retrieved from
"https://en.wikipedia.org/w/index.php?
title=Problem_statement&oldid=1186480347"

This page was last edited on 23 November 2023,


at 12:18 (UTC). •
Content is available under CC BY-SA 4.0 unless
otherwise noted.

You might also like