UpTrajectory Review

Small Business Trends offers a serviceable how-to on building IT project communication plans: identify stakeholders, pick channels, set update schedules, assign ownership, and gather feedback. The advice is sound but generic. What the piece gestures at without developing is why this matters more now than it did five years ago. Most small businesses today are running some form of IT project — a POS migration, a CRM rollout, a security overhaul after an insurer demanded it — with a team that has never managed one. The failure mode is rarely technical. It is the owner assuming the vendor is communicating, the vendor assuming the owner's office manager is communicating, and nobody telling the floor staff anything until the system goes dark on a Friday.

For a small operator, the concrete stake is money and time you cannot spare. A botched software rollout at a 20-person company does not produce a postmortem; it produces three weeks of manual workarounds and a vendor relationship you cannot afford to exit. The article's core point — that communication has to be planned, assigned, and scheduled rather than assumed — is exactly right, and it maps to the single most common complaint we hear from operators after a failed implementation: nobody told me. A communication plan is cheap insurance. An hour spent writing down who hears what, when, and from whom prevents the far more expensive discovery that your bookkeeper learned about the accounting system change from a login screen.

Where we would push back on the piece is its framing of communication as primarily a stakeholder-satisfaction exercise. The bullet points about tailoring messages and improving satisfaction read like they were written for a mid-size IT department, not a five-person operation where the same person is the client, the approver, and the tester. The genuinely useful, underplayed idea here is structured protocols reducing misunderstandings — that is the part with teeth. A written escalation path matters more than a monthly report when a migration goes sideways at 4 p.m. on a Thursday. We are skeptical of any plan that produces more meetings rather than fewer surprises.

The second-order effect worth naming: communication plans change who absorbs risk. When a vendor's plan says updates flow through one designated contact, that person becomes the bottleneck and the scapegoat. Operators should notice that a good plan also creates a paper trail — and a paper trail cuts both ways. If the project fails, the record of who was told what and when determines whether you have leverage in a dispute or a refund negotiation. That is a reason to keep the plan in writing and in your own systems, not just in the vendor's project tool, which you will lose access to the moment the contract ends.

What to do with this: before your next technology project starts, spend one hour producing a single page that lists every person affected, what they need to know, the channel, the frequency, and the named owner — including someone on the vendor's side with a name and email, not a support alias. Then ask the two questions the article raises but does not answer: what happens when the schedule slips, and who is allowed to pause the project. If your vendor cannot answer both, that tells you something the demo did not. Watch for whether your team actually reads the updates; if they do not, the plan is decoration, and the problem is the message, not the medium.

“Start by identifying key audiences, like your team members, clients, and external partners.” — Small Business Trends

Takeaway: Before your next IT project, write a one-page plan naming who gets told what, when, and by whom — including a named contact on the vendor's side.