Maros ZemanFractional / Interim Head of Data Platform in Europe/Nordics

Maros Zeman

How difficult programmes get unstuck

Full, named walkthroughs and executive references are available in a first conversation.

Case 01

Eighteen months stalled, two vendors, three rebuilds - in production in 2.5 months.

A business area needed a machine-learning product forecasting production from historical data spread across multiple operational systems. After eighteen months, two vendors and three rebuilds it still could not reach production — and had lost credibility with engineering and senior management alike. I was brought in to establish whether it could be saved, and how.
AI/ML productionisation18 months stalled → 2.5 months to productionHanded over to the internal team

  1. Situation

    The previous attempts weren't incompetent - they were conforming to an architectural constraint they had no standing to challenge. The solution had been built inside a software-development framework, containerised with model-serving nested inside, and could never run beyond a laptop-scale proof of concept. The problem wasn't the vendor. It was a combination of architecture, decision rights and lost stakeholder confidence.

  2. Assessment of situation and what I did

    What the assessment found I gathered input from every involved party and ran a code-level and architecture-level investigation of the latest iteration. Three problems, stacked:

    1. A decision-rights problem — the architecture had been fixed by a function that was not a delivery organisation
    2. A technical problem — the toolset served software delivery, where the workload demanded a data-development framework; no amount of vendor effort inside that constraint could produce a production-grade system.
    3. A confidence problem — after repeated failed deliveries, stakeholders no longer believed the initiative could land at all.

    What I did

    • Described the real state of the solution to senior management in plain, non-technical terms — separating genuine showstoppers from ordinary technical debt.
    • Was explicit that the existing build would never sustain production load or any growth in scope, and managed the understandable reluctance to change course a fourth time.
    • Stopped the current approach & proposed, architected and led a fourth rebuild on a battle-tested data architecture sized for the actual workload and its future scope.

  3. Outcome

    A functioning data product in governed production in 2.5 months, delivered with two half-time people — myself and a data scientist. The product was handed over to the local team, which took full ownership of further architectural and development decisions.

  4. What I would do differently

    I initially underestimated how badly repeated failure had damaged executive trust. The engineering team already understood the architectural problem; the real constraint was confidence at senior-management level. I now test stakeholder trust explicitly in the first week of any recovery.
Case 02

A build-versus-reuse standoff, ended with numbers — a fit-for-purpose platform live in three months

A North American business unit of an industrial group needed fragmented operational data under one roof: hourly-refreshed analytical products across thousands of MES and control-system tables, standardised KPIs, less manual reporting effort. The company already owned a data platform - excellent at what it was built for, streamed telemetry, and the wrong tool for massively parallel batch load. Whether to extend or build anew had become an open question.
Platform strategy & delivery3 months to a live platform$500k+ engineering cost avoided$700k saved per year on the first data product

  1. Situation

    • The business case: cut the manual effort behind monthly management reporting and standardise KPI calculation across plants.
    • The workload: thousands of primarily batch-loaded tables refreshed hourly - the sources couldn't stream data.
    • The incumbent platform was engineered for streaming-telemetry ingestion, not parallel batch at this scale, and could not offer the end-to-end, multi-timezone support the requesting business needed.
    • For senior leadership, extending was the natural default, and had never been costed against the alternative.

  2. Assessment of situation

    What the assessment found (one month) 

    Reuse would demand more engineering effort than a new build - an estimated 12-18 months given the platform team's existing workload, against roughly three months for a fit-for-purpose platform. I put both options in front of senior leadership fully priced, including the cost of doing nothing, with one explicit guarantee attached: the existing platform keeps its telemetry mission.

  3. Outcome

    • Led delivery of a new platform into production in three months - at least $500k in avoided engineering effort, before counting 9-15 months of earlier business value.
    • With the internal BI team, delivered the first data product three months later: standardised KPIs across 10+ plants, resulting in business-verified savings of $700k annually.
    • Helped hire the platform's permanent DevOps team and handed over operations and further development within two more months. Nine months, end to end.
    • The incumbent platform continued doing exactly what it was designed for - right tool per workload, not platform sprawl.

  4. What I would do differently

    I underestimated how the build-versus-reuse question felt to the incumbent platform's owners - for me it was workload placement. What finally ended the standoff - listing of all possible options and their prices, the incumbent's mission guaranteed, the new build anchored inside group standards and architecture review - should have been my opening move, not my closing one. Architecture arguments may become tribal; priced options are decidable.