DEV Community: Sonal Jain

The 'Waiting On You' List: Managing Client-Side Dependencies

Sonal Jain — Wed, 26 Aug 2026 08:00:08 +0000

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.

How I Review an Engineer's Estimate Before the Client Sees It

Sonal Jain — Mon, 24 Aug 2026 08:00:35 +0000

An engineer's estimate is usually right about the coding and wrong about everything around it. So when one lands on my desk, I don't check the hours per feature. I check what the estimate quietly assumes: what is already working, what we are waiting on, who reviews the work, and how much of it is testing. That review takes me thirty minutes and it has saved more client relationships than any status report.

What am I actually looking for?

Four things, in this order, and none of them is the hours per feature. What the estimate assumes already exists. What sits outside our control. Where the vague ticket is hiding. And who reviews the work once it is written. Half an hour, every time, before a number leaves the building.

What does this assume already exists? An estimate for "add invoice PDF export" assumes the invoice data model is clean and complete. If it isn't, the export is a data-cleanup project wearing a small feature's clothes.
What sits outside our control? A payment sandbox, a client-side approval, a vendor's onboarding queue. Engineers estimate the work they will do; the calendar time is set by the work they won't.
Where is the "we'll figure it out" ticket? Every estimate has one. It is usually the integration or the migration, and it carries a suspiciously round number. That ticket gets broken down before anything ships to the client.
Who reviews it, and when? Review time is almost never in the estimate. Neither is the second round of fixes after review. Both are real hours.

Line item	In the engineer's estimate	In the number I send out
Coding	Present, and usually about right	Same hours, left alone
Code review and rework	Rarely there at all	Budgeted as real, named hours
QA	Sometimes, and first to be cut	Roughly 10% of build hours, held
Waiting on the client	Never	Named risks with owners and dates

Has AI made estimates better or worse?

Worse, in a specific way. Coding assistants made engineers faster at the part they were already good at estimating, so the coding line shrank. Review and integration did not get faster, and there is now more code to review. The total moves far less than the coding line suggests.

I have watched a feature's build hours drop by half while the calendar time barely moved, and the missing time was all in checking the output. That is why the testing line in my estimates has stopped shrinking. Our template pegs QA at roughly ten percent of build hours, and I no longer let anyone cut it, however confident the demo looks. The reasoning in the QA layer that has to grow when AI writes four times the code matches what I see on every project now: more output, same number of eyes, so the eyes need budget.

A number or a range?

A range, with one sentence about what pushes it to the top. "Six to nine weeks; nine if the legacy export turns out to be undocumented." Clients handle ranges better than most engineers expect, as long as the range comes with a reason and a date by which it will narrow.

What clients cannot handle is a single number that turns out to be the bottom of a range nobody mentioned. That is where the word "overrun" comes from.

What do I do with an optimistic engineer?

I don't double it. Silently padding an estimate was my mistake for years, and it had a cost I didn't see for a long time: the team learned that my number was never their number, so they stopped owning the date. It became "Sonal's estimate".

Now I ask them to walk me through the first five days, task by task. Optimism collapses under a day-by-day walk. Around day three there is a pause, and then "oh, we'd need the staging environment by then". The padding still ends up in the plan, but as named risks with owners, visible to the client, and it is the engineer's plan.

At Shanti Infosoft no estimate reaches a client without that walk-through, and the same habit sits behind the software consulting work we do for teams who want a second opinion on somebody else's number. I would rather delay a proposal by a day than send a clean-looking figure I don't believe.

When you last missed a date, was the coding late, or was it everything wrapped around the coding?

Sonal Jain heads delivery at Shanti Infosoft, a CMMI Level 5 company, and reviews every estimate before it reaches a client.

The First 30 Days After Go-Live Decide If the Client Comes Back

Sonal Jain — Sat, 22 Aug 2026 08:00:16 +0000

The month after go-live is when a client decides whether to trust you with the next thing, and it is exactly when most vendors go quiet. The build team rolls onto another project, the client hits the first real-world snag, and the reply is a ticket number. I now plan the first thirty days after launch as a phase of the project, with named people and its own budget line.

