Problem statement

Last updated

A problem statement is a description of an issue to be addressed or a condition to be improved upon. It identifies the gap between the current problem and goal. The problem statement should be designed to address the Five Ws. The first condition of solving a problem is understanding the problem, which can be done by way of a problem statement. [1]

Contents

Problem statements are used by most businesses and organizations to execute process improvement projects. [2]

Purpose

The main purpose of the problem statement is to identify and explain the problem. This includes describing the existing environment, where the problem occurs, and what impacts it has. [3] Additionally, the problem statement is used to explain what the expected environment looks like. [4]

Another important function of the problem statement is to be used as a communication device. A problem statement helps with obtaining buy-in from those involved in the project. [3] Before the project begins, the stakeholders verify the problem and goals are accurately described in the problem statement. Once this approval is received, the project team reviews it to ensure everyone understands the issue at hand and what they are trying to accomplish. This also helps define the project scope, which keeps the project concentrated on the overall goal. [5]

The problem statement is referenced throughout the project to establish focus within the project team and verify they stay on track. At the end of the project, it is revisited to confirm the implemented solution indeed solves the problem. A well-defined problem statement can also aid in performing root-cause analysis to understand why the problem occurred and ensure measures can be taken to prevent it from happening in the future. [2]

It is important to note that the problem statement does not define the solution or methods of reaching the solution. The problem statement simply recognizes the gap between the problem and goal. [4] [6]

Defining the problem

Before the problem statement can be crafted, the problem must be defined. [7]

The process of defining the problem is often a group effort. It starts with meeting with the stakeholders, customers, and/or users affected by the issue (if possible) and learning about their pain points. [8] Since people often struggle with effectively communicating their issues, particularly to someone outside of the process, it is helpful to ask a series of "why" questions until the underlying reasoning is identified. This method, known as the five whys, helps drill down to the core problem as many of the experienced frustrations could be mere symptoms of the actual problem. [6] Asking these additional questions as well as paraphrasing what the stakeholder had said demonstrates a degree of empathy and understanding of the problem. [5]

The information collected from these initial interviews is only one part of problem analysis. Many times the problem extends to multiple areas or functions to which the stakeholders, customers, and users are unaware. They may also be familiar with what is happening on the surface but not necessarily the underlying cause. Therefore, it is just as essential to gather knowledge, information, and insights from project team members and subject matter experts concerning the problem. [8] Additional research materials, including work instructions, user manuals, product specifications, workflow charts, and previous project plans may also need to be consulted. Like most other stages in the process improvement project, defining the problem is often iterative as several rounds of discussions may be needed to get the full picture. [2]

Once the problem is understood and the circumstances driving the project initiation are clear, it is time to write the problem statement.

Writing the problem statement

The problem statement will be used to gain project support and approval from stakeholders. As such, it must be action-oriented. [3] More importantly, the problem statement must be written clearly and accurately in order to deliver successful results. A poorly crafted or incorrect problem statement will lead to a faulty solution, as well as wasted time, money, and resources. [1]

There are several basic elements that can be built into every problem statement to decrease the risk of project failure. First, the problem statement must focus on the end user. A common mistake is focusing on how a problem will be solved rather than the current gap. Second, the problem statement should not be too broad. A benefit of using the five whys approach is that it avoids over-simplicity by providing the details needed for understanding the problem and developing an appropriate solution. Finally, the problem statement should not be too narrow. Solution-bias stifles the creativity that arises while brainstorming a solution, which may result in less-than-optimal experience for the user. [8]

It is useful to design and follow a specific format when writing a problem statement. While there are several options for doing this, the following is a simple and straightforward template often used in business analysis to maintain focus on defining the 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 statements can vary in length, depending on the complexity of the problem. The following is an example of a simple problem statement for the creation of a single sign-on capability:

Ideal:

Reality:

Consequences:

Proposal:

Related Research Articles

<span class="mw-page-title-main">Business plan</span> Formal written document containing the goals of a business

A business plan is a formal written document containing the goals of a business, the methods for attaining those goals, and the time-frame for the achievement of the goals. It also describes the nature of the business, background information on the organization, the organization's financial projections, and the strategies it intends to implement to achieve the stated targets. In its entirety, this document serves as a road-map that provides direction to the business.

Software design is the process by which an agent creates a specification of a software artifact intended to accomplish goals, using a set of primitive components and subject to constraints. The term is sometimes used broadly to refer to "all the activity involved in conceptualizing, framing, implementing, commissioning, and ultimately modifying" the software, or more specifically "the activity following requirements specification and before programming, as ... [in] a stylized software engineering process."

In software and systems engineering, the phrase use case is a polyseme with two senses:

  1. A usage scenario for a piece of software; often used in the plural to suggest situations where a piece of software may be useful.
  2. A potential scenario in which a system receives an external request and responds to it.

User-centered design (UCD) or user-driven development (UDD) is a framework of process in which usability goals, user characteristics, environment, tasks and workflow of a product, service or process are given extensive attention at each stage of the design process. These tests are conducted with/without actual users during each stage of the process from requirements, pre-production models and post production, completing a circle of proof back to and ensuring that "development proceeds with the user as the center of focus." Such testing is necessary as it is often very difficult for the designers of a product to understand intuitively the first-time users of their design experiences, and what each user's learning curve may look like. User-centered design is based on the understanding of a user, their demands, priorities and experiences and when used, is known to lead to an increased product usefulness and usability as it delivers satisfaction to the user.

