Don't Stop Mid-Project: How to Run Meetings, Reporting, and Risk [Vendor Control, Part 2]

The real game starts after you place the order

In Part 1, we covered locking down requirements and the estimate before placing the order. Once the groundwork is set, the next challenge is how you run things after the contract is signed. No matter how good your requirements are, a project will blow up if you skip the design of mid-flight communication. This time we take on the daily habits that keep a project moving.

Decide your meeting cadence and reporting frequency up front

If you try to figure out "when, to whom, and what to report" after the fact, you will always be playing catch-up. Set it up as a defined meeting cadence at the start of the project.

• Reserve the frequency in advance according to importance—a weekly standing meeting, a biweekly review, and so on (it's easier to cut them later if they turn out to be unnecessary)
• Text is plenty for sharing progress. Use meetings as the place to decide and agree.
• Work the goal of today's meeting backward from the end goal. Trace it as "final form → what's needed by next month → what to decide this week → what to lock down today," and the points to discuss naturally narrow.

Meetings where people just read out progress slow the project down.

Make the ball and the deadline explicit every time

With every exchange, make it clear whose turn it is to act—who holds the ball.

• Always end an email or chat message with the next action, the owner, and the deadline.
• "By this week" or "early next week" leaves room for interpretation. Lock it down by day and time, as in "by Friday 5 p.m." or "Monday morning."
• The moment you realize the other side's judgment or sign-off is needed, send candidate dates.

If you close with "Thanks in advance," the ball is left hanging in the air.

What to do when the vendor never reports

You only ever hear "things are on track" in the progress meeting, and you can't see what's actually happening internally—this is a classic bottleneck. Believing "on track" and waiting backfires, and so does grilling them in an interrogating tone. Solve it with a system.

• Define a standard format for regular reports: make four items mandatory—progress percentage, issues, risks, and next week's plan.
• Review the deliverables: judge progress by the actual work product, not by the words in the report.
• Set up one-on-ones: draw out the concerns people can't voice in a group meeting through one-on-one conversations.
• Make "bad news first" the rule: build a culture that praises the person who reports early rather than blaming them.

The trick is not to blame the other side for "not reporting," but to provide—from the client side—a format and an atmosphere that make reporting easy.

Catch risks while they're small; in a crisis, decide by structure

When problems are found only after they've grown, the cost of dealing with them skyrockets. Constantly pick up on the off-feeling signals (this hasn't moved this week, that person isn't acting), and move the moment you spot one. The real cause of a stuck task is almost always one of three things: people, information, or sign-off.

So you don't hesitate when a problem arises, decide on a yardstick for judgment in advance.

"Let's wait and see a little longer" is the most dangerous response of all. The worse the news, the faster it goes out—share it the moment you spot it, in the form of "there's a problem, and here's what we'll do about it." Surface it early and you have many moves; surface it late and only one option is left.

Report to leadership in "three points, numbers, options"

If you get pressed with "So when is it actually done?" and "Will it go over budget?" in the reporting meeting, it's because the shape of your report is poor. Detailed technical explanations and "we'll do our best" don't land.

• Report in three points: (1) where things stand (in numbers), (2) the issue (in terms of impact), (3) the next action.
• Answer with numbers: not "on track," but "75% complete, on schedule."
• Prepare for likely questions: before reporting, come up with three things you'd ask "if I were the executive."
• Bad numbers first: "Actually, we're a week behind. The cause is X, and the countermeasure is Y."

Rather than dumping it on the decision-maker with "What should we do?", lay out the options—"Which of (1) through (3) would you like?"—and the decision comes faster.

Keep "what was decided" in the minutes

Even things confirmed verbally will be thrown back at you later as "I never said that" unless you write them down. Rather than transcribing every remark in detail, focus on decisions.

• Write around decisions, not a transcript of remarks: make clear who, what, and by when.
• Share within 24 hours (the sooner, the faster and more accurate, while memories are fresh).
• Set a deadline—"raise any objections within 48 hours"—and secure tacit agreement.

Don't ask "dump-it-on-them" questions

How you ask changes how things move forward.

• Instead of "How's this going?", attach a hypothesis: "My understanding is that this is X—is that right?"
• Don't take "so-and-so said so" at face value; for anything important, go to the primary source.
• For things that are hard to convey in words, show a screen mockup or a sample.

When the schedule starts to slip

Several tasks are more than a week behind. Expecting them to recover on their own with "we'll do our best," or blanket-applying overtime across every task, backfires.

• Sort the cause of the delay into three buckets: a technical problem, a shortage of resources, or a change in requirements.
• Concentrate on tasks on the critical path: for everything else, you can tolerate some delay.
• Escalate early: tell them ahead of time, "At this rate, the deadline will slip by two weeks."
• Offer three responses: (1) add resources, (2) cut scope, (3) extend the deadline.

The same applies when you start the work and find the effort is double what you assumed. Don't quietly let it run long—rebuild the effort estimate from the ground up and consult early, together with the options.

When stakeholders disagree

"Sales wants it in now, IT wants to be cautious, the frontline doesn't want it at all"—when positions differ, so do opinions. Being vague with "we respect everyone's views" or deciding by majority vote will tangle things up later.

• Make the lines of conflict explicit: structure who wants what, and why.
• Return to the shared objective: realign around the higher-order goal of "achieving the business objective."
• Offer three alternatives: look for a compromise where each position can say "half of this is OK."
• Make clear who owns the decision: settle in advance who ultimately decides.

When you can't get the frontline to cooperate with interviews or testing, don't blame them as "uncooperative." Put into words what this system actually makes easier for the frontline, lighten the burden into something like a 30-minute session that can even be done over chat, and respond to the input they give with "we've reflected this." Starting from one ally and spreading sideways is the standard play.

Make a "stakeholder map" at the start

At the start of the project, write out who is interested in what, at what frequency, and through which channel you'll reach them. Meet everyone involved face-to-face once when you join, and ask about their position, interests, pain points, and the sign-off flow. The trick here is to grasp both their interests (what results they want to see) and their anxieties (what they don't want to lose). People you've met in person become easier to work with.