What does the launch month actually involve?

Real users doing things nobody on the team predicted. Real data with shapes staging never had. Volumes that make a slow query visible for the first time. All of that is normal. It is what production looks like, and no amount of staging shows it to you first.

So the phase has a shape, and it is the same five things every time:

A named engineer on point, with a second name for cover.
Response times for the first two weeks that are tighter than the eventual support contract.
A ten-minute morning check of error logs and the slowest endpoints.
A short weekly note covering what real people did and what we changed because of it.
A launch review, booked on the calendar before launch day.

The morning check matters more than it sounds. Most launch problems announce themselves quietly, as a growing error count or a job that runs a little longer each night. Catching them on day three instead of day twelve is the difference between a message and an incident.

Why does silence in week two hurt so much?

Because the client is nervous in a way they will not say out loud. They have just told their own organisation the thing is live. Their credibility is now attached to our software. If their first email after launch gets a two-day auto-reply, that fear turns into a story about the vendor.

Compare that with a call in week two where we open with: here is what we saw, here is what we fixed without being asked, here is what we would change now that we have watched real usage. I have had that call turn a cautious client into one who asked for a roadmap conversation on the same day. Same software. Different month.

The bill that only shows up after launch

Running costs stay theoretical until real traffic arrives. Hosting scales up, storage grows past the plan, email volumes trigger a higher tier, and a third-party API moves past its free band. The first month is when a client finds out what the thing costs to keep running.

Cost line	Why it moves after launch	What we usually do about it
Hosting	Real traffic replaces polite staging traffic	Right-size the instance after week two
Storage	Uploads and logs grow every single day	Set a retention rule, archive the rest
Transactional email	Volume crosses the plan's band	Change tier, or batch the notifications
AI tokens	Users paste whole documents into a box	Shorter prompts, caching, an input cap

For AI features the token bill is the one that surprises people, since a feature that cost pocket change in testing meets real users who paste in whole documents. I bring the actual first-month numbers to the week-two review, next to the estimate, because a client should never learn the real bill for automation from their finance team before they hear it from me.

That conversation also decides what we tune. Sometimes a caching change or a shorter prompt cuts the bill by a third. Sometimes the answer is that the estimate was wrong and we say so.

What happens on day thirty?

A forty-five-minute launch review with the client. What broke, what surprised us on both sides, what we would do differently, and what the next ninety days should hold. It closes the build cleanly and it opens the relationship, which is the whole point.

At Shanti Infosoft I ask delivery leads to book that review before launch day, so it exists on the calendar when everyone is still paying attention. Reviews booked after launch have a way of never happening. On the SaaS products we build and keep running, the launch month is written into the plan as a phase with a name, an owner and a cost.

One more habit: I keep the launch-month engineer partly on the project for the following month too. Rolling them off on day thirty-one loses the person who knows what production actually did.

Which is scarier on your projects, launch day itself, or the quiet fortnight after it?

Written by Sonal Jain, delivery lead at Shanti Infosoft, a CMMI Level 5 team that has launched software for 700+ companies.

How to Run UAT So the Client Actually Signs Off

Sonal Jain — Thu, 20 Aug 2026 08:00:28 +0000

User acceptance testing works when four things are fixed before the build starts:

The scenarios the client will test, written in their words.
The length of the testing window, in the calendar.
The name of the person who signs.
The rule for sorting whatever they find.

Miss any of them and UAT turns into an open-ended tour of the product where sign-off never quite arrives. I learned this the slow way. For my first few years I sent a staging link with "please test and let us know", then spent three weeks chasing feedback that mixed real defects with colour preferences and brand-new ideas.

Why does UAT stall in the first place?

UAT stalls because nobody agreed in advance what the word "accepted" means. The client's testers explore the product, which is natural, and exploring produces opinions. Opinions are useful and they belong in a backlog. A backlog cannot be signed, so the window stays open while everyone waits.

