How to Write a Problem Statement
How to Write a Problem Statement
A problem statement is a short, succinct explanation of a problem a business is facing and a proposed solution to the problem. Problem statements can be effective ways to define an issue and communicate a solution within a short span of time. Before you write your problem statement, think about the problem and your proposed solution, and be prepared to back it up with facts!
Steps

Writing Your Own Problem Statement

Describe the "ideal" state of affairs. There are lots of different ways to write a problem statement — some sources will recommend jumping right to the problem itself, while others recommend providing background context first so that problem (and its solution) are easier to understand for the reader. If you're ever unsure of how to begin, opt for the latter option. While conciseness is something every piece of practical writing should aim for, it's even more important to be well-understood. Start by describing how things should work. Before you even mention your problem, explain in a few sentences how things would be if the problem didn't exist. For instance, let's say that you work at a major airline and that you've noticed that the way passengers board your planes is an inefficient use of time and resources. In this case, you might begin your problem statement by describing an ideal situation where the boarding system isn't inefficient that the company should shoot for, like this: "The boarding protocols used by ABC Airlines should aim to get each flight's passengers aboard the plane quickly and efficiently so that the plane can take off as soon as possible . The process of boarding should be optimized for time-efficiency but also should be straightforward enough that it can be easily understood by all passengers."

Explain your problem. In the words of the inventor Charles Kettering, "A problem well-stated is a problem half-solved." One of the most important goals (if not the most important goal) of any problem statement is to articulate the problem being addressed to the reader in a way that's clear, straightforward, and easy to understand. Succinctly summarize the problem you intend to solve — this cuts to the heart of the issue immediately and positions the most important information in the problem statement near the top, where it's most visible. If you've just started an "ideal" state of affairs as suggested above, you may want to start your sentence with phrasing like "However, ..." or "Unfortunately, ..." to show that the problem you've identified is what is preventing the ideal vision from being a reality. Let's say that you think you've developed a quicker, more efficient system for getting passengers aboard our planes than the typical "back to front" seating system. In this case, you might continue with a few sentences like, "However, ABC Airline's current passenger boarding system is an inefficient use of the company's time and resources. By wasting employee man-hours, the current boarding protocols make the company less competitive, and by contributing to a slow boarding process, they create an unfavorable brand image." Try to stress the problem's urgency in your explanation.

Explain your problem's financial costs. Soon after you state your problem, you'll want to explain why it's a big deal — after all, no one has the time or resources to try to solve every single minor problem. In the business world, money is almost always the bottom line, so you'll want to try to highlight the financial impact of your problem on the company or organization you're writing for. For instance, is the problem you're discussing keeping your business from making more money? Is it actively costing your business money? Is it damaging your brand image and thus indirectly costing your business money? Be as exact and specific about the financial burden of your problem — try to specify an exact dollar amount (or a well-supported estimate) for your problem's cost. For our airline example, you might proceed to explain the problem's financial cost like this: "The inefficiency of the current boarding system represents a significant financial burden for the company. On average, the current boarding system wastes roughly four minutes per boarding session, resulting in a total of 20 wasted man-hours per day across all ABC flights. This represents a waste of roughly $400 per day or $146,000 per year."

Back up your assertions. No matter how much money you claim your problem is costing your company, if you can't back up your claims with reasonable evidence, you may not be taken seriously. As soon as you start making specific claims about how serious your problem is, you'll need to start supporting your statements with evidence. In some cases, this may be from your own research, from data from a related study or project, or even from reputable third-party sources. In some corporate and academic situations, you may need to explicitly reference your evidence in the text of your problem statement, while in other situations, it may be enough to simply use a footnote or another form of shorthand for your citations. If you're unsure, ask your boss or teacher for advice. Let's reexamine the sentences used in the previous step. They describe the cost of the problem but don't explain how this cost was found. A more thorough explanation might include this: "...Based on internal performance tracking data, on average, the current boarding system wastes roughly four minutes per boarding session, resulting in a total of 20 wasted man-hours per day across all ABC flights. Terminal personal are paid an average of $20 per hour, so this represents a waste of roughly $400 per day or $146,000 per year." Note the footnote — in an actual problem statement, this would correspond to a reference or appendix containing the data mentioned.

