From Strategy to Execution: Where Hospitality Transformation Succeeds or Fails

My career did not start in a boardroom. It started in hotel operations, where a plan is only as good as the shift that delivers it. That grounding stayed with me when I moved into hospitality technology with companies such as Amadeus, BirchStreet Systems and ALICE. On the vendor side I saw the same pattern many times: a well-chosen system, a signed contract, a launch date, and then a property where the team had never been asked how they actually worked. The technology was rarely the problem. The handover between the decision and the daily routine was.

London 2012 reinforced this in a very different setting. Olympic Family Hospitality transport had no tolerance for a good plan that failed at the kerb. Every procedure had to work for a driver, a dispatcher and a guest at the same moment, under real pressure. You learn quickly that clear ownership and rehearsal matter more than elegance on paper.

Those experiences shape how EIP MGT works today. I do not consider a recommendation finished when it is accepted. It is finished when it runs reliably in live operation, owned by the people who use it, and when leadership can see that it is working without needing me to explain it.

The gap is usually created at the point where a decision leaves the leadership table without an operational owner. Strategy documents describe outcomes; they rarely describe who changes which process, with what time, budget and authority. Decision rights stay at head office while the consequences land on property teams who were not part of the design. Incentives often still reward the old way of working, and resources are assumed rather than allocated. The frontline then does what any sensible team does under pressure: it protects service and works around the new process.

Early signs of drift are usually visible well before any report shows them. Workarounds appear, often in spreadsheets or messaging groups. Steering meetings discuss status rather than decisions. Go-live dates move without anyone being able to say what was learnt. Different properties ask the same questions because the answers were never written into standard procedures. Adoption is reported as logins or licences rather than as work actually done in the new way. Perhaps the clearest sign is this: when you ask who owns the outcome, you get a committee rather than a name.

None of these signs is dramatic on its own. Together they tell a leader that the programme is being managed as a project, while the organisation has quietly decided to keep operating as before.

I start by separating symptoms from causes. A stalled transformation usually presents as a technology complaint: the system is slow, the data is wrong, the vendor is not responsive. Sometimes that is true. More often the system is exposing a process that was never agreed, a data owner who was never named or a decision that was never taken.

The diagnosis is done on site as well as on paper. I walk the process with the people who run it, from requisition to invoice or from booking to check-out, and compare what happens with what the programme assumes happens. I speak with leadership, finance, operations and the vendor separately, because each holds part of the picture. From there we agree a short list of root causes rather than a long list of issues.

Carrying responsibility means staying for the uncomfortable part. We redesign the process with the team, set clear ownership and decision rights, sequence the rollout property by property and support the first cycles in live operation. Evidence that change is working is practical: the old workaround disappears, exceptions are handled inside the process, questions go to local owners rather than to head office, and the team can explain why the new way is better. When that happens, my role reduces deliberately. The objective is an organisation that can run and improve the change without us.

AI readiness is primarily an operating question. I am studying it formally at present, through an MBA combined with a Master in AI for Business, and the academic work keeps confirming what operations teaches: the model is rarely the constraint. Before any tool is selected, a leader should be able to answer five things.

People: who will use the output, how their role changes, and whether they have the confidence and time to question it rather than simply accept it. Processes: AI accelerates whatever it is given. If a process is inconsistent across properties, AI will scale the inconsistency, so the process must be defined and stable first. Data: whether the data exists, who owns it, how clean it is and whether systems actually share it. Many hotel groups hold data across PMS, procurement, finance and guest platforms with no single accountable owner. Governance: what the AI may decide, what must remain a human decision, how guest and employee data is protected, and how the organisation meets its obligations under regulation such as GDPR and the EU AI Act where they apply. Accountability: a named owner for each use case and a clear definition of what useful value looks like.

The risk of moving too quickly is loss of trust as much as wasted investment. If a team sees an AI tool give confident but wrong answers in its first weeks, adoption is very hard to recover. I would rather see a group start with one well-prepared use case than run ten pilots on unready foundations.

The starting point is the problem, not the product. Leaders should define the operational use case in their own words, with the people who will live with the system, before any demonstration takes place. The useful question is not what a product does in a demonstration, but what it will do in your conditions, with your data, your integrations and your staffing.

I encourage clients to assess technology on a few practical grounds. Evidence: references from comparable operations, spoken to directly, and a proof of concept on real processes where the risk justifies it. Integration: how the system connects with the PMS, finance, procurement and other platforms already in place, and who maintains those connections. Ownership: who configures, supports and improves the system after go-live, both internally and on the vendor side. Total operational impact: not only licence cost, but implementation effort, training, process change and management time. Organisational fit: whether the group can use the product well now, not in three years.

Internal enthusiasm deserves the same scrutiny as vendor claims; the decision should be tested by operations, finance and IT together. Vendor neutrality matters here because the advisor's only interest is whether the decision works for the client, which is why we keep our independence from the vendors we assess.