There is a second reason. The people asked to test have day jobs. A branch manager asked to "try the new system this week" will do it on Friday at five, on a phone, half-distracted. If the request has no scenarios and no deadline, it lands at the bottom of a list that never empties.

Who writes the scenarios, and when?

The client writes them, at scoping, with our help. Twenty to forty short lines in plain language: "As a store manager, I approve a leave request and the employee receives an email within a minute." No technical wording. Each one describes a moment in someone's working day.

I ask for these before the estimate is final because they change the estimate. A scenario like "the payroll export matches what our accountant expects" reveals a whole integration nobody had mentioned. Better to find that in week one than in the testing window.

How long is the window, and who is in the room?

Five to ten working days, in the calendar from the start, with a daily fifteen-minute triage call. On that call sit the client's lead tester, our QA lead and me. Every finding gets a label on the spot, and the label decides what happens to it next.

Label	What it means	Blocks sign-off?
Defect	A written scenario does not pass	Yes, and we fix it inside the window
Change	A new idea or a preference	No, it goes to the backlog with an estimate
Question	The behaviour was misunderstood	No, answered on the call and closed

The labelling is where the trust is won or lost. If we call a genuine defect a "change" to protect the timeline, the client stops believing the triage. If we accept every wish as a defect, the project never ends. Doing it out loud on a daily call keeps both sides honest.

Who signs, and what does signing mean?

One named person, agreed at kickoff, with the authority to say yes. Sign-off means the scenarios pass. It does not mean the client loves every screen. I say that sentence in the kickoff and again at the start of the window, because it takes the emotion out of the decision.

Conditional sign-off is fine and common. The client signs with a punch list attached: six known items, each with an owner and a date. That is a far healthier outcome than an unsigned project with six open items and a vendor waiting on an invoice.

The QA work that has to happen before UAT

UAT is the client's test of fitness, and it only works when it is not also our first serious test. Before a client sees a release candidate, our QA team has already run the client's own scenario list against it, so the window becomes a confirmation rather than a discovery.

With AI assistants generating a large share of the code on our projects, the volume of things to check has grown faster than the number of hands, which is why I follow the thinking in the QA layer that keeps up when AI writes four times the code and budget internal testing before every window rather than after it. On the software development work we take on at Shanti Infosoft, that internal pass sits in the plan and in the price.

The best UAT window I ever ran ended on day four of ten. The client's tester finished the list, found two defects, and asked if she could go back to her actual job. That is what sign-off should feel like. If you want to talk through a window for your own release, my calendar is open here.

What does "accepted" mean on your current project, and could the person signing explain it back to you?

Sonal Jain heads project management at Shanti Infosoft, where a team of 80+ engineers ships into a UAT window like this one every few weeks.

How to Write a Weekly Status Report Clients Actually Read

Sonal Jain — Tue, 18 Aug 2026 08:00:17 +0000

A weekly status report should be readable in ninety seconds by someone who has never joined a single call. That means one line of health at the top, then what changed, then what you need from the client, then the risks. Everything else is an attachment.

I have written one of these every Friday for about ten years, and the format above is what survived. The early versions were long. They listed everything the team did, and nobody read them. The current version fits on one phone screen, and I know it gets read because people reply to it.

What goes in the first line?

The first line carries the status and the reason together, in one sentence a reader can repeat from memory. "Amber. Payment sandbox access came three days late; the launch date still holds." That single line tells a busy person whether they need to keep reading or can close the email.

I put it in the subject line too. A finance head on the client side once told me she had read nothing but my subject lines for a month, and she still felt she knew where the project stood. I took that as the highest compliment the format can get. If your subject line says "Weekly Update - Week 14", it is telling the reader nothing.

Green, amber and red also need definitions the client has agreed to, because without them amber becomes the colour you reach for to avoid saying red.

Label	What it means	What I need from the client
Green	The plan holds and the dates have not moved	Nothing this week
Amber	Something slipped and a recovery is running	Awareness, sometimes a faster answer
Red	The date or the scope needs a decision	A decision, named and dated

What changed, or what happened?

A status report records change in the product rather than activity on the team. "Completed 14 tickets" is activity. "Checkout now works end to end on staging, and the address step is still mocked" is change. The second version lets a client picture the thing they are paying for.

If a workstream did not move, write "no change" and stop. Two words. It feels wrong the first few times because it looks like admitting idleness. In practice clients respect it far more than a padded paragraph, and it makes the weeks where something moves stand out.

What do you need from them?

Every report has a section titled "Needed from you", and every item in it carries a date and a consequence. "Sign-off on the invoice PDF layout by Thursday, otherwise the print step moves into the next sprint." The consequence is the part people skip, and it is the part that gets action.

This section is also my early-warning system. When the same item shows up three Fridays in a row, the item itself has stopped being the problem. Someone who owns it is stuck or has left, and I need a phone call rather than a fourth reminder.

How many risks belong in it?

Two or three, each with a next review date. Six risks means you have not decided which ones matter. A risk that has sat unchanged for eight weeks stops being a risk and becomes the plan, so either it gets a mitigation or it leaves the list.

I also keep the risk wording plain. "The client's data export may not include the fields we assumed" is a risk. "Data dependency uncertainty" is a fog. When I looked at what the AI projects that don't get cancelled tend to have in common, honest and regular communication sat near the top, and plain risk language is where that starts.

The mistake I made for years

I wrote the report for the person I spoke to every day. She already knew everything in it, so the report felt like a formality. What I missed was that she forwarded it. Her manager read it. Sometimes a board member read it. The report was the only version of the project those people ever saw.

Now I write it for the forward, and I ask every delivery lead at Shanti Infosoft to run four checks before hitting send:

Does the subject line carry the status and the reason in one breath?
Could a stranger repeat the state of the project back to you after ninety seconds?
Does every item under "Needed from you" have a name, a date and a consequence?
Have you cut every sentence that only makes sense to someone on the daily call?

The fourth check is where most of the red pen goes. It carries into our IT consulting work too, where the weekly note is often the only artefact a sponsor ever reads.

The whole thing takes me about twenty minutes on a Friday afternoon. It is the highest-value twenty minutes of my week, and I would rather skip a standup than skip it.

What is the one thing your clients actually look for in an update, and does your report put it first?

Sonal Jain runs delivery at Shanti Infosoft, a CMMI Level 5 software company, where the Friday report format above is the house standard.

How to Say No to Scope Creep Without Losing the Relationship

Sonal Jain — Tue, 11 Aug 2026 08:00:22 +0000

Scope creep rarely shows up as a big demand. It arrives as a small, friendly 'could we also...'. One tiny addition, reasonable on its own. Then another. Each one sounds like nothing. Stacked over two months, they are the reason the team is suddenly working weekends and the timeline everyone agreed to has become fiction.

Learning to say no to this without bruising the relationship took me years. My early instinct was to please, so I said yes to keep everyone happy, and then quietly drowned. That helps no one. A missed deadline damages a client relationship far more than a well-handled no ever will.

Say yes to the idea, then show the cost

I almost never reject a request outright. Most of the time the new idea is genuinely good, and killing it makes me look rigid while making the client feel unheard.

Instead I make the trade-off visible. 'We can absolutely add that. It is roughly a week of work, so we either move the launch date or swap it for something already on the list. Which would you prefer?' That single move changes the whole temperature of the conversation. I stop being the gatekeeper blocking their idea and become the person helping them spend a fixed budget of time well. The choice, and the consequence, sit with them.

Nine times out of ten, once a request has a real cost attached, the client decides it can wait. The 'could we also' was a wish, not a priority, and naming the price sorts one from the other in seconds.

Point back to what we agreed

This is where the boring groundwork pays off. Because we wrote down the scope and the 'not now' list at the start, I have something neutral to point at. The conversation stops being me against the client and becomes the two of us looking at the same plan we made together.

'This was in our later bucket, remember? Happy to pull it forward if we push something else back.' That framing keeps me on the client's side of the table. We are solving the same puzzle, working from a shared agreement rather than my opinion against theirs.

Protect the team without hiding behind them

Behind every scope conversation are real people who absorb the extra work if I cave. Part of leading delivery is refusing to quietly transfer pressure onto engineers to dodge one awkward moment with a client. When I hold that line, I am doing the job I was hired to do. Caving would just punish the people who trusted me to guard their week.

I have found clients respect a delivery lead who holds a line far more than one who agrees to everything and then misses the date. Firm and warm can live in the same sentence. That balance is something I care about a great deal at Shanti Infosoft, and it is why I would rather have the honest scope conversation today than the apology conversation next month. A little more on how we work is at https://shantiinfosoft.com.

Guarding the scope is how I keep the promise we both made on day one. Clients feel that difference, even on the days when the answer is no.

Holding that line is one of the five things projects that don't get cancelled do differently.

What is your best line for saying no to a request without making the other person feel shut down?

Keeping Distributed Delivery on Track Without Micromanaging

Sonal Jain — Sun, 09 Aug 2026 08:00:19 +0000

When a team sits in one room, a lot of coordination happens by accident. You overhear a blocker. You catch that someone's stuck from the look on their face. A five-second question gets a five-second answer.

Remote delivery strips out all that free coordination, and plenty of teams never replace it. They run the old office rituals over video and wonder why things slip. The work is to rebuild what the room did for free, deliberately.

Write it down, or it didn't happen

The biggest single shift is writing. A decision made on a call and left unwritten will be remembered three different ways by Thursday.

We keep decisions, scope changes, and the reasoning behind them somewhere everyone can read without having to ask. When a client approves a change on a call, it goes into writing the same day, with a short 'confirming what we agreed' note back to them. That one habit has rescued more projects than any tool we use. Memory is unreliable, time zones make 'let me just ask' expensive, and the written record quietly does the job the hallway used to.

Async by default, live for what needs a room

With people spread across time zones, treating every question as urgent exhausts everyone and slows the work anyway. Most questions can wait a few hours for a written answer. We keep async as the default and protect live time for what genuinely needs it: kickoff, demos, a knotty design debate, and the conversation when something has gone wrong.

Live time is costly when half the team is replying at 9pm their time. So we spend it on judgment and relationships and let the routine run through writing. A solid written update the client reads at their own hour beats a meeting booked at someone's midnight.

Trust the work, not the clock

Remote delivery tempts a manager toward surveillance. More check-ins, more status pings, more 'just circling back.' That reads as distrust, and it drives good people up the wall.

I watch the work instead of the hours. Is the demo further along than last week? Are tasks crossing the board, or stacking up in one column? Has someone gone quiet in a way that's unlike them? Those signals tell me far more than a timesheet could. When something looks stuck, I ask directly and early, before it hardens into a missed date.

The other half of trust is being reachable. My team knows a genuine blocker gets my attention fast, whatever the clock says on my end. Async only works as a default when people believe the escalation path is real.

Distance is a design problem

A distributed team can deliver every bit as well as a co-located one. It just won't happen on its own, and it won't happen by pasting office habits onto video calls. It takes deciding, on purpose, how information should move when nobody shares a room.

At Shanti Infosoft we've delivered remotely for years, across time zones and for clients who never meet us in person, and the projects that run smoothly are the ones where we designed the communication rather than assuming it. You can read more about how we work at https://shantiinfosoft.com.

I wrote about running delivery this way in what actually happened when I ran a company on AI-agent 'departments'.

What's the one thing your remote team does that a team sharing an office would never need to?

When an AI Feature Underdelivers, the Delivery Lead's Real Job Starts

Sonal Jain — Thu, 06 Aug 2026 08:00:38 +0000

Sometimes the model just does not perform the way everyone hoped. Accuracy lands lower than the target. The clever feature shines in the demo and stumbles on real inputs. This is not rare in AI work. It is ordinary. What separates a recoverable situation from a lost account is entirely how the news gets handled, and that part is my job, not the model's.

I have been on both sides of this. Early in my career I let bad results sit while I hunted for a fix, hoping to walk in with a problem and a solution stapled together. That instinct feels responsible. It is actually how trust quietly dies, because the client can smell the avoidance.

