Late for a reason in another system

The project is three weeks late.

The project tool does not say so. It says the job is on track, because the person who updates it has been on site all month and has not opened it. The first anyone hears about the delay is when the customer calls.

The reason it is late is not complicated. The one man who can commission that panel was on leave. That fact was in the company the whole time — in a different system, the one nobody thinks of as a delivery system, because it is called HR.

Delivery dates and people are not two subjects

Software split them, so we think of them as separate. Projects live in one tool and people live in another, and there is usually a spreadsheet somewhere doing the joining once a month.

But no project has ever actually been late for a project reason. It is late because somebody was on leave, or resigned, or was pulled onto a customer escalation, or is certified for a thing that two other jobs also needed that week.

A plan that cannot see the people is not a plan. It is a statement of intent, and it goes stale the moment somebody books a holiday.

How VarahiConverse works, roughly

VarahiConverse puts projects and people on the same core. That is the whole design decision, and everything useful comes out of it.

• Project state is assembled from the work. The mail, the files, the approvals, the calls — not from somebody's recollection of the week on a Friday afternoon.
• Slippage arrives with its evidence. You get the delay and the thing that caused it in the same place, which turns the meeting into a conversation about the problem instead of a conversation about the report.
• People run on the same identity. Attendance, leave, onboarding and appraisals sit on the same model as everything else. Nobody maintains a second list of who works here.

Put those together and the sentence that opened this post becomes catchable. A commissioning date and a leave request are no longer two systems apart, so the clash shows up while it is still a scheduling problem rather than a customer problem.

Why it listens rather than asks

A site engineer in a hard hat is not going to open a form. This is not a training issue and it will not be solved by a better interface — their hands are busy and the form is the last thing between them and going home.

So VarahiConverse is voice-first where the work is. He says what happened; it goes to the right place. It works with no signal and syncs when the phone is back in range, because the shed is where the update is worth having and the shed is where there is no bar of reception.

And a person still decides what it means. The system surfaces the clash and the evidence behind it; a manager decides whose week changes. That is the part we are not trying to automate.

VarahiConverse · drag to turn