# Tenhaw case studies and evidence Tenhaw is a UK AI consultancy and AI delivery partner based in London. We build AI products and workflows, design operating models and develop your team's capability. We also lead programmes across your teams and suppliers. Index: https://tenhaw.com/llms.txt Full corpus: https://tenhaw.com/llms-full.txt Illustrative resources are teaching examples, separate from delivered client evidence. Cite the native page below. ## Centralising EMEA programme reporting and Copilot adoption Source: https://tenhaw.com/case-studies/microsoft-emea-programme-delivery-copilot Last updated: 2026-11-05 { "slug": "microsoft-emea-programme-delivery-copilot", "client": "Microsoft", "duration": "3 months", "published": "2026-11-05", "title": "Centralising EMEA programme reporting and Copilot adoption", "summary": "In his own contractor role as Program Manager for Microsoft's EMEA Data Centre Operations, James Rooney centralised programme reporting with every EMEA country lead and embedded Microsoft 365 Copilot into their biweekly reporting cycle. The work ran from December 2025 to February 2026 and ended with documented processes for the internal team.", "metrics": [ { "value": "All country leads", "label": "EMEA country leads worked with James on programme reporting" }, { "value": "About 10% to all", "label": "reported Copilot usage among the EMEA country leads in this engagement" }, { "value": "3 months", "label": "December 2025 to February 2026, James's contractor role" } ], "stage": "Reporting processes implemented and handed over; Copilot embedded in country-lead reporting", "challenge": "EMEA Data Centre Operations needed one view of which programmes mattered. Information sat across countries, lessons did not travel consistently and leadership lacked a clear workload picture. Microsoft 365 Copilot licences were already available, but usage among country leads was roughly 10%. Programme visibility was the primary brief; Copilot adoption formed part of improving that work.", "approach": "James worked with every EMEA country lead and visited data centres to understand operations first-hand. He mapped the gaps in prioritisation, information sharing and lessons learnt, then designed programme and status-reporting processes that brought the information together for leadership.\n\nHe built Copilot prompts and workflows into the biweekly reporting cycle, helping country leads synthesise site updates, normalise risk registers and prepare leadership briefings. He documented the processes so the internal team could continue after the three-month role.", "outcome": "Programme information was centralised, giving EMEA leadership a shared view of high-level workload and status. Copilot use among the country leads moved from roughly 10% to all of them within this leadership group, as reported for the engagement. The case describes adoption in those reporting routines, not Microsoft-wide usage or an independently audited adoption study. Documented ways of working remained with the internal staff after James's role ended.", "agenticLens": "The transferable practice is to connect AI adoption to a task people already own: gathering updates, reviewing risks and preparing a decision-ready briefing. This was James's own programme-management contractor role inside Microsoft, with Copilot embedded in delivery practice. It was not a standalone Tenhaw Copilot implementation engagement.", "withheld": "Internal programme names, tooling, individuals and decision timings remain confidential.", "faq": [ { "question": "Was the Microsoft work a Tenhaw engagement or James's own role?", "answer": "It was James Rooney's own contractor role inside Microsoft, as Program Manager for EMEA Data Centre Operations from December 2025 to February 2026. This is founder experience, like the HSBC and Discovery roles. It demonstrates programme delivery and Copilot adoption within a live reporting practice, rather than a standalone Tenhaw Copilot contract." }, { "question": "What was James's primary job in Microsoft EMEA Data Centre Operations?", "answer": "Orchestrating priority programmes and making high-level workloads visible to the EMEA senior leadership team. James worked with every EMEA country lead, centralised programme information and documented the operating processes. Copilot was designed into this reporting work; it was part of the delivery practice." }, { "question": "How was Copilot adoption built into Microsoft country leads' reporting?", "answer": "In this engagement, it included prioritisation, centralised programme status, documented ways of working and prompts used in the country leads' existing biweekly reporting cycle. The practical job gave people a reason to use the tool and a routine in which to review its output. Reported usage rose from about 10% to all the EMEA country leads involved, not all Microsoft staff." }, { "question": "Who should read the Microsoft EMEA programme-delivery case study?", "answer": "Technology, operations and transformation leaders coordinating programmes across countries or sites. It is particularly relevant where programme information is fragmented and Microsoft 365 Copilot is already licensed but weakly used. The case shows how reporting, prioritisation and a tool-adoption routine can be designed together." }, { "question": "Which Tenhaw engagement covers work like the Microsoft EMEA role?", "answer": "Tenhaw's Programme & Delivery Management engagement can rebuild programme reporting, prioritisation and governance across teams and suppliers. Where Copilot is already part of the client's approved stack, adoption can be designed into that live work. The published engagement is £18k–£35k per month, with the actual scope agreed before work begins." } ] } In his own contractor role inside Microsoft's EMEA Data Centre Operations, James centralised programme reporting with every EMEA country lead and embedded Copilot into their existing biweekly reporting. Documented processes remained with the internal team after the role ended. Role period: December 2025 to February 2026. Primary job: Programme prioritisation, shared workload/status reporting and operating processes for EMEA leadership. Working context: Every EMEA country lead, with on-site data centre visits to understand the operations behind the reporting. Copilot scope: Prompts and workflows for site updates, risk registers and leadership briefs inside the existing biweekly reporting routine. Reported adoption: Roughly 10% to all EMEA country leads in this engagement. This is a reported group-level outcome, not Microsoft-wide adoption or audited telemetry. Explore programme delivery with AI adoption in scope: https://tenhaw.com/services/programme-management Build practical AI habits through live work: https://tenhaw.com/use-cases/ai-training-and-adoption ## From traditional ways of working to an agentic operating model Source: https://tenhaw.com/case-studies/agentic-ai-in-insurance-operating-model Last updated: 2026-11-05 { "slug": "agentic-ai-in-insurance-operating-model", "client": "Placing Platform Limited (PPL)", "rung": "Embedded Agentic Lead", "engagement": "specialty-insurance-agentic-lead", "published": "2026-10-12", "duration": "6 months", "title": "From traditional ways of working to an agentic operating model", "summary": "Tenhaw came into Placing Platform Limited (PPL), the London market digital placing platform, and showed its team how to move from traditional delivery to an agentic operating model. We arrived to support a stalling programme, as an embedded delivery lead, and moved AI from theory into practical delivery. A year of stalled PDF work rebuilt using AI as a working proof of concept in two weeks, then an 8-week special project took the new way of working from concept to handover, packaged up as how-to guides for reuse after we left.", "metrics": [ { "value": "54 vs 1", "label": "front-end changes shipped on the same epic, outcome ticket against normal ticket, in a similar cycle time" }, { "value": "12 months → 2 weeks", "label": "stalled PDF work rebuilt as a working proof of concept (greenfield)" }, { "value": "70%", "label": "the paired client engineer's confidence, at the end of the two-week build, that they could run the process without us" } ], "challenge": "A specialty insurance programme was stalling in traditional delivery: governance unclear, data quality blocking build and test, a backlog nobody trusted, release readiness slipping, a security gate with no coordination owner, and tooling split across Azure DevOps and GitHub. Leadership wanted AI in insurance operations to be more than licences.\n\nWe arrived to support the programme and became its embedded lead across delivery, governance, data quality, backlog, release readiness, beta planning and product evolution. One senior person owning momentum, and a new way of working.", "approachHeading": "What we did over a 6-month period", "approach": "", "phases": [ { "name": "Phase one: an AI readiness assessment", "when": "Month one", "body": "Phase one was an AI readiness assessment that took ownership of blockers. We defined a backlog, produced delivery analysis, and drove data cleansing to unblock the teams so development and testing could move. Workshops on product vision, data strategy and the AI operating model fed the governance frameworks. By month end, the path into agentic ways of working was clear." }, { "name": "Phase two: intelligent document processing in two weeks", "when": "Two weeks", "body": "The question: can we replace an existing extraction capability in-house on Azure and use Claude, turning contracts and other PDFs into business intelligence via document intelligence? We ran the team using The Tenhaw Way, leveraging the agentic engineering method.\n\nRequirements (PDFs, diagrams, images) became structured markdown and AI mapped the outcomes to be achieved. Build then started from a blank Azure repo, high-level prompts against the full requirement set. A security review was run every fifth prompt to ensure what was built was secure, as well as built quickly.\n\nIn two weeks the proof of concept was working: documents in, structured and enriched data out, business intelligence on a dashboard they already used. Twelve months of circling around, closed in a fortnight. Perhaps more important than the proof of concept is that one of their engineers had run the agentic method end to end.\n\nWe asked that engineer how confident they were that they could follow the process and deliver the next outcome without Tenhaw. They said 70%. That is the biggest win, and is part of what you are buying. Going from traditional delivery to AI-assisted product development, packaged so your team can run it, not a demo you rent.", "readMore": { "slug": "specialty-insurance-agentic-lead", "label": "Read the two-week build in full" } }, { "name": "Phase three: from AI theory to agentic engineering", "when": "Eight weeks", "body": "A special project was then run for 8 weeks to move the wider team's AI conversation from theory into practice. The intent was to prove that agentic ways of working could be implemented for the client, within their existing tool stack, by changing the ways of working.\n\nWe introduced:\n\n- Outcome-based tickets instead of prescriptive stories\n- AI-assisted development workflows\n- Engineering skills and reusable prompts\n- Security, deployment and standards skills inside the delivery workflow\n- Automated \"What's Changed\" review documentation\n\nWe pushed testing higher up the delivery lifecycle: AI-generated tests, mutation testing as quality evidence, structured test plans, evidence-based delivery, and \"What's Changed\" review pack for AI-written code. We also explored GitHub-based delivery tooling, enterprise AI connectors, and market-intelligence experiments with their approved AI tools." } ], "outcomeHeading": "What we left behind", "outcome": "", "outcomeBlocks": [ { "title": "Every step proven hands-on", "body": "Throughout the 6 months, Tenhaw was hands-on. We proved every step of the agentic operating guides on live work: design, engineering, testing, review and deployment. Nothing went into a guide until we had run it with their team. Once the client was confident they could continue without us, we left them ready to roll out across Product, Engineering and QA." }, { "title": "Special projects: from concept to handover", "body": "We ran the special project from concept to handover: operating model, stakeholder demos, and the coordination across engineering, QA, security, architecture and DevOps that traditional delivery had been missing. The output was not a slide pack. It was role-based Product, Engineering and QA packs, reusable engineering skills, testing and security processes inside the workflow, and governance and adoption material the team could keep using after we left." }, { "title": "Documented for reuse", "body": "Every experiment became reusable knowledge: lessons learned, architecture and governance artefacts, testing strategies, operating guides, steering materials, product and delivery frameworks, and handover packs with agentic operating model learnings per domain. The guides spread the operating model without Tenhaw in the room." } ], "comparison": { "heading": "Outcome and prescriptive tickets on one front-end epic", "lede": "The observed comparison counts front-end changes shipped in a similar cycle time. The two ticket shapes described different scopes of work.", "columns": [ "Outcome ticket", "Prescriptive story" ], "rows": [ { "label": "Front-end changes shipped", "values": [ "54", "1" ] }, { "label": "Work compared", "values": [ "The same front-end epic", "The same front-end epic" ] }, { "label": "Cycle time", "values": [ "Similar cycle time in the reported comparison", "Similar cycle time in the reported comparison" ] } ], "note": "This is one reported epic comparison. It is not a general 54-fold productivity, speed or quality benchmark." }, "securityPractice": { "heading": "Security built into the workflow", "lede": "Security sits inside the build, not after it.", "items": [ "Security review roughly every fifth prompt", "Only client-approved AI tools, on zero-retention or enterprise model agreements", "Work on client infrastructure, under client identity and least privilege" ] }, "agenticLens": "What transfers is the sequence: take ownership of what is blocking delivery, prove the agentic method on one real build with one of your own engineers pairing throughout, then take it to Product, Engineering and QA inside the tool stack you already have, with nothing written into a guide until it has run on live work. What differs between organisations is the tool stack and the domain rules, so the guides are written around yours rather than copied from this one.", "withheld": "The architecture in detail, the prompt and review approach, and the working history of the six months sit under client confidentiality. Naming the client does not make its private technical material public. Your name and estate are published only within agreed permissions.", "stage": "Working proof of concept; operating guides proven hands-on (design to deployment); outcome-ticket practice on one front-end epic", "tag": "Agentic operating model", "companionBlurb": "The whole six months: how the agentic way of working went from this one build to Product, Engineering and QA, including an outcome ticket that shipped 54 front-end changes against 1 on the same epic.", "faq": [ { "question": "What is a real example of agentic AI in insurance?", "answer": "One example of agentic AI in insurance is Tenhaw's six months with Placing Platform Limited (PPL), where it meant changing how the delivery teams worked and proving it on one build first. A year of stalled PDF work became a working proof of concept in two weeks, on Azure with Claude: documents in, structured and enriched data out, business intelligence on a dashboard the business already used. An eight-week special project then took the agentic way of working to Product, Engineering and QA, with outcome-based tickets, AI-assisted development workflows and AI-generated tests. On one front-end epic, an outcome ticket built with Claude in the agentic workflow shipped 54 front-end changes, against 1 for a normal ticket built the standard way, in a similar cycle time." }, { "question": "How do you implement an agentic operating model in insurance?", "answer": "In three steps: take ownership of whatever is blocking delivery, prove the agentic method on one real build with one of your own engineers pairing throughout, then take it to Product, Engineering and QA inside the tool stack you already have. That was the sequence at Placing Platform Limited (PPL). Month one was an AI readiness assessment that unblocked development and testing. Month two brought a two-week working proof of concept, run using The Tenhaw Way and the agentic engineering method. An eight-week special project then moved the wider team's AI conversation from theory into practice. Nothing went into an operating guide until Tenhaw had run it with the client's team." }, { "question": "What did Tenhaw's embedded lead own across the insurance programme?", "answer": "Momentum across the whole programme: delivery, governance, data quality, the backlog, release readiness, beta planning and product evolution. Tenhaw arrived at Placing Platform Limited (PPL) to support a stalling programme and became its embedded lead across all of them, one senior person bringing a new way of working. Tenhaw calls the role Embedded Agentic Lead, though most buyers arrive looking for a fractional head of AI or an interim AI programme director who will sit inside the programme. It stayed hands-on for all six months: the two-week proof of concept was pair-programmed with a client engineer, and the eight-week special project ran from concept to handover." }, { "question": "What was stalling the insurance programme before Tenhaw arrived?", "answer": "Six problems at once: unclear governance, data quality blocking build and test, a backlog nobody trusted, slipping release readiness, a security gate with no coordination owner, and delivery tooling split across Azure DevOps and GitHub. It was a multi-workstream programme in traditional delivery, stalling in the gaps between product, engineering and platform. Leadership also wanted AI in insurance operations to be more than licences. The immediate need was momentum, and the underlying need was a different way of building. Tenhaw arrived to support the programme, took ownership of the blockers through an AI readiness assessment in month one, and by the end of that month the path into agentic ways of working was clear." }, { "question": "Why did the insurance engagement run six months when the proof of concept took two weeks?", "answer": "Because the proof of concept was one build, and the aim was a new way of working that the wider team could run. The build was the middle of three phases. Phase one, an AI readiness assessment, filled month one and took ownership of the blockers. Phase two rebuilt a year of stalled PDF work as a working proof of concept in two weeks, the first visible proof of the new operating model, with one of the client's engineers running the method end to end. Phase three, an eight-week special project, took that way of working to Product, Engineering and QA. Tenhaw was hands-on throughout, and spent the last two months proving every step of the operating guides before handover." }, { "question": "What happened when an outcome ticket ran against a user story on the same epic?", "answer": "The outcome ticket shipped 54 front-end changes and the story shipped 1, in a similar cycle time. Both sat on the same front-end epic at Placing Platform Limited (PPL). The outcome ticket was written as an outcome and built with Claude in the agentic workflow. The normal ticket was written as a prescriptive story and built using the standard approach. So the two differed in how the work was written and in how it was built. Outcome-based tickets were one of the practices Tenhaw introduced during the eight-week special project, which took the agentic way of working to Product, Engineering and QA." }, { "question": "Why use mutation testing and What's Changed review packs on AI-written code?", "answer": "Both supplied evidence: mutation testing as quality evidence, and the What's Changed review pack as automated review documentation for AI-written code. Tenhaw brought them in during the eight-week special project at Placing Platform Limited (PPL), when it pushed testing higher up the delivery lifecycle alongside AI-generated tests, structured test plans and evidence-based delivery. Testing and review were two of the five steps the agentic operating guides covered, with design, engineering and deployment, and each step was proven hands-on on live work before it went into a guide. Testing and security processes inside the workflow were part of what Tenhaw left behind." }, { "question": "Which AI tools and models did Tenhaw use at PPL?", "answer": "Only AI tools the client had approved, on zero-retention or enterprise model agreements. The engagement used Claude, Codex and Azure. Claude was the model for the two-week proof of concept on Azure and for the agentic workflow that built the outcome ticket on a front-end epic, and a separate data-quality proof of concept ran on Azure OpenAI. Tenhaw worked on client infrastructure, under client identity and least privilege. Security sat inside the build rather than after it, with a security review roughly every fifth prompt, and the eight-week special project put security, deployment and standards skills inside the delivery workflow." }, { "question": "What was PPL's eight-week special project meant to prove?", "answer": "That agentic ways of working could be implemented for the client within its existing tool stack, by changing the ways of working. The project followed the two-week proof of concept and set out to move the wider team's AI conversation from theory into practice. It introduced five practices: outcome-based tickets instead of prescriptive stories; AI-assisted development workflows; engineering skills and reusable prompts; security, deployment and standards skills inside the delivery workflow; and automated What's Changed review documentation. Tenhaw also explored GitHub-based delivery tooling, enterprise AI connectors and market-intelligence experiments with the client's approved AI tools. The project ran from concept to handover." }, { "question": "What was in the operating guides and role-based packs PPL kept?", "answer": "Every step from design to deployment. The agentic operating guides covered design, engineering, testing, review and deployment, and each step was proven hands-on with PPL's team on live work before it went into a guide. The output was not a slide pack. Product, Engineering and QA each had a role-based pack, alongside reusable engineering skills, testing and security processes inside the workflow, and governance and adoption material the team could keep using after Tenhaw left. Every experiment also became reusable knowledge, including lessons learned, testing strategies, product and delivery frameworks, and handover packs with agentic operating model learnings per domain. The guides were written to spread the operating model without Tenhaw in the room." }, { "question": "How did the handover to PPL's own team work?", "answer": "By running every step with the client's own people before Tenhaw left. It began in the two-week proof of concept, where one of the client's engineers paired throughout and ran the agentic method end to end. Asked at the end of that build how confident they were that they could follow the process and deliver the next outcome without Tenhaw, they said 70%. The eight-week special project then ran from concept to handover, and every step of the operating guides was run with the client's team on live work before it was written down. Once the client was confident it could continue without Tenhaw, the team was left ready to roll out across Product, Engineering and QA." }, { "question": "Are Tenhaw's two insurance case studies about the same engagement?", "answer": "Yes. Both describe one six-month Embedded Agentic Lead engagement with Placing Platform Limited (PPL). The six-month write-up covers the whole engagement, from traditional delivery to an agentic operating model: the month-one readiness assessment, the two-week working proof of concept and the eight-week special project that took the new way of working to Product, Engineering and QA. The other write-up is the close-up on months one and two: the audit month, then the two-week working proof of concept in full, with requirements turned into structured markdown before any code, the pipeline stage by stage, confidence-routed review, and the 70% confidence the paired engineer reported at the end of the fortnight." }, { "question": "How did governance fit into PPL's move to agentic ways of working?", "answer": "As groundwork in month one and as coordination in the eight-week special project. When Tenhaw arrived, governance was unclear and a security gate had no coordination owner. In phase one, workshops on product vision, data strategy and the AI operating model fed the programme's governance frameworks, alongside the backlog, delivery analysis and data cleansing that got development and testing moving. The special project then covered the operating model and stakeholder demos, and supplied the coordination across engineering, QA, security, architecture and DevOps that traditional delivery had been missing. By handover, the team held governance and adoption material it could keep using after Tenhaw left, with steering materials and architecture and governance artefacts alongside." } ] } During six months at PPL, Tenhaw combined delivery recovery, a two-week document-to-BI proof of concept and an eight-week project developing AI-assisted ways of working across Product, Engineering and QA. The team kept operating guides and practised the method on live work. Role period: 2026, six-month engagement. First phase: Readiness assessment and ownership of delivery blockers, data quality, backlog and release coordination. Build: A two-week greenfield PDF-to-BI working proof of concept on Azure, paired with a PPL engineer. Adoption: An eight-week project developed and practised operating guides for Product, Engineering and QA, from design through deployment. Observed comparison: On one front-end epic, an outcome ticket shipped 54 front-end changes against 1 for a prescriptive story, in a similar cycle time. 54 versus 1 counts front-end changes shipped on the same epic in a similar cycle time. It is not a general 54-fold speed, quality or productivity claim. The case does not publish a controlled benchmark. Inspect the document-to-BI build: https://tenhaw.com/case-studies/specialty-insurance-agentic-lead Explore practical AI training and adoption: https://tenhaw.com/use-cases/ai-training-and-adoption See the operating-model design scope: https://tenhaw.com/services/agentic-design-team ## Roughly a year of stalled work, rebuilt as a working proof of concept in two weeks Source: https://tenhaw.com/case-studies/specialty-insurance-agentic-lead Last updated: 2026-11-05 { "slug": "specialty-insurance-agentic-lead", "client": "Placing Platform Limited (PPL)", "rung": "Embedded Agentic Lead", "companionBlurb": "The two-week build in full: requirements turned into structured markdown before any code, the pipeline stage by stage, confidence-routed review, and the paired engineer's 70% at the end of the fortnight.", "duration": "6 months", "title": "Roughly a year of stalled work, rebuilt as a working proof of concept in two weeks", "summary": "For Placing Platform Limited (PPL), the London market digital placing platform, a working proof of concept in two weeks: PDFs in, business intelligence out on Azure, covering ground that had previously taken this business roughly twelve months. We pair-programmed the entire fortnight with one of the client's own engineers, who ended it saying they were 70% confident they could run the process without us. Month one was the audit that pulled us across the whole programme, month two was this build, and an eight-week project then took the agentic way of working to Product, Engineering and QA.", "metrics": [ { "value": "12 months → 2 weeks", "label": "prior build effort rebuilt as a working proof of concept" }, { "value": "70%", "label": "the client engineer's own confidence, at the end of the fortnight, that they could run the process unaided" }, { "value": "Month 2", "label": "AI-engineering proof of concept delivered, from a month-1 start" } ], "challenge": "PPL was running a complex multi-workstream programme with delivery stalling in the gaps between product, engineering and platform. Data quality issues were blocking development and testing, a security gate was approaching with no coordination owner, delivery tooling was split across Azure DevOps boards and GitHub, and the leadership team wanted an AI strategy that amounted to more than a set of tool licences. The immediate need was momentum; the underlying need was a different way of building.", "approach": "Month one was an audit, and it took us across far more of the programme than a readout exercise would have. We took ownership of whatever was actually blocking delivery: unblocking the data issues holding up development and testing, supporting disaster-recovery failover planning and release governance, and leading the migration from Azure DevOps boards to a GitHub-based delivery model with agent-assisted workflows. In parallel, on the operating-model workstream, we contributed to the workshops shaping product vision, data strategy and the AI operating model, and produced the structured outputs defining MVP focus, data foundations and AI strategy. The value of doing it that way is that by the end of the month we understood the estate from the inside rather than from a survey.\n\nMonth two went after the capability the business had been circling for roughly a year: getting information out of PDFs and turning it into business intelligence. We ran our AI-engineering-first method. Every requirement (PDFs, diagrams, images) became structured markdown, AI built a knowledge map across the corpus, and a gap-and-contradiction pass surfaced ambiguities the business had not realised were ambiguous, before a line of code was written. Those went back to the subject-matter experts and were resolved in conversation rather than in rework.\n\nOnly then did the build start, from a blank repository on Azure, with high-level prompts against the whole requirement set and a security review roughly every fifth prompt. This was greenfield. It replaced work that had stalled rather than changing a running system with existing behaviour to preserve, and the two-week figure should be read in that context. The pipeline itself is set out stage by stage below.\n\nThe entire fortnight was pair-programmed with one of the client’s own engineers, because a proof of concept nobody internal can reproduce is a demonstration rather than a capability.", "outcome": "In two weeks the proof of concept was working: PDFs in, structured and enriched data out, business intelligence on a dashboard the business could use, covering ground that had previously taken roughly twelve months. A separate AI data-quality proof of concept on Azure OpenAI demonstrated that entity-resolution output could be validated and scored automatically, with human review prioritised rather than queued.\n\nThe number we care about most is the softest one. At the end of the fortnight we asked the client engineer who had paired on the whole build how confident they were that they could follow the process and deliver the next outcome without us. They said 70%, and 70% after two weeks is the difference between having bought a proof of concept and having started to acquire a capability.\n\nThe two-week build is a working proof of concept, and it was the first visible sign of the new operating model. An eight-week project then took the agentic way of working to Product, Engineering and QA, ending with operating guides proven on live work and a team ready to continue without us. That part of the engagement has its own write-up.", "agenticLens": "What transfers is the whole shape of the engagement: one senior person accountable from month one, the operating-model outputs produced alongside the build, a monthly cadence with measurable value at the end of each month, and a handover built into the build rather than bolted onto the end of it. The build itself is a working proof of concept inside PPL's estate. The six-month write-up covers what came next: changing how Product, Engineering and QA write, build, test and review their work.", "techLine": "Blank repository on Azure. Markdown-first extraction, third-party API enrichment, confidence scored from source provenance plus model certainty plus a search cross-check.", "pipeline": [ { "name": "Extract to markdown", "detail": "Every source document is converted to markdown before anything else happens, so what the model actually read stays inspectable by a human rather than disappearing into an embedding." }, { "name": "Narrow to the key fields", "detail": "The markdown is reduced to the fields the business needs, rather than carrying whole documents forward and paying for them at every later step." }, { "name": "Normalise", "detail": "Fields are normalised into consistent shapes and units, so downstream logic compares like with like instead of guessing." }, { "name": "Enrich against third-party APIs", "detail": "Records are enriched from external sources, and each enrichment carries the provenance of the source it came from." }, { "name": "Add semantic context and thematic grouping", "detail": "Related records are grouped and given the context a person would otherwise add by hand when reading them side by side." }, { "name": "Apply business logic", "detail": "The client's own rules run over the enriched record. This is the layer that is theirs, not ours, and it is the layer that changes most often." }, { "name": "Land in the dashboard", "detail": "Output lands in an internal dashboard the business already uses, rather than in a tool that only exists while we are there." } ], "confidenceRouting": { "inputs": [ { "name": "Source provenance", "detail": "How much the source of a given enrichment is worth trusting." }, { "name": "Model certainty", "detail": "What the model itself reports about the extraction or the match." }, { "name": "Search cross-check", "detail": "An independent search-based check against the value that was produced." } ], "note": "Those three produce a confidence score on the record, and the score is an input to routing rather than a display value. Review is routed by confidence and consequence together, so a low-confidence field on a high-consequence record reaches a human first and a high-confidence field on a low-consequence one does not generate work. That is a routing rule, not an assurance framework, and it has not been through a regulator or an audit." }, "withheld": "The architecture in detail, the prompt and review approach, and the working history of the fortnight sit under client confidentiality. Naming the client does not make its private technical material public. Your name and estate are published only within agreed permissions.", "publishedEquivalent": "£70k–£85k/month for an Agentic Build Team, or £18k–£35k/month for programme oversight only", "faq": [ { "question": "Who was the client for the two-week insurance proof of concept?", "answer": "The client was Placing Platform Limited (PPL), the London market digital placing platform. The two-week working proof of concept was part of one six-month Embedded Agentic Lead engagement, also covered by the operating-model write-up. Naming PPL does not disclose its private technical material: the detailed architecture, prompt and review approach, and working history remain confidential. The build was a proof of concept, not a production deployment." }, { "question": "Is the twelve months to two weeks comparison fair?", "answer": "Yes, provided you read it the way the case study frames it. The two-week proof of concept was greenfield. It began from a blank repository on Azure and replaced work that had stalled, so there was no running system with existing behaviour to preserve. The roughly twelve months is this client's own prior effort circling the same capability, getting information out of PDFs and turning it into business intelligence, without a working result. Same business goal, reached in a fortnight, under conditions that favoured speed. And the claim is a working proof of concept, not a production system." }, { "question": "What does the 70% figure in this case study mean?", "answer": "It is the client engineer's own confidence, in their own words, that they could run the process without Tenhaw. The entire two-week build was pair-programmed with one of the client's engineers, because a proof of concept nobody internal can reproduce is a demonstration rather than a capability. At the end of the fortnight Tenhaw asked that engineer how confident they were that they could follow the process and deliver the next outcome unaided, and the answer was 70%. It is deliberately the softest number on the page and the one Tenhaw cares about most, because it marks the difference between buying a proof of concept and starting to acquire a capability." }, { "question": "Is the insurance proof of concept in production yet?", "answer": "No, and the case study says so plainly. The two-week build is a working proof of concept inside PPL's estate: PDFs in, structured and enriched data out, business intelligence on a dashboard the business already uses. From there the engagement took the method wider: an eight-week project brought the agentic way of working to Product, Engineering and QA and finished with operating guides proven on live work. Every proof of concept on this site is labelled as one." }, { "question": "What did month one of the insurance engagement involve?", "answer": "Month one was an audit, and it went a long way past a readout. Tenhaw took on whatever was actually blocking delivery. That meant unblocking the data quality issues holding up development and testing, supporting disaster-recovery failover planning and release governance, and leading the migration from Azure DevOps boards to a GitHub-based delivery model with agent-assisted workflows. In parallel it contributed to the workshops shaping product vision, data strategy and the AI operating model, and produced the structured outputs defining MVP focus, data foundations and AI strategy. By the end of the month Tenhaw understood the estate from the inside, and that is what set up the month-two build." }, { "question": "What would this insurance engagement cost at published rates?", "answer": "At Tenhaw's published pricing this maps to an Agentic Build Team at £70k–£85k per month, three people under partner oversight. A business that wanted the programme oversight without the build would be looking at Programme and Delivery Management at £18k–£35k per month. Both come off a published rate card. Partner £1,560 a day, senior practitioner £1,250, associate £950, excluding VAT, at twenty billable days a month. These are published equivalent prices, not the historic fee for this engagement. You can price the same shape of engagement for your own estate before a single call." }, { "question": "What happened before any code was written on the insurance build?", "answer": "The requirements were engineered first. Every requirement, including PDFs, diagrams and images, was converted to structured markdown, AI built a knowledge map across the whole corpus, and a gap-and-contradiction pass surfaced ambiguities the business had not realised were ambiguous. Those went back to the subject-matter experts and got resolved in conversation, before they could turn into rework later. Only then did the build start, from a blank repository on Azure, with high-level prompts against the whole requirement set and a security review roughly every fifth prompt. That sequence is what Tenhaw calls its AI-engineering-first method, run here inside PPL's estate." }, { "question": "How does the pipeline decide which records a human reviews?", "answer": "Three things go into a confidence score on each record. Where the enrichment came from, how certain the model itself reports it is, and what an independent search-based check makes of the value produced. The score drives routing and is never simply displayed. Review is routed by confidence and consequence together, so a low-confidence field on a high-consequence record reaches a human first, and a high-confidence field on a low-consequence record does not generate work. The case study is explicit that this is a routing rule, not an assurance framework, and it has not been through a regulator or an audit." }, { "question": "Who owns the business rules in the document pipeline?", "answer": "The client does, by design. Extraction to markdown, narrowing to key fields, normalisation, enrichment against third-party APIs and semantic grouping are all plumbing. The business logic layer sits on top of them and runs the client's own rules over each enriched record. The case study calls that layer theirs, not ours, and it is the layer that changes most often, so it should not belong to a supplier. Output then lands in an internal dashboard the business already uses. Built to leave applies to the architecture, not just the contract." }, { "question": "Can AI validate entity resolution output automatically?", "answer": "On this engagement, yes, at proof-of-concept level. Alongside the main document pipeline, a separate AI data-quality proof of concept on Azure OpenAI showed that entity-resolution output could be validated and scored automatically, with human review prioritised rather than queued. The practical difference is who waits. The scoring decides which matches need human eyes first, so people are not working down a queue of every matched record. This was demonstrated on a real client engagement with Placing Platform Limited (PPL), and like the main build it is a proof of concept, not a production deployment." }, { "question": "How does a specialty insurance AI implementation run month by month?", "answer": "Monthly, and each month has to end in something measurable. Month one of this specialty insurance AI implementation was an audit that behaved like ownership, taking on whatever was actually blocking delivery and producing the operating-model outputs on MVP focus, data foundations and AI strategy. Month two was the build. A working proof of concept in a fortnight, PDFs in and business intelligence out on a dashboard the business already uses. After that, an eight-week project took the agentic way of working to Product, Engineering and QA, ending with operating guides proven on live work. One senior person was accountable across all six months." }, { "question": "What does a London specialty insurance AI strategy need beyond tool licences?", "answer": "Something the business can build against. This client's leadership wanted a London specialty insurance AI strategy that amounted to more than a set of tool licences, so month one produced the structured outputs defining MVP focus, data foundations and AI strategy, alongside the workshops shaping product vision and data strategy. Month two then tested it by building. A working proof of concept in two weeks, PDFs in, structured and enriched data out, business intelligence on a dashboard the business already uses. The order is the point. The people who wrote the strategy had to deliver against it a month later. That is a harder test than a slide review." }, { "question": "How was security handled on the two-week AI build at PPL?", "answer": "Roughly every fifth prompt, a security review ran across the whole system, inside the build rather than after it. The fortnight started from a blank repository on Azure inside PPL's estate, with high-level prompts against the whole requirement set. Reviewing at that rhythm keeps each review small enough to act on while the code is still cheap to change. Security was already a live programme concern when we arrived, with a gate approaching and no coordination owner, and month one picked that up. The cadence started as a build practice and outlived the fortnight: security and standards skills went into the delivery workflow the eight-week project handed over." }, { "question": "Why move delivery from Azure DevOps boards to GitHub?", "answer": "The delivery tooling was split across both, so no single place showed the state of the work. Month one led the migration to a GitHub-based delivery model with agent-assisted workflows. That puts the delivery record next to the code the agents are working in, so nobody has to keep a separate system in step by hand. The same month also covered the data issues holding up development and testing, plus disaster-recovery failover planning and release governance. Read it as the right call for this estate. It is not a general instruction to leave Azure DevOps behind." }, { "question": "Why not just send whole PDFs to the model?", "answer": "Because carrying whole documents through every stage is expensive and hard to check. Each source document is converted to markdown first, so what the model actually read stays inspectable by a human instead of disappearing into an embedding. The markdown is then narrowed to the fields the business needs, so whole documents are not carried forward and paid for at every later step. Normalisation, enrichment against third-party APIs with the provenance of each source attached, and semantic grouping all run on that narrow record, and the client's own business rules run last. Keeping the markdown means a person can still see where an answer came from." } ] } At Placing Platform Limited (PPL), the London market digital placing platform, Tenhaw paired with a client engineer to turn PDFs into structured, enriched data for an existing business-intelligence dashboard. The two-week greenfield proof of concept sat inside a six-month embedded-lead engagement. Role period: 2026, six-month engagement. Input: PDF documents and written requirements, converted into structured markdown. Working output: Normalised records, source-linked enrichment, confidence-routed review and a dashboard already used by the business. Client contribution: One PPL engineer pair-programmed throughout the fortnight and reported 70% confidence in following the process independently at its end. Stage: Working proof of concept on Azure. Production hardening and assurance are a separate decision. Two weeks describes one greenfield proof of concept. The 70% figure is one engineer's self-reported confidence, not an accuracy or productivity measurement. Explore document and workflow automation: https://tenhaw.com/use-cases/ai-agents-and-workflow-automation Read the wider PPL operating-model engagement: https://tenhaw.com/case-studies/agentic-ai-in-insurance-operating-model ## Standing up the delivery engine behind a £40bn hydrogen business case Source: https://tenhaw.com/case-studies/anglo-american Last updated: 2026-11-05 { "slug": "anglo-american", "client": "Anglo American", "logo": "/logos/angloamerican.svg", "duration": "18 months", "title": "Standing up the delivery engine behind a £40bn hydrogen business case", "summary": "We built and ran the digital teams that proved hydrogen-powered mining was viable, then watched the venture spin out as First Mode.", "metrics": [ { "value": "£40bn", "label": "business case underpinned" }, { "value": "3", "label": "disciplines: Data, Simulation, DevOps" }, { "value": "First Mode", "label": "spun out as a standalone leader" } ], "challenge": "Anglo American formed an ambitious internal startup to prove mining operations could run on hydrogen-powered trucks with hydrogen produced on-site. It needed a digital framework that would hold up under scrutiny, decisions made on data, and aligned teams across three continents, with no precedent to copy from.", "approach": "Tenhaw set up and ran digital teams specialising in Data, Simulation, and DevOps. We installed a lightweight, scalable agile blueprint so high-calibre specialists (Cambridge PhDs among them) could onboard fast and stay aligned across the UK, Australia, and the USA. Delivery ran async by necessity, throughput data fed Monte Carlo simulations, and outcome-based milestones replaced traditional project plans so the largest risks were attacked first.", "outcome": "The work underpinned a £40bn business case and produced the decisive insight that hydrogen trucks were not yet cost-competitive, letting leadership invest with eyes open. The internal startup spun out as First Mode, now a leader in heavy-industry decarbonisation.", "agenticLens": "What transfers is standing up a delivery function with no precedent and forecasting from throughput rather than opinion, which is the footing an agentic programme is installed on before any agent is deployed.", "faq": [ { "question": "What did Tenhaw do for Anglo American?", "answer": "Over 18 months we set up and ran the digital teams inside Anglo American's internal hydrogen startup, three disciplines covering Data, Simulation and DevOps. The venture existed to prove that mining operations could run on hydrogen-powered trucks with hydrogen produced on-site. It needed a digital framework that would hold up under scrutiny, with decisions made on data and teams aligned across three continents, and there was no precedent to copy from. The work underpinned a £40bn business case and produced the decisive insight that hydrogen trucks were not yet cost-competitive. The internal startup later spun out as First Mode, now a leader in heavy-industry decarbonisation." }, { "question": "Did Anglo American prove hydrogen-powered mining was viable?", "answer": "Yes, and with an honest economic edge. Anglo American's internal startup existed to prove mining operations could run on hydrogen-powered trucks with hydrogen produced on-site, and the digital teams Tenhaw built and ran over 18 months proved it, underpinning a £40bn business case. The same work also produced the decisive insight that hydrogen trucks were not yet cost-competitive, so leadership could invest with eyes open rather than on optimism. Viability and economics are different questions, and a delivery engine built on throughput data and Monte Carlo forecasting is what let the venture answer both without flattering itself." }, { "question": "What is First Mode and where does Tenhaw fit in its story?", "answer": "First Mode is the heavy-industry decarbonisation company that began life as Anglo American's internal startup, formed to prove mining operations could run on hydrogen-powered trucks with hydrogen produced on-site. Tenhaw's role came before the spin-out. We built and ran the venture's digital teams across Data, Simulation and DevOps for 18 months, installing the delivery engine that let it make decisions on data and stand up to scrutiny. The work underpinned a £40bn business case, and the venture subsequently spun out as First Mode, now a standalone leader in its field." }, { "question": "How do you run delivery when there is no precedent to copy?", "answer": "Eighteen months, three teams, three continents, no precedent to copy. At Anglo American's internal hydrogen startup we stood up Data, Simulation and DevOps, kept them aligned across the UK, Australia and the USA, and put forecasting on a measured footing. Throughput data fed into Monte Carlo simulations. Outcome-based milestones took the place of traditional project plans, so the largest risks were attacked first. The venture got its answer, including the unwelcome finding that hydrogen trucks were not yet cost-competitive, and it later spun out as First Mode." }, { "question": "How do you stand up a delivery function when there is no precedent to copy?", "answer": "You attack the largest risks first and let data replace opinion. At Anglo American's hydrogen venture we installed a lightweight, scalable agile blueprint so specialists could onboard fast and stay aligned. Outcome-based milestones took over from traditional project plans, so the riskiest assumptions were tested earliest, and throughput data fed Monte Carlo simulations so forecasts came from evidence. The framework stayed lightweight on purpose. It had to hold up under scrutiny without smothering specialist work. That balance matters most when nobody has built the thing before and the plan cannot be copied from a previous programme." }, { "question": "How did the hydrogen programme stay aligned across three continents?", "answer": "Delivery ran async by necessity, with teams in the UK, Australia and the USA, so alignment could never depend on everyone being in the same meeting. A lightweight, scalable agile blueprint let high-calibre specialists onboard fast and stay aligned. Throughput data fed Monte Carlo forecasts, so every location worked from the same evidence. Outcome-based milestones replaced conventional project plans, and everyone knew the priority. Attack the largest risks first. When the shared reference point is data and not a meeting, time zones stop being the constraint they first appear to be." }, { "question": "Why replace a project plan with outcome-based milestones?", "answer": "Because on a programme with no precedent, a traditional plan is guesswork presented with false confidence. At Anglo American's hydrogen venture the milestones were outcome-based instead, so the largest risks were attacked first. The programme existed to find out whether hydrogen-powered mining was viable, so every milestone was framed around answering that question rather than completing tasks in sequence. The approach showed in the result. The venture produced the decisive insight that hydrogen trucks were not yet cost-competitive, and leadership could invest with eyes open instead of discovering the economics at the end." }, { "question": "Why was finding hydrogen trucks not yet cost-competitive a good outcome?", "answer": "The venture's job was to establish the truth about viability, not to confirm a hope. Its digital teams produced the decisive insight that hydrogen trucks were not yet cost-competitive, so Anglo American's leadership knew the economics before the money was committed. Tenhaw applies the same principle to AI work today. A recommendation to stop is a valid outcome, and an honest number beats a flattering one. The finding did not kill the venture either. It spun out as First Mode and now leads in heavy-industry decarbonisation." }, { "question": "How can delivery data underpin a £40bn business case?", "answer": "By giving every forecast an evidence trail. The Data, Simulation and DevOps teams gave Anglo American's hydrogen venture a digital framework built to hold up under scrutiny. Throughput data fed Monte Carlo simulations, forecasts carried probabilities rather than a single guessed date, and decisions were made on data. A £40bn business case attracts hard questions, and answers grounded in measured delivery survive them in a way estimates on a slide do not. Tenhaw forecasts client delivery from throughput history today for the same reason, so nobody has to trust a date on faith." }, { "question": "Can agile work for PhD-level specialists?", "answer": "Yes, if the framework is lightweight enough to serve the work rather than dominate it. Anglo American's hydrogen venture brought high-calibre specialists, Cambridge PhDs among them, into Data, Simulation and DevOps teams, and the agile blueprint Tenhaw installed was deliberately lightweight and scalable so those specialists could onboard fast and stay aligned without ceremony for its own sake. Specialists do not resist structure, they resist structure that wastes their time. Give them outcome-based milestones, honest throughput data and async ways of working that respect colleagues on other continents, and the discipline protects the research instead of interrupting it." }, { "question": "Where does a mining AI digital transformation usually stall?", "answer": "In delivery, almost never in the models. A mining AI digital transformation tends to put specialists, sites and decision makers on different continents, offers no precedent to copy, and hangs off capital decisions too large to settle on opinion. That was the problem at Anglo American's internal hydrogen startup. Over 18 months we set up and ran Data, Simulation and DevOps teams across the UK, Australia and the USA, replaced traditional project plans with outcome-based milestones so the largest risks were attacked first, and fed throughput data into Monte Carlo simulations so forecasts came from evidence. That footing is why the £40bn business case underneath the venture held up under scrutiny, and why a programme of that size stalls without it." }, { "question": "Why did the Anglo American engagement run for 18 months?", "answer": "Because the venture was building a delivery function from nothing, not tuning one that already existed. Anglo American's internal hydrogen startup had no precedent to copy, so across those eighteen months we set up and ran three disciplines, Data, Simulation and DevOps, with high-calibre specialists spread across the UK, Australia and the USA, and produced a digital framework that held up under the scrutiny a £40bn business case attracts. Length like that is earned month by month. Engagements today are retainer-shaped, with an exit date agreed at kickoff and 30 days' notice either side, so you judge each month on the value it delivered." }, { "question": "What goes wrong when a big company launches an internal startup?", "answer": "It inherits the parent's delivery machinery, and that machinery assumes somebody has done this before. Anglo American's hydrogen venture needed the opposite: a framework light enough that high-calibre specialists, Cambridge PhDs among them, could onboard fast and stay aligned, yet credible enough to survive the scrutiny a £40bn business case attracts. The move that mattered was pointing every milestone at the question the venture existed to answer, whether mining operations could run on hydrogen-powered trucks with hydrogen produced on-site, so answers arrived while they could still change the investment. That included the unwelcome one, that hydrogen trucks were not yet cost-competitive. The failure mode to avoid is a venture that reports beautifully and learns slowly." }, { "question": "What should we ask a partner before a first-of-a-kind programme?", "answer": "Three things, all about evidence. First, how will you forecast when there is no history to forecast from? At Anglo American's hydrogen venture we fed throughput data into Monte Carlo simulations as it accumulated, so forecasts rested on measurement rather than optimism. Second, what are your milestones pointed at? Ours were outcome-based and replaced traditional project plans, so the largest risks were attacked first instead of tasks being completed in sequence. Third, will you tell us something we would rather not hear? That venture's decisive insight was that hydrogen trucks were not yet cost-competitive. Leadership could then invest with eyes open, and the startup went on to spin out as First Mode." }, { "question": "How do we test the economics before funding a big AI programme?", "answer": "Name the decision the money turns on, then buy the cheapest honest test of it. Anglo American's hydrogen venture worked that way. Its milestones were framed around whether mining could run on hydrogen-powered trucks with hydrogen produced on-site, so the economics surfaced early enough to act on, including the finding that hydrogen trucks were not yet cost-competitive. Leadership could invest with eyes open instead of meeting the numbers at the end. For AI the equivalent is the AI Readiness Audit: four weeks, £44,000 fixed, ending in working prototypes, with no obligation to continue. A recommendation to stop is a valid outcome, and it is far cheaper than learning late." } ] } Tenhaw set up and ran Data, Simulation and DevOps teams for Anglo American's hydrogen venture across the UK, Australia and USA. Their work informed a £40bn business case, including the finding that the hydrogen trucks were not yet cost-competitive. Role period: July 2021 to January 2023. Role: Programme and delivery leadership across three digital disciplines and three countries over eighteen months. Decision supported: Whether the proposed hydrogen-powered mining operation was economically viable. Method: Throughput-based Monte Carlo forecasting, async coordination and outcome-based milestones. Result: Evidence informed the investment case and surfaced the cost-competitiveness constraint. £40bn is business-case scope, not revenue or savings generated by Tenhaw. Explore programme delivery leadership: https://tenhaw.com/services/programme-management See industrial and engineering applications: https://tenhaw.com/sectors/industrial-energy ## Landing the Discovery+ launch on a CEO-set deadline Source: https://tenhaw.com/case-studies/discovery-plus Last updated: 2026-11-05 { "slug": "discovery-plus", "client": "Discovery", "logo": "/logos/discovery.svg", "duration": "10 months", "title": "Landing the Discovery+ launch on a CEO-set deadline", "summary": "James ran the visual rebrand team and made delivery risk visible early enough to act on it. The six-team launch hit its date.", "metrics": [ { "value": "6", "label": "development teams on the launch, one of them the visual rebrand team James ran" }, { "value": "On time", "label": "launch hit under a fixed deadline" }, { "value": "2", "label": "platforms: Discovery+ and Eurosport" } ], "challenge": "Discovery+ had a hard launch date announced by the CEO and six teams that needed to redesign and merge content. The visual rebrand team James was asked to run was badly overloaded relative to the time available.", "approach": "We moved delivery onto a data-driven footing, recalibrating Story Points to reflect actual capacity after completion rather than optimistic estimates. Across three sprints we presented the Head of Delivery with Happy, Normal and Sad path forecasts, made the probability of missing the date undeniable, and issued daily recommendations to lift speed and quality.", "outcome": "Discovery+ and Eurosport got the clarity to manage delivery under real constraints and hit the launch. By the end of the engagement both teams could run those forecasting and tracking practices autonomously.", "agenticLens": "Probabilistic forecasting and confidence intervals are exactly what leadership needs to govern an agentic transformation: not a single guessed date, but a range you can plan and intervene against. On the Discovery+ launch that clarity is what let a six-team programme land on a date the CEO had already announced.", "faq": [ { "question": "Was the Discovery+ launch a Tenhaw engagement or James's own role?", "answer": "James's own role, not an engagement delivered under the Tenhaw banner. It was one of James Rooney's delivery and transformation roles, and he ran the visual rebrand team on the Discovery+ launch for ten months, one of six development teams working to a launch date the CEO had announced. The case study sits on tenhaw.com because the discipline it demonstrates is the one Tenhaw installs today, probabilistic forecasting that leadership can plan and intervene against. We are always clear about which engagements were the founder's roles and which were Tenhaw's, and will walk you through which is which on a call." }, { "question": "How do you hit a launch date the CEO has already announced?", "answer": "By making the risk of missing it visible early enough to act on. On the Discovery+ launch, six development teams had to redesign and merge content for a date announced by the CEO, and the visual rebrand team was badly overloaded relative to the time available. Delivery moved onto a data-driven footing. Story Points were recalibrated to reflect actual capacity, three sprints of Happy, Normal and Sad path forecasts made the probability of missing the date undeniable, and daily recommendations lifted speed and quality. The launch hit its date on both Discovery+ and Eurosport." }, { "question": "What are Happy, Normal and Sad path forecasts?", "answer": "Three delivery scenarios put side by side: what happens if everything goes well, what happens at the pace the data says is normal, and what happens if it does not. On the Discovery+ launch these went to the Head of Delivery across three sprints, built on Story Points recalibrated to actual capacity. Together they made the probability of missing the CEO's announced date undeniable. That is what leadership needs. Not a single guessed date, but a range of outcomes it can plan and intervene against." }, { "question": "Does telling leadership a launch will probably miss backfire?", "answer": "Not when the forecast is built on measurement. On the Discovery+ launch, three sprints of scenario forecasts made the probability of missing the CEO's date undeniable, and what came back was clarity, not blame. Discovery+ and Eurosport could finally manage delivery under real constraints, and the six-team launch hit its date. What backfires is the alternative, a single optimistic date defended until it collapses. A forecast presented as a range gives leadership time and options to intervene while intervening can still change the outcome." }, { "question": "Why adjust Story Point estimates after the work is completed?", "answer": "Because estimates made under deadline pressure drift optimistic, and forecasts built on optimism are fiction. On the Discovery+ launch the fix was to recalibrate Story Points after completion, so they reflected the capacity each team had actually demonstrated and not the capacity everyone hoped for. That recalibration is what made the Happy, Normal and Sad path forecasts credible enough to act on. They were grounded in what the teams had really done, sprint after sprint. Once the numbers reflected reality, the conversation about the launch date could too." }, { "question": "What do you do when one team is the bottleneck on a big launch?", "answer": "First make the overload a measured fact instead of a feeling. On the Discovery+ launch, the visual rebrand team James ran was badly overloaded relative to the time available, one of six teams working to a fixed date. Recalibrating Story Points after completion, so they reflected the capacity the team had actually demonstrated, turned that overload into numbers nobody could argue with. Once the constraint was measurable, the Happy, Normal and Sad path forecasts kept its consequences in front of the Head of Delivery sprint by sprint. Daily recommendations worked the problem from the other end by lifting speed and quality." }, { "question": "Did the Discovery teams learn to run the forecasting themselves?", "answer": "Yes. By the end of the ten-month engagement both the Discovery+ and Eurosport teams could run the forecasting and tracking practices autonomously, without James in the room. That was deliberate, not a side effect. The point of making delivery risk visible is that the client's own people keep doing it once you leave. It is the same standard Tenhaw holds today under the built to leave principle, and the forecasting method itself is published free in The Tenhaw Way, so nothing about it depends on a consultant staying." }, { "question": "Why does probabilistic forecasting matter for an AI transformation?", "answer": "Governing an agentic transformation needs what governing the Discovery+ launch needed. Leadership does not want a single guessed date. It wants a range of outcomes it can plan and intervene against. Probabilistic forecasts and confidence intervals tell an executive how likely a programme is to land where it is pointed, early enough to change course instead of holding an inquest. The method carries over intact, because it never depended on what was being delivered. On the Discovery+ launch it turned an overloaded team's demonstrated capacity into three sprints of scenario forecasts the Head of Delivery could act on, and both platforms hit the date." }, { "question": "How long does it take before leadership trusts a delivery forecast?", "answer": "On the Discovery+ launch, three sprints. That was the gap between putting delivery on a data-driven footing and forecasts that made the probability of missing the launch date undeniable to the Head of Delivery. The credibility came from the inputs. Story Points were recalibrated after completion to reflect actual capacity, so every forecast was built on what the teams had demonstrably done and not on what they had promised. Trust in a forecast is really trust in its data, and three sprints of honest numbers was enough to change how a six-team launch was governed." }, { "question": "Are daily delivery recommendations overkill under a hard deadline?", "answer": "No. A hard deadline is when waiting a week between course corrections costs the most. On the Discovery+ launch, daily recommendations to lift speed and quality ran alongside the sprint-level forecasts, so the teams always had something specific to change while there was still time for the change to matter. The forecasts told leadership where the launch was heading, and the daily recommendations were the mechanism for bending that trajectory. Delivery risk made visible early enough to act on it is what made the difference, and a six-team launch hit its date." }, { "question": "Does hitting a fixed launch date always cost quality?", "answer": "It does not have to. It usually does when the squeeze only becomes visible in the last fortnight. On the Discovery+ launch, six development teams had to redesign and merge content for a date the CEO had announced, and the visual rebrand team was badly overloaded relative to the time available. The daily recommendations issued to those teams covered speed and quality together, not speed alone, and they were useful because the pressure showed up early. Story Points recalibrated after completion exposed the real capacity, and three sprints of Happy, Normal and Sad path forecasts put the consequences in front of the Head of Delivery while there was still room to act. Both Discovery+ and Eurosport hit the date." }, { "question": "Does delivery forecasting work for design and content teams?", "answer": "Yes, and the Discovery+ launch is the case in point. James ran the visual rebrand team for ten months, one of six development teams whose job was to redesign and merge content across Discovery+ and Eurosport. The method does not depend on what the work product is. Story Points were recalibrated after completion to reflect the capacity a team had actually demonstrated, and that measures design and content output as readily as it measures code. The Happy, Normal and Sad path forecasts built on those numbers were credible enough to change how the launch was governed. Both platforms hit the date." }, { "question": "Who needs to see a delivery forecast for it to change anything?", "answer": "Whoever can move something. On the Discovery+ launch that was the Head of Delivery, who saw Happy, Normal and Sad path forecasts across three sprints, because that was the person who could act on constraints sitting across six teams rather than inside one. A forecast that reaches people with no levers becomes a report, while a forecast in front of someone who can intervene becomes a decision. The teams themselves needed the same information in a different form and got it, as daily recommendations to lift speed and quality. That is something a team can use the next morning, while the date is still reachable." }, { "question": "Won't teams game their estimates once forecasts drive decisions?", "answer": "The incentive to shade a number largely goes away when nobody is being asked to bid one. On the Discovery+ launch every forecast took its input from measurement after the work, Story Points recalibrated to the capacity a team had already demonstrated, so there was nothing to inflate in advance. The other half of it is what the numbers were used for. When three sprints of Happy, Normal and Sad path forecasts showed the visual rebrand team was badly overloaded relative to the time available, the response was daily recommendations to lift speed and quality rather than an inquest. People defend themselves against measures used against them, and rarely bother with one that gets them help." }, { "question": "Should a delivery lead run the team or advise from the outside?", "answer": "On the Discovery+ launch it was both, and the combination is what made it work. James was asked to run the visual rebrand team, one of six development teams on the launch, so the delivery data came from inside a badly overloaded team rather than from a spreadsheet passed around at a distance. At the same time the Happy, Normal and Sad path forecasts went to the Head of Delivery, because that is where the picture had to land for anything to change. Advice from outside a team rarely survives contact with the sprint, and running a team with no route to leadership means carrying the bad news alone." } ] } James led the visual rebrand workstream within the six-team Discovery+ launch. He used measured capacity to show happy, normal and sad-path forecasts to the Head of Delivery, with daily recommendations while the fixed launch date approached. The launch met its date. Role period: October 2020 to July 2021. Role: Leadership of one visual rebrand team, rather than ownership of all six launch teams. Work: Capacity-based tracking, forecast scenarios and daily recommendations on delivery risk. Result: Discovery+ and Eurosport launched on time; the teams could continue the forecasting and tracking practices after the ten-month engagement. See programme forecasting and governance: https://tenhaw.com/services/programme-management Explore media and product applications: https://tenhaw.com/sectors/retail-consumer ## Turning erratic global delivery into something the business could plan around Source: https://tenhaw.com/case-studies/yondr Last updated: 2026-11-05 { "slug": "yondr", "client": "Yondr", "logo": "/logos/yondr.svg", "duration": "6 months", "title": "Turning erratic global delivery into something the business could plan around", "summary": "We made delivery predictable enough that Yondr could plan beyond a single quarter for the first time.", "metrics": [ { "value": "3", "label": "regions: UK, USA, Singapore" }, { "value": "3 months", "label": "to consistent sprint output" }, { "value": "Dev + security + support", "label": "predictability extended across functions" } ], "challenge": "Yondr's global digital teams delivered inconsistently, so the business could not plan beyond a quarter. That unpredictability was most damaging in the UK and USA, where reliable delivery was critical to scaling data centre operations.", "approach": "We introduced accurate Story Point estimation, adjusted post-completion to reflect real capacity, and embedded the agile ceremonies that were missing: retrospectives, planning, and active backlog management. The work ran remotely across three regions, reinforced with on-site workshops.", "outcome": "Within three months development teams were producing consistent output every sprint. By six months that predictability had reached support and security teams, and the business could finally plan holistically.", "agenticLens": "What transfers is the baseline. You cannot state an automation improvement in a system whose human throughput nobody can currently state to within a factor of two, and this is the work of getting to that number. Predictability is a precondition for automation rather than evidence of it, which is why this work comes first.", "faq": [ { "question": "What did Tenhaw do for Yondr?", "answer": "A six-month engagement to make Yondr's global digital delivery predictable enough to plan around. Teams across the UK, USA and Singapore were delivering erratically. We introduced Story Point estimation recalibrated against real capacity, and we embedded the agile ceremonies that were missing: retrospectives, planning and active backlog management. Within three months the development teams were producing consistent output every sprint, and by six months that predictability had reached the support and security teams too. Yondr could plan beyond a single quarter for the first time." }, { "question": "Why could Yondr not plan beyond a single quarter?", "answer": "Because its global digital teams delivered inconsistently, and you cannot plan around output you cannot predict. The unpredictability was most damaging in the UK and USA, where reliable delivery was critical to scaling data centre operations. Nobody could say with confidence what a team would finish in a sprint, so any commitment beyond the current quarter was a guess. Fixing that was the whole engagement. Once output became consistent sprint after sprint, the planning horizon extended with it, first for development and then across support and security." }, { "question": "How long does it take to make erratic delivery predictable?", "answer": "Three months at Yondr to get the development teams producing consistent output every sprint. Six months for that predictability to reach the support and security teams. That is a realistic shape. Estimation only becomes accurate once it has been recalibrated against a few completed sprints, and ceremonies like retrospectives and backlog management compound rather than pay off instantly. Anyone promising a predictable delivery organisation in a fortnight is describing a report, not a change in how the teams actually work." }, { "question": "Can delivery coaching work remotely across time zones?", "answer": "Yes. The Yondr engagement ran remotely across the UK, USA and Singapore, with on-site workshops where being in the room helped. Three regions made remote-first a necessity. It worked because everything the method relies on is a visible artefact. Estimates get corrected against completed work. Backlogs are managed in the open where anyone can see them, and every ceremony leaves behind an output the whole team can read. Within three months of working that way, the development teams across those regions were producing consistent output every sprint." }, { "question": "Why fix delivery predictability before bringing in AI?", "answer": "Because you cannot state an automation improvement in a system whose human throughput nobody can currently state to within a factor of two. If a team's output swings unpredictably, any claim that AI made it faster is unmeasurable. The Yondr engagement is what getting to that baseline looks like. Consistent sprint output within three months, and support and security on the same footing by six. The payoff does not wait for the AI either. For the first time the business could plan holistically, where before it had never seen past the current quarter." }, { "question": "Our estimates are always wrong. How do we fix that?", "answer": "Adjust the estimate after the work is done. That one habit turns estimation from optimism into measurement. Most teams estimate, deliver something different, then never close the loop, so the next estimate inherits the same error. At Yondr we recalibrated Story Points post-completion to reflect the capacity each team had actually demonstrated, and that feedback loop is a large part of why development output became consistent within three months. The aim is not better guessing. It is that the numbers you plan with start to describe the team you actually have." }, { "question": "Can support and security teams become predictable too?", "answer": "They can. At Yondr predictability started with the development teams, who reached consistent sprint output within three months, and by six months it had reached support and security too. The mechanics do not change with the function. Make the work visible. Correct the estimates against what actually got completed, and hold planning and retrospectives on a regular beat. Extending it beyond engineering mattered because a business plans across all of its functions, and predictable development sitting next to unpredictable support still leaves leadership guessing. Only once all three were predictable could Yondr plan holistically." }, { "question": "Was the Yondr work delivered by Tenhaw itself?", "answer": "Yondr is one of the engagements delivered under the Tenhaw banner, alongside Anglo American, Greggs, Colart, Tecknuovo and Globelynx. Several engagements from that period predate the company's incorporation and were delivered by James Rooney personally on contract. On a call we will walk you through which is which. We say so plainly because a track record is only evidence if you can check it. The same person led the work either way, and this case study describes what was done and what changed." }, { "question": "Do agile ceremonies actually make delivery more predictable?", "answer": "They do when they are the missing feedback loops. Ritual on its own changes nothing. Yondr's teams had no retrospectives and no planning, and nobody was actively managing the backlog. Putting those back alongside honest Story Point estimation took the development teams to consistent output every sprint within three months. The ceremony itself is not the point. What each one adds is a place where the plan meets what actually happened and gets corrected. Teams that hold the meetings without making the corrections get the cost of the ceremonies and none of the predictability." }, { "question": "Why does sprint predictability matter to a data centre business?", "answer": "Reliable digital delivery in the UK and USA was critical to Yondr scaling its data centre operations, and that is where the unpredictability hurt most. When digital output is erratic, the operational side of the business cannot commit to anything that depends on it. Development output became consistent, support and security followed, and Yondr could plan holistically at last. For a business like that, predictable software delivery is an operational dependency, not an engineering nicety." }, { "question": "Do you fix delivery one region at a time or everywhere at once?", "answer": "Everywhere at once. We staged the order of functions and left geography out of it. At Yondr the work ran across the UK, USA and Singapore in parallel, remotely with on-site workshops where they earned the travel, because the erratic delivery was one problem, not three local ones. Development teams went first and hit consistent output every sprint within three months. Support and security followed and had the same predictability by six. Fixing one region at a time would have left leadership planning around whichever region was furthest behind, and Yondr needed reliable delivery in the UK and USA to scale its data centre operations." }, { "question": "Why not just hire an agile coach instead of a consultancy?", "answer": "If one team needs its ceremonies run properly, a coach is the cheaper and better answer, and we will tell you so. Yondr's problem was a size larger. The business could not plan beyond a quarter because digital teams in the UK, USA and Singapore delivered inconsistently, and reliable delivery in the UK and USA was critical to scaling data centre operations. The work meant recalibrating estimation against demonstrated capacity, embedding the ceremonies that were absent, then carrying the same discipline into support and security so leadership could plan across functions rather than one team at a time. Development output was consistent every sprint within three months." }, { "question": "Won't teams inflate their Story Points once you measure output?", "answer": "They will if you use points to rank people. At Yondr the correction ran the other way. Estimates were adjusted after completion to reflect the capacity each team had actually demonstrated, so an optimistic estimate gets corrected by the next sprint's evidence instead of rewarded. Points are a planning unit, not a performance measure. The test of the whole exercise was a business one. Could Yondr commit beyond the current quarter? Within three months the development teams were producing consistent output every sprint, and by six months support and security had the same. Use the number to judge individuals and you lose both the trust and the data." }, { "question": "What happens if our priorities keep changing mid-sprint?", "answer": "Predictability dies, and no estimation method survives it. Active backlog management was one of the ceremonies missing at Yondr, and putting it back gives reprioritisation somewhere to land. The backlog gets reordered in planning, so a sprint that has been committed can finish and produce a number worth learning from. Without that, every sprint is a different experiment and the average tells you nothing. That discipline is a large part of why Yondr's development teams reached consistent output every sprint within three months, and why the same approach held later for support and security." }, { "question": "How do you tell a real delivery improvement from one good quarter?", "answer": "By whether it repeats sprint after sprint, and by whether anyone outside engineering can plan on it. At Yondr the development teams held consistent output every sprint from month three. The same result held as the approach reached support and security by month six, and the business started planning holistically instead of a quarter at a time. One strong quarter is noise, usually a team that pushed hard or got lucky with scope. On live engagements we report value monthly for the same reason, and a month that delivers nothing measurable is reported as a failed month." } ] } Across Yondr engineering teams in the UK, USA and Singapore, Tenhaw introduced capacity-based planning, retrospectives and backlog management. Development output became consistent within three months, with the practices reaching support and security within six. Role period: September 2022 to March 2023. Measure: Consistency of completed work per sprint, using capacity-adjusted Story Points and completed-work history. Development window: The published result records consistent sprint output within three months. Wider adoption window: By six months the practices had reached support and security. The case concerns delivery predictability, not a deployed AI system. The case publishes the three- and six-month milestones, not raw sprint series or a numerical variability threshold. Those are not reconstructed from the outcome. Explore infrastructure and engineering applications: https://tenhaw.com/sectors/industrial-energy See delivery forecasting and governance: https://tenhaw.com/services/programme-management ## Making a pandemic-era app team predictable, and trusted again Source: https://tenhaw.com/case-studies/greggs Last updated: 2026-11-05 { "slug": "greggs", "client": "Greggs", "logo": "/logos/greggs.svg", "duration": "6 months", "title": "Making a pandemic-era app team predictable, and trusted again", "summary": "We turned a rushed technical department into a predictable one, and proved tackling tech debt accelerated delivery.", "metrics": [ { "value": "2", "label": "squads: Mobile App and Integration" }, { "value": "Org-wide", "label": "agile coaching beyond engineering" }, { "value": "Tech debt", "label": "shown to speed up delivery, with data" } ], "challenge": "Greggs launched a mobile app so customers could order and earn rewards, but the rushed setup of technical ways of working created friction with Marketing and other departments. They needed Scrum Master support for two squads plus broader agile coaching across the business.", "approach": "We refined Story Points for capacity-based tracking, coached Product on data-driven prioritisation, and ran prioritisation workshops and alignment sessions that taught non-technical teams how agile actually works. We used data to prove the payback of addressing tech debt.", "outcome": "Delivery became predictable, confidence in the technical department recovered, and prioritisation conversations became realistic and focused. The data showing tech debt accelerated timelines strengthened collaboration across departments.", "agenticLens": "Cross-functional trust and a shared, data-backed language for value are prerequisites for agentic change. Agents amplify whatever operating culture they land in, so the culture has to be sound first. What transfers from Greggs is the coaching and prioritisation discipline that made one department's numbers believable to every other one.", "faq": [ { "question": "What did Tenhaw actually deliver at Greggs?", "answer": "Scrum Master support for two squads, Mobile App and Integration, plus agile coaching across the wider business, over six months. Greggs had launched a mobile app so customers could order and earn rewards, but the rushed setup of technical ways of working created friction with Marketing and other departments. We refined Story Points so tracking followed real capacity. Product was coached to prioritise from data, and the workshops and alignment sessions we ran taught non-technical teams how agile actually works. By the end delivery was predictable and prioritisation conversations were realistic, and confidence in the technical department had recovered." }, { "question": "What has coaching a delivery team got to do with agentic change?", "answer": "More than it looks. This was Scrum Master support for two squads and agile coaching across the wider business, and the preconditions it built are the ones agentic change depends on. Agents amplify whatever operating culture they land in, so cross-functional trust and a shared, data-backed language for value have to be sound before automation arrives. Six months bought Greggs predictable delivery. It also bought prioritisation conversations that were realistic and focused, and a technical department the rest of the business trusted again." }, { "question": "Did Tenhaw exist when the Greggs work was delivered?", "answer": "Some of the work on this site predates the company, and we are straightforward about which. Greggs sits in the group of engagements delivered under the Tenhaw banner, alongside Anglo American, Yondr, Colart, Tecknuovo and Globelynx. Several in that group predate incorporation and were delivered by James Rooney personally on contract, and we will walk you through which is which on a call. The distinction matters more for the paperwork than for the work. Tenhaw is founder-led, James leads every engagement personally, and the six months of Scrum Master support and coaching described in this study happened as written, whichever banner it sat under." }, { "question": "How do you rebuild trust between a technical team and the rest of the business?", "answer": "By making delivery predictable enough that commitments mean something again. At Greggs the problem was never technical. An app team had been stood up at speed during the pandemic, ways of working were invented on the way, and the friction with Marketing and other departments had eroded confidence in the whole technical department. We rebuilt the numbers first, refining Story Points so tracking reflected real capacity, then ran alignment sessions and prioritisation workshops that put those numbers in front of the other departments. Trust followed the data. Once delivery became predictable, prioritisation conversations turned realistic and focused, and confidence in the technical department recovered." }, { "question": "How do you prove paying down tech debt speeds up delivery?", "answer": "Use the delivery data. The claim that paying down tech debt speeds up delivery is usually made as a technical argument and lost as a budget conversation, because nobody outside engineering can weigh an engineer's opinion. At Greggs we used delivery data to prove the payback of addressing tech debt, and the numbers are what let the argument survive contact with Marketing and the other departments. The data showing tech debt work accelerated timelines strengthened collaboration across the departments. The wider lesson is that a shared, data-backed language for value turns the hardest prioritisation arguments into something every department can judge on the same terms." }, { "question": "Why do rushed app launches cause delivery problems later?", "answer": "Because ways of working invented under pressure harden into the operating model. Greggs stood its app team up at speed so customers could order and earn rewards, and the rushed setup created friction with Marketing and other departments. The pattern recurs, and it is not a technical one. A team ships under pressure, estimates stop being believed, then prioritisation turns into a negotiation about credibility rather than value. At Greggs it took a six-month engagement of capacity-based tracking and coaching that reached beyond engineering to make delivery predictable and the department trusted again." }, { "question": "Does agile coaching work outside engineering teams?", "answer": "Yes, and at Greggs coaching beyond engineering was a stated part of the brief, not a side effect. Alongside Scrum Master support for the Mobile App and Integration squads, we ran prioritisation workshops and alignment sessions that showed non-technical teams how agile actually works. The point was never to make Marketing run stand-ups; it was to give every department a shared, realistic picture of capacity, so conversations about what gets built next start from data rather than assertion. That organisation-wide coaching is a large part of why predictable delivery turned into recovered trust across departments." }, { "question": "Why does team credibility matter before starting an AI programme?", "answer": "Because a department whose commitments are not believed cannot sequence anything, including an AI programme. A head of AI inheriting a distrusted technical department will find the blocker is not the model. It is that no estimate the department makes is taken seriously, so nothing can be planned against. The Greggs engagement is what fixing that looks like. Six months of Scrum Master support and coaching made delivery predictable and made the department's numbers believable again. An AI programme gets planned against those numbers like everything else, so they have to be believable before the technology arrives." }, { "question": "What would a Greggs-style engagement cost from Tenhaw today?", "answer": "It would be sold as Programme and Delivery Management at £18k–£35k per month, depending on scope. The Greggs work, Scrum Master support across two squads plus agile coaching beyond engineering, sits squarely in that service. What you are buying is senior delivery leadership that makes output predictable and gives the business numbers it can plan against. Tenhaw engagements are retainer-shaped with an exit date agreed at kickoff and 30 days' notice either side, and a month that delivers no measurable value is reported as a failed month. A 30-minute call is the quickest way to size your version of it." }, { "question": "How do you get prioritisation decisions based on value rather than politics?", "answer": "Give every side the same numbers and coach them to argue from them. At Greggs, friction between the technical department and Marketing meant prioritisation ran on assertion. Refining Story Points for capacity-based tracking rebuilt the numbers, Product was coached to prioritise from data, and the prioritisation workshops and alignment sessions put that evidence in front of every department at once. That is the shift the study records. Prioritisation conversations became realistic and focused, and even the hardest sell, spending delivery time on tech debt, was won with delivery data rather than opinion. Shared numbers that everyone believes leave politics very little to work with." }, { "question": "Does retail tech debt have to be paid down before AI modernisation?", "answer": "Not all of it, and the real decision is which parts. Pay down the retail tech debt that sits directly in the path of the work you intend to automate, and keep the rest costed and visible. Tech debt and an AI modernisation programme draw on the same delivery capacity, so it gets settled as a budget question and not an engineering one. At Greggs we used delivery data to show that tackling tech debt accelerated timelines, which gave Marketing and the other departments a shared basis for agreeing the order of work. That same data lets you sequence modernisation around the debt that actually blocks it. Clearing the lot first is rarely the cheapest route." }, { "question": "Is our delivery problem the team or the way they work?", "answer": "Usually it is the way they work. Greggs shows the difference clearly. The app team was stood up at speed so customers could order and earn rewards, and it was the rushed setup of technical ways of working, not the engineering, that created friction with Marketing and other departments. The tell is where the disbelief sits. One team missing its own dates is a team problem. Several departments no longer believing any estimate is an operating model problem, and more pressure on the team will not shift it. What made delivery predictable again was six months of Scrum Master support and capacity-based tracking, with coaching that reached beyond engineering." }, { "question": "Should Marketing be in the prioritisation workshop, or just Product?", "answer": "Both, and at Greggs that was rather the point. Product was coached to prioritise from data, but the friction sat between the technical department and Marketing, so a workshop with only Product in it would have moved the argument rather than settled it. We ran prioritisation workshops and alignment sessions together, the sessions teaching non-technical teams how agile actually works so everyone in the room could read the capacity numbers. Once the people asking for work and the people doing it were looking at the same figures, prioritisation became a choice between options instead of a test of anyone's credibility." }, { "question": "What happens if the delivery data makes the team look bad?", "answer": "It often does at first. What you do with that first honest picture decides the engagement. Capacity-based tracking replaces optimistic estimates with what the team has actually demonstrated, so the early numbers tend to be smaller than what the business believed it had been promised. At Greggs the refined Story Points went straight into prioritisation workshops with Marketing and the other departments. They were the basis for deciding what came next, not a scorecard for what had gone before, and confidence in the technical department recovered. Used as a stick, the same data destroys the trust it was gathered to rebuild." }, { "question": "How do you tell whether agile coaching actually worked?", "answer": "By what changes outside the team, not by how the ceremonies feel. Ask whether what the team forecasts matches what lands. Ask whether other departments plan against those numbers, and whether the arguments have moved from credibility to value. Greggs is what passing looks like. After six months of refined Story Points and capacity-based tracking, delivery was predictable and prioritisation conversations were realistic and focused, and confidence in the technical department had recovered. We hold our own engagements to the same standard. They are retainer-shaped, and a month that delivers no measurable value is reported as a failed month." } ] } Tenhaw supported Greggs' Mobile App and Integration squads with Scrum Master work and wider agile coaching. Capacity-based tracking and prioritisation workshops helped the business plan against delivery data and see the payback from technical-debt work. Role period: November 2021 to September 2022. This is the wider published role period. The case covers six months of delivery and coaching work. Remit: Scrum Master support for two squads and coaching beyond engineering, rather than a claim that Tenhaw built the customer app. Working changes: Capacity-based Story Point tracking, data-backed prioritisation and workshops connecting Product with non-technical departments. Result: More predictable delivery, more realistic prioritisation and recovered confidence in the technical department. The case does not publish a numerical speed improvement. Explore learning and adoption through delivery: https://tenhaw.com/use-cases/ai-training-and-adoption See retail app and workflow applications: https://tenhaw.com/sectors/retail-consumer ## Building a PMO from zero to govern 19 projects, including public-sector delivery Source: https://tenhaw.com/case-studies/tecknuovo Last updated: 2026-11-05 { "slug": "tecknuovo", "client": "Tecknuovo", "logo": "/logos/tecknuovo.svg", "duration": "9 months", "title": "Building a PMO from zero to govern 19 projects, including public-sector delivery", "summary": "We stood up a centralised PMO from scratch and ran a complex portfolio while upskilling the next generation of delivery leads.", "metrics": [ { "value": "19", "label": "projects overseen" }, { "value": "HMRC · MOD · Thames Water", "label": "high-profile public sector" }, { "value": "PMO", "label": "built and operationalised from nothing" } ], "challenge": "Tecknuovo, a consultancy, needed a centralised Portfolio Management Office to oversee 19 diverse projects, including critical public-sector engagements, and wanted its junior staff upskilled in best practice.", "approach": "We built a PMO function from the ground up, implemented portfolio frameworks for tracking and managing delivery, and provided hands-on coaching to junior team members in portfolio management and agile delivery while overseeing the live portfolio.", "outcome": "Tecknuovo gained a fully functional PMO with real visibility and control, a markedly more capable junior delivery team, and reinforced credibility on high-profile public-sector work.", "agenticLens": "What transfers is the function itself: a standing register of what is being built, who owns it, what it was permitted to do and what happened when it was reviewed, which is the discipline every portfolio needs once delivery is spread across teams, suppliers and departments. What this engagement was not is a technology build. It was portfolio governance and the upskilling of a delivery team, and the study is written as exactly that.", "faq": [ { "question": "How long does it take to build a PMO from scratch?", "answer": "Nine months, in our experience. At Tecknuovo, a consultancy, we stood up a centralised Portfolio Management Office from nothing and had it governing 19 projects, including public-sector delivery for HMRC, the MOD and Thames Water. The work ran in parallel. We implemented portfolio frameworks for tracking and managing delivery while we oversaw the live portfolio, so nothing was designed on paper and switched on later. By the end Tecknuovo had a fully functional PMO with real visibility and control, and a junior delivery team markedly more capable than when we arrived." }, { "question": "What did Tenhaw do for Tecknuovo?", "answer": "We built Tecknuovo a Portfolio Management Office from zero and ran it for nine months. Tecknuovo is a consultancy. It needed centralised oversight of 19 diverse projects, including critical public-sector engagements for HMRC, the MOD and Thames Water, and it wanted its junior staff upskilled in best practice. We implemented the portfolio frameworks for tracking and managing delivery, oversaw the live portfolio, and coached junior team members in portfolio management and agile delivery. Tecknuovo came out of it with a fully functional PMO and real visibility and control. Its junior delivery team was markedly more capable, and its credibility on high-profile public-sector work was reinforced." }, { "question": "Does Tenhaw take on work for other consultancies?", "answer": "Tecknuovo is one. It is a consultancy, and it brought us in to build the Portfolio Management Office that governed its own 19-project portfolio, including public-sector delivery for HMRC, the MOD and Thames Water. A consultancy is a demanding client for delivery work, because delivery is what it sells. The engagement had to give its leadership real visibility and control and leave its junior delivery leads markedly more capable. Over nine months it did both. If your firm sells delivery and needs its own house in order, that is a problem we have solved before." }, { "question": "Has Tenhaw worked on HMRC or MOD programmes?", "answer": "At portfolio level, yes. Tecknuovo is a consultancy delivering into the public sector, and we built and ran the Portfolio Management Office that governed a 19-project portfolio taking in HMRC, the MOD and Thames Water. Our role was governance and oversight. We owned the frameworks and the tracking that kept high-profile public-sector work visible and well run, and Tecknuovo's own teams delivered the projects. The outcome reinforced Tecknuovo's credibility on that work. It is portfolio delivery, and it is the record we point at when a buyer asks about public sector experience." }, { "question": "How many projects can one PMO team realistically oversee?", "answer": "Nineteen at Tecknuovo, all governed by one centralised PMO. It was a diverse book, and it included critical public-sector engagements for HMRC, the MOD and Thames Water. What makes that scale workable is the framework, not headcount. One consistent way of tracking and managing delivery across the whole portfolio means leadership can see what is being built, who owns it and how it is going, in one place instead of nineteen. The real test is not how many projects the office touches. It is whether leadership gets real visibility and control, and Tecknuovo did." }, { "question": "Can you coach our junior delivery leads during a live engagement?", "answer": "Yes, and live is where coaching sticks. At Tecknuovo we provided hands-on coaching in portfolio management and agile delivery to junior team members while overseeing the live 19-project portfolio, so people learned on the work they were actually accountable for rather than in a classroom. Over nine months that produced a markedly more capable junior delivery team, which was one of the two things Tecknuovo hired us for in the first place. Building up the client's own people is standard for us. It is how an engagement ends without leaving a dependency behind." }, { "question": "Who runs the PMO after the consultants leave?", "answer": "Your people, if the engagement was set up honestly. At Tecknuovo the deliverable was not just a functioning Portfolio Management Office. It was also a junior delivery team coached in portfolio management and agile delivery while the live portfolio ran, so the capability stayed in the building when the engagement ended. That is our standard shape: the exit date is agreed at kickoff, the client owns all work product, and skill transfer is written in as a deliverable. A PMO that only works while the consultancy is in the room is a subscription, not a function." }, { "question": "What should a portfolio management office actually track?", "answer": "Keep a standing register of four things: what is being built, who owns it, what it was permitted to do, and what happened when it was reviewed. That is the function underneath the PMO we built for Tecknuovo, implemented as portfolio frameworks for tracking and managing delivery across a 19-project portfolio. Everything else a PMO produces derives from that register. There is a simple test for whether yours tracks the right things. Does leadership have real visibility and control, or just reporting?" }, { "question": "Does portfolio governance experience transfer to a technology programme?", "answer": "It does, because the hard part is the function, not the subject matter. A portfolio office keeps a standing register of what is being built, who owns it, what it was permitted to do and what happened when it was reviewed, and it holds that record current while the work runs rather than assembling it afterwards. Tenhaw built and ran that function at Tecknuovo across a 19-project portfolio spanning HMRC, the MOD and Thames Water, and upskilled the junior delivery team while it ran. A programme that cannot answer those four questions on any given week is not governed, whatever it is building." }, { "question": "Does upskilling our own people slow the delivery down?", "answer": "No. At Tecknuovo the coaching was the delivery. Junior team members were coached in portfolio management and agile delivery on the portfolio itself, while we oversaw the live 19-project portfolio, critical public-sector work included. Nothing paused for training. The portfolio kept moving for the full nine months and the coaching rode on it. Tecknuovo got both outcomes at once, a fully functional PMO with real visibility and control and a markedly more capable junior delivery team. That is why coaching on live work beats sending people on a course." }, { "question": "Does stronger delivery governance help win public sector work?", "answer": "It did at Tecknuovo, where reinforced credibility on high-profile public-sector work is one of the three outcomes the study records. The portfolio we governed included delivery for HMRC, the MOD and Thames Water. Buyers of that kind will not take assurance on trust. They want to see how a supplier tracks work and who owns each project, down to what happened at the last review. A centralised Portfolio Management Office produces that evidence as a by-product of running the portfolio properly, so it is already there when someone asks. Credibility of that sort follows the evidence rather than the pitch." }, { "question": "Should government and commercial projects run to the same standard?", "answer": "Yes. Let the public-sector work set it. Tecknuovo's book of 19 was a diverse one. Engagements delivering to HMRC, the MOD and Thames Water sat alongside the rest of the portfolio, and the office we built governed all of it under the same frameworks. Running two standards is where portfolio offices come undone, because every project that moves between them has to be translated and leadership stops comparing like with like. Hold the whole book to what your most scrutinised client expects, and everything else inherits it at no extra cost." }, { "question": "Is it worth building a PMO for just a handful of projects?", "answer": "Often not, and it is cheaper to hear that now. The function you actually need is a current register of what is being built and who owns it, and with a handful of projects one person can hold that in a single document and a weekly conversation. At that size a separate office adds reporting without adding much control. Tecknuovo's position was different: a book of 19 diverse projects, including delivery for HMRC, the MOD and Thames Water, is well past the point where anyone carries the picture in their head. That is why it needed a centralised Portfolio Management Office, and why building one was nine months of work." }, { "question": "How do you get delivery teams to actually use a new PMO?", "answer": "Build it on the work they are already doing. At Tecknuovo we implemented the portfolio frameworks while overseeing the live portfolio, so there was never a launch day when nineteen projects were told to switch to something designed elsewhere. The people who would run the office afterwards, Tecknuovo's junior delivery leads, were coached in portfolio management and agile delivery inside it while it took shape, which gave the office advocates on the ground before it had any authority. An office designed on paper and handed over finished gets treated as head office reporting. One that grew out of the portfolio gets used." }, { "question": "What should we ask a firm offering to build our PMO?", "answer": "Three questions get you most of the way. First, what will leadership be able to see that they cannot see today, in concrete terms, because an answer that amounts to more reporting is overhead rather than real visibility and control. Second, who owns the frameworks, the register and the documentation at the end. With us the client owns all work product and the exit date is agreed at kickoff. Third, what capability stays behind. At Tecknuovo the junior delivery leads were coached in portfolio management and agile delivery while the portfolio ran, and a markedly more capable delivery team is recorded as an outcome alongside the office itself." } ] } Tenhaw built and ran Tecknuovo's central Portfolio Management Office across nineteen projects and coached the delivery leads who took it over. The portfolio included HMRC, MOD and Thames Water work delivered by Tecknuovo teams. Role period: October 2023 to June 2024. Tenhaw's role: Portfolio governance, delivery visibility, frameworks and coaching over nine months. Project delivery: Tecknuovo's teams delivered the projects. The named public-sector organisations identify portfolio scope, not direct Tenhaw AI-build references. Handover: A working PMO and delivery leads coached while the live portfolio ran. Explore PMO and programme governance: https://tenhaw.com/services/programme-management See the public-sector delivery approach: https://tenhaw.com/sectors/public-sector ## Turning three merged teams into one delivery unit through workflow design Source: https://tenhaw.com/case-studies/colart Last updated: 2026-11-05 { "slug": "colart", "client": "Colart", "logo": "/logos/colart.png", "duration": "6 months", "title": "Turning three merged teams into one delivery unit through workflow design", "summary": "We designed the processes and Jira workflows that let a newly merged digital team ship an e-commerce platform.", "metrics": [ { "value": "3", "label": "merged teams aligned" }, { "value": "E-commerce", "label": "website successfully built" }, { "value": "Less downtime", "label": "via matured backlogs" } ], "challenge": "After Colart merged its Global Marketing, Development, and Business Intelligence teams, the new Digital Team lacked alignment, communication channels, and consistent delivery, stalling key transformation work including a new e-commerce site.", "approach": "We designed agile processes for a cross-functional team, aligned Jira workflows to how the business actually worked, established clear communication channels, matured the backlog to cut downtime, used data to guide prioritisation, and escalated critical issues to senior leadership when needed.", "outcome": "The Digital Team became cohesive and predictable, transformation work progressed consistently, and the e-commerce website shipped successfully.", "agenticLens": "What transfers is that an agent needs exactly what this merged team needed: an unambiguous definition of a piece of work, a state model to move it through, and somewhere to escalate when it cannot. The process, workflow and backlog design that gave three merged functions those three things is the same groundwork an agentic operating model stands on.", "faq": [ { "question": "What did Tenhaw do for Colart?", "answer": "Over six months we turned three newly merged teams, Global Marketing, Development and Business Intelligence, into one working Digital Team. The work was process and workflow design: agile processes built for a cross-functional team, Jira workflows aligned to how the business actually worked, clear communication channels, a matured backlog that cut downtime, and data-guided prioritisation, with critical issues escalated to senior leadership when needed. The result was a cohesive, predictable team, transformation work that progressed consistently, and an e-commerce website that shipped successfully. The discipline behind that, one agreed definition of a finished piece of work and one route for moving it, is what turned three merged functions into a single delivery unit." }, { "question": "Why do merged teams stop delivering after a reorganisation?", "answer": "Because the merger creates a team on the org chart before it creates one in practice. When Colart merged its Global Marketing, Development and Business Intelligence teams, the new Digital Team had no shared alignment, no established communication channels and no consistent way of delivering, and key transformation work stalled, including a new e-commerce site. Nobody in that situation is underperforming individually. The connective tissue is missing. So the fix at Colart was structural, not motivational. We agreed processes for the cross-functional team, matched workflows to the real work, made the communication channels explicit, and gave the team a route to senior leadership for the issues it could not resolve itself." }, { "question": "Can agile work across marketing, development and business intelligence teams?", "answer": "Yes, when the process is designed for the mixed team rather than borrowed from software engineering and imposed on everyone else. At Colart the new Digital Team combined Global Marketing, Development and Business Intelligence, and we designed agile processes for that cross-functional shape, with Jira workflows aligned to how the business actually worked. Clear communication channels and data-guided prioritisation did the rest. The team became cohesive and predictable, and the stalled e-commerce website shipped successfully." }, { "question": "Is it worth redesigning Jira workflows around how the business works?", "answer": "It was at Colart. A workflow that mirrors how work actually moves through the business gets used honestly; one that mirrors a tool's defaults gets worked around, and the board stops telling the truth about delivery. We aligned Colart's Jira workflows to how the newly merged Digital Team really operated, as part of a wider redesign covering agile processes, communication channels and a matured backlog. Delivery became consistent enough that the stalled e-commerce build progressed and shipped. The workflow itself is not the point; it is the state model that makes a piece of work unambiguous, and that is what the merged team had been missing." }, { "question": "How does a mature backlog reduce downtime?", "answer": "A matured backlog means the next piece of work is already defined, understood and ready when the team finishes the current one, so nobody idles while requirements are chased or decisions are awaited. At Colart, maturing the backlog was one of the specific levers we used, and less downtime is the result the study records. It matters most in a newly merged team, because the person who used to answer a quick question across the desk may now sit in a different part of the organisation, and every ill-defined item turns into a wait. Combined with data-guided prioritisation, it kept Colart's Digital Team delivering consistently." }, { "question": "How do you prioritise when newly merged teams disagree?", "answer": "Data settled it. Three merged teams arrived at Colart with their own views of what mattered, so we used data to guide prioritisation and the backlog began reflecting evidence instead of whichever function argued loudest. Two other mechanisms mattered alongside it. A matured backlog meant every item was well enough defined to be compared honestly. A clear escalation route meant the critical issues the team could not settle went to senior leadership before they festered. Prioritisation disputes are usually a symptom of missing structure. The people are rarely the problem. Once the structure existed, Colart's Digital Team delivered predictably." }, { "question": "How long does it take to align merged teams into one delivery unit?", "answer": "At Colart it took six months to take three merged teams, Global Marketing, Development and Business Intelligence, from stalled and misaligned to cohesive and predictable, with the e-commerce website shipped along the way. Most of that time went into design work. We shaped agile processes for a cross-functional team, matched the Jira workflows to the real work, set up communication channels people actually used, and matured the backlog to the point where downtime fell. The honest caveat is that six months describes this organisation, not every merger. The pattern transfers. The number is theirs." }, { "question": "Did Colart's e-commerce platform actually ship?", "answer": "Yes. The e-commerce website was among the key transformation work that stalled while Colart's merged Digital Team lacked alignment and consistent delivery, and it shipped successfully once the team was working as one unit. The causal chain is worth being clear about. We designed the processes, Jira workflows and communication channels that let the merged team build the platform, and Colart's own engineers built it. That distinction is one to check in any consultancy's case studies. The delivery discipline was ours. The engineering was Colart's own people, unblocked." }, { "question": "What does a workflow design engagement have to do with agentic AI?", "answer": "More than it first appears. An AI agent needs the same things Colart's merged team needed. It has to know what a piece of work is, how to move it through a state model, and where to escalate when it cannot proceed. Design those well for people and you have designed most of what an agentic operating model needs later. Colart is what that groundwork looks like in practice. Three merged functions ran off a single backlog and a single state model, and a stalled e-commerce site shipped once the team worked as one unit." }, { "question": "Was the Colart work delivered by Tenhaw or by James personally?", "answer": "Colart is one of the engagements delivered under the Tenhaw banner, alongside Anglo American, Yondr, Greggs, Tecknuovo and Globelynx. Several of those predate the company's incorporation and were delivered by James Rooney personally on contract, and we will walk you through which is which on a call rather than blur the line in marketing copy. The delivery experience is the same either way, because James leads every Tenhaw engagement personally today. We keep this separate from the HSBC, Microsoft, Sky, F1 and Discovery track record, which were the founder's delivery and transformation roles inside those organisations." }, { "question": "Does a retail AI operating model start with the team or the technology?", "answer": "With the team. A retail AI operating model is mostly a set of agreements about how work is defined and moved between functions, and Colart is the pre-AI version of that argument. When Global Marketing, Development and Business Intelligence merged into one Digital Team, the team had no shared alignment, no established communication channels and no consistent way of delivering, and a new e-commerce site stalled. Six months of process, Jira workflow and backlog design made it cohesive and predictable, and the site shipped. If those three functions cannot agree today what a finished piece of work looks like, no agent will settle it for them." }, { "question": "Can't our own delivery managers fix a stalled merged team?", "answer": "Often, yes. If leadership is aligned and the merged functions already trust one way of working, run it in-house and keep the fee. It gets harder when the shape of the merger is the problem. Colart's new Digital Team combined Global Marketing, Development and Business Intelligence, and a process shaped around any one of those sets of habits tends to be quietly ignored by the other two, so whoever designs it has to work for the mixed team without belonging to a part of it. That took six months at Colart, alongside a standing route to senior leadership for the calls the team could not make itself. If your own managers can hold both, you do not need us." }, { "question": "What if senior leaders ignore the issues a team escalates?", "answer": "Then the escalation route is decoration, and no amount of workflow design compensates for it. Escalating critical issues to senior leadership was one of the named mechanisms at Colart, and it only counts as a mechanism if somebody answers. A team that raises a blocker and hears nothing learns to stop raising blockers, so the risk log goes quiet while the risks carry on. Test it before you design around it. Take one properly blocked item, escalate it, and time how long a decision takes. If the answer is never, that is the thing to fix first, and no board redesign will hide it." }, { "question": "What does fixing a team's communication channels actually involve?", "answer": "Less than a governance framework and more than a new chat channel. Colart's merged Digital Team spanned Global Marketing, Development and Business Intelligence, and making its channels explicit meant agreeing where each kind of request or decision gets raised, who the three functions go to for what, and where critical issues go when the team cannot settle them itself, which at Colart was senior leadership. A merger quietly removes the informal routes people relied on before anyone notices they have gone. The symptoms then look like poor delivery rather than poor plumbing. It was one of the levers that got the stalled e-commerce work moving again." }, { "question": "How do you stop merged teams quietly re-forming as silos?", "answer": "Make them share the artefacts, not just the org chart. Three functions can sit in one Jira project and still run three processes, so at Colart the shared layer was designed deliberately: agile processes built for the cross-functional team rather than lifted from one function's habits, Jira workflows aligned to how the business actually worked, and one backlog the whole Digital Team drew its next piece of work from. Silos re-form through small defaults, a separate board here, a private thread there, and the way to stop that is to leave nowhere sensible for those defaults to live. Six months in, the team was predictable and the e-commerce site had shipped." } ] } Tenhaw designed agile processes and Jira workflows for Colart's merged Marketing, Development and Business Intelligence team. The six-month delivery change helped the cross-functional team work predictably and enabled Colart's engineers to ship the ecommerce website. Role period: April 2018 to May 2019. The published career record covers the wider Colart role. This case describes six months of delivery work within it. Starting point: Three functions had merged, with unclear communication, inconsistent delivery and a stalled ecommerce project. Work: Shared process, Jira workflow design, backlog preparation, prioritisation and escalation to senior leadership. Result: The team became cohesive and predictable and the ecommerce website shipped. The case records delivery enablement rather than Tenhaw owning the engineering build. Explore retail and ecommerce applications: https://tenhaw.com/sectors/retail-consumer Plan a new AI product or feature: https://tenhaw.com/use-cases/ai-product-development ## Coordinating five agile teams through a £1bn e-commerce re-platform Source: https://tenhaw.com/case-studies/ynap Last updated: 2026-11-05 { "slug": "ynap", "client": "YOOX NET-A-PORTER", "logo": "/logos/ynap.svg", "duration": "12 months", "title": "Coordinating five agile teams through a £1bn e-commerce re-platform", "summary": "We provided the Scrum Master and PMO backbone that kept a £1bn re-platforming programme aligned to tight client deadlines.", "metrics": [ { "value": "£1bn", "label": "re-platforming programme" }, { "value": "5", "label": "agile teams coordinated" }, { "value": "Deadlines met", "label": "with strong client satisfaction" } ], "challenge": "Salmon was re-platforming YNAP's e-commerce solution to IBM WebSphere Commerce. The scale demanded tight coordination across five agile teams against strict client deadlines, while managing staff transitions and operational logistics.", "approach": "We ran a dual Scrum Master and PMO model: facilitating agile delivery across five teams, managing onboarding logistics and equipment, streamlining communication between the client PMO and internal teams, and maintaining transparency through weekly reporting and travel coordination.", "outcome": "The programme progressed efficiently, teams met client deadlines with a high standard of collaboration, and tight operational processes produced a well-executed project and strong client satisfaction.", "agenticLens": "Multi-team coordination with a single source of truth is the same problem agentic transformation faces at scale: many actors, shared dependencies, one operating rhythm everyone trusts. This was 12 months of Scrum Master and PMO work on an e-commerce re-platform, and that coordination is what an agentic programme inherits rather than invents.", "faq": [ { "question": "What did Tenhaw do at YOOX NET-A-PORTER?", "answer": "We provided the Scrum Master and PMO backbone on a £1bn programme re-platforming YNAP's e-commerce solution to IBM WebSphere Commerce, delivered by Salmon. Over 12 months we coordinated five agile teams against strict client deadlines: facilitating agile delivery, managing onboarding logistics and equipment, streamlining communication between the client PMO and the delivery teams, and maintaining transparency through weekly reporting. The teams met their deadlines with a high standard of collaboration, and the programme closed with strong client satisfaction. Tight operational processes are what held that together across five parallel teams." }, { "question": "How do you coordinate five agile teams on one programme?", "answer": "With one operating rhythm everyone trusts and a single source of truth about the state of the work. On YNAP's £1bn re-platform we ran a dual Scrum Master and PMO model. Agile facilitation sat inside the teams so each kept its cadence, and a PMO layer above them owned reporting, dependencies and operational logistics. Communication between the client PMO and the delivery teams was streamlined, so questions had one route in and answers had one route out, and weekly reporting kept the whole programme transparent. Five teams met strict client deadlines for 12 months on that footing." }, { "question": "Do agile programmes still need a PMO?", "answer": "At scale, yes, and YNAP is the evidence. Five agile teams inside a £1bn re-platform each had their own cadence, but somebody still had to hold the cross-team picture. That meant dependencies, onboarding logistics, equipment, travel, and one version of progress the client PMO could trust. We ran Scrum Master and PMO as a dual model, not as rivals. Agile facilitation gave the teams their rhythm and the PMO gave the programme its transparency through weekly reporting. Teams met their deadlines and collaboration stayed strong. That is what a PMO is actually for." }, { "question": "How big was the YNAP re-platforming programme?", "answer": "It was a £1bn programme, with five agile teams coordinated through a 12-month Scrum Master and PMO engagement. Salmon was re-platforming YOOX NET-A-PORTER's e-commerce solution to IBM WebSphere Commerce, and the scale demanded tight coordination against strict client deadlines while staff transitions and operational logistics were managed in parallel. Streamlined communication, weekly reporting and one operating rhythm across all five teams kept it aligned, because alignment is the constraint at that size. The programme met its deadlines with strong client satisfaction." }, { "question": "What platform did YNAP move its e-commerce to?", "answer": "IBM WebSphere Commerce. Salmon delivered the re-platform of YOOX NET-A-PORTER's e-commerce solution, and we provided the Scrum Master and PMO backbone that kept five agile teams aligned to the client's deadlines across 12 months. Our part was delivery coordination. We facilitated agile delivery inside the teams, streamlined communication between the client PMO and the internal teams, and maintained transparency through weekly reporting, with onboarding logistics and equipment handled centrally so the teams kept their hours for delivery. The programme progressed efficiently and met its deadlines." }, { "question": "What does a £1bn re-platform have to do with agentic AI?", "answer": "The coordination problem is the same. Multi-team delivery with a single source of truth, many actors, shared dependencies and one operating rhythm everyone trusts is what agentic transformation faces at scale, just with agents among the actors. The YNAP engagement proved that discipline across five teams on a £1bn programme. What it took was one operating rhythm the five teams shared, a single route for questions between the client PMO and the delivery teams, and weekly reporting nobody had to reconcile. Dependencies were handled before they turned into missed dates, and the teams held strict client deadlines for 12 months." }, { "question": "How do you keep a client PMO and supplier delivery teams aligned?", "answer": "By giving communication one spine instead of many threads. On the YNAP re-platform, Salmon's five agile teams delivered against YOOX NET-A-PORTER's strict deadlines, and we sat in the middle: streamlining communication between the client PMO and the internal teams, maintaining transparency through weekly reporting, and coordinating the operational detail (onboarding, equipment and travel) that otherwise leaks into delivery time. When both sides trust the same version of progress, escalations get faster and surprises get rarer. The teams met their deadlines and the client's satisfaction was strong." }, { "question": "How do you keep a programme moving through staff changes?", "answer": "Treat transitions as an operational discipline. The YNAP re-platform ran for 12 months across five agile teams, and staff transitions were part of the terrain, so we managed onboarding logistics and equipment centrally. A new joiner arrived to a working setup and a clear picture of the programme, not a fortnight of finding their feet. Weekly reporting and streamlined communication with the client PMO did the rest, and delivery stayed efficient enough to meet strict client deadlines throughout." }, { "question": "Do you have large-scale e-commerce delivery experience?", "answer": "Yes. We spent 12 months providing the Scrum Master and PMO backbone on YOOX NET-A-PORTER's £1bn re-platform to IBM WebSphere Commerce, coordinating five agile teams against strict client deadlines that were met. That is e-commerce delivery at serious scale. Staff transitions, onboarding logistics, equipment and travel were handled centrally, communication between the client PMO and the delivery teams ran through one streamlined route, and progress stayed transparent through weekly reporting. The programme closed with strong client satisfaction, which at that size is a statement about coordination more than about any one team." }, { "question": "Did the YNAP re-platform hit its deadlines?", "answer": "They did. The teams met the client's deadlines with a high standard of collaboration, and tight operational processes produced a well-executed project and strong client satisfaction. At £1bn scale that is not luck. Five agile teams shared one operating rhythm, communication between the client PMO and the delivery teams ran through a single streamlined channel, and weekly reporting kept progress transparent enough that problems surfaced while they were still cheap. Deadlines hold when coordination is somebody's actual job. That is what the 12-month Scrum Master and PMO engagement existed to do." }, { "question": "Does a retail AI operating model have to cover our delivery partners?", "answer": "If a partner does the building, yes. A retail AI operating model that stops at your own org chart leaves the busiest seam in the programme undesigned, because decisions, dependencies and reporting all have to cross it anyway. YOOX NET-A-PORTER's £1bn e-commerce re-platform was delivered by Salmon across five agile teams, and the coordination backbone was scoped to cover both sides of that boundary rather than the client's side alone. Across 12 months the teams met strict client deadlines and the programme closed with strong client satisfaction. Agents change who does the work, not who has to agree the picture." }, { "question": "What does a PMO take off a delivery team's plate?", "answer": "Everything that keeps the programme running but does not build anything. On YOOX NET-A-PORTER's £1bn re-platform the PMO layer above the five agile teams owned cross-team dependencies, onboarding logistics, equipment and travel coordination, so a team's own hours went into delivery. Nobody on those teams was chasing kit for a new joiner or assembling a status pack. Weekly reporting came from that layer too, and the client PMO saw one version of progress instead of five. The teams met strict client deadlines across 12 months on that split. Where nobody owns that work, five teams end up doing it badly in the margins." }, { "question": "How does a PMO hold teams to a date without line authority?", "answer": "By making the state of the work visible rather than by issuing instructions. A Scrum Master and PMO backbone manages nobody's people, which was our position across the five agile teams delivering YOOX NET-A-PORTER's £1bn re-platform. What we had instead was one operating rhythm, weekly reporting the client and the delivery teams both trusted, and a single streamlined route for questions between the client PMO and the teams. A dependency or a slip that is visible in the week it happens gets handled by the people who own it, long before it needs an escalation. That held for 12 months against strict client deadlines." }, { "question": "What breaks first when a programme grows past two or three teams?", "answer": "The shared picture, long before the code does. Two teams keep each other honest in a corridor. At five, on something the size of YOOX NET-A-PORTER's £1bn re-platform, dependencies surface late, each team reports progress in its own dialect, and a question to the client takes a different route every time. Nothing looks broken from inside a team, so it tends to get found at a deadline. That is why coordination on that programme was a dedicated Scrum Master and PMO job for 12 months rather than something five team leads squeezed in, and the teams met their deadlines with strong client satisfaction at the close." }, { "question": "Do five agile teams all need the same sprint cadence?", "answer": "No, and forcing it usually solves the wrong problem. On YOOX NET-A-PORTER's £1bn re-platform each of the five agile teams kept its own cadence, because agile facilitation sat inside the teams while the PMO layer above them owned reporting and dependencies. What has to be common is the reporting rhythm and the definition of progress, so the client PMO sees one version of the programme rather than five partial ones. Weekly reporting did that job for 12 months and the teams met strict client deadlines throughout. The alignment that matters sits in the reporting layer, not in a shared sprint calendar." } ] } In the Salmon-delivered YOOX NET-A-PORTER ecommerce replatforming programme, James provided Scrum Master and PMO coordination across five agile teams. The work connected the client PMO, team delivery and onboarding logistics against fixed client deadlines. Role period: March 2016 to May 2017. Wider published Salmon role period. The case describes twelve months of delivery coordination and PMO work. Programme scale: A £1bn replatforming programme. This is the programme's scope, not Tenhaw fees, savings or value solely attributable to this role. Direct contribution: Scrum Master and PMO coordination across five agile teams, reporting, onboarding, equipment and travel logistics. Result: Teams met client deadlines with coordinated communication and operating processes across client and supplier. Explore ecommerce delivery and AI applications: https://tenhaw.com/sectors/retail-consumer See multi-team programme management: https://tenhaw.com/services/programme-management ## Running agile at the top: a Scrum Master for the CIO's executive team Source: https://tenhaw.com/case-studies/hsbc-executive-ways-of-working Last updated: 2026-11-05 { "slug": "hsbc-executive-ways-of-working", "client": "HSBC", "logo": "/logos/hsbc.svg", "duration": "3 months", "title": "Running agile at the top: a Scrum Master for the CIO's executive team", "summary": "James gave HSBC's executive team a delivery rhythm, and annual planning finished ahead of schedule for the first time in years.", "metrics": [ { "value": "150+", "label": "global teams in scope" }, { "value": "$102M", "label": "operating budget" }, { "value": "Days, not weeks", "label": "to clear blockers" } ], "challenge": "HSBC's CIO and ExCo had no shared mechanism to track and manage critical strategic initiatives. Visibility was poor, milestones slipped, blockers persisted without escalation, and confidence in the function's ability to deliver had eroded across 150+ teams and a $102M budget.", "approach": "Operating effectively as a Scrum Master for the executive team, James designed a lightweight governance model around a live Kanban of all work, planned initiatives, and dependencies. He introduced daily executive stand-ups, removed obstacles directly, and established a review and planning cadence that created a common language across technology, operations, and transformation.", "outcome": "Executive alignment and decision speed improved sharply. Annual planning completed ahead of schedule for the first time in years, C-suite visibility increased, delivery cadence stabilised, and blockers that once took weeks were routinely cleared in days.", "agenticLens": "Agentic transformation lives or dies in the executive room, and this is the operating discipline an Embedded Agentic Lead installs at the top: visible work, fast decisions, and accountability that holds. What transfers is that discipline rather than the scale: the $102M and the 150+ teams are scope, not authority.", "faq": [ { "question": "Does agile work at executive level, or only for delivery teams?", "answer": "It works, and HSBC is the proof we point to. The CIO's executive team had no shared mechanism to track strategic initiatives across 150+ teams, so James ran the group the way a Scrum Master runs a squad: a live Kanban of all work and dependencies, daily executive stand-ups, and a review and planning cadence that gave technology, operations and transformation a common language. Decision speed improved sharply and annual planning finished ahead of schedule for the first time in years. The ceremonies scale up well; what changes is the size of the decisions moving across the board." }, { "question": "What does a Scrum Master for an executive team actually do?", "answer": "The same job as at team level, aimed at bigger blockers. At HSBC, James designed a lightweight governance model around a live Kanban showing all work, planned initiatives and dependencies. He ran the daily executive stand-ups. When something was in the way he went and removed it himself, and he set a review and planning cadence that gave technology, operations and transformation one language for progress. Judge the role by what stops sitting still. Blockers that had persisted for weeks were routinely cleared in days, and C-suite visibility across a $102M operating budget went from poor to live." }, { "question": "Do executives have time for a daily stand-up?", "answer": "They have time for the alternative even less. Before the daily rhythm, HSBC's executive team was losing weeks to blockers that persisted without escalation and to milestones slipping quietly out of view. The stand-up ran against a live Kanban of initiatives and dependencies, and it turned that around. Blockers that once took weeks were routinely cleared in days and decision speed improved sharply. A daily meeting that exists to clear obstacles pays for itself the first time it saves an initiative a fortnight of drift. At HSBC the cadence stabilised delivery around it." }, { "question": "How do you give a CIO visibility across 150 teams?", "answer": "Not with more reporting. At HSBC, 150+ global teams and a $102M operating budget sat in scope with no shared mechanism to track strategic initiatives. The answer was one live Kanban holding all work, planned initiatives and dependencies, wrapped in a deliberately lightweight governance model. The executive rhythm then ran on that board every day. Nobody was reconciling status decks for it. C-suite visibility increased and delivery cadence stabilised. You want one source of truth that stays current because leadership works from it, and not a reporting layer that goes stale between steering committees." }, { "question": "Why does annual planning always overrun, and what fixes it?", "answer": "It overruns because the cycle starts without knowing the current state. Initiatives are untracked, dependencies are invisible, blockers are unresolved, and so the first weeks go on reconstructing reality before anyone can decide anything. At HSBC the fix was structural. Once the executive team had a live Kanban of all work and dependencies, daily stand-ups and a standing review and planning cadence, annual planning completed ahead of schedule for the first time in years. Planning got faster because the inputs were visible and already agreed before the planning window opened." }, { "question": "How do you clear blockers that have sat for weeks?", "answer": "Escalate them daily, in a room where the people who can remove them are present. At HSBC, blockers persisted for weeks because nothing surfaced them and nobody owned their removal. The model James installed put them on the executive team's live Kanban and raised them at a daily stand-up in front of the CIO's leadership group, with someone in the room whose job was to go and remove obstacles directly. Under that rhythm, blockers that once took weeks were routinely cleared in days. Most blockers are not hard problems. They are unowned ones." }, { "question": "How long does it take to change how an executive team works?", "answer": "Three months, in the engagement this page describes. That covered designing the lightweight governance model, standing up the live Kanban of initiatives and dependencies, embedding daily executive stand-ups and establishing the review and planning cadence, all inside a function of 150+ global teams and a $102M operating budget. The results landed in the same window. Decision speed improved sharply, blockers that had taken weeks were cleared in days, and annual planning finished ahead of schedule for the first time in years. Executive habits change faster than organisational ones, because the group is small and it meets every day." }, { "question": "How do you rebuild executive confidence in a delivery organisation?", "answer": "By making the work visible and the rhythm reliable, then letting results do the persuading. At HSBC, confidence in the function's ability to deliver had eroded. Milestones slipped, blockers sat unescalated, and the CIO's executive team had no shared view of critical initiatives. James put every initiative and dependency on one live Kanban, ran daily executive stand-ups against it, and removed obstacles directly. Within three months alignment and decision speed had improved sharply and delivery cadence had stabilised. Confidence follows evidence. A leadership team that can watch delivery happening stops needing to be reassured about it." }, { "question": "Why do Tenhaw's case studies include work James did at HSBC?", "answer": "Because you are buying the person as much as the company. James Rooney leads every Tenhaw engagement personally, so what he delivered inside HSBC's executive team in his own delivery and transformation career is direct evidence of what you get. This study is founder track record rather than work delivered under the Tenhaw banner, and James is named throughout it because the work was his. Engagements such as Anglo American, Yondr and Greggs were Tenhaw deliveries; HSBC was James inside the bank. We will walk through which is which on a call if the distinction matters to your procurement." }, { "question": "What has executive ways of working got to do with AI transformation?", "answer": "Everything except the technology. Agentic transformation lives or dies in the executive room, and this engagement installed what an Embedded Agentic Lead installs at the top of an agentic programme. Visible work on one live board, fast decisions at a daily cadence, and accountability that holds. So the evidence here is that James has run that operating discipline inside the executive team of a global bank, and that is the room where an AI programme's funding, priorities and blockers get decided." }, { "question": "What does a banking AI target operating model need from the executive team?", "answer": "It needs a rhythm it can be run on, and not just sign-off. A banking AI target operating model usually arrives well argued and then stalls in the executive layer, because that is where the money and the priorities really move. At HSBC, the CIO's executive team had no shared mechanism for tracking critical strategic initiatives across 150+ global teams and a $102M operating budget. Operating effectively as a Scrum Master for that team, James put every initiative and dependency on one live Kanban, ran daily executive stand-ups and removed obstacles directly. Decision speed improved sharply and blockers that once took weeks were cleared in days. Three months in, annual planning finished ahead of schedule for the first time in years." }, { "question": "How do you stop technology and operations tripping over each other?", "answer": "Put the dependencies where both can see them, then give both the same cadence. At HSBC, the CIO's executive team had no shared mechanism for tracking critical strategic initiatives, so milestones slipped and blockers sat unescalated in the gaps between functions, owned by neither. James built the fix around one live Kanban of all work, planned initiatives and dependencies, daily executive stand-ups, and a review and planning cadence that created a common language across technology, operations and transformation. Decision speed improved sharply, delivery cadence stabilised, and blockers that once took weeks were routinely cleared in days. Functions rarely fall out over priorities. They fall out over dependencies nobody could see." }, { "question": "Is an executive Scrum Master just a chief of staff by another name?", "answer": "The overlap is real, and the difference is that one is a post and the other is a mechanism. A chief of staff is a permanent role built around a single leader. What James installed at HSBC was a small set of artefacts the executive team itself ran on: a live Kanban of all work, planned initiatives and dependencies, daily executive stand-ups, a review and planning cadence that gave technology, operations and transformation one language, and someone removing obstacles directly rather than logging them. Three months in, blockers that once took weeks were clearing in days and annual planning finished ahead of schedule for the first time in years. Install the rhythm first, then decide who holds it permanently." }, { "question": "How do you stop an executive stand-up becoming another status meeting?", "answer": "Give it one job. The stand-up exists to move work that is stuck, and at HSBC it ran against a live Kanban holding all work, planned initiatives and dependencies, so nobody spent the meeting reporting a position everyone could already see. The governance model around it stayed deliberately lightweight, so it never became a second reporting layer. The other half is accountability. Obstacles were removed directly, so raising one led somewhere, and the group judged itself on movement instead of attendance. In that function, blockers that had persisted for weeks were routinely cleared in days, decision speed improved sharply and delivery cadence stabilised. A meeting that has changed nothing by Thursday is a status round, whatever it is called." }, { "question": "How much does it cost to have someone run an executive delivery rhythm?", "answer": "At Tenhaw's published pricing that shape of work is Programme and Delivery Management, £18k–£35k a month, bought on its own with no requirement that Tenhaw builds any of the programme. The figures come off a published rate card: partner £1,560 a day, senior practitioner £1,250, associate £950, excluding VAT, at twenty billable days a month. The HSBC engagement predates Tenhaw and was James inside the bank in a delivery and transformation role, so read the price as what the same three months would be sold at today. Every month is expected to deliver measurable value, and a month that delivers none is reported as a failed month." } ] } In a role inside HSBC, James acted as Scrum Master for a CIO and executive committee. He introduced a live Kanban, daily executive stand-ups and a planning/review rhythm. Annual planning finished ahead of schedule for the first time in years. Role period: August 2024 to November 2025. The wider HSBC role contained several workstreams. This write-up covers three months of executive ways-of-working work. Direct role: The CIO and executive committee's delivery rhythm, tracking, escalation and planning. Organisational scope: 150-plus global teams and a $102M operating budget. These describe the function's scale, not James's sole delivery authority. Observed result: Annual planning completed early and blockers that had taken weeks were routinely cleared in days. Explore programme governance: https://tenhaw.com/services/programme-management Read the HSBC target operating model case: https://tenhaw.com/case-studies/hsbc-gps-operating-model ## Testing voice summaries and insights inside HSBC Source: https://tenhaw.com/case-studies/hsbc-voice-insights-ai Last updated: 2026-11-05 { "slug": "hsbc-voice-insights-ai", "client": "HSBC", "logo": "/logos/hsbc.svg", "duration": "3 months", "title": "Testing voice summaries and insights inside HSBC", "summary": "James led the proof of concept that turned millions of hours of unstructured voice data into automated intelligence.", "metrics": [ { "value": "Working PoC", "label": "voice-insights prototypes led by James inside HSBC" }, { "value": "NLP + sentiment", "label": "analysis and entity recognition applied to enterprise voice data" }, { "value": "3 months", "label": "completed proof-of-concept workstream inside HSBC" } ], "challenge": "Across HSBC, millions of hours of calls and meetings were captured but never analysed. Insight about customers, inefficiency, and risk was buried in voice data while manual note-taking drained staff time. The task was to turn that data into usable intelligence with privacy, accuracy, and scale intact.", "approach": "Joining HSBC's Innovation Portfolio to lead an AI-led Voice Insights platform, James translated business problems into deliverable AI capability, combining natural language processing, sentiment analysis, and entity recognition. The team built prototypes that auto-generated meeting summaries, detected emerging themes, and surfaced real-time dashboards, while coordinating innovation, operations, and risk for adoption readiness.", "outcome": "The proof of concept showed potential to remove 1.5M+ hours of manual administration annually and proved voice data could become a new source of business intelligence, shaping the bank's strategic direction on AI platforms.", "agenticLens": "The engineering transfers: natural language processing, sentiment analysis and entity recognition applied to enterprise voice data inside a regulated bank, with innovation, operations and risk in the room from the start. James led the work inside HSBC. The platform reached proof of concept, with a projected saving of 1.5M+ hours of administration a year.", "techLine": "NLP, sentiment and entity recognition over enterprise voice data. Proof of concept.", "faq": [ { "question": "Is voice analytics experience relevant to building AI agents?", "answer": "Yes. The HSBC Voice Insights proof of concept applied natural language processing, sentiment analysis and entity recognition to enterprise voice data inside a regulated bank, with innovation, operations and risk in the room from the start. Those disciplines also matter in agentic systems: extracting reliable structure from messy language, keeping privacy and accuracy in the design, and building alongside the people who own the controls. James led the work inside HSBC, and the study provides proof-of-concept engineering evidence in that regulated environment." }, { "question": "Is the 1.5 million hours a year figure at HSBC a real saving?", "answer": "It is a projected saving. The proof of concept demonstrated how natural language processing, sentiment analysis and entity recognition could reduce manual administration, note-taking and summarising across millions of hours of recorded calls and meetings. At HSBC's scale, the projected reduction was 1.5M+ hours a year. The figure describes the potential shown by the proof of concept rather than a measured saving." }, { "question": "What did the HSBC voice insights proof of concept actually build?", "answer": "Working prototypes, not slideware. The build combined natural language processing, sentiment analysis and entity recognition over enterprise voice data, and shipped prototypes that auto-generated meeting summaries, detected emerging themes across conversations, and surfaced real-time dashboards. The point was to turn millions of hours of captured but unanalysed calls and meetings into usable intelligence, with privacy, accuracy and scale treated as requirements rather than afterthoughts. The study's own label for it is a proof of concept shipped, not theorised." }, { "question": "Did HSBC's voice insights platform go into production?", "answer": "No. It reached proof of concept. The work showed that voice data could become a new source of business intelligence inside a regulated bank and helped shape HSBC's strategic direction on AI platforms. James led the work inside HSBC, combining natural language processing, sentiment analysis and entity recognition in working prototypes." }, { "question": "How was privacy handled when analysing HSBC's voice data?", "answer": "Privacy was in the task definition from the start, not retrofitted. The brief was to turn recorded calls and meetings into usable intelligence with privacy, accuracy and scale intact, so the constraint sat alongside the capability and never arrived as a late objection. In practice that meant coordinating innovation, operations and risk throughout the build, so the people who would have to approve adoption were shaping the work while it was being made. The detailed controls are HSBC's own. The operating pattern is the part that travels. In a regulated estate, adoption readiness gets built with the risk function, not presented to it." }, { "question": "What insight is hiding in a bank's recorded calls and meetings?", "answer": "Customer insight, operational inefficiency and risk signals, in HSBC's case buried across millions of hours of voice data that was captured but never analysed. Every call and meeting held information about what customers wanted, where processes were failing and where risk was emerging, and none of it was reachable because the only extraction method was a person taking notes. That is the shape of the problem in most large organisations: the data already exists and is already being recorded, so the cost is not collection but analysis. The HSBC proof of concept showed the analysis could be automated with natural language processing, sentiment analysis and entity recognition." }, { "question": "Why involve risk and operations before an AI prototype is finished?", "answer": "Because a prototype that risk sees for the first time when it is finished is a prototype that stalls. On the HSBC Voice Insights work, innovation, operations and risk were coordinated throughout the build, so the platform was moving towards adoption readiness while it was still being made rather than queuing for approval afterwards. In a regulated bank that is the difference between a demonstration and a candidate for deployment. Tenhaw carries the same pattern into agentic work now. The people who own the controls are in the room from the start, because retrofitting their requirements is slower than building to them." }, { "question": "Can voice data become a source of business intelligence?", "answer": "Yes, and the HSBC proof of concept demonstrated it inside a major regulated bank. Applying natural language processing, sentiment analysis and entity recognition to enterprise voice data produced auto-generated meeting summaries, emerging-theme detection and real-time dashboards, turning a passive archive of recorded calls and meetings into intelligence the business could act on. At HSBC's scale the projection was 1.5M+ hours a year of manual administration removed. If your calls and meetings are already recorded then the raw material exists. The analysis layer that reads it can be built and shipped, and three months at HSBC produced one." }, { "question": "How long did the HSBC voice insights proof of concept take?", "answer": "Three months, from James joining HSBC's Innovation Portfolio to a shipped proof of concept with working prototypes over enterprise voice data. For comparison, Tenhaw's current Agentic Proof of Concept is a fixed £20k–£55k and runs two to four weeks, a pace today's models and tooling make possible. What has not changed is the shape of the outcome. Both end in a working system you can judge with your own eyes, not a paper recommending one." }, { "question": "Can one proof of concept change a bank's AI strategy?", "answer": "It did at HSBC. The Voice Insights proof of concept proved that voice data could become a new source of business intelligence, and that evidence shaped the bank's strategic direction on AI platforms. It carried that weight because it was shipped, not theorised. The case rested on working prototypes running over real enterprise voice data, and innovation, operations and risk had been coordinated throughout the build, so the result arrived with adoption readiness attached instead of a queue of unanswered objections. A working prototype changes a strategy conversation in a way no deck can. That is why Tenhaw's own AI Readiness Audit ends in working prototypes." }, { "question": "Why not just use the meeting summariser in our conferencing tool?", "answer": "For a single meeting, use it. The HSBC AI Voice Insights proof of concept sat a layer above that, applying natural language processing, sentiment analysis and entity recognition across an estate where millions of hours of calls and meetings were captured but never analysed, and shipping prototypes that auto-generated summaries, detected emerging themes and surfaced real-time dashboards. A built-in summariser tells you what was said in the room you were already in. Reading the whole archive tells you what customers keep raising, where processes are failing and where risk is building. The study describes that as the insight buried in voice data. Both are uses of personal data, so the smaller tool does not remove the privacy work." }, { "question": "Why analyse recorded calls when we already survey our customers?", "answer": "Because the conversation happens first, and almost none of it reaches you. At HSBC, millions of hours of calls and meetings were captured but never analysed, with insight about customers, inefficiency and risk sitting inside them, unreachable because the only extraction method was a person taking notes. A survey gives you the people who chose to answer, after the event, in your words. The recorded estate is everyone who called, in theirs. What the proof of concept established is that voice data could become a new source of business intelligence, with natural language processing, sentiment analysis and entity recognition doing the reading no team could do by hand." }, { "question": "What does entity recognition actually do on a customer call?", "answer": "It turns the specifics of a conversation into things you can count. Natural language processing gives you structure and sentiment analysis gives you tone, but entity recognition is what pulls out the names, products, amounts and references a call contains, so a stretch of speech becomes something you can group, filter and trend. At HSBC the three were used together over enterprise voice data. That combination is what made emerging-theme detection and real-time dashboards possible. Without it you have a searchable pile of words. The same extraction lets a write-up be generated instead of typed, and that is where the projected 1.5M+ hours a year of manual administration sat." }, { "question": "Should we start with meeting summaries or trend dashboards?", "answer": "Summaries, usually, because that is where the removable administration sits and the people whose calls are analysed feel it immediately. The HSBC figure of 1.5M+ hours a year came from manual note-taking and summarising, and it remains a projection. That platform reached proof of concept and went no further. Themes and dashboards are worth more over a longer run, since they tell you what is rising across the whole estate and not just what happened in one conversation, but they only pay if someone in operations has already decided what they will do with the answer. At HSBC all three shipped inside a three-month proof of concept, so sequencing is rarely the real constraint." }, { "question": "Do you need to analyse every call, or is a sample enough?", "answer": "A sample tells you what was happening. The whole estate tells you what is changing. Emerging-theme detection, one of the prototypes the HSBC proof of concept shipped, only means something if new themes can be spotted as they rise, and that needs continuous coverage. A quarterly slice will not do it. Scale sat in the brief for that reason, alongside privacy and accuracy, because the value was locked in millions of hours of calls and meetings that were captured but never analysed. Sampling is still the sensible way to start, on your own recordings, while you test whether the analysis holds up before you commit to the full pipeline." } ] } Inside HSBC's Innovation Portfolio, James led a three-month AI Voice Insights proof of concept. Working prototypes used natural language processing, sentiment analysis and entity recognition to create summaries, themes and dashboards from enterprise voice data. Role period: August 2024 to November 2025. The published period covers the wider HSBC role; this proof-of-concept workstream ran for three months. Input and output: Enterprise calls/meetings became summaries, detected themes and dashboards through working prototypes. Role: James led the work inside HSBC, coordinating innovation, operations and risk for adoption readiness. Stage and projection: Proof of concept. The case's 1.5M-plus annual hours is a business-case projection, not a realised bank-wide saving. The original projection's call-volume and manual-effort inputs are not published in this case. The headline therefore describes the tested capability; the projection remains explicitly identified in the historical account. Explore internal AI assistants: https://tenhaw.com/use-cases/enterprise-ai-assistants Scope a proof of concept and a separate production decision: https://tenhaw.com/services/agentic-proof-of-concept ## Designing the target operating model for 500 teams and a $450M portfolio Source: https://tenhaw.com/case-studies/hsbc-gps-operating-model Last updated: 2026-11-05 { "slug": "hsbc-gps-operating-model", "client": "HSBC", "logo": "/logos/hsbc.svg", "duration": "6 months", "title": "Designing the target operating model for 500 teams and a $450M portfolio", "summary": "James co-led the design, piloting and refinement of HSBC Global Payment Solutions' target operating model for an intended 500-team, $450M scope. His work is complete; the wider global rollout is in progress.", "metrics": [ { "value": "500", "label": "teams in the intended operating-model scope" }, { "value": "$450M", "label": "portfolio scope of the model James co-designed" }, { "value": "In progress", "label": "global rollout; James's design and pilot work is complete" } ], "challenge": "HSBC's Global Payment Solutions division had no consistent operating model across 500 teams and a $450M budget. Every region had its own processes, creating fragmented delivery, unclear ownership, and unpredictable outcomes with little leadership visibility.", "approach": "Brought in as Delivery Lead, James co-led the design, piloting, and refinement of a new target operating model with select GPS teams: standardised roles, governance and reporting; agile practices tailored for product delivery at scale; and metrics and dashboards for progress, dependencies, and value. The model was tested against real-world feedback with executive alignment throughout.", "outcome": "The pilots validated the model with improved predictability, clear ownership and faster decisions. Blockers and dependencies surfaced earlier. James's design and pilot work is complete, and the wider global rollout is in progress. The case does not claim a completed rollout across all 500 teams.", "agenticLens": "The relevant practice is operating-model design: defining roles, governance, reporting and value metrics with the teams that will use them. James co-led design, pilots and refinement inside HSBC. His work is complete, while the wider global rollout remains in progress.", "faq": [ { "question": "Was the HSBC payments operating model a Tenhaw engagement?", "answer": "No. James Rooney, Tenhaw's founder, was brought into HSBC's Global Payment Solutions division as Delivery Lead and co-led the design, piloting and refinement of the target operating model over six months. It sits on the site as founder track record, alongside his other delivery and transformation roles at HSBC, rather than as work delivered under the Tenhaw banner. The discipline it demonstrates is the one Tenhaw sells today. Designing an operating model at bank scale and then piloting it is a different job from drawing one on a slide." }, { "question": "How do you design one operating model for 500 teams?", "answer": "You start with a handful of the 500. At HSBC's Global Payment Solutions division, a $450M portfolio, James co-led the design with select GPS teams first: standardised roles, governance and reporting, agile practices tailored for product delivery at scale, and metrics and dashboards covering progress, dependencies and value. The model was then piloted and refined against real-world feedback, with executive alignment maintained throughout. Pilots validated it, and the framework is fully designed and tested ahead of its global rollout now in progress. Get the model right with a few teams before you ask hundreds to adopt it." }, { "question": "Why pilot an operating model before rolling it out?", "answer": "Because an operating model that has only lived on a slide has never met a real team. At HSBC Global Payment Solutions, the target operating model was piloted with select teams and refined against real-world feedback before any global commitment. The pilots did two jobs. They validated the model, showing improved predictability, clear ownership and faster decisions, and they surfaced blockers and dependencies earlier. That evidence is what turns a 2026 rollout across 500 teams into a controlled step. Without it you are asking 500 teams to take a leap of faith." }, { "question": "Has the HSBC payments operating model rolled out yet?", "answer": "Global rollout is in progress. James's design and pilot work is complete. The evidence in this case comes from selected teams testing and refining the model, including clearer ownership, improved predictability and faster decisions. The 500 teams and $450M describe the intended programme scope, not a completed global rollout." }, { "question": "What goes wrong when every region runs its own delivery processes?", "answer": "HSBC's Global Payment Solutions division is a concrete example. Across 500 teams and a $450M budget there was no consistent operating model. Every region ran its own processes, which produced fragmented delivery, unclear ownership and unpredictable outcomes, and leadership had little visibility into any of it. The cost is not only inefficiency. It is that nobody can say who owns a decision or when work will land. The fix was one target operating model with standardised roles, governance and reporting, piloted with select teams and refined on real feedback before a global rollout." }, { "question": "What did six months of operating model work at HSBC cover?", "answer": "Design, piloting and refinement of one target operating model. Brought in as Delivery Lead, James co-led the work for HSBC's Global Payment Solutions division: standardised roles, governance and reporting, agile practices tailored for product delivery at scale, and metrics and dashboards for progress, dependencies and value. The model was then tested with select GPS teams against real-world feedback, with executive alignment maintained throughout. By the end, pilots had validated it and the framework was fully designed and tested, ready for global rollout now in progress." }, { "question": "How do you keep executives aligned during an operating model redesign?", "answer": "Keep the alignment continuous. At HSBC Global Payment Solutions, executive alignment was maintained right through the design, piloting and refinement of the target operating model, so leaders watched it evolve against real-world feedback instead of being handed a finished document to approve. Then the pilots gave them results to look at, with improved predictability, clear ownership, faster decisions, and blockers and dependencies surfacing earlier. An executive who has seen a model survive contact with real teams needs far less persuading than one reading about it for the first time." }, { "question": "What should an operating model's dashboards actually measure?", "answer": "Three things: progress, dependencies and value. That was the metrics layer built into HSBC Global Payment Solutions' target operating model, alongside standardised roles, governance and reporting, in a division of 500 teams and a $450M budget that previously gave leadership little visibility. In pilots, that visibility showed up as improved predictability, clear ownership and faster decisions, with blockers and dependencies surfacing earlier. A dashboard that tracks activity tells you people are busy; one that tracks progress, dependencies and value tells you whether the portfolio is actually moving." }, { "question": "What does payments operating model work have to do with agentic AI?", "answer": "The transferable part is the operating model discipline itself. You define roles, governance, reporting and value metrics once, so the fifty-first team to adopt a capability is cheap instead of a fresh negotiation. That is the problem an AI programme hits at scale, where every new team otherwise renegotiates ownership, oversight and measurement from scratch. The study is honest about its limit. The model was piloted and validated against real feedback, and nothing in it has been through a global rollout yet, let alone an agentic one. Tenhaw's agentic design work applies the same discipline to organisations putting agents into real workflows." }, { "question": "Does agile actually work across hundreds of teams in a bank?", "answer": "It works when it is tailored, and it fails when it is transplanted. In HSBC's Global Payment Solutions division, agile practices were adapted for product delivery at scale and embedded in a wider target operating model with standardised roles, governance and reporting. Nobody rolled out an off-the-shelf framework. Piloted with select teams and refined on real-world feedback, the result was improved predictability, clear ownership and faster decisions, with blockers and dependencies surfacing earlier. The scale is the notable part. That model is designed for 500 teams and a $450M operating budget, with global rollout in progress." }, { "question": "Is a banking AI target operating model worth it for a smaller bank?", "answer": "Yes, because scale is not what makes one work. A banking AI target operating model is mostly a set of decisions you want to make once: roles, governance and reporting, and metrics for progress, dependencies and value. At HSBC's Global Payment Solutions division those decisions were co-designed with select teams, piloted and refined against real-world feedback before anything global was committed, so the working unit was a handful of teams even though the scope was 500 teams and a $450M budget. The HSBC model covered payments delivery. Agents were not in its scope. The components travel down to twenty teams without much trouble." }, { "question": "How do you get teams to give up processes they built themselves?", "answer": "Design the replacement with some of them, not for all of them. At HSBC Global Payment Solutions, James was brought in as Delivery Lead and co-led the target operating model with select GPS teams, piloting it and refining it against real-world feedback, so the version now due for global rollout now in progress has already been changed by the people who used it. The pilots gave teams a reason to move as well, with improved predictability, clear ownership, faster decisions, and blockers and dependencies surfacing earlier. People give up a process they built when the replacement visibly makes their week easier. That is a different argument from a mandate." }, { "question": "What should you standardise first when every team delivers differently?", "answer": "Roles and ownership, before process. Across HSBC's Global Payment Solutions division the deeper problem was not that 500 teams worked differently; it was that nobody could say who owned a decision, so outcomes were unpredictable and leadership had little visibility across a $450M budget. The target operating model addressed that directly: standardised roles, governance and reporting, with agile practices tailored for product delivery at scale and metrics and dashboards for progress, dependencies and value alongside. In the pilots, clear ownership showed up next to improved predictability and faster decisions. Standardise a process before its owner and you get compliance without accountability." }, { "question": "What should we ask a firm proposing an operating model redesign?", "answer": "Ask which teams will pilot it and what the pilot changed. A model that has never met a real team is a document. At HSBC's Global Payment Solutions division the target operating model was co-designed with select GPS teams, piloted, and refined against real-world feedback, and the pilots reported improved predictability, clear ownership, faster decisions and earlier sight of blockers. Then ask what the firm is not claiming yet. This study separates completed design and pilots from the global rollout now in progress. A firm that is careful about where its evidence stops is usually careful about the rest of its numbers too." }, { "question": "Should we just roll out our best region's way of working?", "answer": "Rarely. A region's process carries the context that produced it, meaning its people, its products and the history behind every exception. HSBC's Global Payment Solutions division had all of that, with every region running its own processes across 500 teams and a $450M budget. What was designed instead was one target operating model for the division: standardised roles, governance and reporting, agile practices tailored for product delivery at scale, and metrics and dashboards for progress, dependencies and value, then piloted with select GPS teams and refined on real feedback. Your strongest region is a valuable input to that design rather than the design itself." } ], "stage": "Design and pilots completed; global rollout in progress" } As Delivery Lead inside HSBC Global Payment Solutions, James co-led operating-model design, pilots and refinement with selected teams. The intended scope was 500 teams and a $450M portfolio. Global rollout is in progress; this case describes the completed design and pilot work. Role period: August 2024 to November 2025. Wider HSBC role period. This write-up covers six months of design and pilot work. Rollout status was confirmed as in progress on 5 November 2026. Design completed: Common roles, decision rights, governance, reporting and delivery practices, co-designed with executive alignment. Pilot evidence: Selected teams tested the model and fed back on ownership, predictability, decisions, blockers and dependencies. Programme status: Global rollout in progress. The 500 teams and $450M are intended programme scope, not a completed rollout or a realised financial return. Explore target operating-model design: https://tenhaw.com/services/agentic-design-team Read the definition and eight components: https://tenhaw.com/target-operating-model ## Cutting delivery lead times by 60% with agile and operational insight Source: https://tenhaw.com/case-studies/globelynx Last updated: 2026-11-05 { "slug": "globelynx", "client": "Globelynx", "duration": "9 months", "title": "Cutting delivery lead times by 60% with agile and operational insight", "summary": "We applied agile across 16 client deliveries and a major internal change, and turned operational data into decisions.", "metrics": [ { "value": "60%", "label": "reduction in delivery lead times" }, { "value": "16", "label": "client deliveries plus internal change" }, { "value": "£100k", "label": "supplier savings negotiated" } ], "challenge": "Globelynx had long delivery timelines, inconsistent coordination, and little operational insight. Teams could not prioritise effectively, and decisions across Operations, Partnerships, and Client Management lacked actionable data.", "approach": "We introduced iterative planning, stand-ups, and retrospectives across 16 client deliveries and one internal change project, coordinated timelines and dependencies, renegotiated supplier engagements to cut cost and improve performance, and continuously collated operational data into trends leadership could act on.", "outcome": "Within six months delivery lead times fell by 60%, client satisfaction rose, supplier relationships strengthened, and data-driven insight let teams make sharper strategic decisions, positioning Globelynx for scalable growth.", "agenticLens": "What transfers is the habit of baselining a process before claiming an improvement to it, and of counting the running cost of a change rather than only the cost of building it. Both habits came out of agile delivery, supplier negotiation and operational reporting, which is where an AI business case is usually won or lost long before a model is chosen.", "faq": [ { "question": "What did Tenhaw do for Globelynx?", "answer": "Globelynx is a UK media and broadcast technology business, and the engagement ran nine months across 16 client deliveries and one internal change project. We introduced iterative planning, stand-ups and retrospectives, coordinated timelines and dependencies across the workstreams, renegotiated supplier engagements, and continuously collated operational data into trends leadership could act on. Within six months delivery lead times had fallen by 60% and client satisfaction had risen, and £100k of supplier savings were negotiated." }, { "question": "How did Globelynx cut delivery lead times by 60%?", "answer": "By changing working practices, not by buying anything. Iterative planning, stand-ups and retrospectives went in across 16 client deliveries and one internal change project. Timelines and dependencies were coordinated across the lot rather than per team, and supplier engagements were renegotiated to improve performance as well as cost. Those practices produced comparable delivery data, which gave the improvement a measured baseline, and the 60% reduction was measured against it with the client over six months. Teams that previously could not prioritise effectively got operational data to prioritise with, and decisions across Operations, Partnerships and Client Management, which had lacked actionable data, got sharper." }, { "question": "Is a 60% reduction in delivery lead times believable?", "answer": "Yes, and the working behind the number is the part that matters. The reduction was measured with the client from their own delivery data over six months, against a baseline the agile practices themselves created. Iterative planning and retrospectives across 16 deliveries produced comparable data before any improvement was claimed. The limit is worth stating. This is our measurement of our own work, and it has not been independently audited. Most of the AI business cases we are shown fail earlier than that, on the missing before. A number with a measured baseline and a stated limit is a different class of claim from a number alone." }, { "question": "What transfers from a delivery engagement into agentic work?", "answer": "Two habits transfer straight into agentic work. The first is baselining a process before you claim an improvement to it, and the 60% on this page is quotable because there was a measured before. The second is counting the running cost of a change as well as the cost of building it, which is what the supplier renegotiation exercised. Nine months of agile delivery, supplier negotiation and operational reporting across 16 client deliveries and one internal change project is where both were learned. Those two habits are where the AI business cases we are shown most often fall over." }, { "question": "Where did the £100k of supplier savings at Globelynx come from?", "answer": "From renegotiating supplier engagements to cut cost and improve performance at the same time. Nothing technical about it. The outcome records supplier relationships strengthening alongside the price coming down. It sits in this study because an AI programme's cost line is never only the model, and a delivery partner who has had to defend a supplier line in a profit and loss account reads a vendor contract differently from one who has not. The commercial work is part of the delivery work, not an extra." }, { "question": "Why do AI business cases quietly fail in year two?", "answer": "Usually because the case presented a build cost and omitted the running one. Inference has a monthly bill, the vendor contracts around it renew, the human reviewers the system now needs are salaried, and the tooling nobody cancelled keeps charging. None of that appears in a business case built around the cost of reaching a working demo, so year one looks like success and year two's profit and loss tells a different story. Catching it is a commercial habit more than a technical one. Someone has to own the supplier lines, the way the Globelynx engagement did when £100k of savings came from renegotiation." }, { "question": "What would the Globelynx engagement be sold as today?", "answer": "Programme and Delivery Management, at £18k–£35k per month at published rates. That band means you can price the equivalent engagement rather than guess at it. The Globelynx shape is what that service covers: agile delivery and operational insight across many parallel workstreams, with operational data collated into trends leadership can act on. The price derives from a published rate card at twenty billable days a month, the same arithmetic behind every engagement price on the site." }, { "question": "Has Tenhaw worked with media and broadcast companies?", "answer": "Yes. Globelynx is a media and broadcast technology business in the UK, and the engagement there ran nine months: agile delivery across 16 client deliveries and one internal change, a 60% reduction in delivery lead times, and £100k of supplier savings negotiated. James also ran the visual rebrand team on the Discovery+ launch, which hit its CEO-set date, and Sky and F1 sit in his delivery and transformation background." }, { "question": "How do you give leadership operational data they will actually act on?", "answer": "Collate it continuously into trends. Do not wait for someone to ask for a report. At Globelynx, decisions across Operations, Partnerships and Client Management lacked actionable data, so operational data was gathered continuously and turned into trends leadership could act on, and the outcome credits that insight with sharper strategic decisions. The mechanism matters. A one-off report describes the past, while a maintained trend line changes the next decision. It is also the discipline an automation programme needs later, because a business that has never measured a process cannot report a saving from changing it." }, { "question": "Should we time a process before automating it?", "answer": "Yes, before anything else. The most common gap in the AI business cases we are shown is a firm proposing to automate a process it has never timed, then proposing to report the saving. The Globelynx 60% is quotable because there was a measured before, with comparable delivery data in place before any improvement was claimed. The cheapest week of an agentic programme is the one spent measuring the process you are about to change, and our four-week audit exists partly to close that gap before a build starts." }, { "question": "How do you stop internal projects being starved by client work?", "answer": "Put the internal work on the same plan and the same cadence as the client work, so it gets traded off in the open and does not slip quietly. Globelynx ran 16 client deliveries and one major internal change project together. Iterative planning, stand-ups and retrospectives covered all of it, and timelines and dependencies were coordinated across the whole set. Operational data was collated continuously into trends, so leadership could see what the internal project was costing and what it was worth, and choose deliberately. Within six months delivery lead times had fallen by 60% and client satisfaction had risen, with the internal change moving alongside the client work." }, { "question": "Does client satisfaction drop when you speed up delivery?", "answer": "It went the other way at Globelynx. Delivery lead times fell by 60% within six months and client satisfaction rose over the same period. That is what happens when the speed comes from coordination. The changes were iterative planning, stand-ups and retrospectives across 16 client deliveries and one internal change project, timelines and dependencies coordinated across the whole set, and supplier engagements renegotiated to improve performance as well as cost. Clients experience that as dates that hold and fewer late surprises. Satisfaction suffers when speed comes from cutting the checks, not when it comes from removing the waiting between them." }, { "question": "Can we take on more client work without hiring more people?", "answer": "Often yes, when the limit is coordination rather than hands. Globelynx had long delivery timelines, inconsistent coordination and little operational insight, and teams that could not prioritise effectively. What changed that was iterative planning, stand-ups and retrospectives across 16 client deliveries and one internal change project, coordinated timelines and dependencies, and operational data collated continuously into trends leadership could act on. Lead times fell by 60% within six months, which is capacity you are already paying for coming back into the business, and the study records the result as positioning Globelynx for scalable growth. If your delivery is already coordinated and instrumented, then the honest answer is headcount." }, { "question": "Should the person running delivery also negotiate with suppliers?", "answer": "Yes. Delivery and supplier negotiation are the same problem seen from two ends, and one engagement can carry both. At Globelynx supplier renegotiation sat with the delivery work and produced £100k of savings alongside the 60% reduction in delivery lead times, and supplier relationships came out stronger rather than soured. Someone coordinating 16 client deliveries knows which supplier is actually holding up which date. That is leverage a price-only conversation never has. Those renegotiations cut cost and improved performance at the same time. It carries into AI work directly, because an AI cost line is never only the model, and someone has to own the contracts around it." }, { "question": "How do you spot a dependency before it wrecks a delivery date?", "answer": "Look across the whole portfolio, not down one project. At Globelynx timelines and dependencies were coordinated across 16 client deliveries and one internal change project together, and that is where a clash actually becomes visible. Inside a single project the dependency looks like someone else's problem right up until the week it lands on yours. The other half is data. Operational information was collated continuously into trends, so a stretched team or a slipping supplier showed up as a trend before it showed up as an apology. Delivery lead times fell by 60% within six months once that coordination was in place." } ] } Across sixteen client deliveries and one internal change at Globelynx, Tenhaw introduced iterative planning, coordinated dependencies and renegotiated supplier engagements. Delivery lead times fell by 60% within six months, alongside £100k of negotiated supplier savings. Role period: June 2017 to February 2018. Delivery-flow result: 60% lower delivery lead times, measured with the client against its delivery-data baseline over six months. Commercial result: £100k supplier savings negotiated through supplier-engagement changes. This is a separate result from lead-time reduction. Scope: Sixteen client deliveries and one internal change over a nine-month engagement in media/broadcast technology. The public case reports the 60% client-data comparison, not its raw before/after durations or an independently audited result. No baseline figures are inferred here. Explore operational reporting and supplier governance: https://tenhaw.com/services/programme-management Read another media delivery case: https://tenhaw.com/case-studies/discovery-plus