Say it early, say it straight

The moment I know a feature is missing its mark, I book the conversation. Not after I have a perfect recovery plan. Early, while there is still room to adjust budget, timeline, or expectations together. Waiting until the deadline to reveal a shortfall strips away every good option the client used to have.

I open with the plain facts. Here is the target we set, here is where we landed, here is why. No softening it into fog, no burying it under jargon so it sounds less bad than it is. Stakeholders can handle a hard number. What they cannot forgive is learning that I knew and stayed quiet.

Never walk in with only bad news

Straight talk without a path forward is just gloom, and a stuck client quickly becomes a scared one. So I never arrive empty-handed. I bring two or three real routes and their honest trade-offs, each one roughly costed before I sit down.

Maybe we narrow the scope so the system only handles the cases where it is genuinely strong and a person takes the rest. Maybe we spend two more weeks and some budget improving the data behind it. Maybe the feature ships as an assistant to a human rather than a replacement for one. Each option has a cost and a benefit, and I lay them out plainly so the client can choose with open eyes. That choice belongs to them, and my job is to make sure it is a real one with real options on the table.

Protect the relationship, not your ego

The strongest pull in these meetings is to defend yourself. To explain how hard the problem was, how messy their data turned out to be, how ambitious the goal always was. Some of that may be true. None of it helps the person across the table who now has to explain this to their own boss.

So I take the weight instead of spreading it around. I keep the focus on what we do next, not on who should have known what. A client who watches you stay calm and useful on a bad day will trust you with the next project, and that reputation for honesty on hard days is what I want for my team at Shanti Infosoft. You can read how we think about it at https://shantiinfosoft.com.

An underdelivering feature is a bad afternoon. A client who feels misled is a lost year. I will take the bad afternoon every single time.

We looked at why so many of these stall in the projects that quietly get cancelled by 2027.

When a project of yours fell short, what did the people involved remember most, the shortfall or the way you handled it?

What to Do When the Project Is Late

Sonal Jain — Tue, 04 Aug 2026 08:00:16 +0000

Every project manager knows the feeling. The date you promised is close, the work isn't, and the honest arithmetic says you're going to miss. The first instinct is to go quiet, work the weekend, and hope to claw it back before anyone notices.

I've done exactly that. It never works, and it trades a schedule problem for a trust problem, which is the harder one to repair.

Tell them early and tell them straight

The moment I'm reasonably sure we'll slip, the client hears it from me. Not the day before the deadline. The week I can first see it coming.

The message stays plain. Here's where we are, here's why, here's the new date, and here's what we changed so this one holds. No burying it under three paragraphs of context. Clients can handle bad news. What wrecks a relationship is learning late that you knew early.

There's a version of the late conversation that rebuilds trust instead of draining it, and it always carries a cause and a correction, not only an apology. 'We underestimated the payment integration, we've added a second developer, and the realistic date is the 14th' lands completely differently from 'sorry, we need more time.'

Give them something real to hold

A slipped deadline unsettles a client because the ground feels like it moved. My job in that moment is to hand them footing.

That means a demo of what does work, even if it's partial. A revised plan they can actually read, with the shaky parts named. And a smaller, firmer commitment they can believe. A tight promise you keep is worth more than a big one you miss, and after a slip, keeping the next small promise is how you buy the room back.

I'd rather commit to one solid milestone this Friday and hit it than promise the whole feature in two weeks and miss again. Two misses in a row is the point where a client quietly stops believing your dates.

Fix the cause out loud

A late project almost always has a reason, and the client can sense whether you found it. Scope that was never clear. A dependency that showed up broken. An estimate that ran optimistic. Whatever it is, I name it and say what changed because of it.

That candor does something odd and useful. Owning a miss cleanly, with a specific fix attached, often leaves the relationship stronger than a project that ran smooth and forgettable. People remember how you carried yourself when it went sideways.

