Why Technical Excellence Isn’t Enough

The engineers who get promoted to lead projects are often the ones least equipped to manage stakeholder communication. As engineers, we excel at solving complex technical problems but fumble the human systems that determine whether our solutions get implemented, funded, or accepted.

I learned this the expensive way early in my career when I built a Human-Machine Interface (HMI) for an underground coal reclaim system feeding a coal-fired power plant. The client asked for simple on/off control of the coal feeders. While I was at it, I decided to add alarms, live weigh scale readings, and downstream status because, well, I thought it would be useful (and cool!). And it was useful. But it also wasn’t requested, budgeted for, or approved. When the invoice landed, we ate the hours. Not because the features were bad, but because the Conditions of Satisfaction (CoS) were never defined, aligned, or understood. I solved the wrong problem.

This pattern repeats everywhere. Engineers disappear to “get it done” their way, surface at milestones, and hope the work speaks for itself.

Meanwhile, budgets drift, schedules slip, and teams stall waiting for updates that never came. The issue isn’t technical ability; it’s treating communication like an open-loop system instead of the closed-loop controller it needs to be.

The Real Cost of Communication Failures

Let me tell you about the client I lost for almost a decade because I sent status updates via email instead of picking up the phone.

I was reporting week after week that we were projecting to go over budget. Email after email, buried in status updates. I didn’t know if the client was reading them, but I didn’t confirm that. I assumed they understood and either had contingency funds or were hoping the problem would magically resolve itself. By the time we were actually over budget, he finally clued in but was already backed into a corner with his own.

When we finally TALKED about it (instead of hiding behind email), he reluctantly issued a small change order – just enough to get us to a handoff point where another firm could complete the programming and commissioning. We lost not just that project, but ten years of future work, all because I chose the wrong communication channel for bad news.

The “assumed scope” scramble is just as expensive but more common. I’ve watched entire project teams realize in the final weeks that critical work, the thing everyone thought someone else was handling, has no owner. Cue the panic. Weekend work. Finger-pointing. Missed commissioning dates. Client relationships that never fully recover.

Your Missing Control System

You already think in systems. A project is just a coupled system with four critical subsystems: scope, budget, schedule, and stakeholders. The problem? Most of us treat communication like an open-loop system; we send information out and hope for the best. (if we send it at all)

What we need is a closed-loop controller for project communication. CoS defines that setpoint (what “done” looks like). Regular updates and feedback provide the process variable. Course corrections become the control action that keeps the project stable. Most importantly, it lets you adjust the setpoint proactively, not reactively, after the system’s already failing.

That’s exactly what the Conversation-Commitment Framework does.

The Conversation-Commitment Framework

The Conversation-Commitment Framework is that missing closed-loop controller for project communication. It stops email disasters before they destroy client relationships and prevents assumed scope scrambles that cause weekend panic.

What it is: A practical framework that turns messy conversations into clear, written commitments tied to Conditions of Satisfaction (CoS). It works whether you’re managing up to your boss, coordinating with another department, delivering to external clients, or working with vendors; any relationship where someone needs something from you.

Origins: After watching budget overruns, scope creep, and client disasters repeat across decades of engineering projects, I realized the pattern: we treat communication like optional overhead instead of the control system it needs to be. The Conversation-Commitment Framework is my systematic approach to the four critical conversations that keep technical projects stable: clarify the need, commit to outcomes, course-correct in flight, and close with learning. These principles are drawn from commitment-based management research, project management best practices, and hard-won lessons from over 25 years of managing complex engineering projects and stakeholders, with a specific focus on the communication failures that cost engineering firms millions.

Two roles, four artifacts

Client (your manager, PM, stakeholder, customer): defines success criteria and confirms acceptance

Performer (you or your team): clarifies, commits, delivers, and proposes options when things change

Capture these four pieces every time:

• CoS: 1-3 bullets of acceptance criteria (what “done” looks like)
• Commitment: owner, deliverable, due date, and success test
• Cadence: who gets updates, how often, and via what channel
• Change triggers: what forces a renegotiation conversation, and who approves

The four phases

1. Clarify the Need – Align on outcomes and CoS. Ask, don’t assume.

• Write down what they say and what they don’t, so you’re not blindsided later
• Ask them to spell out their trade-offs. Is it quality, budget, or schedule? What matters most?

2. Commit to Outcomes – Write the promise: owner → deliverable → date → acceptance test

• Document the client’s CoS explicitly
• Define what triggers renegotiation upfront

3. Course-Correct in Flight – Send updates on cadence. Flag variance early with options.

• Keep an eye on the budget and schedule. If you’re drifting, stop and get sign-off first
• Identify issues while there’s still time for the client to choose their preferred trade-off

4. Close & Learn – Declare complete against CoS, get acceptance, capture lessons

• Written Declaration of Completion against original CoS
• Client confirms satisfaction; capture lessons learned

Example: “So success looks like operators can start/stop both feeders from the control room. Must-haves are on/off control with basic status. We’re capped at 60 hours by month-end. I’ll send a brief update every Friday. Anything missing?“

What it prevents: Assumed scope, silent variance, undocumented “extras,” fuzzy ownership, unclear acceptance.

This isn’t paperwork, it’s a habit. Use it for big projects and quick one-offs alike. You’ll do more work upfront to get these definitions, but it’s worth it.

The Disaster Prevention Checklist

Remember that email disaster and assumed scope scramble? Both could have been prevented by spending 10 minutes on this checklist before the work began. Clear Conditions of Satisfaction eliminate the assumptions that kill projects.

Use this before you start any task – paste it into your kickoff notes and answer in one short line per bullet:

• Outcome: What must be true at handoff? Write the client’s exact words.
• Must-have vs. nice-to-have: What’s required vs. what’s optional? Get it in writing.
• Constraints: Where is the hard stop? Is it budget, hours, deadline, or compliance? Which one wins if you cannot have all three?
• Update cadence: Who needs updates, how often, and by what channel? Include phone-call triggers.

Get the full 10-point checklist (interfaces, standards, change policy, paper trail) in the free CCF Toolkit.