Scott Hicar thought his CIO career was behind him—until hands-on ERP implementation work pulled him back in as a fractional CIO. He explains why, even with AI adoption, ERP still comes down to people; why outcomes matter more than methodology; why iteration beats perfect planning; and why sustainability has to start on day one.
I failed at my first attempt at retirement.
For a while, I enjoyed waking up to an open calendar with no deadlines and no stress. Eventually, however, I realized what I missed most: being part of a team and leading initiatives that are bigger than any one individual. The drive to tackle complex challenges and build something meaningful never really goes away.
As I reflected on the most rewarding parts of my career, a common theme emerged. The experiences that delivered the greatest professional satisfaction were transformational. Sometimes that meant rebuilding an IT organization. Other times it was a "frame-off restoration" of technology infrastructure (a term borrowed from classic car restoration, meaning a complete rebuild down to the foundation), leading a high-risk M&A integration, executing an ERP transformation, or some combination of all three.
And that's what pulled me off the sidelines and into the fractional CIO model. Private equity firms, in particular, have a near-constant appetite for this kind of work: complex transformations on compressed timelines, with a defined scope and a clear handoff back to the operating company once it's done. It's a natural fit for someone who thrives on that kind of challenge.
Of everything I could take on as a fractional CIO, ERP implementation is where I've added the most value—and had the most fun. That pull goes back to the start of my career, when I worked as an SAP implementer in supply chain and manufacturing: configuring systems, writing reports in ABAP (SAP's programming language), running data migrations, and living inside the software every day. As careers progress, most of us move further from the technology itself and into program leadership, portfolio management, and eventually the executive seat. Somewhere along the way, someone takes away your system access.
Becoming a fractional CIO gave me that access back. Since then, I've supported several private equity portfolio companies through ERP strategy, program planning, team development, and execution. The companies are different. The software selection varies. But the same four patterns keep showing up, reminding me that some IT truths endure.
ERP Is Still a Human Endeavor
Despite all the discussion around AI's impact on business and technology, ERP success still depends fundamentally on people.
AI is becoming increasingly valuable in program management, issue tracking, scheduling, testing, and analysis. And those capabilities will continue to improve. However, successful ERP transformation still depends on identifying your strongest process thinkers and most experienced operators and giving them the authority and time to design the organization's future operating model.
There are no shortcuts here. In many ways, it has been refreshing to see firsthand how critical and irreplaceable great people remain, even in an age of increasingly powerful technology.
Methodologies Matter Less Than Outcomes
Software implementation methodologies go by many names, and most can provide value when applied appropriately. I've learned to be pragmatic—mixing approaches where it makes sense and pivoting when necessary.
Today's ERP implementations aren't really that different from their waterfall-based counterparts of yore, regardless of the terminology used. That's largely because of what you're actually building. For mid-size companies especially, an ERP implementation mostly means accepting what packaged software has already standardized. The result is less customization, but it creates an efficient platform that simplifies the business and supports future M&A integration. Absorbing that much standardization is often all the organizational change a company can handle in one program.
Call the early deliverables what you will: requirements, blueprints, epics, or user stories; the early questions are largely the same: How do we want to operate? How must we operate to satisfy controls and system constraints? How will we measure success?
On my current program, which is milestone-driven, we incorporated monthly sprint cycles to leverage Agile's ability to create achievable short-term goals while maintaining focus on long-term outcomes. That result compares favorably to pure waterfall approaches, where problems typically don't surface until testing—late enough in the process to put the whole timeline at risk. The sprint cycles create a faster failure-detection loop, catching issues while there's still room to adjust.
Iteration Is the Only Way
One lesson keeps reinforcing itself across every ERP program I've led: iteration wins.
DevOps emphasizes continuous deployment and rapid feedback loops. In my programs, that runs alongside the Agile sprints I mentioned. Combining continuous deployment and review with sprint-driven outcomes can get chaotic, but it accelerates feedback.
Seeing a business process executed in the software lets teams have far more productive conversations than trying to design every scenario on a whiteboard. Demonstrating that process in the live system creates understanding. Understanding drives better decisions.
By configuring, demonstrating, learning, adjusting, and repeating, organizations can engage visual learners and speed up decision-making.
Build quickly. Learn quickly. Improve continuously. That approach consistently outperforms attempts to perfect everything in a vacuum.
Plan for Sustainability From Day One
One of the more interesting reactions I've encountered in ERP programs comes up when discussing phase two work: the capabilities we intentionally leave out of the initial go-live to build later, once the organization has absorbed the first wave of change. Phase two becomes a catchall for organizational changes that were too much to absorb initially, for M&A activity that happened while the project was already in flight, and for enhancements and optimizations identified along the way. It's less a discrete phase than part of the company's ongoing, continuous improvement effort.
When I explain the logic of deferring this work to manage risk and organizational change, seasoned (and skeptical) stakeholders often push back immediately: "But ERP Phase 2 never happens."
Sometimes that's true. However, today's ERP project often replaces yesterday's ERP system, which became outdated precisely because the organization failed to invest in it continuously.
ERP isn't a project; it's an operating asset. Successful organizations begin planning for how they'll sustain and evolve the system long before go-live. They establish ownership, governance, enhancement roadmaps, and the organizational structures necessary to continue evolving after hypercare—the intensive support period right after go-live—ends.
If you do not plan for sustainment, you are simply creating tomorrow's legacy system.
We're now midway through our current ERP transformation. I will continue to record my observations and lessons learned from AI-enabled process testing, employee training approaches, and adoption strategies as the program progresses. The technology will continue to evolve. The fundamentals of successful transformation, however, won’t. People, process, iteration, and leadership still matter most.
