PROVE · P · PINPOINT THE OPPORTUNITY

How to write a problem statement for an IT request

A good IT problem statement names who is affected, what it costs and what success looks like, without prescribing a solution. Use this template and examples.

By Jason Rhoads · · 3 min read

Most IT requests arrive as solutions. "We need a dashboard." "Can we add a field to the order screen?" "We should move to a new ERP." Each may be the right answer, but without the problem behind it, nobody can tell whether it is, or whether something simpler would work better.

A problem statement fixes that. It takes five minutes to write and saves weeks of building the wrong thing.

What a good IT problem statement contains

A useful problem statement answers five questions:

  1. Who is affected? A specific group, such as "accounts payable clerks" or "field supervisors in the South region," not "the business."
  2. What happens today? The current behavior or process, described factually.
  3. What does it cost? Time, money, errors, risk, customer impact. Rough numbers are fine.
  4. What should happen instead? The desired outcome, described as a result, not a feature.
  5. How will we know it's solved? A measure and a target.

Notice what's missing: the solution. A problem statement deliberately leaves the "how" open, so the people who know the technology can propose options.

A template you can use today

Who: [specific group of people] Today: [what happens now] Cost: [time, money, errors, risk; estimate if needed] Instead: [the result we want] Measure: [how we'll know, with a target]

Three examples, before and after

Example 1: the dashboard request

Before: "We need a sales dashboard."

After:

  • Who: regional sales managers (14 people).
  • Today: each manager spends about 3 hours every Monday combining CRM exports in spreadsheets to see pipeline by rep.
  • Cost: about 42 hours a week, and forecasts arrive Tuesday instead of Monday morning.
  • Instead: managers see current pipeline by rep without manual work.
  • Measure: weekly preparation time under 30 minutes; forecast submitted by 10 a.m. Monday.

The dashboard may still be the answer. But now it competes on a clear value (about 40 hours a week) and might lose to a simpler fix, such as a scheduled CRM report.

Example 2: the field request

Before: "Add a 'reason code' field to the returns screen."

After:

  • Who: the returns analysis team.
  • Today: return reasons are typed as free text, so they can't be grouped.
  • Cost: the team can't identify the top causes of returns, which cost about $1.2M a year.
  • Instead: return reasons can be analyzed by category.
  • Measure: 90% of returns categorized; top five causes reported monthly.

Example 3: the platform request

Before: "Migrate to the new ERP."

After:

  • Who: finance, procurement and inventory teams.
  • Today: the current ERP is out of vendor support next year and month-end close takes 9 days.
  • Cost: unsupported-software risk; about 40 staff days per close.
  • Instead: a supported system and a faster close.
  • Measure: vendor-supported by the end of next year; month-end close in 5 days.

This one reveals two objectives (risk and speed) that may justify different scopes. That is exactly the conversation a problem statement should provoke.

Common mistakes

  • Smuggling in the solution. "Users can't see data because we don't have a dashboard" assumes the answer. Describe what users can't do, not what they don't have.
  • Vague populations. "Everyone" is never true and can't be measured.
  • No cost at all. If the requester can't estimate any cost, ask what happens if nothing is done. If the honest answer is "nothing much," you've learned something useful.
  • Measures nobody can collect. A target is only useful if someone can actually measure it. Agree on the data source up front.

Where problem statements fit in your process

Problem statements belong at the very start of your intake process. Make the five fields required on the request form, and don't schedule a request for review until they are filled in. Expect some pushback at first. Within a couple of months, requesters start thinking in problems, and the quality of your whole pipeline improves.

They also make prioritization possible. Once every request states its cost and target, you can compare them on value and complexity. See IT portfolio prioritization.

How Aizu helps

Aizu's intake records the problem and intended outcome with each request, along with the accountable owner and the product it affects. Items without enough context are flagged as needing it, rather than silently moving forward. The problem and objective then stay attached through assessment, approval and outcome measurement. Related: The hidden cost of unclear project objectives.

Frequently asked questions

How long should an IT problem statement be?

A short paragraph or five brief fields. If it runs to pages, it has become a business case, which is a later and more detailed step for larger investments.

What if the requester doesn't know the cost?

Ask for an estimate with a confidence level, or ask what happens if nothing is done. A rough number is far better than none, and it can be refined during assessment.

Should IT write the problem statement for the business?

IT can help, but the requester should own it. The person who has the problem is best placed to describe it and to agree on how success is measured.