Propose a solution. When you've explained what the problem is and why it's so important, proceed to explain how you propose to deal with it. As with the initial statement of your problem, your explanation of your solution should be written to be as clear and concise as possible. Stick to big, important, concrete concepts and leave any minor details for later — you'll have plenty of opportunities to get into every minor aspect of your proposed solution in the body of your proposal. In our airline example, our solution to the problem of inefficient boarding practices is this new system you've discovered, so you should briefly explain the broad strokes of this new system without getting into the minor details. You might say something like, "Using a modified boarding system proposed by Dr. Edward Right of the Kowlard Business Efficiency Institute which has passengers board the plane from the sides in rather than from the back to the front, ABC Airlines can eliminate these four minutes of waste." You might then go on to explain the basic gist of the new system, but you wouldn't use more than a sentence or two to do this, as the "meat" of our analysis will be in the body of the proposal.

Explain the benefits of the solution. Again, now that you've told your readers what should be done about the problem, it's a very good idea to explain why this solution is a good idea. Since businesses are always trying to increase their efficiency and earn more money, you'll want to focus primarily on the financial impact of your solution — which expenses it will reduce, which new forms of revenue it will generate, and so on. You can also explain non-tangible benefits, like improved customer satisfaction, but your total explanation shouldn't be too much longer than a few sentences to a paragraph. In our example, you might briefly describe how our company could conceivably benefit from the money saved with our solution. A few sentences along these lines might work: "ABC Airlines stands to benefit substantially from the adoption of this new boarding program. For instance, the $146,000 in estimated yearly savings can be re-directed to new sources of revenue, such as expanding its selection of flights to high-demand markets. In addition, by being the first American airline to adopt this solution, ABC stands to gain considerable recognition as an industry trendsetter in the areas of value and convenience."

Conclude by summarizing the problem and solution. After you've presented the ideal vision for your company, identified the problem keeping you from achieving this ideal, and suggested a solution, you're almost done. All that's left to do is to conclude with a summary of your main arguments that allows you to transition easily into the main body of your proposal. There's no need to make this conclusion any longer than it needs to be — try to state, in just a few sentences, the basic gist of what you've described in your problem statement and the approach you intend to take in the body of the article. In our airline example, you might conclude like this: "Optimization of current boarding protocols or adoption of new, more-effective protocols is crucial for the continued competitiveness of the company. In this proposal, the alternative boarding protocols developed by Dr. Right are analyzed for their feasibility and steps for effective implementation are suggested." This sums up the main point of the problem statement — that the current boarding procedure isn't very good and that this new one is better — and tells the audience what to expect if they continue reading. Be sure to mention the possible consequences if the solution isn't implemented.

For academic work, don't forget a thesis statement. When you have to write a problem statement for school, rather than for work, the process will be largely the same, but there may be extra items you'll need to take into account to assure a good grade. For instance, many composition classes will require you to include a thesis statement in your problem statement. The thesis statement (sometimes just called the "thesis") is a single sentence that summarizes your entire argument, boiling it down to its bare essentials. A good thesis statement identifies both the problem and the solution as succinctly and clearly as possible. For instance, let's say you're writing a paper on the problem of academic essay mills — companies that sell pre-written and/or custom works for students to purchase and turn in as their own work. As our thesis statement, you might use this sentence, which acknowledges the problem and the solution we're about to propose: "The practice of buying academic essays, which undermines the learning process and gives an advantage to rich students, can be combated by providing professors with stronger digital analysis tools." Some classes explicitly require you to put your thesis sentence at a certain place in your problem statement (for instance, as the very first or very last sentence). Other times, you'll have more freedom — check with your teacher if you're not sure.

Follow the same process for conceptual problems. Not all problem statements are going to be for documents dealing with practical, tangible problems. Some, especially in academics (and especially in the humanities), are going to deal with conceptual problems — problems that have to do with the way you think about abstract ideas. In these cases, you can still use the same basic problem statement framework to present the problem at hand (while obviously shifting away from a business focus). In other words, you'll want to identify the problem (often, for conceptual problems, this will be that some idea is not well-understood), explain why the problem matters, explain how you plan to solve it, and sum up all of this in a conclusion. For instance, let's say that we're asked to write a problem statement for a report on the importance of religious symbolism in The Brothers Karamazov by Fyodor Dostoevsky. In this case, our problem statement should identify some poorly-understood aspect of the religious symbolism in the novel, explain why this matters (for instance, you might say that by better understanding the religious symbolism in the novel, it's possible to draw new insights from the book), and layout how you plan to support our argument.

Polishing Your Problem Statement

Be concise. If there's one thing to keep in mind when writing problem statements, it's this. Problem statements shouldn't be any longer than they need to be to accomplish their task of laying out the problem and its solution for the reader. No sentence should be wasted. Any sentence that doesn't directly contribute to the problem statement's goals should be removed. Use clear, direct language. Don't get bogged down in minor details — problem statements should deal only with the essentials of your problem and solution. In general, keep your problem statement as short as possible without sacrificing its informativeness. A problem statement is no place to add your own personal commentary or "flavor", as this makes the problem statement longer for no practical purpose. You may or may not have the opportunity to be more long-winded in the body of your document, depending on the seriousness of your topic and audience.