Choose the channel by urgency

Choose by the speed you need, not by what's least burdensome for the other side. It's also important not to spend too much time producing reports. Settle on a fixed template—progress, issues, risks, next week's plan—keep the writing under 15 minutes, and attach a separate document for anyone who needs the detail.

Don't let everything hinge on one person

When a key person is frequently out—sick or on leave—progress stalls. It's dangerous for everyone to wait, thinking "we'll do it once so-and-so is back."

• Carve out work that can move forward without that person.
• Build a setup where other members can stand in, through pair work and knowledge sharing.
• Have them write out the information that's in their head as documentation.

Becoming person-dependent is the hardest risk to see mid-project. The moment you spot a "only this person understands it" situation, break it down early.

Close every standing meeting with "decisions and homework"

You can hold a meeting and have nothing left afterward. Five minutes before the end, always confirm these three out loud:

• What was decided
• The points carried over
• Homework (who, what, by when)

Just making this a habit turns "felt-productive" meetings into meetings that actually move things forward. When decisions are recorded, the next meeting can start by checking on the previous round's homework.

Log issues; don't let them sit

Log the issues that come up day to day in an issue list rather than keeping them in your head. Putting them on record cuts down the "I said / I didn't say" and prevents things from slipping through the cracks.

• For each issue, record the content, owner, deadline, and status.
• Handle "risks" (concerns that haven't happened yet) and "issues" (problems that have already happened) separately.
• In standing meetings, spend time only on overdue issues and newly surfaced risks.

The trick is not to chase every issue each time, but to shine a light only on "the ones that aren't moving."

Treat the vendor as a "collaborator"

What's easily overlooked in project management is the relationship with the vendor. The more tightly you clamp down on management, the less bad information surfaces.

• Align on requirements and assumptions, and share the same goal.
• When something goes well, evaluate it honestly and say so.
• From the client side, keep stacking up responses that make them feel "glad I reported that."

If you make a habit of including one "benefit for the other side" with every contact, you'll find it easier to win their cooperation. Organizing the inputs for a decision, spelling out the next action, offering alternatives—this kind of extra step changes how readily your requests get taken up. Treat the vendor as a partner rather than a subcontractor, and the quality of reporting goes up—and, in the end, so do both quality and speed.

Part 2 checklist

• Did you decide the meeting cadence and reporting frequency at the start?
• Are you writing "the next action, the owner, and the deadline" at the end of every exchange?
• Did you define a format for regular reports (progress percentage, issues, risks, next week's plan)?
• Are you and the vendor sharing risks and off-feeling signals while they're still small?
• Are you building reports to leadership around "three points, numbers, options"?
• Are your minutes centered on decisions, and shared the same day?

Related material: Project-driving skills such as running meetings and managing risk are also covered in our free IT Consulting Guidebook (the project management course).

Wrap-up and what's next

Project management isn't an individual feat—it's the accumulation of habits. Set up your meeting cadence, make the ball and the deadline explicit, prepare a reporting format, and surface risk early. Just this much sharply reduces the number of projects that stall.

In the next installment (Part 3), we'll take on the trouble that still happens anyway—quality, the back-and-forth on estimates, and how to handle closing—and bring the series to a close. When you want an outside perspective to support your project management, a PMO that understands development can also provide hands-on support.