Frequently technology implementations go-lives don't go smoothly. Orders get stuck, invoices can't be created, bills can't be paid, customers get angry, and teams spend weekends fixing what should have worked from day one. But some organizations turn on new systems and nothing breaks. This episode reveals exactly why, using a real-world case study of a mid-sized international manufacturer that replaced their core business systems without a single crisis.

What You'll Learn

• Why tech disasters aren't about the software, they're about what happens before go-live
• The leadership decision that eliminates confusion before implementation begins
• How to identify which processes must work on day one (and which can wait)
• The difference between training employees and making them truly ready
• Why "we'll fix it later" is the most expensive phrase in tech implementation
• A practical framework for preventing chaos that any organization can replicate

Who Should Listen

• Business leaders planning technology implementations
• IT directors and project managers overseeing system rollouts
• Operations managers responsible for business continuity during transitions
• Anyone who's experienced (or wants to avoid) a tech implementation disaster

Key Takeaways

Leadership Alignment Matters More Than Technology Success starts when senior leadership makes participation non-negotiable and communicates why the initiative matters to every level of the organization.

Test Real Work, Not Demos Critical workflows must be validated end-to-end under real conditions. If something doesn't work in testing, it won't magically work at go-live.

Answer the Critical Question What must work on day one for the business to operate? Prioritize those processes, validate them, and build contingency plans around them.

Readiness Over Training The real question isn't "Were people trained?" It's "Can people actually do their jobs in the new system under pressure?"

Plan for Problems Before They Exist Inventory staging, customer notifications, strategic timing, and contingency planning are all forms of intentional risk reduction.

Systems Fail Where Organizations Allow Gaps It's not bad luck when implementations fail. Systems break exactly where processes aren't documented, people aren't engaged, and assumptions replace validation.

Featured Case Study

A mid-sized international manufacturer and distributor replacing core systems for financials, procurement, manufacturing, distribution, and customer service. The initiative wasn't just a technology upgrade, it was a business-critical risk. Their approach eliminated go-live chaos through disciplined preparation, not larger budgets or complex tools.

Questions to Ask About Your Organization

Before your next technology initiative, consider:

• Has leadership truly made participation mandatory, or is it still optional in practice?
• Which processes are assumed to work but have never been fully documented or tested?
• Where are you relying on "we'll fix it later" instead of validating now?
• Can your people actually perform their real jobs in the new system, or have they only seen demos?
• Where might people not be fully engaged, and what's the plan to address it?

Bottom Line

Technology implementations don't fail randomly. They fail exactly where organizations allow gaps to exist. The good news? Success is completely repeatable. It doesn't require massive budgets or complex tools. It just requires saying: "Before we turn this on, let's make sure it actually works for everybody who depends on it."

Connect With Me On LinkedIn

www.linkedin.com/in/jimkineon

In this episode, I examine a cautionary tale about a well-funded, well-planned technology implementation that went horribly wrong—not because of bad technology, but because of organizational gaps that were never addressed. When a mid-size organization rolled out a new finance, purchasing, payroll, and CRM system, thousands of employees couldn't get paid, vendors went unpaid, and mortgages bounced. The hardest part? It was completely preventable.

This story isn't about technology failure—it's about what happens when people, processes, and organizational alignment are treated as optional rather than critical to success.

Key Takeaways

The Setup Was Sound

• Well-funded project with good consultants and preparation
• Employees were trained and tested for readiness
• Core departments (purchasing, finance, payroll, call center) actively participated
• The project team validated that people could perform real day-to-day work in the system

The Critical Mistake

• Multiple departments and business units never engaged in the project
• These departments didn't attend workshops, contribute processes, review designs, or perform test scenarios
• Leadership never made participation mandatory
• The assumption was made: "If we didn't hear about a problem, there isn't one"

What Went Wrong

• Non-participating departments' processes were never identified or documented
• Non-standard processes were never built into the system
• Critical workflows were never tested
• When the system went live, it couldn't process payroll or pay vendors
• Employees' mortgage payments bounced, late fees hit, and trust was damaged

