Most late projects I have run were not late because of the build. They were late because something on the client's side arrived weeks after it was promised: sandbox credentials, a data export, a logo in the right format, a decision about which of two workflows to keep. The fix is unglamorous. Keep one visible, dated list of everything you are waiting on from the client, and review it with them every single week.
Why do client-side items slip so reliably?
Because the people who own them have day jobs, and our project is a side quest. Nobody on their side has "get the vendor VPN access" in their objectives. The person with the API key is on leave. The decision needs two managers who have not been in the same room since kickoff.
Access is the single most common blocker I have seen in a decade of doing this, ahead of design disagreements and well ahead of bugs. Staging databases, app store accounts, payment sandboxes, single sign-on setups. Every one of them looks like a five-minute task from the outside and takes eleven days on the inside.
What does the list actually look like?
Five columns and nothing else. The item, an owner, the date we need it by, what it blocks, and how many days we have been waiting. A real row reads: "Production read-only DB credentials. Owner: Ramesh. Needed by 14 Aug. Blocks: reporting module. Waiting: 9 days."
| Column | What goes in it | Why it earns its place |
|---|---|---|
| Item | The thing itself, in plain words | Nobody has to decode it |
| Owner | A person's name, never "the IT team" | A team cannot be chased |
| Needed by | A date, agreed out loud | Turns a wish into a commitment |
| Blocks | The feature or milestone it stops | Makes the cost visible |
| Waiting | Days elapsed since we first asked | Turns a soft delay into a number |
That last number is the one people react to. Nobody enjoys seeing their name next to a nineteen. The list lives in a shared document, and the top three rows go into every weekly status report under a heading called "Needed from you". Same wording every week, so it becomes a habit rather than a nag.
How do you raise it without sounding like you're blaming them?
You frame it as protecting their date, because that is what you are doing. My usual line: "If the product export lands after the 14th, the import feature moves to sprint six and go-live moves a week. Would you like me to plan for that now, or can we get it by the 14th?"
That sentence gives them a choice and a consequence and no accusation. Nine times out of ten the export shows up. Tone matters too. The list is a shared instrument rather than a scoreboard, and I say so at kickoff when I introduce it. I also put our own dependencies on it, the things the client is waiting on from us, so it never reads as one-sided.
Why regulated industries multiply the waiting
In banking and healthcare projects the longest wait is rarely a person being slow. It is a process: a security questionnaire, a data-access approval, a compliance sign-off with its own committee calendar. Those items sit in a queue nobody on either side controls, and they do not respond to chasing.
I have seen the approval for read access to a data set take longer than building the feature that needed it, and it is a big part of why AI projects die faster in fintech and healthtech than anywhere else. So on those projects the paperwork starts on day one, before a line of code, and it sits at the top of the list until it clears.
What do I do when an item has been stuck for three weeks?
Three steps, in order, and each one is heavier than the last. A stuck item is almost always a stuck person, so the first two are about helping them rather than chasing them. The third is deliberately uncomfortable, and it is the one that tends to move things.
- Offer a workaround. A stub, a sample data set, anything that keeps the team moving while we wait.
- Phone the owner instead of sending a fourth email. Email is where stuck items go to be ignored.
- Re-baseline with the sponsor, in writing, with the new dates on it.
At Shanti Infosoft the list is the second document a client sees, right after the plan, and our IT consulting engagements start the same way. I would rather a client find it slightly annoying than find out in month three why the date moved. If your own list has gone quiet, grab thirty minutes with me and we can look at it together.
What is sitting on your project's waiting list right now, and does the person whose name is next to it know?
Sonal Jain leads delivery at Shanti Infosoft, a CMMI Level 5 firm, and has kept a waiting-on-you list on every project she has run.
