Do not start with a product demonstration. Clearly define the operational problem, inefficiency, risk or opportunity before discussing technology.
The first technology decision is deciding whether technology is actually the answer. Start by describing what is happening today, who it affects, how often it occurs, and what operational consequence it creates. There is a real difference between “we are losing too much time checking and locating equipment, expiration dates are occasionally missed, and we do not have a reliable department-wide view of inventory” and “we need an inventory tracking system.” The first describes your operation and leaves every option open. The second has already chosen the answer, and it is the sentence most departments walk into a demonstration carrying.
There is a real difference between these two sentences, and almost every technology decision a department gets wrong can be traced back to starting from the second one.
The first statement describes an operational condition. The second statement has already selected a solution.
A well-written problem statement should leave multiple possible solutions open.
A problem statement needs more than a story. Before evaluating technology, establish a baseline that describes what is happening today. The baseline does not have to be perfect, but it needs to be measurable enough that you can return to it later and determine whether anything improved.
The exact measure will be different for every problem. It may be time, errors, missed inspections, duplicate entry, response performance, overtime, expired equipment, user complaints, unavailable units, documentation delays, or another operational measure.
Do not create fake precision. If the number genuinely is not available, qualitative evidence is acceptable — but say plainly that it is qualitative, so nobody later mistakes an impression for a measurement.
If you do not establish the baseline in Step 1, Step 11 has nothing meaningful to measure against.
These may be three different people, or three different groups. They are rarely the same person, and treating them as though they are is one of the most reliable ways to lose a project at the second budget hearing.
The person or group dealing with the problem during the actual workflow.
The person responsible for the budget, purchasing decision, or funding source.
The people whose daily workflow will change if the project succeeds.
Technology projects often fail when these groups are treated as though they are the same stakeholder.
The person who wants the technology is not necessarily the person who has to live with it.
One of the most common technology-adoption mistakes is seeing a product first and writing the problem statement afterward to justify buying it.
Discovering technology at FDIC, FRI, Technology Summit International, a vendor demonstration, a conference exhibit hall, or a peer department is genuinely useful. That is how most of us learn what is possible, and there is nothing wrong with it.
The problem occurs when a department moves directly from “that is impressive” to “we need one” without stopping in between to write down what it would actually be solving.
A useful test: if your problem statement has only one possible solution, you may have written it backward from the product.
A good problem statement should leave at least three reasonable approaches open.
Sometimes the right technology decision is not to buy technology.
Departments regularly discover that part or all of the capability they are looking for already exists inside a system they own. It may never have been configured, integrated, licensed, documented, or taught to the people who need it.
This is not an optional extra step. Treat it as a precondition of finishing Step 1 — the related guide “Map the Systems You Already Have” is where to do that work.
Do not buy the second system until you understand the first one.
Today, [WHO] experiences [CURRENT CONDITION], resulting in [OPERATIONAL CONSEQUENCE]. Our current baseline is [MEASURE]. We want to improve that to [TARGET] without assuming a specific technology is the answer.
The 22 minutes above is an illustration of the format, not a figure from any real department and not a benchmark to measure yourself against. Your number comes from your own two weeks of watching.
Do not end Step 1 with “fix the problem.” Define the condition you want to create.
The target becomes the bridge between Step 1 and Step 11.
Fill this in before moving to Step 2. If a box cannot be filled, that is the part of the problem still undefined.
Download / Print the Step 1 WorksheetIf you read one thing on this subject, read this.
Where to do the work of finding out what you already own.
Why it matters
Step 1 is not finished until this has been done. Half the time the capability is already sitting unused in a system nobody was trained on.
Step 2 of the roadmap.
