Choose an observable problem
A first project benefits from a visible problem within a manageable scope. Irregular delays, frequent rework or incomplete cases can be starting points. Avoid an ambition too broad for any team to act on. The initial question should describe a gap experienced by a customer or process user without prescribing a solution.
Listen to those involved
Customers explain consequences; teams describe what actually happens. Both views matter. A procedure may describe a simple route while daily work contains exceptions. Short interviews, observation and case examples help understand constraints without assigning blame. Scope should reflect this reality.
Set the scope
Specify where the studied process begins and ends, which requests are included and which teams participate. This avoids comparing unlike cases or piling up conflicting goals. Exclusions should be explicit. If the project concerns ordinary requests, urgent cases may need separate analysis. Clear scope helps data collection and ownership.
Choose a useful measure
Total lead time may run from receiving a request to resolving it. Rework rate counts cases returned for correction. Define start and end events precisely. A vague measure creates endless debate when results change. Record exceptional cases too, so variation can be understood instead of hidden in an average.
Establish a baseline
Before setting a target, collect data over a representative period. Check missing data, duplicates and changes in recording method. A reliable baseline separates real change from a change in counting. If volumes are low, complement figures with observation and keep conclusions cautious.
Do not begin with a solution
Automating a form, recruiting or training may sound appealing. Yet if delays come from ambiguous decision criteria, such actions may only move the problem. List plausible causes and look for ways to test them. A flow map, representative cases and discussion with the team often beat an early imposed hypothesis.
Plan a first experiment
When evidence supports a cause, choose a limited measurable change. Specify who applies it, for how long and what effects will be observed. Watch for unintended effects: removing a step may speed flow but increase errors. A short trial helps learning before scaling without turning a guess into a promise.
Prepare follow-up
A project does not end when the first measure improves. Agree on monitoring frequency, ownership and responses to exceptions. Document decisions and test conditions. This makes improvement transferable and allows revision of a solution that does not last. Coaching can help maintain this discipline.
A concrete situation
A Tunisian administrative team might choose routine document requests as its first scope. It would define the beginning and end of lead time, record incomplete cases and note exceptions. After several weeks, the team would compare suspected causes with observed cases before changing a form or approval route. This discipline prevents a strong impression from becoming an untested explanation. Follow-up includes feedback from staff and service users.