When a project runs late at Shanti Infosoft, the goal is simple and unglamorous: a client who never feels blindsided, because they've had the real status the whole way. No heroic all-nighter that nobody sees. That's the reputation we guard, and it's why clients come back after a hard project rather than in spite of it. More on how we work sits at https://shantiinfosoft.com.

The pattern gets sharper in high-stakes work, which we covered in why AI projects die faster in fintech and healthtech.

Have you ever given a client bad news earlier than felt comfortable, and did it land better or worse than you feared?

How to Scope AI Work When the Client Wants One Fixed Price

Sonal Jain — Sun, 02 Aug 2026 08:00:29 +0000

Fixed price and artificial intelligence make an awkward pair. A fixed price wants certainty. AI work, especially the first version, carries real unknowns about data quality, accuracy, and how people will actually use the thing. Pretending those unknowns away to win a clean number is how projects quietly go underwater. I have watched it happen to good teams.

You can still commit to a fixed price. You just have to scope as if the unknowns are real, because they are.

Draw the box before you price the work

Before anyone talks money, I get almost fussy about the boundary. What goes in, what stays out, and where the edges sit. For an AI feature that means naming the exact inputs, the exact outputs, and the specific situations the system is responsible for. 'Answer customer emails' is not a scope. 'Draft replies for the eight most common order-status questions, in English, for a human to approve before sending' is a scope I can actually size.

The narrower and more concrete the box, the safer a fixed price becomes. Vague scope is where the money leaks out. So I spend real time here, and I pull the client into it instead of guessing on their behalf.

Phase the risky parts, commit the safe parts

Not every part of an AI project carries the same risk. Building the interface, the workflow, the human review step: fairly predictable. Getting a model to hit a certain accuracy on messy real-world data: much less so. I refuse to price those two things as if they were the same.

So I split the work. The predictable pieces get committed with confidence. The genuinely uncertain piece gets its own short, time-boxed phase where we prove feasibility on the client's real data first. That early phase answers the scary question cheaply, before a big number depends on the answer. Most clients respect this once I explain it, because it guards their budget as much as my team's sleep.

Put 'good enough' in writing, in plain language

The worst fixed-price fights are about the word 'working'. The client thinks working means ninety-nine percent right. The proposal quietly assumed eighty. Nobody wrote it down, so both sides are correct and both sides are upset.

I settle that at the start. We agree, in writing and in plain words, on what good enough looks like and how we will measure it together. A number, a test set, a review method. Dull to negotiate, priceless to have when someone later says, 'this is not what I paid for.' A written standard turns a shouting match into a five-minute check.

Scoping this way is slower up front, and I have lost a little sleep worrying it makes us look cautious next to a competitor who says yes to everything. But the projects hold. That discipline is a big part of how I keep the delivery promise I make at Shanti Infosoft, and you can see how we frame that work at https://shantiinfosoft.com.

A fixed price is a promise. I would rather make a smaller, honest one I can keep than a generous one that becomes a mess for both of us four months in.

It helps to understand how buyers actually shop for AI work in 2026 before you put a number on it.

When you scope a fixed-price project, where do you build in room for the things you cannot know yet?

The Small Rituals That Keep a Project Honest

Sonal Jain — Fri, 31 Jul 2026 09:21:20 +0000

A project rarely goes wrong all at once. It drifts. A small misunderstanding in week two, an unspoken worry in week four, a 'we'll sort that out later' that nobody wrote down. Eight weeks on, the client is surprised, the team is defensive, and everyone is certain they mentioned it earlier.

The rituals I care about exist to catch that drift while it's still small. None of them are clever. All of them are a little dull on purpose, and the dullness is the point.

The standup that isn't status theater

A daily standup goes wrong the moment it becomes people reciting yesterday's tasks to a manager. I ask for three things only: what moved, what's stuck, and what you need from someone else in the room. Fifteen minutes.

The word I listen for is 'stuck.' A developer who says 'still working on it' three mornings in a row isn't slow, they're blocked and too polite to say so. Catching that on day two instead of day nine is most of what a standup is really for.

The demo is the truth serum

Every week or two, we show working software to the client. Not slides. Not a percentage. The actual thing, clicked through live.

