Why strategy—not software—determines whether technology investments actually deliver value

Technology buying failures rarely happen because a team chose the “wrong” software. They happen earlier when the organisation enters the RFP process without the strategy, clarity, or alignment required to make a good decision.

Most technology buyers in engineering and manufacturing only see a handful of production lines, factories, or process workflows over the course of their careers—often within the same company, sometimes within the same operating model. That means they know what their world looks like, but they have limited visibility into what “good” looks like across industries, growth stages, or operating models. At the same time, technology is accelerating, vendors are proliferating and consolidating, and marketing claims are getting louder—especially around PLM, CAD/CAM, simulation software, and end-to-end engineering platforms.

Against that backdrop, many buyers treat the RFP as a starting point. They move quickly, rely on familiar signals, and focus requirements on the most immediate problems in front of them. Unfortunately, those instincts often lead to predictable and expensive mistakes.

Below are 10 common ways technology buyers in engineering and manufacturing get it wrong before the RFP ever hits the street and what a strategy-first approach does differently.

1. Starting With a System Instead of a Business Outcome
Most initiatives begin with a conclusion rather than a question: “We need a new ERP, PLM, or MES.” That belief may come from growth, acquisition, process expansion, or the sense that current tools have been outgrown.

Why it fails:
When technology is treated as the objective, requirements focus on functionality instead of outcomes. Buyers spend their time documenting what the system should do rather than what the business needs to achieve: faster time to market, improved product quality, optimized resource utilization, or scalable engineering operations. Vendors respond accordingly with polished demos and confident roadmaps, but no one is accountable for whether those capabilities translate into measurable business impact.

Strategy-first alternative:
Start with the outcomes the business needs to deliver and work backward. Let those outcomes determine whether technology is required at all, what role it should play, and which tradeoffs matter. Technology should be a consequence of strategy, not a substitute for it.

2. Treating Today’s Pain as the Real Problem
Manual workarounds, missed project deadlines, spreadsheet dependency, and poor reporting often dominate early discussions because they are visible and painful. But they are rarely the underlying issue.

Why it fails:
Pain points are symptoms of deeper structural problems: misaligned engineering processes, unclear decision rights, weak data foundations, or operating models that no longer fit the business. When these conditions exist, technology is often used to compensate. Workflows get manually overridden, rules get bypassed, and “temporary” workarounds become standard practice. When buyers select new technology to fix a pain instead of addressing the underlying problem, they often embed the same behavior into a new system.

Strategy-first alternative:
Treat pain as a signal, not a diagnosis. Step back and understand why the organisation is struggling before deciding how to fix it. Otherwise, technology becomes an expensive way to mask deeper issues.

3. Assuming Technology Will Fix Broken Processes
RFPs frequently document the current state in extreme detail with the implicit belief that “modern software” will somehow make those processes better.

Why it fails:
Technology does not fix broken processes, it accelerates them. Automating a flawed workflow only increases the speed and visibility of inefficiency, now accompanied by dashboards and alerts. Teams end up locked into faster execution of work that no longer makes sense.

Strategy-first alternative:
Redesign engineering and manufacturing processes based on how the business should operate in the future, then select technology that supports that design. Technology is an amplifier. Without process discipline, it amplifies the wrong things.

4. Skipping the Target Operating Model
Many organisations cannot clearly articulate how they want engineering, production, and quality operations to function three to five years from now. As a result, requirements blend legacy behaviors with aspirational goals.

Why it fails:
Without a defined target operating model, technology decisions lack direction. Vendors are asked to reconcile competing objectives—standardisation and customisation, automation and manual control—without clear guidance. Fundamental questions remain unanswered: who owns decisions, when automation should intervene, and when human override is expected. These ambiguities resurface during implementation, when tradeoffs become costly and hard to reverse.

Strategy-first alternative:
Define the target operating model upfront: roles, decision rights, escalation paths, and performance expectations. When the operating model is clear, technology requirements become coherent and comparable.

