What Questions Do I Need to Ask?

A new consultant reached out to me the other day, nervous about a kickoff. "What questions do I need to ask?"

I started listing them off and realized something. Initiating a project becomes a skill after you've done it enough times that the questions stop feeling like a checklist and start feeling like instinct. But underneath that instinct, every question I gave her collapsed into four words. What. Who. Where. When. And underneath all of it, why.

What tool are we using? Slack, email, texting, something else. Who needs to be in which conversation, and who's the escalation path when something breaks? Where does the actual work happen, and where do decisions get made? When are we meeting, and is that cadence going to hold once the honeymoon phase of the engagement wears off? And most important: why are we doing what we're doing?

That's a communication plan. It sounds basic because it is basic. And I think we've started treating basic like an afterthought, something to delegate to whoever's newest on the team.

Why Setup Isn't Beneath You

As PM work gets more strategic, there's a temptation to treat the setup work as the part you delegate or rush through so you can get to the real thinking. Strategy, vision, the stuff that looks good in a deck.

I'd push back on that. The communication plan isn't the administrative layer underneath the strategic work. It is strategic work. It's the first real test of whether you understand the engagement you just walked into. I still use AI to draft the first pass of a communication matrix: stakeholders, channels, frequency, and it's a fine time-saver. But it can't tell you which escalation path will actually get used, or which stakeholder says they want weekly updates but really means they only want to hear from you when something's wrong. That's not a template problem. That's a sitting-with-the-client-and-asking-what-they-don't-want-to-answer problem.

Every client relationship has an actual escalation path and a theoretical one, and they're rarely the same. The org chart says one thing. The person who actually picks up the phone when something's on fire says another. If you don't map that out in week one, you find out the hard way, usually mid-crisis, usually at the worst possible time.

Same with meeting cadence. Weekly syncs sound obvious until you're three weeks in and half the stakeholders have quietly stopped showing up because nobody set the expectation that this meeting is where decisions get made, not just where updates get read out.

None of this is glamorous. But skip it, and you spend the first month untangling confusion a single conversation could've prevented.

A Founder, a Parking Lot, and the Question Under the Question

That "why" question isn't just a nice fifth item on the list. It's the one that actually did work for me a few months back, with a founder who was spread thin. Everything that could go wrong on her team was showing up as a fire to put out rather than something caught early. Our first meeting was a whirlwind. I got whiplash after an hour. We threw everything at the wall and started unpacking. Pure aspiration phase.

She told me they were using a project tool. They weren't, not really. It had become a parking lot. Things went in, nothing came back out.

We spent the next month unpacking what was sitting in that parking lot and building communication that actually worked. Documentation isn't the enemy of speed, whatever the scrappy-startup instinct says. It's what gives everyone a shared picture of where things stand and what you're building toward. Without it, you don't have alignment. You have everyone's individual version of the plan, and those versions drift the second nobody's looking.

So we set the rule: tasks and work in progress live on the Kanban board, not in a Slack DM. Simple to say, harder to hold. It took training, and it's still taking pushback in week two, me reminding people to work inside the system instead of pinging whoever answers fastest.

Here's what the pushback actually surfaced. Every time I asked why a task was jumping the line, the honest answer kept landing in the same place: they needed to get funded. Full stop. Every task, when you traced it back far enough, was either helping convert a lead or it wasn't. The team wasn't short on urgency. They had plenty. What they didn't have was a shared filter for which urgent thing actually moved them toward funding and which one just felt loud in the moment. Once "does this convert a lead" became the real test, the reprioritizing didn't stop, but it stopped being arbitrary. The Kanban board gave the work a home. The why gave the team a reason to agree on what belonged at the top of it.

That's the part that doesn't happen in a vacuum. We built the process in meetings, pulling input from the team, adjusting based on what people pushed back on. We agreed on it together, including on what actually counted as urgent. Every team is a little different, a slightly different combination of what makes it work, and your communication plan should reflect that. A comms plan or a task system someone hands down doesn't get followed. One the team built alongside you, including the fights about what matters more, does.

Permission to ask the Question

Back to that consultant. What I was really teaching her wasn't a framework. It was permission to ask the basic questions without apologizing for them. Where are we communicating? Who's in the room? When do we meet? What happens when something breaks? And why we're doing the work at all, the thread that ties everything else together and the one most likely to get skipped because it feels like it slows things down.

It doesn't slow things down. It's the only thing that tells you whether the speed you're moving at is pointed anywhere.