Demos are uncomfortable in the best way. You cannot fake one. A feature that's been '90% done' for three weeks running gives itself up the second someone asks to see it. Clients settle when they watch progress with their own eyes, and the team stays honest because the deadline is a live audience rather than a private board.

I've had demos where something broke on the shared screen. Those aren't the disasters they feel like in the moment. A client who watches you calmly note the bug, log it, and fix it by next week trusts you more, not less.

The risk log nobody wants to keep

The least loved ritual is the one that saves the project. A plain running list: what could go wrong, how likely, who owns it, what we're doing about it. Reviewed every week.

Half of those risks never happen. The effort still pays for itself, the way insurance does. The value sits in the one that does happen, the one we flagged in week two with a plan already attached, instead of meeting it in week nine as an emergency. Writing a worry down does something quiet for a team, too. The fear stops rattling around in one person's head and becomes a line with an owner.

Rituals are how trust scales

When I tell a client at Shanti Infosoft that a project is on track, that sentence carries weight, because a demo they watched and a risk list they've read sit behind it. Honest delivery is built from small, repeated habits that make hiding hard and surfacing easy. You don't get there by hoping your team is the trustworthy kind. You can read how we run delivery at https://shantiinfosoft.com.

These habits overlap closely with the five things AI projects that don't get cancelled do differently.

Which of your team's rituals actually changes what you ship, and which one is just a meeting?

Most AI Projects Drift in Week One. Here Is the Kickoff That Stops It.

Sonal Jain — Fri, 31 Jul 2026 06:19:17 +0000

The gap between a calm AI project and a chaotic one usually opens in the first week, before anyone writes real code. It opens quietly. The client pictures one thing, the engineers hear another, and nobody says the mismatch out loud because everyone is being polite and hopeful. A month later that small gap has turned into a very uncomfortable meeting.

So I treat the kickoff as the most important deliverable of the whole engagement. Not the model, not the first demo. The kickoff. Get that right and most of the drama never happens.

I make everyone describe 'done' in plain words

At the start I ask each person in the room to finish one sentence: 'This project is a success if...'. The client's answer and the delivery team's answer are almost never the same on the first try, and that difference is the gold. Someone will say the win is a system that answers customer questions accurately. Someone else will say it needs to handle the top twenty question types we see every week. Those are different promises, and pinning down which one we are making saves everybody weeks of guessing.

I write the answers on a shared doc while people watch. Seeing their own words land on the page makes stakeholders slow down and correct me, which is exactly what I want. A vague expectation is easy to nod along to. A written one gets argued with, and I would rather have that argument now.

We list what we are not building

The most useful page in any kickoff is the 'out of scope' list. AI work invites daydreaming. Someone always pictures the assistant summarizing reports, translating five languages, and predicting next quarter's demand, all in the first version. None of that is bad to want. It simply cannot all ship at once.

I name those wishes, thank people for them, and park them in a clearly labeled 'later' section that everyone can see. Nothing gets dismissed. It gets sequenced. When a feature reappears mid-project as something the client assumed was always included, I can point back to the list we all looked at together. That single page has cooled more tense moments than any status report I have ever sent.

The data reality check comes first, not last

The fastest way to blow an AI timeline is to discover in week six that the data everyone assumed was clean is actually full of duplicates, missing fields, and three spellings of the same customer name. I refuse to let that be a surprise. During kickoff we look at real samples together, not a tidy example someone prepared the night before.

I would rather deliver honest bad news on day two than a delayed miracle in month three. That habit of surfacing the ugly parts early is the standard we hold at Shanti Infosoft, and it is the one I hold myself to on every engagement. A little more on how we work sits at https://shantiinfosoft.com.

A kickoff done well is a little uncomfortable. People realize the thing is bigger than the sentence they pitched it as, and that realization is the whole point. Everyone walks out holding the same picture in their head.

The habits that keep this from unravelling are in the five things AI projects that don't get cancelled do differently.

What is the one question you wish you had asked in a first meeting, before it cost you a month?