5. Letting One Function Drive the RFP
Technology buying is often led by a single function—IT, engineering, or production—based on where the pain feels most acute or who has budget available.

Why it fails:
Optimising from one functional perspective frequently creates friction elsewhere. Systems that work well locally can degrade end-to-end performance, introduce handoff issues, or misalign incentives across the broader operation.

Strategy-first alternative:
Design requirements cross-functionally, anchored in end-to-end operational outcomes. Input should reflect the needs of all impacted stakeholders, not just primary users. Technology should serve the organization as a whole, not the loudest stakeholder in the room.

6. Overloading Feature Lists Instead of Decision Support
Many buyers rely on exhaustive requirement lists, sometimes sourced from third parties without tailoring to their own business, to demonstrate rigor.

Why it fails:
Feature checklists do little to improve decision quality. Buyers end up with platforms that can do many things but do not materially improve engineering planning quality, responsiveness, or execution speed. The system becomes a tool for compliance rather than better decision-making.

Strategy-first alternative:
Anchor requirements around decisions and use cases: what decisions need to be made, under what conditions, and with what balance of automation and human judgment. When requirements reflect how the business operates, responses become valuable gauge to help determine if the technology is designed to support and improve your operations. Decision quality, not feature count, is what drives value.

7. Ignoring Change Management Until After Selection
Change management is often treated as an “implementation issue” rather than a strategic input.

Why it fails:
Solutions exceed the organization’s readiness, skills, or appetite for change. Advanced capabilities are quietly shelved, workarounds proliferate, and adoption stalls without anyone formally declaring failure.

Strategy-first alternative:
Assess organizational maturity early and align technology ambition accordingly. A solution that the organization can fully adopt will outperform a more sophisticated one it cannot.

8. Assuming Data Is “Good Enough”
RFPs often assume optimal conditions: clean master data, consistent processes, and disciplined data governance even when reality says otherwise.

Why it fails:
Technology performs well in demos and poorly in production not because the software breaks, but because the data feeding it is unreliable. When data readiness is not assessed upfront, organizations expect the system to compensate for weak inputs. Technology cannot correct these behaviors; it will reflect them.

Strategy-first alternative:
Evaluate data maturity explicitly and early. Identify which elements are critical to system performance, how they are created and maintained, and where ownership sits. Standardise foundational data where possible and align expectations with vendors around data requirements. Addressing gaps upfront allows organizations to plan remediation intentionally, rather than discovering limitations after technology is already in place.

9. Treating the RFP as a Documentation Exercise
Many organizations measure RFP success by participation rather than insight.

Why it fails:
The RFP becomes a static artifact instead of a decision-making tool. Assumptions go untested, tradeoffs remain implicit, and real priorities stay hidden.

Strategy-first alternative:
Use the RFP to challenge thinking, surface priorities and tradeoffs, and sharpen decisions. The goal is clarity and strategic alignment, not volume.

10. Rushing to “Show Progress”
Leadership pressure to move quickly often drives teams to issue an RFP or select a solution before alignment exists.

Why it fails:
Shortcuts upfront create delays downstream: re-scoping, mid-implementation resets, missed ROI. What looks like speed becomes drag.

Strategy-first alternative:
Recognize that strategy accelerates execution. Alignment eliminates false starts and reduces long-term risk.

The Bottom Line
Most technology failures are not the result of poor vendor selection. They are the result of organizations being unprepared to buy technology in an increasingly complex, hype-driven market. A strategy-first approach doesn’t slow technology selection. It ensures buyers are solving the right problems, setting realistic expectations, and using technology as a tool—not a crutch—to deliver real business outcomes.

About the Author: Tara Buchler is Principal, Strategy at JBF Consulting, a leading logistics strategy advisory and technology integration firm. She brings more than 20 years of experience at the intersection of logistics operations and enterprise supply chain software. For more information, please visit www.jbf-consulting.com.