By the end of week four, you already know. You might not admit it yet - you might still be telling yourself it's early days, that the team's finding their feet, that these things always take a while to get going. But somewhere in the back of your mind, you've clocked it. The stakeholder interviews that keep getting rescheduled. The system access that was requested in the kick-off but hasn't materialised. The discovery scope that's quietly ballooned from three workstreams to five without anyone formally agreeing to that.
The problems that blow up at month six? They were almost always visible at week two. I've seen it enough times now to say that with real confidence.
The first few weeks are always slow. You're just getting started. It's not worth worrying about until you're properly underway.
I understand that instinct. And look, sometimes it's right - some projects genuinely do need a bit of runway before they find their rhythm. But there's a difference between a slow start and a project that's already drifting. The first 30 days establish the habits, communication norms, and decision-making patterns that govern everything that follows. If those foundations are shaky, no amount of heroic effort at month four is going to fix it cleanly.
So here's what I think should actually happen in those first 30 days - and, more usefully, what usually doesn't.
A good kick-off meeting should end with everyone in the room holding the same understanding of four things: scope, success criteria, roles, and the decision-making process. Not a vague sense of direction. An actual, shared understanding that could be written down - and is, within 48 hours.
Every team member should be introduced with their specific role confirmed. Not "this is Sarah, she's part of the delivery team" but "Sarah is leading the technical assessment and she'll need access to your staging environment and integration documentation by Wednesday."
System and data access should be formally requested - not provisioned, necessarily, because I know how internal IT works - but requested, with a named internal contact responsible for making it happen and a specific date by which it should be available. Discovery planning should be confirmed: a schedule for stakeholder interviews, technical assessments, and content reviews, with named interviewees and actual confirmed times. Not "we'll sort that out next week."
Here's what usually happens instead.
The kick-off meeting establishes tone but not decisions. Everyone leaves feeling good about the relationship. The chemistry's right. The agency team seem sharp. There's a nice slide about methodology. But nobody wrote down who's accountable for what, and the follow-up email that arrives two days later is a summary of the conversation rather than a set of decisions and actions with owners and deadlines.
The access request gets sent to IT and sits there. Nobody follows up because it feels too soon. The discovery schedule is agreed "in principle" but without confirmed appointments. And the agency team introductions happen without any clarity about who is actually doing the work versus who showed up to make a good impression.
That last one - I should probably say more about it. I've been on both sides of this. The team you meet in the kick-off and the team that does the work are not always the same people. If you haven't met the full delivery team by the end of week one, ask. Directly. It's not rude. It's essential.
By the end of week three, a delivery team that's genuinely underway should have completed - not scheduled, completed - the initial stakeholder interviews, with notes shared and patterns starting to emerge. The technical lead should have a clear picture of the existing systems, integrations, and infrastructure. A content audit should be underway, with the volume, quality, and migration complexity of existing content understood well enough to inform the delivery plan.
And - this is the bit that matters most - the team should be sharing first observations with you. Not conclusions. Observations. Things like: "We've noticed that three of the four stakeholders we interviewed described the same pain point around the enquiry process, but each described it differently." Or: "The integration between your CMS and CRM is more tightly coupled than we expected - that's going to affect how we approach the migration."
A delivery team that has nothing to share at the end of week two hasn't started. Or it's managing its narrative. Either way, that's worth noticing.
What usually happens? The stakeholder interviews get rescheduled twice because people are "swamped" and end up being conducted in compressed form during week four - three back-to-back on a Thursday afternoon, which produces shallow answers and no time for the team to reflect between conversations. The technical assessment is blocked by a firewall access request that was sent but never escalated when it didn't come back. The content audit begins with "we weren't given access to the CMS."
I remember sitting in a week-three check-in a couple of years ago where the agency's project manager cheerfully told us that "things are progressing well" and then, when pressed, admitted that none of the five planned stakeholder interviews had actually happened. "We're lining them up for next week." That's not progress. That's a project that hasn't started yet, wearing a progress costume.
What I didn't say in that meeting - and should have - was that we'd also been slow to provide the brief documentation they'd asked for. I let the agency take the heat while quietly knowing we'd contributed to the delay. That's the kind of thing that festers. By month three, both sides had a grievance and neither had named it.
By the end of week four, an honest delivery team should be able to show you a specific set of initial findings - not a comprehensive analysis, but the two or three most significant observations already shaping how they're thinking about the delivery approach. There should be an emerging priority order for the first major delivery phase. And there should be at least one decision that needs to be made: about scope, about technical approach, or about a conflict between what one stakeholder wants and what another stakeholder needs. If there isn't a single tension to resolve after four weeks of discovery, either the project is extraordinarily simple or the team hasn't been listening carefully enough.
The week-four check-in that consists entirely of a status update and a plan for what's coming next is not a discovery that has produced anything. It's a kick-off that took four weeks.
I should be fair here, though. Not every project type follows this exact cadence. A pure build where the discovery was done separately has a different first 30 days. So does a migration, or an AI implementation. The sequence I'm describing applies to discovery-led engagements - which is where most of the projects we work on at Distinction start. If your project structure is different, the specific milestones shift, but the underlying principle doesn't: by week four, you should have tangible evidence that work has happened and thinking has advanced.
Over the years, I've started keeping a mental list of early indicators - patterns in the first 30 days that are most predictive of problems at month three, four, five. Some are immediately concerning. Some are manageable if there's a clear plan. But all of them are worth watching for.
The one I take most seriously: no visible output by the end of week two. Any delivery team that cannot show you a stakeholder interview summary, a technical observation, or a content sample assessment within the first two weeks hasn't started the discovery work. Full stop.
Close behind it: stakeholders who are "too busy" for interviews. A project whose key stakeholders cannot make time for a 60-minute conversation in the first three weeks will not get the internal alignment required for successful delivery. This isn't a scheduling problem. It's a sponsorship problem. If partners or department heads won't give an hour of their time early on, they certainly won't engage meaningfully when difficult decisions need making later. I've seen this pattern sit at the heart of almost every platform migration that's gone sideways.
Then there's access still being negotiated in week three. System access that wasn't provisioned in week one should have been escalated by the end of week one. If it's still being "worked on" in week three, that's a sign of either insufficient agency urgency or insufficient client-side sponsorship - probably both, honestly. And this one's on you as much as the agency. If your internal IT team is blocking access and you haven't personally intervened by day ten, you've contributed to the delay.
Discovery scope that has expanded without a formal change discussion is another one. The discovery that's grown from three workstreams to six without a documented conversation is showing you exactly how governance will work for the rest of the engagement. Spoiler: not well.
Watch for agency team members the client has never met. If unnamed people are doing the actual work while the principals manage the relationship, that's a structural risk. You should know who's writing the code, who's conducting the interviews, who's making the design decisions - not just who's presenting at the check-in. Raise it at week two if the full delivery team hasn't been introduced.
And finally: kick-off decisions that haven't been circulated in writing within 48 hours. This sounds minor. It's not. The discipline of documenting decisions immediately is a proxy for how the agency manages accountability throughout the engagement. If they can't write up week one's agreements promptly, they won't be rigorous about change control at week twelve either.
Not all of these are equal. No visible output by week two is a red flag. Access still being negotiated in week three, with a clear escalation plan and a named person working on it, is uncomfortable but manageable. The skill is in knowing which situations demand immediate intervention and which just need watching.
Here's the thing about the first 30 days that makes them different from every other phase of the project: intervention is easy. The relationship is new enough that direct feedback is expected. The project is young enough that the team can genuinely adjust course. Nobody's defensive yet. Nobody's invested months of effort that they feel the need to protect.
The effective early intervention is surprisingly simple. Name the specific observation: "I've noticed that the stakeholder interviews aren't yet scheduled - I want to make sure we have confirmed times by end of week." Ask for the agency's view: "What's getting in the way?" Then set a specific resolution timeline: "Let's confirm the schedule by Thursday and I'll remove any internal blockers from my side."
That's it. No drama. No escalation. Just specificity and a shared commitment to resolve it.
The sponsor who raises a week-two concern as a genuine question gets a completely different response from the agency than the one who raises the same concern as an accusation at the month-two review. By month two, everyone's entrenched. Positions have hardened. The agency has a narrative about why things are where they are, and the client has a narrative about whose fault it is. At week two, you're still just two parties figuring out how to work together.
The first 30 days aren't a warm-up period. They're a diagnostic. Every habit that forms in those first four weeks - how quickly decisions get documented, how access blockers get escalated, how scope changes get discussed, whether the people doing the work are visible to the client - those habits don't change later. They calcify.
So pay attention. Not anxiously, not with a clipboard and a stopwatch. But with the awareness that what you're seeing in the first month is what you're going to get for the next five.
If you want the week-by-week expectations, warning signs, and intervention prompts as a one-page project sponsor checklist, [download it here]. It's designed to sit on your desk - or more realistically, in a browser tab you actually keep open - for the first month of any digital engagement. Because by the time the formal review meeting rolls around, you should already know whether this project is on track. And if it isn't, you should have already had the conversation.