Write to your audience. When making a problem statement, it's important to remember that you're writing for someone else, not for yourself. Different audiences will have different sets of knowledge, different reasons for reading, and different attitudes toward your problem, so try to keep your intended audience in mind as you write. You want your problem statement to be as clear and easy for your audience to understand as possible, which means you may need to change your tone, style, and diction from one audience to another. As you write, try to ask yourself questions like: "Who, specifically, am I writing for?" "Why am I addressing this audience?" "Does this audience know all of the same terms and concepts as I do?" "Does this audience share the same attitude as I do towards this problem?" "Why should my audience care about this problem?"

Don't use jargon without defining it. As noted above, your problem statement should be written so that it's as easy for your audience to understand as possible. This means that, unless you're writing for a technical audience that is likely to be knowledgeable in the terminology of the field you're writing about, you'll want to avoid using technical jargon too heavily and to make sure that you define any pieces of jargon that you do use. Never make the assumption that your audience automatically has all of the technical knowledge that you do or you risk alienating them and losing readers as soon as they encounter terms and information they're not familiar with. For instance, if we're writing for a board of highly-educated physicians, it may be OK to assume that they'll know what the term "metacarpal" means. However, if we're writing to an audience made up of both physicians and wealthy hospital investors who may or may not be medically trained, it's a good idea to introduce the word "metacarpal" with its definition- the bone between the first two joints of the finger.

Stick to a narrow, defined problem. The best problem statements aren't sprawling, rambling pieces of writing. Instead, they're focused on a single, easily-identified problem and its solution. Generally, narrow, defined topics are easier to write convincingly about than large, vague ones, so whenever possible, you'll want to keep the scope of your problem statement (and thus the body of your document) well-focused. If this makes your problem statement (or the body of your document) short, this is usually a good thing (except in academic situations where you have minimum page limits for your assignment). A good rule of thumb is to only address problems that you can definitively solve beyond a shadow of a doubt. If you're not sure of a definitive solution that can solve your entire problem, you may want to narrow the scope of your project and change your problem statement to reflect this new focus. To keep the scope of a problem statement under control, it can be helpful to wait until after completing the body of the document or proposal to write the problem statement. In this case, when you write your problem statement, you can use our actual document as a guideline so that you don't have to guess about the ground you may cover when you write it.

Remember the "five Ws". Problem statements should be as informative as possible in as few words as possible, but shouldn't delve into minute details. If you're ever in doubt of what to include in your problem statement, a smart idea is to try to answer the five Ws (who, what, where, when, and why), plus how. Addressing the five Ws gives your reader a good baseline level of knowledge to understand the problem and solution without treading into unnecessary levels of detail. For instance, if you're writing a problem statement to propose a new building development to your local city council, you might address the five Ws by explaining who the development would benefit, what the development would require, where the development should be, when construction should begin, and why the development is ultimately a smart idea for the city.

Use a formal voice. Problem statements are almost always used for serious proposals and projects. Because of this, you'll want to use a formal, dignified writing style (the same as the style hopefully used for the body of the document) in the problem statement. Keep your writing clear, plain, and direct. Don't attempt to win your reader over by taking a friendly or casual tone in your problem statement. Don't use humor or jokes. Don't include pointless asides or anecdotes. Don't use slang or colloquialisms. Good problem statements know that they have a job to accomplish and don't waste any time or ink on unnecessary content. The closest you can usually get to including purely "entertaining" content in academic writing in the humanities. Here, occasionally, it's possible to encounter problem statements that begin with a quote or epigraph. Even in these cases, however, the quote has some bearing on the problem being discussed and the rest of the problem statement is written in a formal voice.

Always proofread for errors. This is a must for all forms of serious writing — no first draft has ever existed that couldn't have benefited from the careful eye of a good proofreader. When you finish your problem statement, give it a quick read. Does it seem to "flow" properly? Does it present its ideas coherently? Does it seem to be logically organized? If not, make these changes now. When you're finally satisfied with the structure of your problem statement, double-check it for spelling, grammar, and formatting errors. You'll never regret re-reading your problem statement before you turn it in. Since, by its very nature, the problem statement is usually the first part of a proposal or report that someone will read, any errors here will be especially embarrassing for you and can even reflect negatively on your entire document.

What's your reaction?

Comments

https://sharpss.com/assets/images/user-avatar-s.jpg

0 comment

Write the first comment for this!