The Root Cause This wasn't a technology failure—it was a people and process failure that manifested in the technology. The system did exactly what it was told to do; the problem was what it was never told.

Critical Questions for Your Organization

Before implementing any new system, ask yourself:

1. Are all departments truly engaged? Not just invited—actually participating?
2. Have all processes been identified and documented? Including the non-standard ones in different corners of the organization?
3. Has leadership clearly stated that participation is required? Or is engagement optional?
4. Have you tested real end-to-end scenarios? Not just button-clicking, but actual day-to-day work?
5. Where are you assuming instead of validating?

The Four Pillars That Must Align

• People: Everyone who will be affected must participate
• Process: All workflows must be identified, documented, and built into the system
• Technology: The system must be configured for your actual processes, not ideal ones
• Organization: Leadership must make participation non-negotiable and hold departments accountable

Why This Matters for Every Organization

Size doesn't protect you. Small and mid-size businesses actually get hit harder when this happens because they have fewer people and less margin for error.

The cost of fixing always exceeds the cost of preventing. The organization in this story spent far more on emergency consultants, workarounds, and crisis management than they would have spent ensuring complete participation upfront.

Your system will fail exactly where it's weakest. If even one department opts out, that's where your system will break. It's not bad luck—it's simple physics.

How to Prevent This Disaster

The solution doesn't require fancy tools or massive budgets. It requires:

• Bringing every department to the table
• Getting their processes documented
• Holding them accountable for participation
• Testing real-world scenarios end-to-end
• Making participation a leadership requirement, not a request

Bottom line: Before you turn the system on, make sure it actually works for everyone who depends on it.

Final Thought

Your technology will only ever be as strong as the people, processes, and organizational structure behind it. The next time you're planning a technology initiative, don't just ask "Is the technology ready?" Ask "Are we ready?"

Connect With Me On LinkedIn

www.linkedin.com/in/jimkineon

A routine prescription refill should take two minutes. But when a healthcare provider botched their technology rollout, it turned into a two-day ordeal that cost them a long-term patient.

In this episode, I walk you through exactly what went wrong—and more importantly, the five simple steps that would have prevented the entire disaster. If you're a business leader planning any kind of technology change, this episode will show you how to avoid pushing your customers straight to your competitors.

This episode is for you if:

• You're planning a technology upgrade or system migration
• You've ever lost customers after implementing new technology
• You want to know the difference between technology that works and technology that drives people away
• You're tired of watching good intentions turn into expensive disasters

What You'll Learn

The Real Story Behind Technology Failures

• Why the software itself wasn't the problem—the rollout was
• How a single botched implementation can erase years of customer loyalty
• The actual cost of skipping basic implementation steps (spoiler: it's more than you think)

The Five Elements Every Successful Rollout Needs

1. Clear, repeated communication before go-live
2. Full data verification and testing before launch
3. Easy-to-follow transition instructions
4. Staff training completed before customers use the new system
5. Immediate, effective support when customers need help

Why This Matters to Your Business

• How technology frustration translates directly to customer loss
• Why customers blame you, not the technology, when things go wrong
• The competitive advantage of getting technology rollouts right

Key Takeaways

"Technology doesn't fail on its own. It fails when people, processes, and the organization aren't aligned around it."

"When technology disrupts and frustrates people, they don't blame the technology—they blame you."

"Poor technology, or good technology with poor rollout, pushes customers away. It costs you money, damages your reputation, and in competitive markets, those customers aren't coming back."

Action Items

Before your next technology rollout, ask yourself:

• Are we investing as much in the rollout as we are in the technology itself?
• Have we verified that all data will transfer correctly?
• Have we communicated clearly and repeatedly with customers?
• Have we trained our staff before go-live?
• Have we planned adequate support resources?

If you answered "not really" or "we'll figure it out" to any of these questions, you're setting yourself up for the exact disaster described in this episode.