How to Write a Problem Statement

Project management is all about solving problems and delivering results. When your manager comes to you with a project proposal, it’s because there’s a business issue that needs resolution. Part of the job of a project manager is to define that problem so that it is solvable, then develop the plan, the schedules, and handle the deliverables.

It all starts with the problem statement.

As important as the problem statement is in creating a plan that solves it, PMI doesn’t focus on problem statements. On page 236 of the Project Management Book of Knowledge (PMBOK), 5th edition, the only reference to “problem statement” appears in the Project Quality Management section under Cause and Effect Diagrams: “The problem statement typically describes the problem as a gap to be closed or as an objective to be achieved.”

In the 6th Edition of the PMBOK, we get even less direction. On page 415, under Data Analysis, the reference is to use a problem statement as part of a root cause analysis. “It can be used to identify threats by starting with a problem statement…”

All well and good – but not much help in developing a problem statement.

Focus on the problem that the team needs to solve is important. But how do you get there?

“We cannot solve our problems with the same thinking we used to create them” ~Albert Einstein

Let’s borrow some tips from process managers to get to define the problem. There are several ways to do this.

Problem Definition

Start by answering a few basic questions:

• Who is affected by this problem?
• How are they affected?
• When does this problem occur?
• Where does it occur?
• What is the outcome of the problem in terms of revenue, productivity, operations, or production?

For example – The sales team is currently emailing Word document lead reports to their supervisors on Friday. Every report is different because there is no standard enforced. Each Monday the supervisors spend the entire day rounding up the reports, transferring the sales data into a spreadsheet, and compiling another report to send to upper management.

Upper Management wants to reduce the amount of time it takes to compile these reports to free the sales managers up to close more business.

Who is affected? The sales team members and the managers. You might even make a case that upper management is affected because as long as managers are compiling reports, they are not closing business.

How are they affected? The sales team is writing personal reports, managers are trying to compile results and report them up, and senior managers are making decisions based on these reports. The amount of time used to compile these reports seems excessive, particularly for the managers.

When does the problem occur: Every week.

Where does the problem occur: Mainly at headquarters.

The outcome? Manager productivity is less than optimal, data could be suspect, and there is no central source of information.

The 5-Why’s

When trying to get to the root of the problem, it’s handy to use a technique called the 5-Whys. Keep asking “why” until you get to the root of the problem. The sales team’s process has several issues. Managers spending an entire day gathering data and preparing reports seems like an important issue. For example:

• Why is there no standard lead report? Because salespeople don’t seem to like a standard template.
• Why not? Because they can’t be descriptive with a template.
• Why do they need to be descriptive? Because they want to describe their meetings with potential leads.
• Why do they need to describe meetings? Is that data put in the report to upper management? Well, no. Upper management is only interested in lead generation, the number of contacts, the status of orders, and actual sales complete.
• Why couldn’t we have the salespeople enter the important numbers into a spreadsheet or database directly for the reports to upper management and save the descriptions for direct managers? Because we don’t have the technology to do that.
• Why don’t we acquire or develop the technology? Because we don’t have the budget.
• Why don’t we request the budget? Because no one ever thought managers spending an entire day on reporting was a problem to solve.

The point is to keep drilling down through this until the real reason is revealed. This can get uncomfortable for many managers because often they feel too busy to evaluate the “why” of doing certain processes.

Sample Problem Statement

Once the team has peeled back the issues and found the actual problem, it’s time to write your problem statement. You’re not solving the problem here – just stating what the problem is and the ramifications of not solving it. Some companies also include the possible methods for solving the problem – but not the actual solution. The solution is found in the deliverables section of the project plan.

In our sample case, this could be the problem statement.

Sales managers are spending 20% of their time each week receiving and compiling sales reports for upper management, reducing the number of hours spent on mentoring sales staff, lead generation, and closing business. This is a productivity issue, and ignoring it results in decreased sales and missed revenue targets over the past 3 months. XYZ Company is committed to reducing the time spent compiling reports to no more than 10% of the sales manager’s time in any week.

By examining the current sales report processes for duplicative and wasted effort, XYZ Company can determine how to reduce the amount of time sales managers spend on compiling reports.

Keep in mind that management might want to revise this statement until everyone can agree. It’s important to get this right so the team knows where to focus attention.

Problem Statement Template

Here’s a template for a problem statement. In the parenthesis replace the suggestions your own words to express your company’s situation.

Problem: (department or affected personnel) are (current situation with quantification, including timeframes), (ramifications of the current situation). This is a (productivity, expense, liability) issue and results in (decreased sales, wasted time, lowered productivity, lost revenue, increased expenses).

XYZ company is going to (examine our processes, determine the root causes through review, generate a business plan, implement a specific piece of software) in order to (reduce expenses, increase revenue, increase productivity, decrease liability).

After the problem statement is created and approved, it’s time to move on to possible solutions. But that’s another blog post. For an earlier discussion of problem statements and project plans, go here.

For more detail on creating a problem statement, this is a good explanation.

Do you create problem statements in your project plans? Let us know in the comments.

Want a copy of this post?