My role on HubSpot's 2026 Customer Advisory Board, where I contribute perspective on services-business transformation, operational scaling and AI-driven growth, has reinforced this from the other side of the table. The most valuable input a technology company receives is honest evidence of how its product performs in real operations. Hospitality leaders deserve the same honesty in their own evaluations.

I would standardise rigorously wherever the guest, the brand, employee safety or the organisation's financial integrity is at stake. That includes the service standards that define the brand experience, health, safety and security, data protection, financial controls, procurement approval rules and the core data definitions that allow group reporting to mean the same thing everywhere. These non-negotiables should be few, clear and enforced.

Local teams should retain autonomy in how they deliver within those standards. Staffing patterns, supplier choices within approved frameworks, local guest preferences, language, cultural expression and the rhythm of the operation vary by market for good reason. A resort and a city hotel may share a brand standard and still need different workflows to meet it.

The cost of a one-size-fits-all process is rarely visible at head office. It shows up locally as workarounds, parallel spreadsheets and a quiet loss of trust in central decisions. A useful approach is to define the outcome and the control centrally, then give properties a structured way to adapt the method, document the variation and share what works. Standardisation should make local teams more capable, not less responsible.

Adoption starts long before training. The most effective approach I have seen is to involve frontline teams in designing the workflow, not only in testing it. When a housekeeper, a storekeeper or a night auditor has shaped the process, the system becomes theirs rather than something imposed on them.

Communication should explain what changes for each role, what stays the same and why it matters to their day, not only to the business case. Workflow design should remove steps rather than add them; if a new system asks for more input without giving anything back, people will find a way around it. Training works best when it is role-based, short, delivered close to go-live and reinforced by on-site support in the first weeks, with local super users who can answer questions in the team's own language.

Feedback must be visible. Teams need to see that the issues they raise are logged, answered and, where appropriate, acted upon. Leadership also has to be present. When a general manager or head of department uses the system, asks for its reports in meetings and recognises the people who adopt it well, the message is clear. Technology should give time back to people so they can spend it on guests and colleagues. If it does the opposite, the design needs to change, not the people.

When ESG reporting, CSRD or electronic invoicing are treated as compliance exercises, the organisation typically produces what is required once, often through an external adviser or a spreadsheet, and then repeats the effort the following year. The data is gathered late, owned by nobody in operations and trusted by nobody in finance.

Treated as operational design questions, they become far more useful. Energy, water and waste data, supplier information and invoice data all originate in daily operations: in engineering, purchasing, receiving and accounts payable. If ownership sits where the data is created, and the process captures it correctly at source, reporting becomes a by-product of good operations rather than an annual project.

Electronic invoicing is a good example. Several European countries are moving towards mandatory e-invoicing and, in some cases, near real-time reporting, and the scope and timelines of these rules, like those of CSRD, continue to evolve, so each group should confirm the position for its own markets. Groups that prepare by cleaning supplier master data, standardising purchase-to-pay processes and aligning procurement with finance usually find the benefits extend well beyond compliance: fewer disputes, faster approvals and better visibility of spend.

The long-term discipline is the same in each case: clear data owners, defined processes, controls built into systems and leadership that reviews the information as a management tool rather than a regulatory obligation. Sustainability, in particular, is managed in operations every day, not in the annual report.

Before launching another programme or buying another platform, leadership should examine why the last one stalled, honestly and specifically. In my experience the cause is rarely the technology alone. It is usually a combination of unclear ownership, decisions that were never taken, processes that were not redesigned and teams that were not given the time or authority to change.

The most practical starting point is a short, structured review built on three questions. What was the programme meant to change in daily operations, and what is actually happening today? Who owns the outcome, and do they have the decision rights and resources to deliver it? What is blocking adoption on the ground, as described by the people doing the work rather than by the steering committee?

That review should cover a small number of properties, include direct observation of the process and bring operations, finance and IT into the same conversation. It will often show that part of the existing investment can be recovered by fixing process, ownership and data before anything new is purchased. A new platform on an unchanged operating model tends to reproduce the same result at a higher cost. Leaders who pause long enough to understand the stall generally move faster afterwards, because they are no longer solving the wrong problem.

One warning sign that strategy is disconnected from operations: when the people running the operation cannot explain how the strategy changes their work this month. If the answer depends on who you ask, or nobody can answer, the strategy has not yet reached operations.

The first question a hospitality leader should ask before selecting an AI tool: what decision or task are we trying to improve, and who owns it? If that cannot be answered clearly, the organisation is not yet ready to choose a tool.

One operating discipline that deserves wider use beyond hospitality: the daily shift briefing. A short, structured conversation at the start of every shift on priorities, issues and responsibilities keeps a hotel aligned in real time, and most organisations outside hospitality would benefit from the same habit.