An app is one option. Start with the process.
A team receives requests by email, records information in Excel and checks each case’s status across several messages. When errors and delays appear, a proposal emerges: ‘We need an application’. The idea may make sense, but you still need to explain what is failing, how much it affects the work and why it happens.
Process digitization is easier to steer when you separate the problem from the proposed solution. This journey helps you describe the current situation, investigate causes and decide which needs a change must meet. You can apply it using simple records and conversations with the people who do the work.
- 01Understand what is happeningProcess and observable problems
- 02Explain what you need and whyObjectives, causes and evidence
- 03Choose and checkAlternatives, actions and results
Step 01
Understand the current process
Choose a request type and follow several real cases from beginning to end, including one that caused problems. Identify how they arrive, who is involved, which decisions are made, which tools are used and when you consider a request complete.
Distinguish working time from waiting time. A request may need ten minutes of review and spend two days waiting for information. Also note exceptions: who returns an incomplete case, how a priority is communicated and where a change is recorded.
A shared description of the process, who is responsible, where decisions happen and where work changes hands. Check with the people doing the work that it covers everyday cases and exceptions.
Step 02
Identify and quantify problems
Look for errors, waits, incomplete requests, rework and missing follow-up. ‘Excel is chaos’ expresses a perception; ‘there are requests whose status nobody can determine’ describes a problem you can investigate.
To quantify it, set the period, number of requests reviewed and measurement criterion. Count how many cases it affects and, where possible, its impact on time, cost or deadlines. If several problems affect the same request, avoid adding their contributions as if they were separate cases.
- Observation
- What you have seen: someone returns a request because information is missing.
- Available data
- What you can measure: returned cases, total requests and time spent correcting them.
- Hypothesis
- An explanation to check: perhaps different areas interpret mandatory information differently.
If data is missing, note what you need and agree how to collect it. Estimates can help if you explain their source. Do not present them as measurements.
Step 03
Define the expected outcome
Specify what must improve, for whom and by when. ‘Having an application’ describes a deliverable. ‘Reducing returns for incomplete information’ describes a process outcome.
Choose an indicator, an initial situation and a target whose feasibility you will review. Agree how it will be measured and which conditions must remain the same, such as the volume handled or response quality. You can then check whether the change improves the problem that prompted it.
If we delivered the application and this indicator did not improve, would we consider the problem solved?
Step 04
Investigate the causes
Email and Excel are process tools; their presence does not prove they cause the problems. Returned requests might relate to unclear criteria, information the requester does not know or changes in the needs of whoever receives the work.
Root-cause analysis means looking for explanations, not stopping at symptoms. For each possible cause, ask what would support it, what would contradict it and how you could check it using records and observations.
Compare complete and incomplete requests, review the instructions their authors received and observe how information is validated. Two facts coinciding is not enough to prove causality. Keep the explanation as a hypothesis until you have sufficient evidence; several causes may be relevant.
Step 05
Identify needs and evaluate solutions
A need explains what the process must enable to improve. For example, having the minimum information before starting a review. A form with validations is one possible way to meet it; you could also clarify the criteria and improve the current template.
These links are examples. Before choosing a feature, check the evidence about the problem and its causes, and compare other options.
Scroll the table horizontally to read the alternatives and their conditions.
| Problem | Possible feature | What to check before choosing |
|---|---|---|
| Incomplete requests | Form with input checks | Which details are missing, why, and whether people can provide them when making the request. Compare a form with clearer templates and instructions. |
| Inefficient manual distribution | Assignment rules | Check whether assignment causes the waits and whether clear rules exist. Compare rules with giving one person clear responsibility for incoming work. |
| Lack of traceability | Statuses and history | Which changes need a record, who reads it and who keeps it up to date. Compare this with a simple shared log. |
| Lack of follow-up | Management indicators | Which decisions the indicators will help with, what data they need and how often. Compare them with regular reviews of the records you already have. |
Some improvements can be achieved by changing the process without developing new software. Also evaluate maintenance, data quality and ease of use. Automating an unnecessary activity can preserve the problem in another tool.
Step 06
Prioritize and plan
Separate what you need to reach the objective from improvements that can wait. Compare expected impact, effort, dependencies and risks. State where you are still unsure.
For each action, name an owner, a deadline, the people affected and how you will check it. Set shared criteria before defining input checks. A small trial can help you choose, with clear reasons to continue, adjust or stop.
Step 07
Check results
Compare indicators before and after implementing changes using the same measurement criterion and comparable periods. Check whether volume, request types or other conditions have changed and could explain part of the difference.
Also check unintended effects. Reducing incomplete requests is of little use if people stop submitting them because the form is hard to use. If the outcome does not reach the target, review the evidence and hypotheses; finishing development does not mean the problem has been solved.
Fictitious, illustrative case · Not a real experience
From ‘we want an application’ to a well-founded brief
Imagine a team that, in one week of this fictitious scenario, receives 100 requests and returns 30 for missing information. It spends 10 hours reviewing and correcting requests. It wants to study whether that time can be reduced to 6 hours a week within eight weeks, with comparable volume and no loss of quality.
- Initial situation
- 10 h / week
- Proposed objective
- 6 h / week
- Gap
- 4 h / week
These data describe a gap, but do not prove its cause. The team suggests that intake criteria might be ambiguous. To check this, it agrees to review missing data, instructions received and correction time for each case. It will also check how much returns contribute to those ten hours.
How the conversation changes
‘We have defined the problem of returned requests, the time objective and the needs to evaluate: clear minimum information, a validation owner and a record of each request’s status. Before commissioning an application, we will check the causes and compare improving the current template with creating a form.’
The outcome of this example is an initial analysis and an investigation plan. Needs still await validation; there are no achieved savings, approved features or complete specification.
A guide for working through your reasoning
How POLARIS can support you
POLARIS is an AI assistant for analyzing problems through seven conversational phases. You can provide your process context, review what you know and need to investigate, define objectives and assess improvement proposals.
- Understand the need
- Identify problems and measure their impact
- Define the objective
- Investigate the causes
- Design and evaluate solutions
- Plan implementation
- Check the results
You provide and check the evidence, validate hypotheses and decide which actions to take. POLARIS can help structure the needs you identify; it does not automatically generate a complete functional specification or develop or deploy applications.