A third-generation manufacturing company hired me to oversee their first internal software project. They made industrial packaging equipment - physical machines, shipped to factories worldwide. The company had 200 employees, $30M in revenue, and their entire operations ran on a combination of spreadsheets, a 20-year-old ERP system, and phone calls.
They had recognized that their field service technicians - the people who flew around the world to install and repair their machines - were operating blind. No digital record of machine history. No way to know what parts a technician would need before arriving on site. No visibility into service call outcomes across the fleet. The sales team was losing renewal conversations because they could not demonstrate service value.
The project: a field service management platform. Simple in concept - a mobile app for technicians, a web dashboard for operations managers, an API connecting to the ERP. In execution, it was the most complex project the company had ever attempted, because it was the first one.
Eighteen months later, they had shipped. The technician app had 93% adoption within 60 days. The operations team had visibility they had never had. The sales team had data. One enterprise customer renewed a contract that had been at risk, citing the service reporting as a deciding factor.
What made it work was not the technology. It was having a structure for making decisions that a first-time software project does not have by default.
The First Software Project Problem
Traditional companies building their first significant software product face a set of challenges that are invisible to people who have shipped software before.
They do not know what they do not know. A company that has shipped products before knows where the hard parts are in their domain. A company shipping software for the first time does not know that requirements will change, that estimates are fiction, that testing is not a phase at the end, or that "done" means something different in software than in manufacturing.
They underestimate the organizational change component. A field service app does not just give technicians a new tool. It changes how work is recorded, how performance is measured, and who has visibility into what. The people whose jobs change are the same people the project depends on for requirements and adoption. Managing this tension is not a technology problem.
They have no internal vocabulary for software decisions. When a software team presents three architecture options, a traditional company decision maker does not have a framework for evaluating them. They pick based on cost, or based on familiarity with the vendor names, or they defer entirely to the technical team - which then makes decisions without business context.
A fractional CTO in a traditional company context provides the bridge: someone who speaks both the technical language of the engineering team and the operational language of the business, and can translate between them.
The Playbook for a First Software Project
I have run first software projects in manufacturing, logistics, healthcare operations, and professional services. The playbook that works across these contexts:
Start with a process map, not requirements. Before anyone talks about features, map the current process. In the field service case: how does a service call currently flow from initial customer report to technician dispatch to site visit to completion to billing? Walk it step by step with the people who actually do the work, not the managers who think they know how it works. The gap between how management thinks a process works and how it actually works is reliably surprising.
Identify the minimum viable change. What is the smallest version of this system that creates measurable business value? The first version does not need all the features. In the field service case, version one was: technician receives job details digitally, records job completion digitally, customer receives digital service report. That is it. Everything else - parts inventory, predictive maintenance, customer portal - was version two or later.
Choose boring technology. First software projects should use established, well-documented technology with a large talent pool. This is not the moment to evaluate cutting-edge frameworks. The organization's ability to hire engineers who can maintain the system is more important than the technical advantages of a newer technology.
Embed in the business, not just the project. I spent time at this manufacturing client's facility watching technicians work, sitting with the operations team during their morning briefings, and reviewing service reports. The technical work is useless if it does not match how the business actually operates.
Plan for change. Requirements will change. The people who gave you requirements will discover they were wrong once they see working software. Build this into the schedule explicitly - plan two-week sprints, hold regular demos, maintain a change process that is cheap enough to use.
The ERP Integration Problem
Almost every traditional company has an ERP system - SAP, Oracle, Microsoft Dynamics, Sage, or one of a hundred vertical-specific systems. Every new software project needs to integrate with it.
ERP integrations are consistently the hardest part of digital transformation projects in traditional companies. The reasons:
ERP systems are old and complex. The system reflects 20 years of business-specific customization. The data model is not clean. The documentation is incomplete. The people who know how it works are often a single long-tenured employee and an expensive consulting firm.
ERP vendors charge for integration access. Many ERP systems charge for API access separately from the base license. This is sometimes a surprise budget item in first software projects.
ERP data quality is often poor. The assumption that the ERP is the "system of record" for clean, reliable data is frequently wrong. Customer records are duplicated, part numbers are inconsistent, historical data is incomplete. The new software will inherit these problems through the integration.
The guidance I give: treat the ERP integration as a separate project within the project, budget for it at 2x the initial estimate, and define very clearly which direction data flows and what the source of truth is for each data type.
In the field service project, we spent three weeks on the ERP integration alone, and we still had to build a manual data reconciliation process for customer records where the ERP data was too inconsistent to trust.
Change Management Is a Technical Problem
The biggest failure mode in traditional company digital transformation is adoption failure. The software gets built, it works technically, and the people who were supposed to use it do not.
This happens for reasons that are partly human and partly technical:
The new system adds friction to existing workflows. If the technician's job becomes harder with the new app than with the old paper form, they will find ways to avoid using it. Every extra tap, every slow load time, every confusing field label is friction that reduces adoption.
The system was designed for managers, not users. The operations manager wanted reporting. The technicians want to finish their job faster. If the system is designed primarily to generate management dashboards and only secondarily to help technicians do their work, the technicians will be unenthusiastic about it.
Training was insufficient. A one-time training session is not enough. People learn systems by using them repeatedly with support available. Plan for ongoing support during the first 60-90 days of rollout.
The technical design decisions that support adoption: fast performance (the app feels responsive), offline capability (works without reliable connectivity, which matters for technicians in factories), minimal required fields (only capture what is actually needed), and progressive complexity (the most common workflows are the easiest, advanced features are there but not in the way).
What a Fractional CTO Does That an IT Director Does Not
Traditional companies often try to run digital transformation projects through the IT department. IT directors are good at maintaining existing systems and evaluating vendor software. They are less often equipped for custom software development, product decisions, or the business-technical translation that first software projects require.
A fractional CTO brings three things an IT director typically does not have: experience building custom software from scratch, executive-level authority to make architecture decisions and push back on scope creep, and the credibility to represent technical reality to the CEO and board when the project is behind schedule or over budget.
The most important thing I do in traditional company engagements is maintain the connection between business value and technical work. It is easy for a first software project to drift - to accumulate features because someone asked for them, to solve technical problems that are interesting rather than important, to build for the ideal future state instead of the immediate business need.
The discipline to keep a first software project focused on the minimum viable version that delivers business value is harder than it sounds. It requires someone who understands both the business and the technology well enough to have the conversation honestly.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr