All three may be partly right. None of the explanations tells you what actually happened to that request over time.
Construction workflow bottlenecks are easier to investigate when repeat work has a usable event record. Before buying process-mining software, capture enough evidence to follow one request through the decisions that matter.
Start with one repeat workflow
Choose a process with recognizable cases and outcomes, such as clarification requests, purchase approvals or an internal document review. Avoid beginning with "the whole business."
Define where the case starts and ends. State the decision you want the analysis to support. You might need to understand where requests wait, why they return for correction or which handoff repeatedly loses ownership.
The RFI workflow provides an example of a repeat record with a meaningful identity. The analysis should examine its path, not combine every message about a project into one ambiguous case.
Process boundaries matter because a short internal review and a long external response interval may require entirely different improvements.
Record events with consistent meanings
Process-mining guidance identifies the case, activity and timestamp as basic event data. For a practical pilot, record the event that occurred, the case it belongs to and its time on a consistent basis.
Useful events might include received, assigned, returned for information, resubmitted, reviewed and closed. Define what each means before collecting the data.
Do not assume a database's last-modified time is the time of a particular review. A record may have been edited later for an unrelated reason. Identify the source and limitations of each event.
Role or team information can help explain a handoff, but collect only what the analysis needs and protect private data. An operational event log should not become an unapproved employee-surveillance system.
Distinguish elapsed time from effort
The interval between two timestamps tells you how much calendar time passed. It does not tell you how long someone actively worked on the case.
It may include nights, weekends, external waiting or time before the next approved review session. Working-time calculations need a defined calendar and reliable event meanings.
Do not label the longest interval as the slowest employee. A queue can be blocked by missing information, unclear authority or limited review capacity. The visible owner may not control the cause.
Keep those limits beside the findings. A precise elapsed-time calculation can otherwise make an unsupported explanation look scientific.
Follow one hypothetical request
Imagine a request received on Monday at 9:00, assigned at 9:20, reviewed on Tuesday at 11:00 and returned for missing information at 11:15. The requester supplies the missing detail later that day.
The record shows a long interval before the first review and a correction loop. It does not prove that the reviewer spent that entire interval idle or that reviewing faster would have eliminated the missing information.
Examine a sample of comparable cases. Are incomplete requests recognized at intake? Is assignment correct? Does the reviewer receive a manageable queue? Keep the questions separate so an improvement can target an actual cause.
These are illustrative timestamps, not a client result or a measured Blackwing performance claim.
Check data quality before interpreting the pattern
Look for missing cases, duplicated events, impossible sequences and timestamps recorded on different time-zone bases. Explain what the sample excludes.
A request marked closed and later reopened should retain both events. Replacing the earlier closure may hide the correction path. Likewise, cases still open at the analysis date should not disappear because their completion time is unavailable.
Preserve the reporting window and sample basis. Comparing a week's simple requests with a month's complex ones can produce an apparent change that reflects the work mix rather than an improved process.
Treat an incomplete log as incomplete evidence. Do not fill missing events with plausible stories and then present the reconstructed path as observed fact.
Test one intervention
Suppose the review finds that incomplete requests are often discovered only after assignment. A bounded intervention might add a short intake check with a named owner.
State what should change and what must not worsen. Review correction loops and elapsed intervals alongside the completeness of the final outcome. A quicker closure is not an improvement if the issue remains unresolved.
Keep the definition of events and the sample comparable across the test. Record changes in staffing, case mix or external conditions that affect interpretation.
The lessons-learned process can retain the reviewed result. Do not declare a universal productivity gain from a small pilot or assume the same fix applies to every project.
Buy analysis tools after the question is clear
Process-mining software can help discover and compare paths when the event data and case definitions support it. It cannot repair missing business context automatically.
A spreadsheet-level pilot may be sufficient to expose the first useful question. More complex workflows and relationships may need a different data model and specialist support. Choose that investment because of the decision it enables, not because the diagram looks impressive.
Blackwing helps connect process maps to usable operating evidence. An operations review can identify one repeat workflow where the team currently argues about delays without a shared record of what happened.
Frequently asked questions
What is an event log for a construction workflow?
It is a record of defined activities connected to identifiable process cases and timestamps. It can help the team examine paths, waiting intervals and correction loops, provided the event meanings and data coverage are understood.
Does elapsed time measure employee productivity?
No. It measures time between recorded events on the chosen basis. That interval can include nonworking periods, missing information and external dependencies. It should not be used alone to make claims or high-impact decisions about individual performance.
Do small contractors need process-mining software first?
Not necessarily. Start with a clear question and a reliable event sample. A simple pilot can reveal whether better data or a process change is needed. More complex analysis should follow the actual workflow and decision requirements.
How can a bottleneck improvement be evaluated?
Define the intervention, outcome and comparison basis before the test. Keep event definitions and case mix as consistent as practical. Review completeness and correction loops alongside time, and state data gaps and other changes that may affect the result.