The demo ran flawlessly. Integration time came in under the projected estimate. The client's technical team said, and I'm quoting directly, "this is exactly what we needed."
Two weeks later, the project was cancelled.
No explanation. No counter-proposal. Just a polite email saying they were going in a different direction internally.
This is not a rare story. Ask any CS engineer who has worked on industrial PoC projects for more than two years and they will tell you a version of this. The technical execution was sound. The client seemed engaged. And then — nothing. The deal didn't convert, and the engineer never understood why.
The technical PoC succeeded. The organisational PoC was never run. That's the gap most engineers never see.
The standard post-mortem goes: "The champion left." "Budget got frozen." "They chose a competitor." These are symptoms, not causes. The real cause is almost always that the Go/No-Go decision was never made properly — and the engineer assumed it wasn't their job to make it.
It is.
Why Go/No-Go Belongs to You
There's a comfortable fiction in enterprise software that goes: engineers build, PMs decide, executives approve. In theory this is clean. In practice, by the time the decision reaches the executive layer, the framing is already set — and it was set by whoever was closest to the work.
That's you.
A PM who wasn't in the client's server room doesn't know that the latency issue only appears under shift-change load conditions. A sales lead who joined for the final demo didn't see the client's IT admin quietly step out of the room when the integration architecture was discussed. You did. You hold information no one else in the decision chain has.
If you don't surface that information in a structured way before the Go/No-Go moment, two things happen. First, the decision gets made on incomplete data. Second, if it goes wrong, there's no record that the risk was identified. Both outcomes are bad for the client. Both are professionally bad for you.
The engineer who documents the Go/No-Go decision is the engineer who gets called back for the next project. The engineer who stays quiet becomes a footnote in someone else's post-mortem.
Tool 6: The Three-Dimension Framework
The framework assesses readiness across three dimensions. Each dimension is scored 1–4. The combined score drives the recommendation — but the pattern matters as much as the total. A single dimension at 1 is a veto regardless of how strong the others are.
Dimension 1: Technical Readiness — Is your system ready?
This is the dimension engineers over-index on. It's necessary, but not sufficient.
- Core functionality performs at PoC load levels without intervention
- Failure modes are documented and recovery paths are tested
- Integration points with client systems are stable, not demo-stable
- Security posture meets client's minimum stated requirements
- Monitoring and alerting are in place for production hand-off
Scoring: 4 = all criteria met and documented / 3 = minor gaps, clear fix within 2 weeks / 2 = significant gaps requiring workarounds / 1 = fundamental issues — No-Go
Dimension 2: Operational Fit — Is the client organisation ready?
This is the dimension engineers under-index on. Most PoC failures trace back here.
- A named owner exists who has authority and budget to proceed
- The people who will operate this system day-to-day have been identified and briefed
- Internal IT/OT support has been engaged, not just informed
- Change management for affected workflows has been discussed
- Escalation path for production issues is defined and agreed
Scoring: 4 = owner named, operators identified, support committed / 3 = owner named, gaps acknowledged and planned / 2 = owner unclear or operators disengaged / 1 = no owner, no operational plan — No-Go
Dimension 3: Business Case Clarity — Are the numbers clear?
You don't need to write the business case. You need to know whether one exists and whether it's been stress-tested.
- ROI or cost-avoidance figure has been calculated, not estimated
- The calculation has been reviewed by someone with budget authority
- Payback period is within the client's standard capital approval threshold
- Competing priorities for the same budget have been discussed
- Success metrics for the first 90 days post-Go are defined
Scoring: 4 = numbers calculated, reviewed, approved in principle / 3 = numbers exist, approval underway / 2 = directional only, formal case not built / 1 = no business case — No-Go
Reading the Score
Add the three scores. Total ranges from 3 to 12.
10–12 → Go. Proceed. Document assumptions. Set 30-day review.
7–9 → Conditional Go. Proceed only with named owners for each gap.
4–6 → Hold. Address the lowest-scoring dimension first, then re-score.
3 → No-Go. Stop. Document why. A transparent No-Go protects the relationship.
The veto rule: Any single dimension scoring 1 is a No-Go regardless of total. A 4-4-1 is not a Conditional Go — it's a No-Go waiting for a client organisation that can actually use what you've built.
The Two Mistakes That End Careers
Wrong Go #1 — "The client is excited, let's move" Champion enthusiasm substitutes for Operational Fit score. Champion leaves in month 2. No named owner. Project stalls. Your implementation gets blamed for a client readiness failure.
Wrong Go #2 — "They said yes in the room" Verbal commitment from someone without budget authority treated as a Business Case score of 3. Formal approval never materialises. Project approved at working level, killed at executive review.
Wrong No-Go #1 — "The integration isn't perfect yet" Technical perfectionism scores Dimension 1 as a 2 when it's a 3. Operational Fit is strong (4). Business case is solid (4). Your caution kills a deal that was ready. The client moves to a competitor who ships.
Wrong No-Go #2 — "We need more data first" Indefinite extension of the PoC phase to avoid the decision. Client reads this as lack of confidence. Competitor with less complete data but clearer positioning wins on conviction alone.
The Decision Template
Use this before every client debrief. It takes 20 minutes and creates a documented decision trail.
From Framework to Practice
This is the sixth and final tool in the CS Engineer's Field Kit. Tools 1–6 cover the full engagement arc: requirements, value articulation, pain quantification, PoC risk planning, and the decision gate that converts a successful PoC into a live deployment.
The series continues. Tool 7 covers the PoC-to-production transition — where a different category of failure lives. Tool 8 covers stakeholder alignment. Both coming soon.
If you've followed from Tool 1, you've built a methodology. Not a checklist — a methodology. The difference is that a methodology tells you why each step exists and what it connects to. You can adapt it, defend it, and teach it.
That's the position you want to be in.
Wesley Lin is the founder of Wesley AI Inc., based in Taoyuan, Taiwan. 20+ years in industrial automation across Delta Electronics, ABB, and Schneider Electric. He writes about CS practice, OT systems, and EU compliance for engineers working in industrial and enterprise environments.