<span class="mw-page-title-main">Requirements analysis</span> Engineering process

In systems engineering and software engineering, requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements.

In product development and process optimization, a requirement is a singular documented physical or functional need that a particular design, product or process aims to satisfy. It is commonly used in a formal sense in engineering design, including for example in systems engineering, software engineering, or enterprise engineering. It is a broad concept that could speak to any necessary function, attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, internal user, or other stakeholder. Requirements can come with different levels of specificity; for example, a requirement specification or requirement "spec" refers to an explicit, highly objective/clear requirement to be satisfied by a material, design, product, or service.

<span class="mw-page-title-main">Systems development life cycle</span> Systems engineering terms

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system. The SDLC concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

Technical support, also known as tech support, is a call centre type customer service provided by companies to advise and assist registered users with issues concerning their technical products. Traditionally done on the phone, technical support can now be conducted online or through chat. At present, most large and mid-size companies have outsourced their tech support operations. Many companies provide discussion boards for users of their products to interact; such forums allow companies to reduce their support costs without losing the benefit of customer feedback.

In project management, scope statements can take many forms depending on the type of project being implemented and the nature of the organization. The scope statement details the project deliverables and describes the major objectives. The objectives should include measurable success criteria for the project.

Business analysis is a professional discipline focused on identifying business needs and determining solutions to business problems. Solutions may include a software-systems development component, process improvements, or organizational changes, and may involve extensive analysis, strategic planning and policy development. A person dedicated to carrying out these tasks within an organization is called a business analyst or BA.

<span class="mw-page-title-main">Systems architect</span>

The systems architect is an information and communications technology professional. Systems architects define the architecture of a computerized system in order to fulfill certain requirements. Such definitions include: a breakdown of the system into components, the component interactions and interfaces, and the technologies and resources to be used in its design and implementation.

In software engineering, behavior-driven development (BDD) is a software development process that encourages collaboration among developers, quality assurance experts, and customer representatives in a software project. It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave. It emerged from test-driven development (TDD) and can work alongside an agile software development process. Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.

Software project management is the process of planning and leading software projects. It is a sub-discipline of project management in which software projects are planned, implemented, monitored and controlled.

Object-oriented design (OOD) is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design.

Eight Disciplines Methodology (8D) is a method or model developed at Ford Motor Company used to approach and to resolve problems, typically employed by quality engineers or other professionals. Focused on product and process improvement, its purpose is to identify, correct, and eliminate recurring problems. It establishes a permanent corrective action based on statistical analysis of the problem and on the origin of the problem by determining the root causes. Although it originally comprised eight stages, or 'disciplines', it was later augmented by an initial planning stage. 8D follows the logic of the PDCA cycle. The disciplines are:

<span class="mw-page-title-main">Functional specification</span>

A functional specification in systems engineering and software development is a document that specifies the functions that a system or component must perform.

In project management, a project charter, project definition, or project statement is a statement of the scope, objectives, and participants in a project. It provides a preliminary delineation of roles and responsibilities, outlines the project's key goals, identifies the main stakeholders, and defines the authority of the project manager.

In requirements engineering, requirements elicitation is the practice of researching and discovering the requirements of a system from users, customers, and other stakeholders. The practice is also sometimes referred to as "requirement gathering".

<span class="mw-page-title-main">Misuse case</span>

Misuse case is a business process modeling tool used in the software development industry. The term Misuse Case or mis-use case is derived from and is the inverse of use case. The term was first used in the 1990s by Guttorm Sindre of the Norwegian University of Science and Technology, and Andreas L. Opdahl of the University of Bergen, Norway. It describes the process of executing a malicious act against a system, while use case can be used to describe any action taken by the system.

User research focuses on understanding user behaviors, needs and motivations through interviews, surveys, usability evaluations and other forms of feedback methodologies. It is used to understand how people interact with products and evaluate whether design solutions meet their needs. This field of research aims at improving the user experience (UX) of products, services, or processes by incorporating experimental and observational research methods to guide the design, development, and refinement of a product. User research is used to improve a multitude of products like websites, mobile phones, medical devices, banking, government services and many more. It is an iterative process that can be used at anytime during product development and is a core part of user-centered design.

References

  1. 1 2 Kush, Max (June 2015). "The Statement Problem". Quality Progress. 48 (6).
  2. 1 2 3 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. S2CID   60791623.
  3. 1 2 3 Gygi, Craig; DeCarlo, Neil; Williams, Bruce (2015). Six sigma for dummies. Hoboken, NJ: John Wiley & Sons. pp. 76–78.
  4. 1 2 Lindstrom, Chris (2011-04-24). "How To Write A Problem Statement". www.ceptara.com. Retrieved 2018-04-10.
  5. 1 2 Perry, Randy; Bacon, David (2010). Commercializing Great Products with Design for Six Sigma . Prentice Hall. p. 18.
  6. 1 2 Shaffer, Deb (2017-07-12). "How to Write a Problem Statement". ProProject Manager. Retrieved 2018-04-10.
  7. 1 2 Shaffer, David (2015-12-21). "Cooking Up Business Analysis Success". BA Times. Retrieved 2018-04-10.
  8. 1 2 3 Widen, Steven (2018-04-02). "Take These Steps To Define Your UI/UX Problem And Avoid Haphazard Changes". Forbes. Retrieved 2018-04-10.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.