You're twelve weeks into a twenty-week project. The agency sent a status update on Friday - green across the board, a few minor items flagged as amber, nothing red. The Gantt chart looks healthy. The budget tracker shows you're on plan. Everyone seems busy.
So why does something feel off?
I've been on both sides of this moment more times than I can count. As the delivery partner, trying to communicate honestly without triggering panic. And as an advisor to the sponsor, helping them read between the lines of a status report that's been polished to within an inch of its life. What I've learned is that the signals predicting whether a digital project will land well or badly are almost always visible at the midpoint. Not at handover, when it's too late. Not in week two, when everything's still optimistic. Somewhere around the halfway mark, the project shows you what it's going to become.
The question is whether you know what to look for.
Let me start with what healthy looks like, because most sponsors have a vague sense of "things seem fine" without being able to articulate why. Vague comfort is dangerous. It's what allows projects to drift for weeks before anyone notices.
You're seeing working things, not hearing about things being worked on. This is probably the single most reliable indicator I know. A project that's genuinely on track will show you completed designs, working software, tested components - artefacts you can click on, react to, and give feedback on. A project that's in trouble will show you slide decks about what's coming next week. Ask yourself: have you actually touched anything real yet? Because "we're making good progress on the checkout flow" and "here's the working checkout flow, try it" are not the same thing. If you're more than halfway through and the answer is no, that's a substance problem, not a timing one.
Decisions are being made without you. This sounds counterintuitive, but hear me out. A well-functioning delivery team resolves scope questions, technical trade-offs, and minor stakeholder disagreements at their level. They tell you what they decided and why. They escalate the genuinely strategic stuff - the things that need your authority or your budget - but they don't bring you every fork in the road. If you're being asked to approve things you don't fully understand three times a week, something's wrong with the team's confidence or capability. If you're never being asked anything, something might be wrong with transparency. The sweet spot is a team that makes good decisions and keeps you informed about them.
The agency tells you about problems before you spot them. I remember working with a client a few years back - mid-sized financial services firm, portal rebuild. About eight weeks in, the delivery lead called the sponsor on a Tuesday afternoon. No scheduled meeting, just a call. "We've hit an integration issue with your CRM. It's not going to delay the overall timeline, but it's going to change the order we deliver things in sprint four. Here's what we're proposing." The sponsor told me afterwards - and I remember him saying this with genuine relief in his voice - that it was the moment he knew the project was in good hands. Not because there wasn't a problem. But because the team surfaced it proactively, with a plan, before anyone had to ask.
Compare that to the project where you ask "how's it going?" in week ten and get a three-second pause before "yeah, good, mostly on track." That pause is doing a lot of work.
Scope changes are discussed openly, not quietly absorbed. Every project has scope movement. That's normal. The question is whether it's being managed or hidden. On a healthy project, someone says: "The client asked for an additional user role in the portal. That's new scope. Here's what it costs in time and budget, and here's our recommendation." On an unhealthy one, the team quietly absorbs the request to avoid a difficult conversation, compresses something else to make it fit, and the sponsor doesn't find out until the compressed thing turns up half-baked at handover.
Now the bit you probably came here for. I want to be careful about how I frame this, because I'm not trying to turn you into someone who reads sinister intent into every status report. Most delivery teams are trying to do good work. But some patterns, if you see them, genuinely do predict trouble.
The long silence. A delivery team that goes quiet between formal updates is almost always managing something internally. Maybe it's a technical problem they haven't solved yet. Maybe it's a personnel issue. Maybe it's a scope question they're hoping will resolve itself. Whatever it is, the silence is the signal. I've seen sponsors interpret radio silence as "everything must be fine - they'd tell me if it wasn't." In my experience, that's backwards. The projects where everything is fine are the ones where you hear from the team regularly, often informally, because they're confident enough to communicate openly.
The same decision appearing on consecutive status reports. This one's subtle but it's a killer. If "finalise content taxonomy" or "confirm integration approach" shows up as an open item two weeks running, then three, then four - you don't have a content taxonomy problem or an integration problem. You have a governance problem. Someone can't make the decision, or won't, or the team doesn't have the information they need to make it. And every week that decision sits unresolved, downstream work is either blocked or being built on assumptions that might be wrong.
Requirements still being debated past the point of no return. If fundamental questions about what you're building are still being argued in week eight of a twenty-week project, that's not a "requirements clarification." That's a scope crisis that should have been resolved in weeks one and two. I sat in a review meeting once - week ten of a sixteen-week build for a consulting firm's new website - and watched two senior stakeholders have a fifteen-minute debate about whether the site should include a client portal. Week ten. The agency was sat there with their laptops open, waiting. They'd been waiting, in various forms, for about four weeks. That project delivered late, over budget, and missing features. Nobody in that room looked surprised when it did.
Key people unavailable when it matters. And honestly, this is the one I want to be most direct about, because it's often the client's fault, not the agency's. The managing partner whose sign-off is required at three critical gates, but who's in back-to-back client meetings every time the agency needs them. The COO who commissioned the project but hasn't attended a review since week two. The head of marketing who's the designated content owner but hasn't reviewed a single draft. These aren't project management problems. They're client-side governance failures. And in my experience, they're the single most consistent predictor of timeline overrun.
Not all warning signs are created equal, by the way. A single quiet week is barely worth noting. Requirements still being debated at the midpoint is a five-alarm fire. The severity roughly correlates with how close the issue is to the fundamental question of "do we actually agree on what we're building?" The closer it is to that question, the more urgently you need to act.
I've boiled this down to three questions over the years. They're simple, but the answers tell you almost everything you need to know.
"What's working exactly as planned, and what's had to be adjusted?" The honest answer to this separates a well-governed project from one that's managing its own narrative. Every project has adjustments. A team that says "everything's on plan" at the midpoint is either lying or hasn't looked hard enough. What you want to hear is specificity: "The design phase ran to plan. The CRM integration is taking longer than estimated because the API documentation was incomplete, so we've moved the content migration forward by two weeks to keep the overall timeline intact." That's a team in control. "All good, no issues" is a team in denial - or, worse, a team that's decided you don't need to know.
"What's the highest-risk item in the next four weeks, and what's the mitigation?" A delivery team that can't answer this specifically hasn't done the thinking that a midpoint review exists to surface. Risk identification isn't pessimism - it's professionalism. You want to hear something like: "The biggest risk is the client data migration. We're running a test migration next week with a sample dataset. If that throws up issues, we have two weeks of contingency before it affects the launch date." If the answer is "nothing really, it's all under control" - well, that's when I start to worry.
"If we were starting this project again today, knowing what we know now, what would we do differently?" This is the question that separates good from great. And it takes a certain kind of relationship to ask it honestly. But the answer will reveal assumptions that haven't held, decisions that should be reconsidered, and sometimes - if you're lucky - something that genuinely improves the outcome. I asked this once on a portal project for a membership body and the lead developer said, almost sheepishly, "I'd have pushed harder on the single sign-on piece in week one. We treated it as a phase-two item and it's been complicating everything since." We pulled it forward. It added a week to the timeline but saved about three weeks of rework.
I don't want to be the kind of sponsor who interferes with the team. I hired good people - I need to trust the process.
I hear this a lot. And look, I get it. Nobody wants to be the nervous client who derails a perfectly functional delivery. Intervening in a well-running project genuinely does introduce instability - it shifts focus from delivery to reassurance, and it erodes the team's autonomy.
But not intervening when something's going wrong isn't trust. It's avoidance. And the cost of those two things is wildly different.
My rule of thumb is straightforward. If two or more warning signs are present across two or more consecutive reporting periods, intervene. That's the threshold. A single amber flag in a single period is normal project life. A pattern of flags across multiple periods is a trajectory, and trajectories don't correct themselves.
The cost of a well-structured mid-project conversation is a few hours of honest, possibly uncomfortable discussion and a restructured approach. The cost of discovering the same problems at handover? A failed launch. A budget renegotiation. Another digital project that joins the long list of initiatives that "didn't quite deliver what we expected." I've seen that list. In some firms, it's longer than the list of things that actually worked. And every item on it started with a sponsor who noticed something at the midpoint but decided to wait and see.
Research from the Standish Group and others consistently shows that projects with active, engaged sponsorship - not micromanagement, but genuine oversight - deliver significantly better outcomes than those where the sponsor steps back after kick-off. The PMI's Pulse of the Profession data puts a number on it: organisations with effective project sponsors meet their goals around 40% more often. That's not a rounding error.
So you've decided to intervene. Now what? Because there's a version of this conversation that resets the project and there's a version that makes everything worse.
The key - and I genuinely believe this - is framing. You're not there to assign blame. You're there to solve a shared problem.
Start with what you've observed, not what you suspect. "I've noticed the integration decision has been open for three consecutive sprints" is different from "I'm worried you don't know what you're doing." One invites problem-solving. The other invites defensiveness.
Ask the three questions from above. Not as an interrogation - as a genuine attempt to understand what's happening beneath the status reports. Most delivery teams, in my experience, are relieved when a sponsor engages constructively. They've often been sitting on concerns they didn't know how to raise.
And then land on this: "I want to find the two or three things we need to change in the next four weeks to get back on the trajectory we planned. What do you think they are?" That question does something important. It positions the sponsor as a collaborator rather than an auditor. And it gives the delivery team agency over the solution rather than just the problem.
I had this exact conversation on a project last year. SaaS firm, about fifteen weeks into a twenty-week website rebuild. Two warning signs had been present for three weeks running: scope questions unresolved and the product owner increasingly unavailable. The intervention took ninety minutes. We agreed to descope one feature to the next phase, locked three outstanding decisions in the room, and set up a fortnightly thirty-minute call between the product owner and the delivery lead. The project launched on time. Not perfectly - no project is perfect - but on time, on budget, and with the core outcomes intact.
Without that conversation, I'm fairly confident it would have slipped by four to six weeks. And the budget discussion that follows a six-week overrun is never a pleasant one.
Good sponsorship isn't passive. It's not "set the brief and check back at handover." But it's also not "attend every standup and approve every wireframe." It's something more specific: knowing what to look for, asking the right questions at the right moments, and being willing to have a difficult conversation when the signals tell you one is needed.
The warning signs are there at the midpoint. They're always there. The question is whether you've trained yourself to see them.
There's a companion piece worth reading on what to do when your agency relationship isn't working - for situations where the warning signs have gone past the intervention stage and into something more serious. Hopefully you won't need it. But it's there.
If you want the three questions and the good/warning signs framework as a one-page monthly health check template - formatted for a 30-minute sponsor review with a simple traffic-light scoring approach - download it here. It's designed to be used monthly, not as a one-off. Because the whole point is pattern recognition, and you can't spot a pattern from a single data point.